DNS nie działa w systemie Mac OS X.

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

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.

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  

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ń.

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.

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.

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!

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.

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

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.

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.

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.

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ć.

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.

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.

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>

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.

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!

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/

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.

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

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

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

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.