DNS non risolto su Mac OS X

Alcuni dei miei colleghi hanno problemi con i loro Mac: la risoluzione DNS non funziona con Mac OS X. Stanno eseguendo Snow Leopard 10.6.8. Possono utilizzare DNS in una macchina virtuale Windows 7 (VMware Fusion 3.1.3) in esecuzione su OS X. I computer sono MacBook Pro da 15 ", modello all'inizio del 2011.

Cose che hanno provato che non hanno funzionato:

• accendere / spegnere l'aeroporto
• riavvio
• usando la connessione cablata invece wifi
• eliminazione delle credenziali di connessione e aggiunta di nuovo
• disattivazione del firewall per Mac
• utilizzando un IP statico fisso
• impostazione manuale dei server DNS
• riavvio di mDNSResponder
• le correzioni da questa altra domanda

Risposta EDIT Risposta di Martín:

• È possibile eseguire il ping del DNS che si desidera utilizzare?

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

• Qual è / sono gli indirizzi IP dei DNS che si desidera utilizzare?

Questo è un server DNS aziendale fornito con DHCP, funziona bene per altre persone. Ho anche provato 8.8.4.4 e 205.171.3.65 di Google (che ho trovato dal Benchmark DNS di GRC come il più veloce).

• Hai provato a utilizzare 8.8.8.8 (google) o uno qualsiasi degli OpenDNS 208.67.222.222 o 208.67.220.220?

Non funziona, vedi l'output di Google Chrome:

Impossibile trovare il server su www.apple.com perché la ricerca DNS non è riuscita. DNS è il servizio di rete che traduce il nome di un sito Web nel suo indirizzo Internet. Questo errore è spesso causato dalla mancanza di una connessione a Internet o di una rete non configurata correttamente. Può anche essere causato da un server DNS che non risponde o da un firewall che impedisce a Google Chrome di accedere alla rete.

• Puoi eseguire il ping di quegli host?

$ 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

• creazione di un utente vuoto

È stato creato un account utente guest, il problema DNS era ancora presente quando si utilizza l'account guest.

• nslookup e scavare entrambi funzionano bene

$ 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

• anche lo svuotamento della cache DNS è stato eseguito ma non ha aiutato

sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder

MODIFICA 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

Si scopre che la soluzione era rimbalzare mDNSResponder:

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

Ciò è stato ottenuto da un collega diverso da questa domanda di errore del server .

OS X 10.10.0 - 10.10.3, Yosemite

Apparentemente , mDNSResponder non esiste in Yosemite (OS X 10.10). È possibile riavviare descoveryd invece di risolvere questi problemi.

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

In OSX 10.10.4 è stato reintrodotto mDNSResponder . Quindi usa il primo funzionerà di nuovo.

In realtà, penso che potresti voler usare

scutil --dns

scutil -r hostname

Questi comandi usano l'archivio dinamico in configd, al contrario dei flatfile in / etc, che spesso vengono letti solo in modalità utente singolo e per sistemi non collegati in rete.

man scutil   # or

scutil --help  

Ho riscontrato lo stesso problema ... E mentre riavvio mDNSResponder sembra "funzionare", riavviandolo un paio di volte ogni ora fa schifo.

Quindi, per ora, ho "risolto" il problema eseguendo dnsmasq localmente. Fare quello:

• Build dnsmasq (scarica tgz makeeo brew install dnsmasq)

• Metti questo in un dnsmasq.conffile:

  resolv-file=resolv.conf
  user=nobody
  group=nobody
  interface=lo0
  cache-size=1024
  

• Inseriscilo in un resolv.conffile che si trova nella stessa directory del dnsmasq.conffile (nb: not /etc/resolv.conf ):

  nameserver 8.8.8.8
  nameserver 4.2.2.1
  nameserver 4.2.2.2
  

• Corri dnsmasqcon sudo dnsmasq --no-daemon --log-queries -C dnsmasq.conf. L'output dovrebbe assomigliare a:

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

• Apri Preferenze di rete e assicurati che 127.0.0.1sia l'unico server DNS (preferenze di rete -> avanzato -> DNS -> aggiungi 127.0.0.1)

Le cose dovrebbero ricominciare a funzionare bene.

Una volta che le cose funzionano, puoi eseguire dnsmasqsenza le opzioni --no-daemone --log-queries, quindi si avvierà in background e non dovrai tenere aperta una finestra Terminale.

La risoluzione dei nomi in OSX (e UNIX in generale) è presa dagli indirizzi IP dei DNS nel file che si trova in /etc/resolv.conf (che OS X genera automaticamente per quanto posso ricordare).

Dato che hai provato praticamente qualsiasi cosa mi venga in mente, vorrei chiederti:

• Puoi eseguire il ping del DNS che desideri utilizzare?
• Qual è / sono gli indirizzi IP dei DNS che si desidera utilizzare?
• Hai provato a utilizzare 8.8.8.8 (google) o uno dei 208.67.222.222 o 208.67.220.220 di OpenDNS?
• Puoi fare un ping a quegli host?

Infine, un test solitamente piacevole consiste nel creare un utente vuoto e vedere se quel nuovo utente presenta lo stesso problema. In caso contrario, puoi iniziare a scavare ciò che il tuo attuale utente potrebbe causare il problema; se anche fallisce, allora sai che questo è qualcosa di più "di sistema".

Dai anche un'occhiata alla Console per vedere se riesci a individuare qualcosa che potrebbe essere correlato (e che desideri incollare qui).

Ultimo ma non meno importante, il tuo Mac viene fornito con due importanti comandi DNS nslookupe dig.

Quindi per risolvere www.apple.com usando il server di Google, dovresti digitare:

nslookup "host per risolvere" "Server DNS da utilizzare". Per esempio:

$ 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 è un vecchio comando (che doveva essere deprecato alcuni anni fa e sostituito da DIG, ma la sua sintassi facile da usare era troppo buona per uccidere, immagino.), La sua "sostituzione" è digun comando molto più potente, la cui sintassi è più pazzo.

Per eseguire la stessa query, digitare:

dig @ 8.8.8.8 www.apple.com

E qui c'è l'output:

$ 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

Come puoi vedere, scavare è molto più "dettagliato" (il che è utile per eseguire il debug di cosa diavolo sta succedendo). Il potere dello scavo deriva dal fatto che è possibile specificare quale tipo di query si desidera eseguire (tra le altre cose).

In ogni caso, fateci sapere gli esatti output di questi comandi.

Ho avuto gli stessi identici sintomi (e ho trascorso un po 'di tempo nella risoluzione dei problemi) ma sono stato in grado di risolverlo quando mi sono reso conto di aver sbagliato /System/Library/LaunchDaemons/com.apple.mDNSResponder.pliste quello che ho fatto è stato in qualche modo interpretato come malformato. Ho ripristinato da un backup e la macchina è stata in grado di risolvere nuovamente i nomi host.

Prima di arrivare alla soluzione, mi sono anche reso conto che ero in grado di navigare in Internet se avessi usato un proxy SOCKS5 ssh -De provato le ricerche DNS attraverso il tunnel.

Ho avuto un problema molto, molto simile, tranne per i sintomi leggermente diversi.

Il mio utente non è riuscito a risolvere alcun nome (NAS locale, Google ecc.) Ma un utente guest sullo stesso iMac (OS X 10.7.4) ha funzionato bene.

Lavare e riavviare mDNSResponder come menzionato ha funzionato per un po '. Mentre sarebbe rimasto a lavorare quando l'iMac è stato messo in modalità sleep, sarebbe sempre fallire una volta riavviato.

Quando il flush / restart ha smesso di funzionare ho cercato altri motivi / soluzioni e ho scoperto che era correlato al mio firewall. Non so cosa lo causasse nelle mie impostazioni del firewall (OS X), ma se ho ripristinato le impostazioni del firewall ha funzionato.

Per ripristinare le impostazioni predefinite che ho usato:

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

Ovviamente eventuali regole personalizzate saranno state rimosse con questo ripristino.

Volevo condividere la mia versione di questo problema in quanto mi ha causato sofferenza dentro e fuori per mesi e questo post è la migliore raccolta di soluzioni possibili in rete!

Ho riscontrato questo problema su Yosemite (10.10). Si scopre che un demone chiave discoveryd, è stato ucciso perché consumava troppa CPU.

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 

Il riavvio strano non ha causato il riavvio.

Ho riavviato manualmente il servizio con:

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

e ora va tutto bene.

Sto riscontrando lo stesso problema con 10.6.8. Il primo viaggio in un Apple Store ha comportato il ripristino del sistema. Ma dopo ciò, il DNS si è rotto di nuovo mentre ero all'estero e non avevo un DVD di sistema con me. In quel momento ho trovato questo thread ed eliminato /System/Library/LaunchDaemons/com.apple.mDNSResponder.plistper @freezedpeanuts e @Tom Thorogood.

Risolveva il problema, ma, sorprendentemente, il DNS si interruppe per la terza volta un paio di giorni dopo. Ho dato la caccia a un'immagine di sistema di 10.6.3 e:

1. Copiato /System/Library/LaunchDaemons/com.apple.mDNSResponder.plistdall'immagine di sistema.
2. sudo chown root /System/Library/LaunchDaemons/com.apple.mDNS*
3. Riavviato

Ciò ha risolto il problema.

Si interrompe periodicamente per me ora (una volta al mese) e la procedura di ripristino si riduce ai passaggi precedenti, tranne che invece di riavviare è possibile:

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

Si prega di notare che chiunque ha ancora problemi, potrebbe essere necessario rimuovere tutti i server DNS pubblici fino a quando la cache non viene cancellata.

Apparentemente avevo lo stesso problema dell'OP. Usando lo strumento networksetup ho scoperto che per il nome di rete dato, è stato configurato un DNS errato:

networksetup -getdnsservers <networkname>

elencato 192.168.0.1 come DNS. Usando scutil --dns ho ottenuto risultati comparabili, elencando quel resolver # 2 usato nameserver [0]: 192.168.0.1.

Usando il comando

networksetup -setdnsservers <networkname> 192.168.188.1 8.8.8.8

Sono stato in grado di riconfigurare il DNS per la determinata rete e risolvere i nomi di macchine locali e globali quando collegati alla VPN.

Questo probabilmente non aiuterà nessuno, ma nel caso, accidentalmente qualche tempo fa, ho creato un file nella cartella, quando un DNS era inattivo per un determinato dominio:

/ Etc / resolver /

e questo impediva che un nome specifico venisse mai risolto, due anni dopo.

Nel mio caso, tutto il resto andava bene: mDNSResponder era in esecuzione e funzionava, host/ nslookupfunzionava, entrambi /etc/resolv.confe networksetupriportava i server DNS corretti, ecc. Nonostante tutto ciò, la risoluzione DNS in generale (ad esempio con ping) ha inevitabilmente smesso di funzionare ad un certo punto qualche ora dopo stivale.

Questo specifico problema potrebbe essere alquanto improbabile, ma lo documenterò qui come risposta comunque.

Ho notato solo quando la macchina ha iniziato a rallentare, ma c'erano molti processi identici in esecuzione . sensu-client, in particolare.

Lo avevamo configurato in launchd con questo file 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>

La -bbandiera per sensu-clientfarla passare in secondo piano, fungendo da demone. Tuttavia, tutto launchdvede che il processo originale è terminato, quindi (secondo la KeepAlivebandiera) lo riavvia. Questo lascia migliaia di processi biforcuti in background, e anche allora launchd non sarà più saggio del fatto che sia in esecuzione.

Credo che queste diverse migliaia di processi (tutti sensu-clienti software per cui abbiamo scritto una configurazione di avvio) possano aver simultaneamente fatto richieste a mDNSResponder, risultando effettivamente in un denial of service locale della cache DNS . Uccidere questi processi e risolvere il problema dato a launchd alla fine ha risolto il problema.

La correzione del plist era solo quella di rimuovere il -bflag (background / daemonise) dall'invocazione sensu-client. Nota che questo non è colpa di sensu; questo plist è stato scritto da un ex amministratore di sistema di questa società.

Ecco alcuni comandi avanzati che possono aiutare a risolvere il problema DNS:

• Esegui digper elencare i server dei nomi radice.
• Esegui dig example.comper eseguire la ricerca DNS per il example.comdominio.
• Inserisci il tuo porte hardware da: networksetup -listallhardwareports.
• Controllare l'uscita del pacchetto DHCP / BOOTP che il cliente ha accettato dal server DHCP / BOOTP da: ipconfig getpacket en0.
• Controllare la configurazione DNS: scutil --dns.
• Verificare che mDNSResponderprocesso è in esecuzione da: ps wuax | grep mDNSResponder.
• Svuota le voci di traduzione ARP da: arp -ad(esegui man arpaiuto). ^fonte

Per eseguire il debug del mDNSResponderprocesso, può essere utile il seguente comando:

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

Il comando precedente invierà un SIGINFOsegnale al processo che scaricherà i dettagli di debug nell'output del registro che può essere letto e analizzato.

La disattivazione e la riattivazione del Wi-Fi sono state utili.

^{MacBook Pro con 10.9.1}

Soprattutto se si spegne il wifi e si riavvia. Il ritardo aggiuntivo e l'avvio senza connessione IP / di rete assicurano che la richiesta di ricollegamento alla rete abbia maggiori possibilità di successo.

Sfortunatamente nulla di tutto ciò mi ha aiutato, e dopo un'ora ho cercato di capirlo e di battere la testa contro il tavolino ... qualcosa, in qualche modo, da qualche parte ... ha rimosso il /System/Library/LaunchDaemons/com.apple.mDNSResponder.plistfile ed è stato il motivo per cui ho avuto questo problema.

Realizzato questo quando ho visto questo messaggio di errore: /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist: No such file or directory

Ecco una copia di una versione di El Capitan: https://gist.github.com/tripflex/e7147690d1768dc74b1dd626614573c0

Ecco il codice di questa sintesi:

<?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>

A quanto pare, per risolvere il problema devi configurare un dominio di ricerca e aggiungerlo al campo del dominio di ricerca in Configurazione dns Preferenze di Sistema. Fondamentalmente, il dominio di ricerca funzionerà in modo simile a .local, ma invece lo sarà.

Devi impostare il tuo dominio di ricerca come zona principale nel tuo server DNS per farlo funzionare.

Ho un problema simile con la ricerca del server host. Abbiamo 21 iMac in esecuzione dal server (El Capitan, recentemente aggiornato) e solo uno non vincolerà. La correzione è in genere piuttosto semplice tramite Utenti e gruppi in SysPref. Eliminazione del server host e rilegatura, individuazione del server disponibile nell'opzione a discesa, ma per qualche ragione sconosciuta il server è elencato come unkown-00-00-12-34-56-78.home, che ho trovato è l'indirizzo MAC del server. Ho eseguito questo nel terminale:

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

e

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

tornò a legarsi al server in SysPref e apparve brevemente l'opzione del nome del server corretta e poi tornò a "unkown-00-00-12-34-56-78.home" proprio davanti ai miei occhi!

Quando si seguono i comandi dalla risposta accettata:

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

potresti imbatterti in un avvertimento:

Operazione non consentita mentre è attiva la Protezione integrità del sistema

Devi spegnerlo. Istruzioni complete qui: https://www.howtogeek.com/230424/how-to-disable-system-integrity-protection-on-a-mac-and-why-you-shouldnt/

Nel mio caso avevo OpenDNS installato in passato e non è stato rimosso in modo pulito. Esistevano diversi processi relativi al DNS come DNSdnscrypt-proxy. Non sono riuscito a forzarli a chiuderli in Activity Monitor, ma sono riuscito a impedirli di avviarsi al riavvio rimuovendo il file .plist in Library / LaunchDaemons.

Vai su Impostazioni -> Rete -> Avanzate -> DNS. Quindi apporta letteralmente qualsiasi modifica al DNS (riordina le voci DNS, ad esempio). Quindi fare clic su "OK" seguito da "Applica" nella schermata successiva. Non farti ingannare nel pensare che il particolare cambiamento che hai apportato sia stato significativo; è la magia del pulsante "Applica".

~ $  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

Ciò che ha funzionato per me è stata la rimozione di tutte le voci del server dai server DNS e dai domini di ricerca da:

Preferenze di Sistema → Rete → Avanzate ... → DNS

Dopo l'aggiornamento da Snow Leopard su un vecchio Mac Book a Mountain Lion, il sistema non è riuscito a risolvere il DNS. Lavaggio, riavvio, nulla ha aiutato. È stato utile cambiare WiFi in un diverso punto di accesso (il mio telefono).

Mountain Lion aggiunge un nuovo campo client alle impostazioni di rete DHCP. Compilare questo campo sembrava rendere felice il punto di accesso wifi. Lasciarlo vuoto significava che nulla stava passando, anche se la connessione wifi sembrava avere successo.