Le ricerche DNS non riescono con ad es. 'ping', ma funziona con 'host'

Perché hanno fatto questo cambiamento, non lo so, ma mi ha fatto impazzire per un po '.

Non so sapere perché le cose funzionano per l'host, ma non per il ping, ma io penso che ha a che fare con la natura di queste due utilità. Ping è un'utilità di diagnostica semplice (anche se molto utile) per far cadere i pacchetti sul filo che dovrebbero essere restituiti a te. La funzionalità di ricerca del nome host è solo un effetto collaterale del lavoro e passata al risolutore ricorsivo del sistema (credo - non ho verificato controllando le librerie collegate o qualcosa del genere). Il compito principale dell'host è di fare la risoluzione dei nomi DNS, quindi implementa il proprio risolutore ricorsivo.

Il resolver ricorsivo di Apple è mDNSResponder. Per qualche ragione, la versione di mDNSResponder in Lion richiede l'opzione della riga di comando "-AlwaysAppendSearchDomains" per comportarsi come ha fatto in Snow Leopard (almeno).

Ecco un modo rapido per risolverlo:

sudo sed -i .orig '/ProgramArguments/,/<\/array>/ {
s/\(<string>-launchd<\/string>\)/\
                <string>-AlwaysAppendSearchDomains<\/string>/
}' /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist

(Dovrebbero esserci due caratteri di tabulazione all'inizio della penultima riga sopra, ma non sono riuscito a capire come ottenere questo piccolo editor per inserire le tabulazioni, quindi ho aggiunto 16 spazi. ma le schede si adattano meglio alla spaziatura del file originale.)

Questo aggiungerà l'argomento "-AlwaysAppendSearchDomains" al file plist di avvio mDNSResponder (e salverà una copia di backup), ma poiché questo è controllato da launchd, quel sistema deve essere avvisato di riavviare mDNSResponder.

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

Ora, se controlli il tuo processo mDNSResponder in esecuzione, dovresti vederlo in esecuzione con il tuo nuovo argomento:

ps auxww | grep mDNSResponder

(Puntata su link e link , dove ho trovato le mie risposte a questo problema.)

Dalla pagina man host (1):

Mac OS X NOTICE

The host command does not use the host name and address resolution or the DNS query routing mechanisms used by other processes running on Mac OS X. The results of name or address queries printed by host may differ from those found by other processes that use the Mac OS X native name and address resolution mechanisms. The results of DNS queries may also differ from queries that use the Mac OS X DNS routing library.

Sfortunatamente, non ci sono informazioni su come esattamente il comando host risolve i nomi degli host. Questo comportamento lo rende un po 'inutile per il debugging, IMHO.

Cronologia di base ... nslookup era il comando, ma aveva la sua implementazione di tutte le sue routine di resolver. Quello che è successo è che i risolutori di sistema su piattaforme diverse hanno funzionato in modo diverso da nslookup. A volte, questo produrrebbe risultati piuttosto diversi.

I comandi host e dig sono stati creati come "riscrittura" per nslookup. Collegano staticamente le funzioni del resolver di sistema. Il risolutore di sistema è una raccolta di funzioni nella libreria C standard di un sistema UNIX o UNIX (su Mac OS X, queste funzioni fanno parte della libreria netdb). In questo modo, i comandi host e dig funzionano sempre allo stesso modo del risolutore di sistema per qualsiasi sistema operativo per cui sono stati creati, ma non si basano su di essi. In questo modo, sono strumenti diagnostici eccellenti nei casi in cui il risolutore del sistema non funziona correttamente.

NOTA: l'host e scavare entrambi leggono la lista dei server dei nomi da /etc/resolv.conf a meno che non abbiano un nameserver specifico con cui parlare. Solo il comando host utilizza l'elenco di ricerca nel file /etc/resolv.conf; dig non lo fa, motivo per cui si deve sempre dare FQDN dig per risolvere qualsiasi cosa. Entrambi i comandi sono altrimenti completamente autosufficienti; ad esempio, il file /etc/resolv.conf è l'unica cosa che non si trova nel file binario che usano.

mDNSresponder è Bonjour. Non l'ho approfondito troppo profondamente, ma sospetto che questa configurazione non risolva questo o almeno, non direttamente. Ho appena avuto questo stesso problema su Mac OS X 10.9.1 e il semplice riavvio di mDNSresponder lo ha risolto per me. Non ho mai visto questo problema prima su 10.5 - > 10.8 / 10.9 su qualsiasi altro sistema. Inoltre, le applicazioni GUI non ne sono state influenzate, erano solo gli strumenti a riga di comando, come ping e ssh che si sono interrotti.

Se trovo il tempo di scavare un po 'di più nella libreria, vedrò se riesco a trovare una spiegazione più completa.

Ho creato uno script di shell per automatizzare la correzione (e un programma di disinstallazione se ne hai bisogno in seguito), qui:

link

Questo era dare agli utenti meno tecnici al lavoro che potrebbero evitare di modificare manualmente i file di sistema.

.local è riservato per il multicast. mDNS e server DNS sulla stessa rete usando .local possono essere problematici.

L'host sta aggiungendo il suffisso .local dns. Ping non lo è. Se trovi questo sconcertante, puoi aggiungere .local come suffisso predefinito nelle preferenze del sistema di rete e il sistema lo aggiungerà quando tenterà di risolvere i nomi degli host.

Se hai provato tutto quanto sopra e non hai funzionato, puoi aggiungere i tuoi server dei nomi e percorsi di ricerca a System Preferences>Network>Advance(bottom right of the window)>DNS tab

Questo aggiornamento /etc/resolv.conf e il ping dovrebbero ora funzionare. L'aggiornamento del percorso di ricerca modificando /etc/resolv.conf non funziona davvero, ma ciò avviene per qualche motivo.

UPDATE:

La modifica di /etc/resolv.conf non funziona perché il sistema operativo riscrive il file in base all'impostazione del riquadro Preferenze di sistema.

Mi manca una reputazione sufficiente per commentare il post di Lamont Peterson . Il riavvio di mDNSresponder ha funzionato per me su Mac OS X 10.7 (Lion). A differenza di Lamont Peterson, questo problema mi ha causato problemi con un'applicazione GUI: Safari non è stato in grado di risolvere nomi host pubblici o privati. Ecco i passaggi specifici che ho fatto e che sospetto che anche Lamont Peterson abbia fatto:

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

Il unload spegne mDNSresponder e load lo riavvia.

Questo risolve immediatamente il problema; nessun riavvio richiesto.

Puoi verificare che sia stato riavviato correttamente utilizzando il comando list :

$ sudo launchctl list | grep '^PID\|mDNSResponder'
PID     Status  Label
708     -       com.apple.mDNSResponder
-       0       com.apple.mDNSResponderHelper

La presenza di un Process ID (PID) significa che è in esecuzione. 708 varierà in base alle assegnazioni del sistema operativo. Se lo stato mostra qualcosa di diverso da un trattino o zero, qualcosa è andato storto.

Non so come mDNSResponderHelper interagisca con mDNSResponder ; Ho sempre dovuto riavviare mDNSResponder .

In una riga:

sudo kill $(ps ax | grep mDNSResponder | grep -v grep | grep -v Helper | awk '{ print $1 }')

nota di pls sui nomi OSX può essere non standard, quindi per completezza:

• FQDN è pingable
I nomi
• nei file "hosts" sono pingable

I nomi MAC NON sono in generale: due correzioni devono essere fatte: a) cambia spazi in "-" b) aggiungi .local

quindi ad esempio il mio Mac: il MacBook Pro di ingconti

sarà pingable a ingcontis-MacBook-Pro.local

E aprendo le preferenze puoi vedere: