Embora eu não esteja 100% esclarecido sobre o motivo pelo qual ele não funciona conforme o esperado, parece haver um conflito muito grande com o serviço mDNS (Avahi no Linux, Bonjour / Zeroconf no Mac / Windows) e redes Windows que use .local como o nome de roteamento interno para domínios. O que parece acontecer é que, ao executar o ping em server01, ele está pulando usando mDNS para resolução e, em seguida, anexando o domínio de pesquisa (foo.local) à solicitação, consultando com êxito o servidor DNS para server01.foo.local. No entanto, ao usar o mDNS (que usa .local como a extensão padrão do nome da máquina), quando você tenta executar ping no server01.foo.local, na verdade ele está transmitindo pelo mDNS procurando uma máquina com o nome "server01.foo"; quando falha, não passa para o DNS direto por qualquer motivo. Uma grande solução para isso é não nomear o domínio .local, o que provavelmente vai contra o treinamento da maioria dos administradores do Windows para estruturação de domínio. Dito isto:
Se o mDNS não tiver importância na sua rede (como é comum na empresa, que tende a executar servidores DNS dedicados versus a rede doméstica, onde o mDNS às vezes é usado), alterar a ordem de pesquisa é a solução mais fácil.
Isso pode ser encontrado em /etc/nsswitch.conf. A seção para hosts listará a ordem, que para o Fedora 16 padrão é:
hosts: files mdns4_minimal [NOTFOUND=return] dns myhostname
Se você mudar isso para:
hosts: files dns mdns4_minimal [NOTFOUND=return] myhostname
para onde você está movendo o DNS na ordem de pesquisa, isso deve corrigir as coisas por enquanto. Como alternativa, se você sabe que não precisará do mDNS, remova a parte "mdns4_minimal [NOTFOUND = return]".
Olhando para esse bug no rastreador da Red Hat , parece que esse é um problema de longa data, sem solução aparente no momento. No entanto, se alguém puder fornecer mais informações sobre por que isso acontece dessa maneira, seria apreciado.