DNS nie działa w systemie Mac OS X.

100

Niektórzy z moich współpracowników mają problemy na swoich komputerach Mac - rozdzielczość DNS nie działa w systemie Mac OS X. Korzystają z systemu Snow Leopard 10.6.8. Mogą korzystać z DNS na maszynie wirtualnej z systemem Windows 7 (VMware Fusion 3.1.3) działającej w systemie OS X. Komputery to 15-calowy MacBook Pro, model z początku 2011 roku.

Rzeczy, których próbowali, a które nie zadziałały:

  • włączanie / wyłączanie lotniska
  • ponowne uruchomienie
  • za pomocą połączenia przewodowego zamiast wifi
  • usuwając poświadczenia połączenia i dodając je ponownie
  • wyłączanie zapory Mac
  • za pomocą stałego statycznego adresu IP
  • ręczne ustawienie serwerów DNS
  • restartowanie mDNSResponder
  • poprawki z tego drugiego pytania

EDYCJA odpowiedzi Odpowiedź Martína:

Czy możesz pingować DNS, którego chcesz użyć?

$ ping apple.com
ping: cannot resolve apple.com: Unknown host

Jakie są / są adresy IP serwerów DNS, których chcesz używać?

Jest to firmowy serwer DNS, który jest dostarczany z DHCP, działa dobrze dla innych osób. Wypróbowałem również wersje Google 8.8.4.4 i 205.171.3.65 (które według GRC's DNS Benchmark były najszybsze).

Czy próbowałeś używać 8.8.8.8 (google) lub któregokolwiek z OpenDNS 208.67.222.222 lub 208.67.220.220?

To nie działa, zobacz dane wyjściowe Google Chrome:

Nie można znaleźć serwera na www.apple.com, ponieważ wyszukiwanie DNS nie powiodło się. DNS to usługa sieciowa, która tłumaczy nazwę witryny na jej adres internetowy. Ten błąd jest najczęściej spowodowany brakiem połączenia z Internetem lub źle skonfigurowaną siecią. Może to być również spowodowane brakiem odpowiedzi serwera DNS lub zapory ogniowej uniemożliwiającej Google Chrome dostęp do sieci.

Czy możesz pingować te hosty?

$ ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes 64 bytes from
8.8.8.8: icmp_seq=0 ttl=58 time=3.925 ms

tworzenie pustego użytkownika

Konto użytkownika gościa zostało utworzone, problem DNS nadal występował podczas korzystania z konta gościa.

nslookup i dig oba działają dobrze

$ nslookup www.apple.com 8.8.8.8
Server:  8.8.8.8
Address: 8.8.8.8#53

Non-authoritative answer:
www.apple.com canonical name = www.isg-apple.com.akadns.net.
www.isg-apple.com.akadns.net canonical name = www.apple.com.edgekey.net.
www.apple.com.edgekey.net canonical name = e3191.c.akamaiedge.net.
Name: e3191.c.akamaiedge.net
Address: 184.24.141.15

 

$ dig @8.8.8.8 www.apple.com
; <<>> DiG 9.6.0-APPLE-P2 <<>> @8.8.8.8 www.apple.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11298
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION: ;www.apple.com.   IN A
;; ANSWER SECTION:
www.apple.com.  1041 IN CNAME www.isg-apple.com.akadns.net.
www.isg-apple.com.akadns.net. 38 IN CNAME www.apple.com.edgekey.net.
www.apple.com.edgekey.net. 8794 IN CNAME e3191.c.akamaiedge.net.
e3191.c.akamaiedge.net. 17 IN A 184.24.141.15
;; Query time: 4 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Tue Oct 4 09:25:28 2011
;; MSG SIZE  rcvd: 158

Wykonano także opróżnianie pamięci podręcznej DNS, ale to nie pomogło

sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder

EDYCJA 2 :

$ cat /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.
#
# This file is automatically generated.
#
domain {redacted}.com
nameserver 8.8.8.8
nameserver 208.67.222.222
CajunLuke
źródło
Zdarza mi się też na lwie.
dkagedal
Happening dla mnie w Mavericks,
10.9.4
Wygląda to na historyczny problem, który zepsuł życie użytkowników i administratorów sieci od Leoparda do Yosemite. Jeśli ktoś nadal widzi ten problem, zgłoś wyraźnie, jeśli masz więcej niż jeden interfejs aktywny, a ponadto otrzymujesz jego conf. z serwera DHCP (z różnych stron). Dlaczego? Nigdy nie widziałem takiego problemu na żadnym innym Uniksie i na żadnym komputerze Mac (mam dużo), ale żaden z nich nie ma więcej niż jednego interfejsu, który mówi do źródła informacji DNS.
dan
Spróbuj zmienić konfigurację DNS (zmień kolejność lub usuń wpisy), które rozwiązują ten sam problem dla mnie
mems

Odpowiedzi:

90

Okazuje się, że rozwiązaniem było odesłanie mDNSResponder:

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

Zostało to uzyskane przez innego współpracownika z tego pytania o awarię serwera .

OS X 10.10.0 - 10.10.3, Yosemite

Najwyraźniej mDNSResponder nie istnieje w Yosemite (OS X 10.10). Zamiast tego możesz ponownie uruchomić descoveryd, aby rozwiązać te problemy.

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

OS X 10.10.4+, Yosemite

W OSX 10.10.4 przywrócono mDNSResponder . Więc skorzystaj z pierwszego, zacznie działać ponownie.

CajunLuke
źródło
5
Ale to nie jest naprawdę zadowalająca odpowiedź. Muszę przede wszystkim wiedzieć, jak temu zapobiec.
dkagedal
1
@dkagedal To właściwie tak dobra odpowiedź, jak my otrzymamy - dzieje się tak, ponieważ twój Mac buforuje wpisy DNS, aby uniknąć uderzenia w serwer DNS (prawdopodobnie router) przy każdym wyszukiwaniu DNS - co zdarza się często. Ta pamięć podręczna jest niezbędna i dobra, ale byłoby miło, gdyby istniało lepsze zachowanie, gdy nie znaleziono wpisu (uważam to za błąd). W każdym razie w pamięci podręcznej jest trochę czasu; gdy czekałem około 10 minut na moim komputerze, ta sytuacja sama się rozwiązała. Dla większości użytkowników istniejące zachowanie jest w porządku, więc prawdopodobnie nie zostanie zmienione przez Apple w najbliższym czasie.
Matt
2
Oczywiście nie jest to tak dobre, jak to możliwe. Żaden inny system operacyjny nie ma tego problemu. Nie ma nic złego w DNS, rekord dla www.google.com nie zaginął, to tylko pamięć podręczna MacOS, która w jakiś sposób go zgubiła i nie chce go odzyskać. I to jest błąd, który wymaga naprawy.
dkagedal
1
Mam ten problem w wersji 10.9 i rozwiązanie działało idealnie. W moim przypadku DNS rozpatruje pełne nazwy, ale nie krótkie.
sorin
1
@Matteo Może plik nie musi istnieć, a może odpowiedź musi zostać zaktualizowana dla Yosemite. Czy masz ten problem? Czy uruchomienie tych poleceń to naprawia?
CajunLuke
10

Właściwie myślę, że możesz chcieć użyć

scutil --dns

scutil -r hostname

Te polecenia używają dynamicznego magazynu w configd, w przeciwieństwie do plików płaskich w / etc, które często są odczytywane tylko w trybie pojedynczego użytkownika i dla systemów nie podłączonych do sieci.

man scutil   # or

scutil --help  
chiggsy
źródło
3
Nie wyjaśniasz, dlaczego te polecenia pomogłyby w rozwiązaniu tego problemu. Czy oni w ogóle? Czy to oznaczało komentarz do jednej z innych odpowiedzi czy coś takiego?
dkagedal
Jedną możliwą zaletą programu scutil jest to, że może on działać niezależnie od tego, czy komputer wykrył, czy mDNSResponder. Pochodzi z okresu przed ich wprowadzeniem.
DA Vincent
1
te polecenia nie rozwiązują problemu
Radu Simionescu,
7

Rozpoznawanie nazw w OSX (i ogólnie w systemie UNIX) jest pobierane z adresów IP DNS w pliku znajdującym się w /etc/resolv.conf (który OS X automatycznie generuje, o ile pamiętam).

Ponieważ próbowałeś praktycznie wszystkiego, co przychodzi mi do głowy, chciałbym cię zapytać:

  • Czy możesz pingować DNS, którego chcesz użyć?
  • Jakie są / są adresy IP serwerów DNS, których chcesz używać?
  • Czy próbowałeś używać 8.8.8.8 (google) lub dowolnego z OpenDNS 208.67.222.222 lub 208.67.220.220?
  • Czy potrafisz pingować te hosty?

Wreszcie, zazwyczaj miły test polega na utworzeniu pustego użytkownika i sprawdzeniu, czy ten nowy użytkownik ma ten sam problem. Jeśli tak się nie stanie, możesz zacząć kopać to, co ma twój obecny użytkownik, co może powodować problem; jeśli to również zawiedzie, to wiesz, że jest to coś bardziej „systemowego”.

Rozejrzyj się również po konsoli, aby zobaczyć, czy możesz dostrzec coś, co może być powiązane (i chciałbyś tu wkleić).

Last but not least, twój Mac ma dwa ważne polecenia DNS nslookupi dig.

Aby rozwiązać www.apple.com za pomocą serwera Google, wpisz:

nslookup „host do rozwiązania” „serwer DNS do użycia”. Na przykład:

$ nslookup www.apple.com 8.8.8.8
Server:     8.8.8.8
Address:    8.8.8.8#53

Non-authoritative answer:
www.apple.com   canonical name = www.isg-apple.com.akadns.net.
www.isg-apple.com.akadns.net    canonical name = www.apple.com.edgekey.net.
www.apple.com.edgekey.net   canonical name = e3191.c.akamaiedge.net.
Name:   e3191.c.akamaiedge.net
Address: 184.24.141.15

NSLookup to stare polecenie (które miało być przestarzałe kilka lat temu i zastąpione przez DIG, ale jego łatwa w użyciu składnia była chyba zbyt dobra, by zabijać). Jego „zamiana” jest digznacznie potężniejszym poleceniem, którego składnia jest bardziej szalony.

Aby wykonać to samo zapytanie, wpisz:

dig @ 8.8.8.8 www.apple.com

I oto wynik:

$ dig @8.8.8.8 www.apple.com

; <<>> DiG 9.7.3 <<>> @8.8.8.8 www.apple.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17356
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;www.apple.com.         IN  A

;; ANSWER SECTION:
www.apple.com.      1782    IN  CNAME   www.isg-apple.com.akadns.net.
www.isg-apple.com.akadns.net. 42 IN CNAME   www.apple.com.edgekey.net.
www.apple.com.edgekey.net. 21581 IN CNAME   e3191.c.akamaiedge.net.
e3191.c.akamaiedge.net. 2   IN  A   184.24.141.15

;; Query time: 26 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Mon Oct  3 21:21:49 2011
;; MSG SIZE  rcvd: 158

Jak widać, dig jest znacznie bardziej „gadatliwy” (co jest dobre do debugowania tego, co się dzieje). Siła kopania wynika z faktu, że możesz określić, jaki typ zapytania chcesz wykonać (między innymi).

W każdym razie daj nam znać dokładne wyniki tych poleceń.

Martin Marconcini
źródło
Zobacz moją edycję pytania.
CajunLuke
@CajunLuke hmmmm ciekawe… Mam coś przeciwko dodaniu wyniku: cat /etc/resolv.conf do twojego pytania?
Martin Marconcini,
Edytowane. (Wypełnienie, aby komentarz pasował.)
CajunLuke
@CajunLuke Jestem zdziwiony. Wróćmy do korzeni ... dzieje się to tylko na tym komputerze i tylko w OSX maszyny wirtualne są w porządku. Zaczynam podejrzewać, że Parallels lub VMware mogą powodować problemy. Jakiego rodzaju sieci używają te maszyny wirtualne? Zmostkowane? Udostępniono?
Martin Marconcini,
1
Lub jeśli chcesz naprawdę krótko, zawsze możesz zrobić ... wykopać +
skrócić apple.com
7

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
    user=nobody
    group=nobody
    interface=lo0
    cache-size=1024
    
  • Umieść to w resolv.confpliku, który znajduje się w tym samym katalogu co dnsmasq.confplik (nb: not /etc/resolv.conf ):

    nameserver 8.8.8.8
    nameserver 4.2.2.1
    nameserver 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: reading resolv.conf
    dnsmasq: using nameserver 4.2.2.1#53
    dnsmasq: using nameserver 4.2.2.2#53
    dnsmasq: using nameserver 8.8.8.8#53
    dnsmasq: read /etc/hosts - 6 addresses
    
  • 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.

David Wolever
źródło
Chciałbym tylko zauważyć, że po 16 godzinach szperania w Internecie jest to jedyne rozwiązanie, które znalazłem, które pozwala mi rozwiązać wewnętrzne nazwy firm ORAZ umożliwia prawidłowe funkcjonowanie podzielonej sieci. Bardzo dziękuję za komentarz.
Ron Thompson
Chciałbym również zauważyć, że w systemie OS X El Capitan, aby skonfigurować skrypt, zawarłem swoje openconnectpolecenie w skrypcie python, wraz z poleceniami takimi jak networksetup -setdnsservers 127.0.0.1i networksetup -setsearchdomains "$COMPANY_NAME".com. Dodaj swoje dnsmasqpolecenie i gotowe! Dzięki temu komentarzowi mam wreszcie stabilne rozwiązanie VPN.
Ron Thompson
Dla przyszłych czytelników uznałem, że najłatwiej jest po prostu ssh do mojego komputera w pracy, ustalić, który adres IP ma dla serwerów nazw, a następnie zakodować te adresy IP na moim resolv.conf poniżej wersji 8.8.8.8 (serwer DNS Google). Dzięki temu wszystkie nazwy firm nie są poprawnie rozpoznawane bez konieczności przechodzenia przez serwery firmowe, co uważam za przydatne ze względu na prywatność i szybkość. Jeśli chodzi o twarde kodowanie, te adresy IP nie zmienią się w najbliższym czasie, a jeśli tak, to nie będę jedynym, którego to dotyczy i edytowanie dwóch linii powinno być trywialne.
Ron Thompson
Mówi, że adres 127.0.0.1 jest już używany, kiedy próbuję uruchomić dnsmasq. Co mam do zrobienia? High Sierra
IceFire
@IceFire Wiem, że jest stary, ale oznacza to, że na tym porcie jest już związana usługa (53). Technicznie oznacza to, że pojawia się błąd EADDRINUSE, ale tam nie pójdę :) Jeśli chodzi o tę odpowiedź, uważam ją za intrygującą. Mam podobny problem, ale myślę (mam nadzieję), że druga odpowiedź rozwiąże go tylko, że nie muszę włączać go przynajmniej dla mojej sieci domowej, ponieważ mam własne autorytatywne serwery DNS (a jeden z nich jest lokalne i czego używam). Oto, jako długoletni użytkownik Uniksa, fakt, że mógłbym użyć /etc/resolv.conf, jest atrakcyjny, ale wypróbuje drugą.
Pryftan
6

Miałem te same dokładnie te same objawy (i spędziłem trochę czasu na rozwiązywaniu problemów), ale byłem w stanie je rozwiązać, gdy zdałem sobie sprawę, że pomieszałem /System/Library/LaunchDaemons/com.apple.mDNSResponder.plisti to, co zrobiłem, zostało w jakiś sposób zinterpretowane jako źle sformułowane. Przywróciłem dane z kopii zapasowej i komputer mógł ponownie rozpoznać nazwy hostów.

Przed przyjściem do rozwiązania zdałem sobie również sprawę, że mogę przeglądać Internet, jeśli korzystam z serwera proxy SOCKS5 ssh -Di próbuję wyszukiwać DNS przez tunel.

mrożone orzechy ziemne
źródło
1
Moja firma ma ten problem od miesięcy, za każdym razem zabierając komputery Mac do „paska Genius”, którego jedynym rozwiązaniem było wyczyszczenie dysków twardych i rozpoczęcie od nowa. Widziałem twój post i usunąłem com.apple.mDNSResponder.plist, uruchomiłem ponownie i problem został rozwiązany. Chciałbym móc cię głosować miliard razy.
Thomas Thorogood,
1
Uwaga usuń com.apple.mDNSResponder.plist! Zrobiłem to zgodnie z sugestią @TomThorogood. Trudno mi wrócić. Nawet odłożyłem plik i uruchomiłem ponownie, ale nie mogłem uzyskać odpowiedzi z Internetu. To sudo launchctl load -w /System/Library/LaunchDaemons/com.apple.mDNSResponder.plistpomogło.
Pavel Binar
5

Miałem bardzo, bardzo podobny problem, z tym wyjątkiem, że objawy były nieco inne.

Mój użytkownik nie mógł rozpoznać żadnej nazwy (lokalny serwer NAS, Google itp.), Ale gość-gość na tym samym komputerze iMac (OS X 10.7.4) działał dobrze.

Jak wspomniano, opróżnianie i ponowne uruchamianie mDNSResponder działało przez pewien czas. Mimo że nadal działałby, gdy iMac był przełączany w tryb uśpienia, zawsze po awarii uruchamiał się.

Kiedy opróżnianie / ponowne uruchamianie przestało działać, szukałem innych powodów / rozwiązań i odkryłem, że było to związane z moją zaporą ogniową. Nie wiem, co spowodowało to w moich ustawieniach zapory (OS X), ale jeśli przywróciłem ustawienie zapory, zadziałało.

Aby przywrócić ustawienia domyślne, których użyłem:

sudo cp /usr/libexec/ApplicationFirewall/com.apple.alf.plist /Library/Preferences/com.apple.alf.plist

Oczywiście wszelkie niestandardowe reguły zostaną usunięte podczas tego przywracania.

Chciałem udostępnić moją wersję tego problemu, ponieważ od miesięcy wywołuje u mnie żal, a ten post jest najlepszą kolekcją możliwych rozwiązań w sieci!

Simon C. Smith
źródło
4

Uderzyłem ten problem w Yosemite (10.10). Okazuje się, że kluczowy demon discoverydzostał zabity, ponieważ zużywał zbyt dużo procesora.

2014/10/22 3:50:07.000 PM kernel[0]: process discoveryd[49] thread 1251 caught burning CPU! It used more than 50% CPU (Actual recent usage: 68%) over 180 seconds. thread lifetime cpu usage 90.016372 seconds, (74.516637 user, 15.499735 system) ledger info: balance: 90007570271 credit: 90007570271 debit: 0 limit: 90000000000 (50%) period: 180000000000 time since last refill (ns): 131905306167 

Dziwne ponowne uruchomienie nie spowodowało ponownego uruchomienia.

Ponownie uruchomiłem usługę z:

sudo launchctl kickstart -k system/com.apple.networking.discoveryd

a teraz wszystko jest dobrze.

Brian de Alwis
źródło
1
To było również rozwiązanie dla mnie na Yosemite. Niektóre szczegóły: host, dig i Chrome działały poprawnie, ale ping, telnet, ssh, firefox i safari nie mogły rozpoznać nazw hostów. To rozwiązanie rozwiązało mój problem.
Ryan Hoegg
Irytuje mnie to cały czas. Musisz ponownie uruchomić usługę.
Callum Rogers
2

Mam ten sam problem z 10.6.8. Pierwsza podróż do sklepu Apple Store spowodowała przywrócenie systemu. Ale potem DNS znów się zepsuł, kiedy byłem za granicą i nie miałem ze sobą systemowego DVD. W tym czasie znalazłem ten wątek i /System/Library/LaunchDaemons/com.apple.mDNSResponder.plistusunąłem go na @freezedpeanuts i @Tom Thorogood.

Rozwiązało to problem, ale, co zaskakujące, DNS zepsuł się po raz trzeci kilka dni później. Wyśledziłem obraz systemu 10.6.3 i:

  1. Skopiowano /System/Library/LaunchDaemons/com.apple.mDNSResponder.plistz obrazu systemu.
  2. sudo chown root /System/Library/LaunchDaemons/com.apple.mDNS*
  3. Zrestartowano

To naprawiło problem.

Dla mnie teraz okresowo się psuje (raz na miesiąc), a procedura przywracania jest ograniczona do powyższych kroków, z wyjątkiem tego, że zamiast restartu możesz:

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

DKroot
źródło
2

Pamiętaj, że jeśli nadal występują problemy, konieczne może być usunięcie publicznych serwerów DNS, dopóki pamięć podręczna nie zostanie wyczyszczona.

Dustin Matlock
źródło
1
Może powinniśmy wspomnieć o support.apple.com/en-au/HT203244 .
DA Vincent
@DAVincent Kilka lat później, ale ten link jest rozczarowujący. To oczywiście błąd Apple, ale przypisują go do błędu użytkownika.
weberc2
2

Miałem pozornie ten sam problem co OP. Za pomocą narzędzia networksetup odkryłem, że dla danej nazwy sieci skonfigurowano błędny DNS:

networksetup -getdnsservers <networkname>

wymieniono 192.168.0.1 jako DNS. Używając scutil --dns mam porównywalne wyniki, podając, że resolver # 2 używał serwera nazw [0]: 192.168.0.1.

Za pomocą polecenia

networksetup -setdnsservers <networkname> 192.168.188.1 8.8.8.8

Byłem w stanie ponownie skonfigurować DNS dla danej sieci i rozpoznać nazwy komputerów lokalnych i globalnych po podłączeniu do sieci VPN.

Rexford
źródło
2

W moim przypadku wszystko inne było w porządku: mDNSResponder działał i działał, host/ nslookupdziałał zarówno /etc/resolv.confi networksetupzgłaszał prawidłowe serwery DNS itp. Mimo to, ogólnie rozpoznawanie DNS (np. Z ping) nieuchronnie przestało działać w pewnym momencie kilka godzin później bagażnik.

Ten konkretny problem może być nieco mało prawdopodobny, ale i tak udokumentuję go tutaj jako odpowiedź.

Zauważyłem tylko, kiedy maszyna zaczęła zwalniać, ale uruchomiono wiele identycznych procesów . sensu-client, konkretnie.

Uruchomiliśmy go przy użyciu tego pliku plist:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC -//Apple//DTD PLIST 1.0//EN http://www.apple.com/DTDs/PropertyList-1.0.dtd>
<plist version="1.0">
  <dict>
  <key>KeepAlive</key>
  <true/>
  <key>RunAtLoad</key>
  <true/>
  <key>WorkingDirectory</key>
  <string>/etc/sensu</string>
  <key>UserName</key>
  <string>root</string>
  <key>Label</key><string>org.sensuapp.sensu-client</string>
    <key>ProgramArguments</key>
    <array>
      <string>/usr/bin/sensu-client</string>
      <string>-d/etc/sensu/conf.d/</string>
      <string>-b</string>
    </array>
  </dict>
</plist>

-bFlagę sensu-clientsprawia, że widelec w tle, działając jako demon. Widzimy jednak, launchdże oryginalny proces został zakończony, więc (zgodnie z KeepAliveflagą) uruchamia go ponownie. To pozostawia tysiące rozwidlonych procesów w tle, a nawet wtedy uruchomienie nie będzie mądrzejsze od faktu, że jest uruchomione.

Uważam, że te kilka tysięcy procesów (wszystkie sensu-client, dla których napisaliśmy uruchomioną konfigurację) mogło jednocześnie wysyłać żądania do mDNSResponder, co w efekcie skutkuje lokalną odmową usługi pamięci podręcznej DNS . Zabicie tych procesów i naprawienie plist podanego do uruchomienia ostatecznie rozwiązało problem.

Poprawka plist polegała jedynie na usunięciu -bflagi (tło / demon) z wywołania sensu-klienta. Zauważ, że to nie wina Sensu; ten list został napisany przez byłego administratora systemu w tej firmie.

Score_Under
źródło
2

Oto kilka zaawansowanych poleceń, które mogą pomóc w rozwiązaniu problemu z DNS:

  • Uruchom, digaby wyświetlić listę głównych serwerów nazw.
  • Uruchom, dig example.comaby uruchomić wyszukiwanie DNS dla example.comdomeny.
  • Listy swoich portów sprzętowych przez: networksetup -listallhardwareports.
  • Sprawdzić wyjście pakietu DHCP / BOOTP, że klient zaakceptowany przez serwer DHCP / BOOTP przez: ipconfig getpacket en0.
  • Sprawdź konfigurację DNS przez: scutil --dns.
  • Sprawdź, czy mDNSResponderproces jest uruchomiony przez: ps wuax | grep mDNSResponder.
  • Opróżnij wpisy tłumaczenia ARP przez: arp -ad(biegnij man arppo pomoc). źródło

Aby debugować mDNSResponderproces, pomocne może być następujące polecenie:

(sleep 1 && sudo killall -INFO mDNSResponder &); log stream | grep mDNSResponder

Powyższe polecenie wyśle SIGINFOsygnał do procesu, który zrzuci szczegóły debugowania na dane wyjściowe dziennika, które można odczytać i przeanalizować.

kenorb
źródło
1

Wyłączenie i ponowne włączenie Wi-Fi pomogło.

MacBook Pro z 10.9.1

Zwłaszcza jeśli wyłączysz Wi-Fi, a następnie uruchom ponownie. Dodatkowe opóźnienie i rozpoczęcie bez połączenia IP / sieci zapewniają, że żądanie ponownego przyłączenia do sieci ma większe szanse powodzenia.

Łukasz Madon
źródło
1
Chociaż pytanie może wymagać edycji, nadal mówi (w momencie pisania tego komentarza), że pracownicy już próbowali wyłączyć i włączyć Wi-Fi. Może moglibyśmy cofnąć tę odpowiedź?
DA Vincent
Nie mam wystarczającej reputacji, aby dodać komentarz do postu na temat wyłączania i włączania Wi-Fi, ale to działało dla mnie. Cofanie odpowiedzi byłoby głupie.
+1 za sugestię, aby spróbować ponownie. Wiele odpowiedzi pomaga wielu osobom, a każdy router ma inne limity czasu i zachowania.
bmike
1

Prawdopodobnie nikomu to nie pomoże, ale na wypadek, gdy przypadkowo jakiś czas temu utworzyłem plik w folderze, gdy DNS był wyłączony dla określonej domeny:

/ etc / resolver /

i to zapobiegało rozwiązaniu określonej nazwy dwa lata później.

Jérémie
źródło
Dziękuję bardzo, to był mój problem. Debuguję od wielu godzin, a kiedy zajrzałem do / etc / resolver, oczywiście znalazłem plik o nazwie „test” z błędnymi adresami IP ...
keyser
1

Niestety nic z tego nie pomogło i okazało się, że po godzinie próbowałem to rozgryźć i uderzyć głową o stolik kawowy ... coś, jakoś gdzieś ... usunąłem /System/Library/LaunchDaemons/com.apple.mDNSResponder.plistplik i to było przyczyną mojego problemu.

Zrozumiałem to, gdy zobaczyłem ten komunikat o błędzie: /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist: No such file or directory

Oto kopia wersji z El Capitan: https://gist.github.com/tripflex/e7147690d1768dc74b1dd626614573c0

Oto kod z tej treści:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>Label</key>
    <string>com.apple.mDNSResponder.reloaded</string>
    <key>OnDemand</key>
    <false/>
    <key>InitGroups</key>
    <false/>
    <key>UserName</key>
    <string>_mdnsresponder</string>
    <key>GroupName</key>
    <string>_mdnsresponder</string>
    <key>ProgramArguments</key>
    <array>
        <string>/usr/sbin/mDNSResponder</string>
    </array>
    <key>MachServices</key>
    <dict>
        <key>com.apple.mDNSResponder</key>
        <true/>
            <key>com.apple.mDNSResponder.dnsproxy</key>
            <true/>
    </dict>
    <key>Sockets</key>
    <dict>
        <key>Listeners</key>
        <dict>
            <key>SockFamily</key>
            <string>Unix</string>
            <key>SockPathName</key>
            <string>/var/run/mDNSResponder</string>
            <key>SockPathMode</key>
            <integer>438</integer>
        </dict>
    </dict>
    <key>POSIXSpawnType</key>
    <string>Interactive</string>
    <key>EnablePressuredExit</key>
    <false/>
</dict>
</plist>
sMyles
źródło
0

Jak się okazuje, aby rozwiązać problem, musisz skonfigurować domenę wyszukiwania i dodać ją do pola domeny wyszukiwania w Preferencjach systemowych konfiguracji dns. Zasadniczo domena wyszukiwania będzie działać tak, jak działa .local, ale zamiast tego tak będzie.

Aby to działało, musisz skonfigurować domenę wyszukiwania jako strefę główną na serwerze DNS.

Yeison
źródło
0

Mam podobny problem ze znalezieniem serwera hosta. Mamy 21 iMaców uruchomionych z serwera (El Capitan, niedawno zaktualizowany) i tylko jeden nie chce się powiązać. Ta poprawka jest zwykle dość prosta przez użytkowników i grupy w SysPref. Usuwanie serwera hosta i ponowne wiązanie, znajdowanie dostępnego serwera w opcji rozwijanej, ale z jakiegoś nieznanego powodu serwer znajduje się na liście jako unkown-00-00-12-34-56-78.home, co znalazłem, to adres MAC serwera. Uruchomiłem to w terminalu:

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

i

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

powróciłem do wiązania się z serwerem w SysPref i na krótko pojawiła się opcja poprawnej nazwy serwera, a następnie zmieniłem z powrotem na „unkown-00-00-12-34-56-78.home” tuż przed moimi oczami!

cwj73
źródło
0

Gdy następujące polecenia z zaakceptowanej odpowiedzi:

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

możesz napotkać ostrzeżenie:

Operacja niedozwolona, ​​gdy włączona jest ochrona integralności systemu

Musisz to wyłączyć. Cała instrukcja tutaj: https://www.howtogeek.com/230424/how-to-disable-system-integrity-protection-on-a-mac-and-why-you-shouldnt/

andilabs
źródło
0

W moim przypadku miałem w przeszłości zainstalowany OpenDNS i nie został on całkowicie usunięty. Działało kilka procesów związanych z dns, takich jak DNSdnscrypt-proxy. Nie mogłem wymusić ich zamknięcia w Monitorze aktywności, ale byłem w stanie powstrzymać ich uruchamianie przy ponownym uruchomieniu poprzez usunięcie pliku .plist w Library / LaunchDaemons.

Hao
źródło
0

Przejdź do Ustawienia -> Sieć -> Zaawansowane -> DNS. Następnie wprowadź dosłownie wszelkie zmiany w DNS (na przykład zmień kolejność wpisów DNS). Następnie kliknij „OK”, a następnie „Zastosuj” na następnym ekranie. Nie daj się zwieść myśleniu, że konkretna zmiana, którą wprowadziłeś, była znacząca; to magia przycisku „Zastosuj”.

~ $  time nslookup www.google.com
;; connection timed out; no servers could be reached


real    0m21.041s
user    0m0.006s
sys     0m0.010s

 ~ $  time nslookup www.google.com
Server:         8.8.8.8
Address:        8.8.8.8#53

Non-authoritative answer:
Name:   www.google.com
Address: 172.217.5.4


real    0m0.079s
user    0m0.006s
sys     0m0.010s
weberc2
źródło
0

Dla mnie zadziałało usunięcie wszystkich wpisów serwera z serwerów DNS i domen wyszukiwania z:

Preferencje systemowe → Sieć → Zaawansowane ... → DNS

Marcelo
źródło
-1

Po aktualizacji ze Snow Leopard na starej Mac Book do Mountain Lion system nie mógł rozpoznać DNS. Płukanie, restart, nic nie pomogło. Pomogła zmiana Wi-Fi na inny punkt dostępu (mój telefon).

Mountain Lion dodaje nowe pole klienta do ustawień sieci DHCP. Wypełnienie tego pola wydawało się uszczęśliwiać punkt dostępu Wi-Fi. Pozostawienie tego pola pustego oznaczało, że nic nie przechodziło, mimo że połączenie Wi-Fi wydawało się udane.

xt1
źródło