Le ricerche DNS falliscono ad esempio con `ping`, ma funzionano con` host`

Sto usando pfSense 2.0rc3 e l'ho impostato come server d'inoltro DNS e ho abilitato "Registra lease DHCP nel server d'inoltro DNS" e ciò che comprendo sono tutte le impostazioni appropriate per ottenere il server DNS per le ricerche locali.

Funziona come previsto con Linux e in particolare posso eseguire host abce ping abc(e altre applicazioni) e funzionano tutti come previsto.

Tuttavia, in Mac OS X Lion 10.7 non funziona come previsto. In particolare, solo le ricerche con il hostcomando sembrano funzionare, ad es

$ ping abc
ping: cannot resolve abc: Unknown host

$ host abc
abc.local has address 192.168.1.128

$ ping abc.local
ping: cannot resolve abc.local: Unknown host

$ host abc.local
abc.local has address 192.168.1.128

Perché la ricerca del abclavoro funziona quando si utilizza il hostcomando ma non riesce con ping(e altre applicazioni)?

Grazie per aver letto.

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

Non so perché le cose funzionino per l'host, ma non per il ping, ma penso che abbia a che fare con la natura di queste due utility. Il ping è un'utilità diagnostica semplice (anche se molto utile) per far cadere pacchetti sul filo che dovrebbe essere ripetuto. La funzionalità di ricerca del nome host è solo un effetto collaterale del lavoro e viene trasmessa al risolutore ricorsivo del sistema (credo - non ho verificato controllando le librerie collegate o qualcosa del genere). Il compito principale di Host è eseguire la risoluzione dei nomi DNS, quindi implementa il proprio risolutore ricorsivo.

Il risolutore ricorsivo di Apple è mDNSResponder. Per qualche motivo, la versione di mDNSResponder in Lion richiede l'opzione da riga di comando "-AlwaysAppendSearchDomains" per comportarsi come in Snow Leopard (almeno).

Ecco un modo rapido per risolverlo:

sudo sed -i .orig '/ProgramArguments/,/<\/array>/ {
s/\(<string>-launchd<\/string>\)/\1\
                <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 schede, quindi ho aggiunto 16 spazi. O dovrebbero funzionare, ma le schede adatta meglio la spaziatura del file originale.)

Ciò aggiungerà l'argomento "-AlwaysAppendSearchDomains" al file del plist di avvio di mDNSResponder (e salverà una copia di backup), ma poiché questo è controllato da launchd, è necessario dire al sistema 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

(Propone a http://www.makingitscale.com/2011/fix-for-broken-search-domain-resolution-in-osx-lion.html e http://kavassalis.com/2011/07/wtf-bug -in-os-x-10-7 / , dove ho trovato le mie risposte a questo problema.)

Dalla pagina man host (1):

AVVISO per Mac OS X.

Il comando host non utilizza il nome host e la risoluzione dell'indirizzo o i meccanismi di routing delle query DNS utilizzati da altri processi in esecuzione su Mac OS X. I risultati delle query nome o indirizzo stampate dall'host potrebbero differire da quelli rilevati da altri processi che utilizzano il Mac Meccanismi di risoluzione dei nomi e degli indirizzi nativi di OS X. I risultati delle query DNS possono anche differire dalle query che utilizzano la libreria di routing DNS di Mac OS X.

Sfortunatamente, non ci sono informazioni su come esattamente il comando host risolve i nomi host. Questo comportamento lo rende in qualche modo inutile per il debug, IMHO.

Storia di base ... nslookup era il comando, ma aveva la propria implementazione di tutte le sue routine di risoluzione. Ciò che è iniziato è stato che i risolutori di sistema su piattaforme diverse hanno funzionato diversamente da nslookup. A volte, questo produrrebbe risultati piuttosto diversi.

I comandi host e dig sono stati creati come "riscrittura" per nslookup. Si collegano staticamente alle funzioni del resolver di sistema. Il risolutore di sistema è una raccolta di funzioni nella libreria C standard di un sistema simile a 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 esso. In questo modo, sono eccellenti strumenti diagnostici nei casi in cui il resolver di sistema non funziona correttamente.

NOTA: Ospitare e scavare entrambi leggono l'elenco dei nameserver da /etc/resolv.conf a meno che non ricevano un nameserver specifico con cui parlare. Solo il comando host utilizza l'elenco di ricerca nel file /etc/resolv.conf; scavare no, motivo per cui si deve sempre dare scav FQDN per risolvere qualsiasi cosa. In caso contrario, entrambi i comandi sono completamente autosufficienti; ad esempio, il file /etc/resolv.conf è l'unica cosa che non si trova nel file binario che usano.

mDNSresponder è Bonjour. Non ci ho scavato troppo a fondo, ma sospetto che questa impostazione di configurazione non risolva questo o almeno, non direttamente. Ho appena riscontrato 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 della GUI non ne sono state influenzate, sono stati solo gli strumenti da riga di comando, come ping e ssh, a rompersi.

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

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

https://github.com/michthom/AlwaysAppendSearchDomains

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

.local è riservato per multicast. I server mDNS e DNS sulla stessa rete che utilizzano .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 host.

Nel caso in cui si è tentato tutto quanto sopra e niente ha funzionato quindi è possibile aggiungere le nameserver e percorsi di ricerca perSystem Preferences>Network>Advance(bottom right of the window)>DNS tab

Questi aggiornamenti /etc/resolv.conf e ping dovrebbero ora funzionare. L'aggiornamento del percorso di ricerca modificando /etc/resolv.conf non funziona davvero, ma questo per qualche motivo.

AGGIORNARE:

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 la 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 ha causato problemi con un'applicazione GUI per me - Safari non è stato in grado di risolvere i nomi host pubblici o privati. Ecco i passaggi specifici che ho fatto e che sospetto abbia fatto anche Lamont Peterson:

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

I unloadChiude mDNSResponder e loadla fa ripartire.

Ciò ha risolto immediatamente il problema; nessun riavvio richiesto.

È possibile verificare che sia stato riavviato correttamente utilizzando il listcomando:

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

La presenza di un ID processo (PID) indica che è in esecuzione. 708varierà come viene assegnato dal sistema operativo. Se lo stato mostra qualcosa di diverso da un trattino o zero, qualcosa è andato storto.

Non so come mDNSResponderHelperinteragisce mDNSResponder; Ho sempre e solo dovuto riavviare mDNSResponder.

In una riga:

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

si prega di notare che i nomi OSX possono essere non standard, quindi per completezza:

• I nomi di dominio completi sono pingabili
• i nomi nei file "hosts" sono pingabili

I nomi dei Mac NON sono in generale: è necessario eseguire due correzioni: a) cambiare gli spazi in "-" b) aggiungere .local

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

sarà possibile eseguire il ping su: ingcontis-MacBook-Pro.local

E aprendo le preferenze puoi vedere: