DNS non risolto su Mac OS X

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

Questo è 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). Puoi riavviare descoveryd invece per 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 il mDNSResponder è stato reintrodotto . Quindi usa il primo funzionerà di nuovo.

In realtà, penso che potresti voler usare

scutil --dns

scutil -r hostname

Questi comandi usano lo store dinamico in configd, al contrario dei flatfiles in / etc, che spesso vengono letti solo in modalità utente singolo e per sistemi non 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. Per farlo:

• Crea dnsmasq (scarica il tgz e make o brew install dnsmasq )

• Metti questo in un file dnsmasq.conf :

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

• Metti questo in un file resolv.conf che si trova nella stessa directory del file dnsmasq.conf (nb: non /etc/resolv.conf ):

  nameserver 8.8.8.8
  nameserver 4.2.2.1
  nameserver 4.2.2.2
  

• Esegui dnsmasq con sudo dnsmasq --no-daemon --log-queries -C dnsmasq.conf . L'output dovrebbe essere simile 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 le Preferenze di rete e assicurati che 127.0.0.1 sia l'unico server DNS (preferenze di rete - > avanzato - > DNS - > aggiungi 127.0.0.1)

Le cose dovrebbero cominciare a funzionare bene di nuovo.

Una volta che le cose funzionano, puoi eseguire dnsmasq senza le opzioni --no-daemon e --log-queries , quindi inizierà in background e non dovrai tenere aperta una finestra di Terminale.

La risoluzione dei nomi sotto 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 tutto ciò che mi viene in mente, vorrei chiederti:

• È possibile eseguire il ping del DNS che si desidera utilizzare?
• Quali sono / sono gli indirizzi IP dei DNS che si desidera utilizzare?
• Hai provato a utilizzare 8.8.8.8 (google) o uno qualsiasi degli OpenDNS 208.67.222.222 o 208.67.220.220?
• È possibile eseguire il ping di questi host?

Infine, un test di solito 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 utente ha che potrebbe causare il problema; se anche fallisce, allora sai che questo è qualcosa di più "sistema" correlato.

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

Ultimo ma non meno importante, il tuo Mac include due importanti comandi DNS, nslookup e dig .

Per risolvere www.apple.com utilizzando il server di google, digita:

nslookup "host da 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 credo.), la sua "sostituzione" è dig , un molto comando più potente, la cui sintassi è più pazzesca.

Per eseguire la stessa query, devi digitare:

dig @ 8.8.8.8 www.apple.com

ANd ecco 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ù "verboso" (che è buono per eseguire il debug di cosa diavolo sta succedendo). Il potere di scavare deriva dal fatto che è possibile specificare quale tipo di query si desidera eseguire (tra le altre cose).

In ogni caso, facci sapere i risultati esatti di questi comandi.

Ho avuto gli stessi identici sintomi (e ho trascorso un po 'di tempo per risolvere i problemi) ma sono stato in grado di risolverlo quando ho capito di aver incasinato /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist e 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 ho usato un proxy SOCKS5 attraverso ssh -D e provato le ricerche DNS attraverso il tunnel.

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

Il mio utente non è stato in grado di risolvere alcun nome (NAS locale, Google ecc.) ma un utente ospite sullo stesso iMac (OS X 10.7.4) ha funzionato correttamente.

Il flushing e il riavvio di mDNSResponder come menzionato hanno funzionato per un po '. Anche se rimarrà funzionante quando iMac è stato messo in modalità di sospensione, fallirà sempre una volta riavviato.

Quando il flush / restart ha smesso di funzionare ho cercato altre ragioni / soluzioni e ho scoperto che era correlato al mio firewall. Non so se cosa nelle mie impostazioni del firewall (OS X) lo stia causando, ma se ripristino 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 tutte le regole personalizzate saranno state rimosse con questo ripristino.

Volevo condividere la mia versione di questo problema perché mi ha provocato il dolore per mesi e questo post è la migliore raccolta di possibili soluzioni in rete!

Ho riscontrato questo problema su Yosemite (10.10). Si scopre che un demone chiave, discoveryd , è stato eliminato perché stava consumando 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 avendo lo stesso problema con 10.6.8. Il primo viaggio in un Apple Store ha comportato il ripristino del sistema. Ma, dopo, DNS si è rotto di nuovo mentre ero all'estero e non avevo un DVD di sistema con me. A quel tempo ho trovato questo thread e ho eliminato /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist per @freezedpeanuts e @Tom Thorogood.

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

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

Questo ha risolto il problema.

Si rompe periodicamente per me ora (una volta al mese circa) e la procedura di ripristino è giù ai passaggi precedenti, tranne che invece di riavviare puoi:

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

Ricorda che chiunque ha ancora problemi, potresti dover rimuovere qualsiasi server DNS pubblico fino a quando la cache non viene cancellata.

Avevo apparentemente lo stesso problema dell'OP. Utilizzando lo strumento networksetup ho scoperto che per il nome di rete specificato era stato configurato un DNS sbagliato:

networksetup -getdnsservers <networkname>

elencato 192.168.0.1 come DNS. Usando scutil --dns ho ottenuto risultati comparabili, elencando il risolutore n. 2 usato come nameserver [0]: 192.168.0.1.

Utilizzo del comando

networksetup -setdnsservers <networkname> 192.168.188.1 8.8.8.8

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

Disattivare e riaccendere il Wi-Fi è stato utile.

^{MacBook Pro con 10.9.1}

Soprattutto se si spegne la connessione wifi e quindi si riavvia. Il ritardo extra e l'avvio senza connessione IP / di rete assicurano che la richiesta di ricongiungimento della rete abbia maggiori possibilità di successo.

Nel mio caso, tutto il resto andava bene: mDNSResponder era attivo e funzionante, host / nslookup ha funzionato, entrambi /etc/resolv.conf e networksetup hanno riportato i server DNS corretti, ecc. Nonostante tutto, la risoluzione DNS in generale (ad esempio con ping ) ha inevitabilmente smesso di funzionare a un certo punto poche ore dopo l'avvio.

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.

L'abbiamo 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>

Il flag -b in sensu-client lo rende fork sullo sfondo, fungendo da demone. Tuttavia, tutto ciò che launchd vede è che il processo originale è terminato, quindi (in conformità con il KeepAlive flag) lo riavvia. Questo lascia migliaia di processi bifrati in background, e anche in questo caso launchd non sarà più saggio sul fatto che è in esecuzione.

Credo che questi diverse migliaia di processi (tutti sensu-client , il software per il quale avessimo scritto una configurazione di launchd per) potrebbero aver fatto contemporaneamente richieste a mDNSResponder, risultando in effetti un locale Denial of service della cache DNS . Uccidere questi processi e aggiustare il plist dato a launchd alla fine ha risolto il problema.

La correzione di plist era solo per rimuovere il flag -b (background / daemonise) dal richiamo di sensu-client. Si noti che questa non è colpa di Sensu; questo plist è stato scritto da un ex amministratore di sistema presso questa azienda.

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

• Esegui dig per elencare i server dei nomi di root.
• Esegui dig example.com per eseguire la ricerca DNS per il dominio example.com .
• Elenca le porte hardware per: networksetup -listallhardwareports .
• Controllare l'output del pacchetto DHCP / BOOTP accettato dal client dal server DHCP / BOOTP di: ipconfig getpacket en0 .
• Verifica la configurazione del tuo DNS in base a: scutil --dns .
• Verifica che il processo mDNSResponder sia in esecuzione per: ps wuax | grep mDNSResponder .
• Flush voci di traduzione ARP per: arp -ad (esegui man arp per aiuto). ^fonte

Per eseguire il debug del processo mDNSResponder , il seguente comando può aiutare:

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

Il comando precedente invierà il segnale SIGINFO al processo che eseguirà il dump dei dettagli di debug nell'output del log che può essere letto e analizzato.

Come risulta, per risolvere il problema devi configurare un dominio di ricerca e aggiungerlo al campo del dominio di ricerca sotto Configurazione dns Preferenze di sistema. Fondamentalmente, il dominio di ricerca funzionerà nel modo in cui lo fa .local, ma invece lo sarà.

Devi impostare il dominio di ricerca come zona principale nel tuo server DNS affinché funzioni.

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 attraverso utenti e gruppi in SysPref. Eliminazione del server host e re-binding, ricerca del server disponibile nell'opzione dropdown, ma per qualche motivo sconosciuto 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

è tornato a collegarsi al server in SysPref e l'opzione del nome server corretta è apparso brevemente e poi è tornata a "unkown-00-00-12-34-56-78.home" proprio davanti ai miei occhi!

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

/ etc / resolver /

e questo impediva la risoluzione di un nome specifico, due anni dopo.

Sfortunatamente niente di tutto ciò mi ha aiutato, e dopo un'ora ho cercato di capirlo e di sbattere la testa contro il tavolino da caffè .. qualcosa, in qualche modo, da qualche parte ... ha rimosso il file /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist , 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: link

Ecco il codice di quell'elenco:

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

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 ricevere avvisi:

Operation not permitted while System Integrity Protection is engaged

Devi spegnerlo. Tutta l'istruzione qui: link

Dopo l'aggiornamento da Snow Leopard su un vecchio Mac Book a Mountain Lion, il sistema non ha potuto risolvere il DNS. Flushing, restart, niente ha aiutato. La modifica del Wi-Fi in un punto di accesso diverso (il mio telefono) ha aiutato.

Mountain Lion aggiunge un nuovo campo client alle impostazioni di rete DHCP. Compilare in questo campo sembrava rendere felice il punto di accesso wifi. Lasciandolo vuoto significava che non passava niente, anche se la connessione wifi sembrava avere successo.