Chociaż nie jestem w 100% przekonany, dlaczego nie działa zgodnie z oczekiwaniami, wydaje się, że istnieje bardzo duży konflikt z usługą mDNS (Avahi w Linuksie, Bonjour / Zeroconf w Mac / Windows) i sieciami Windows, które użyj .local jako wewnętrznej nazwy routingu dla domen. Wydaje się, że zdarza się, że podczas pingowania server01 pomija użycie mDNS do rozpoznawania, a następnie dołącza domenę wyszukiwania (foo.local) do żądania, pomyślnie wysyłając zapytanie do serwera DNS o server01.foo.local. Jednakże, gdy używasz mDNS (który używa .local jako domyślnego rozszerzenia nazwy komputera), kiedy próbujesz pingować server01.foo.local, w rzeczywistości transmituje przez mDNS, szukając komputera o nazwie „server01.foo”; gdy zawiedzie, z jakiegokolwiek powodu nie przechodzi do bezpośredniego DNS. Dużym obejściem tego problemu jest brak nazewnictwa domeny .local, co prawdopodobnie stoi w sprzeczności ze szkoleniem większości administratorów Windows w zakresie strukturyzowania domen. Biorąc to pod uwagę:
Jeśli mDNS nie ma znaczenia w Twojej sieci (jak to zwykle bywa w przedsiębiorstwie, które ma tendencję do uruchamiania dedykowanych serwerów DNS w porównaniu do sieci domowej, w której czasami używany jest mDNS), zmiana kolejności wyszukiwania jest najłatwiejszym obejściem.
Można to znaleźć w pliku /etc/nsswitch.conf. Sekcja dla hostów wyświetli listę kolejności, która dla Fedory 16 jest domyślna:
hosts: files mdns4_minimal [NOTFOUND=return] dns myhostname
Jeśli zmienisz to na:
hosts: files dns mdns4_minimal [NOTFOUND=return] myhostname
gdzie przesuwasz dns do przodu w kolejności wyszukiwania, to na razie powinno to naprawić. Alternatywnie, jeśli wiesz, że wcale nie będziesz potrzebować mDNS, po prostu usuń część „mdns4_minimal [NOTFOUND = return]”.
Patrząc na ten błąd w trackerze Red Hata , wydaje się, że jest to długotrwały problem bez widocznego rozwiązania w tej chwili. Gdyby ktoś mógł uzyskać więcej informacji na temat tego, dlaczego tak się dzieje, byłoby to mile widziane.