nslookup działa z /etc/resolv.conf, ping i ssh nie


12

W naszej lokalnej sieci uniwersyteckiej mam (uzyskaną przez DHCP) następującą konfigurację w /etc/resolv.conf:

search a.domain.com b.domain.com domain.com
nameserver x.x.x.x
nameserver y.y.y.y

Ustawienia są również takie same w Preferencjach systemowych. Występuje następujący problem:

nslookup server

działa i używa jednego z serwerów nazw, aby poprawnie poprosić o server.a.domain.com. Jeśli jednak spróbuję pingować,

ping server

kończy się niepowodzeniem z nieosiągalnym hostem.

ping server.a.domain.com

Pracuje. Ręczne dodanie serwera z adresem ip uzyskanym przez nslookup do / etc / hosts sprawia, że ​​ping również działa, ale to „rozwiązanie” omija serwery nazw i dlatego nie jest idealne (i musiałbym dodać około 20 innych wpisów). Masz pojęcie, co to powoduje? Dlaczego ping nie korzysta z wyników nslookup / the searchdomains?

ssh server

również zawodzi, co jest prawdziwym problemem / niedogodnością.

Już dodałem AlwaysUseSearchDomains do mDNSResponder, ale ta poprawka pomaga tylko w przypadku używania server.foo.

Używam OS X Lion 10.7.3.


Pakiety ping mogą być blokowane przez sprzęt sieciowy. To samo dotyczy pakietów ssh - mogą nie chcieć, abyś robił to, co robisz.
Thorbjørn Ravn Andersen

Zobacz rozwiązanie poniżej, to nie był problem.
tholu

„Nieosiągalny host” oznacza problem z połączeniem sieciowym (lub zablokowany ICMP), a nie problem z rozpoznaniem DNS
Daniel Serodio

Odpowiedzi:


2

Czy czytałeś komentarze na górze /etc/resolv.conf?

# Mac OS X Notice
#
# This file is not used by the host name and address resolution
# or the DNS query routing mechanisms used by most processes on
# this Mac OS X system.

Prawidłowym rozwiązaniem jest dodanie domen wyszukiwania za pomocą panelu Sieć w Preferencjach systemowych, jak opisano tutaj .


Zrobiłem. Domeny wyszukiwania są automatycznie wprowadzane w panelu Sieć w Preferencjach systemowych dla konfiguracji DHCP (dlatego są wyszarzone i nie można ich zmienić). Dokładne te same wartości / konfiguracje znajdują się w / /etc/resolv.conf.
tholu

Nie wiem więc, co mam powiedzieć. Dostaję zarówno ustawienia Ethernet, jak i Wi-Fi przez DHCP i mogę zmieniać moje domeny wyszukiwania za pomocą panelu Preferencje systemowe.
Old Pro

Domeny wyszukiwania są poprawne w Preferencjach systemowych i /etc/resolv.conf - problem polega na tym, że ping i ssh go nie używają. Gdyby użyli danych wyjściowych nslookup, wszystko działałoby dobrze, ale jakoś nie działa. Jednak szukają / etc / hosts.
2012 r

Ręcznie dodałem domeny wyszukiwania (chociaż były wyszarzone) jeden po drugim za pomocą Preferencji systemowych, a teraz działa. Dzięki!
2012 r

4

Miałem ten sam problem. Rozwiązaniem, którego użyłem, było utworzenie katalogu / etc / resolver. Wewnątrz tego katalogu utwórz plik o nazwie dla każdej domeny, dla której chcesz rozwiązać. Wewnątrz każdego pliku powinny znajdować się dwie linie

nameserver 10.0.100.2
domain  home.cainmanor.com

Powyższy plik miałby nazwę / etc / resolver / home. Może trzeba go nazwać home.cainmanor.com, ale nie mogę go teraz przetestować.

Powodzenia!


Udało mi się to, ustawiając kolejno domeny wyszukiwania w Preferencjach systemowych, zastępując ustawienia DHCP, których OS X nie mógł oczywiście poprawnie przeanalizować. Nie mogłem wypróbować twojego rozwiązania, ale dzięki!
2012 r

Takie podejście działa dobrze, gdy korporacyjny klient VPN robi coś złego w odniesieniu do przejściowych preferencji systemowych.
Peter

1

Uważam, że problem leży w konfiguracji searchdomains: ping / ssh próbują użyć, gethostbyname2()co się nie udaje, ponieważ nazwany już nie działa (przynajmniej w Lionie) i /etc/resolv.confdlatego skonfigurowane searchdomains 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.

Naprawiono je ręcznie dodając domeny wyszukiwania, patrz rozwiązanie powyżej.


Gdy dodam domenę wyszukiwania do mojego połączenia Wi-Fi (które jest konfigurowane przez DNS) w OS 10.7.3 za pomocą Preferencji systemowych -> panelu Sieć, jest ona używana przez ping i ssh, tak jak się spodziewałam. Nie dotykam /etc/resolv.conf ani / etc / hosts ręcznie / bezpośrednio, ale zmiany w Preferencjach systemowych są automatycznie odzwierciedlane w /etc/resolv.conf. OS X robi wiele rzeczy inaczej niż inne systemy uniksowe i jest to jedna z nich.
Old Pro

1
Dzięki, działało to dzięki ręcznemu dodawaniu domen wyszukiwania pojedynczo, patrz mój komentarz do sugerowanego rozwiązania powyżej.
2012 r

Dodanie domen wyszukiwania nie rozwiązało problemów ... Czy ktoś jeszcze ma inne rozwiązanie?

Jak je dodałeś?
tholu

1

Ten problem pojawia się tak często, gdy mój Mac Book Pro (OS X wersja 10.10.1) śpi. Obudź się i nie mogę ssh używać nazwy hosta maszyn w mojej sieci (ping też nie działa). nslookup działa dobrze. Nie widzę żadnych istotnych komunikatów w / var / log. Zostaw to na kilka minut i hej presto, to znowu działa .....


0

Odpowiedziałem na to gdzie indziej, ponieważ była to dla mnie prosta poprawka i nigdzie indziej nie mogłem znaleźć odpowiedzi, która zadziałałaby dla mnie.

Po kilkakrotnym ponownym uruchomieniu mDNSResolver zgodnie z zaleceniami dla innych wątków:

sudo killall -HUP mDNSResponder

W końcu spróbowałem czegoś innego. Wyłączyłem Wi-Fi i usunąłem wszystkie preferowane sieci. Następnie przywróciłem połączenie Wi-Fi i wszystko działało dobrze:

  1. Menu Apple -> Preferencje systemowe -> Wi-Fi (po lewej)
  2. „Wyłącz Wi-Fi”, a następnie wybierz „Zaawansowane”
  3. Usuń połączenie Wi-Fi, z którym masz problem (lub wszystkie, jeśli chcesz). Zrób to, wybierając sieć Wi-Fi, którą chcesz usunąć, i naciskając „-”
  4. Kliknij „Zastosuj” i „OK”
  5. Ponownie włącz Wi-Fi.
  6. Wybierz sieć Wi-Fi i zaloguj się ponownie.

To w końcu dla mnie zadziałało. Prawdopodobnie powinna była to być pierwsza rzecz, której spróbowałem, ale jestem facetem od Linuksa i najpierw patrzę na poprawki konsoli.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.