Wyszukiwanie nazw DNS (był SSH) nie działa po aktualizacji Snow Leopard

Myślę, że zaczęło się to od aktualizacji Snow Leopard. Wyczyściłem katalog .ssh, nadal występuje problem.

~: uname -a
Darwin california-example-com.local 10.0.0 Darwin Kernel Wersja 10.0.0: Pt 31 lipca 22:47:34 PDT 2009; root: xnu-1456.1.25 ~ 1 / RELEASE_I386 i386

~: ssh -V
OpenSSH_5.2p1, OpenSSL 0.9.8k 25 marca 2009

~: ls -l ~ / .ssh

~: nslookup nevada
Serwer: 10.94.62.3
Adres: 10.94.62.3 # 53

Imię i nazwisko: nevada.example.com
Adres: 10.94.62.3

~: ssh nevada
ssh: Nie można rozpoznać nazwy hosta nevada: podana nazwa węzła lub nazwa serwera lub nieznana

Natrafiłem na dokładnie ten sam problem i znalazłem wątek o Macu mini mającym problemy z DNS w dyskusjach Apple'a niezwykle pomocny.

Sedno problemu: mDNSResponder wydaje się od czasu do czasu zmieniać kolejność zapytań serwerów DNS, więc jeśli najpierw zapyta serwerów DNS twojego dostawcy ISP, nie uzyska odpowiedniego rekordu (lub jeśli używasz podzielonego DNS, dostaniesz twój publiczny adres IP).

Najlepszym rozwiązaniem tego jest upewnienie się (tak jak zrobiłeś), że tylko wymagane serwery DNS są wymienione w ustawieniach DNS. Może to wymagać usunięcia serwerów DNS ISP z serwera DHCP (tak jak musiałem to zrobić - i tak wszystkie żądania są przekazywane przez lokalny serwer DNS).

Powodem, dla którego narzędzia takie jak digi nslookupodniosą sukces, jest normalne używanie BIND i /etc/resolv.confbezpośrednio w przeciwieństwie do reszty systemu operacyjnego.

Dla odniesienia w Snow Leopard pamięć podręczna DNS jest teraz przechowywana przez mDNSResponder. Aby ją wyczyścić, należy ponownie uruchomić proces za pomocą sudo killall -HUP mDNSResponder. Możesz uzyskać więcej informacji (rejestrowanie, zrzut stanu wewnętrznego itp.), Używając różnych flag do killallpolecenia.

"sudo killall -USR1 mDNSResponder" to enable operation logging.
"sudo killall -USR2 mDNSResponder" to enable packet logging.
"sudo killall -HUP mDNSResponder" to clear the DNS cache.
"sudo killall -INFO mDNSResponder" to dump mDNSRepsonder's internal state.

Źródło: Snoop Dogg w tym samym wątku.

mieliśmy takie problemy:

host example.com     <<< WORKED
ping example.com     <<< FAILED

Rozwiązany za pomocą czegoś takiego:

sudo launchctl unload -w /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist
sudo launchctl load -w /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist

Aplikacje w Mac OS X nie używają tego samego mechanizmu dla DNS, co „host / dig / nslookup”.

Przy użyciu „host / dig / nslookup” były przydatne do ustalenia, że ​​nie jest to problem z siecią. To był problem z lokalnym systemem rozwiązany za pomocą powyższych poleceń.

Wystąpił ten sam problem… I podczas ponownego uruchamiania mDNSResponder wydaje się „działać”, restartując go kilka razy co godzinę, jest do bani.

Na razie „rozwiązałem” problem, uruchamiając dnsmasq lokalnie. Aby to zrobić:

• Zbuduj dnsmasq (pobierz tgz i makelub brew install dnsmasq)
• Umieść to w dnsmasq.confpliku:

resolv-file = resolv.conf
użytkownik = nikt
grupa = nikt
interfejs = lo0
rozmiar pamięci podręcznej = 1024

• Umieść to w resolv.confpliku, który znajduje się w tym samym katalogu co dnsmasq.confplik (nb: not /etc/resolv.conf ):

serwer nazw 8.8.8.8
serwer nazw 4.2.2.1
serwer nazw 4.2.2.2

• Uruchom dnsmasqz sudo dnsmasq --no-daemon --log-queries -C dnsmasq.conf. Dane wyjściowe powinny wyglądać mniej więcej tak:

...
dnsmasq: czytanie resolv.conf
dnsmasq: korzystanie z serwera nazw 4.2.2.1 # 53
dnsmasq: korzystanie z serwera nazw 4.2.2.2 # 53
dnsmasq: przy użyciu serwera nazw 8.8.8.8 # 53
dnsmasq: odczyt / etc / hosts - 6 adresów

• Otwórz Preferencje sieciowe i upewnij się, że 127.0.0.1jest to jedyny serwer DNS (preferencje sieciowe -> zaawansowane -> DNS -> dodaj 127.0.0.1)

Wszystko powinno znów zacząć działać.

Gdy wszystko zacznie działać, możesz uruchomić dnsmasqbez opcji --no-daemoni --log-queries, więc zacznie się w tle i nie musisz otwierać okna terminalu.

Zauważyłem, że mam 10.94.62.3 na liście serwerów DNS (panel prefiksów sieci), a następnie 2 od mojego dostawcy usług internetowych. Usunąłem pozostałe 2, zmuszając wszystkie wyszukiwania nazw do 10.94.62.3 dla tej lokalizacji i teraz mogę rozpoznawać nazwy w mojej sieci, jak i poza nią.

Nie mam pojęcia, dlaczego to zadziałało.

Chyba mamy podobny problem, jak opisałem tutaj: /apple/50457/nslookup-works-ping-and-ssh-dont-os-x-lion-10-7-3

Uważam, że problem leży w konfiguracji searchdomains: ping / ssh próbuje użyć, gethostbyname2()co się nie udaje, ponieważ nazwany już nie działa (przynajmniej w Lionie) i /etc/resolv.confdlatego skonfigurowane wyszukiwarki są ignorowane. /etc/hostsjest ostatnią deską ratunku gethostbyname2()i dlatego ssh znów działa z poprawnymi wpisami w /etc/hosts. Powinien zostać naprawiony przez Apple imho.

Próbowałeś nevada-example-com.local?

dscacheutil -flushcache

To polecenie odświeża pamięć podręczną DNS.

Czy 10.94.62.3 jest zaufanym serwerem DNS? Jeśli tak, to dlaczego jest tylko jeden? Powinieneś mieć co najmniej 2 serwery DNS, do których możesz się odwoływać w celu przełączenia awaryjnego. Jeśli ten upadnie, jesteś siedzącą kaczką.

Wyszukiwanie zamówień DNS wydaje się działać inaczej w systemie Snow Leopard. Jeśli nie możesz wyszukać domeny, sprawdź, czy w preferencjach sieci nie ma żadnych nieprawidłowych serwerów DNS. Jeśli używasz standardowej konfiguracji DHCP, nie powinieneś mieć żadnych serwerów DNS na liście. Przed aktualizacją miałem na liście stary serwer DNS i nie miało to wpływu na nic. Po aktualizacji całkowicie straciłem dns.

Otwórz Preferencje sieciowe> Wybierz lotnisko> Zaawansowane. Wybierz kartę DNS i usuń wszystkie nieprawidłowe serwery DNS.

Czy patrzyłeś na konsolę? (Aplikacje -> Narzędzia -> Konsola) Może się okazać, że mDNSResponder pojawia się w: Informacje diagnostyczne i dotyczące użytkowania -> Raporty diagnostyczne systemu

Jeśli ulega awarii z powodu innego programu ładującego moduły (takiego jak Little Snitch lub Hands Off), możesz go tam zobaczyć.

Miałem ten sam problem z nslookup rozwiązujący moje okno systemu Windows, ale ping dał mi „nieznanego hosta”. Spróbowałem tego, co zasugerował Navdeep, i poszedłem usunąć serwery nazw na karcie Preferencje sieciowe-> Zaawansowane-> DNS. Nie pozwoliłoby mi ich odjąć, były wyszarzone. W końcu nacisnąłem + i zniknęły. Anulowałem dodawanie nowego i zastosowałem zmiany, gdy nie pojawiały się żadne serwery DNS. Ping zaczął potem działać. Dziwne jest to, że mój lokalny router / serwer DHCP był pierwszy na liście i jest odpowiedzialny za rozwiązanie Windows. To musi być dziwne z zamówieniem. Drugi wymieniony serwer nazw jest działającym NS i nie byłby w stanie rozwiązać hosta systemu Windows. DZIĘKI Navdeep!