Impossibile risolvere i nomi di dominio .foo.local

Il mio posto di lavoro ha una intranet con nomi di dominio come server01.foo.local, server02.foo.localecc. Di recente ho avviato l'ambiente live Fedora 16 per testarlo e ho scoperto che questi nomi di dominio non si risolvono.

Per esempio:

$ ping server01.foo.local
ping: host sconosciuto server01.foo.local
$ ping server01
PING server01.foo.local (XXXX) ...

Perché server01risolvere (e stampare il nome come server01.foo.local), ma server01.foo.localnon lo farà?

linux networking dhcp

— rhollencamp
fonte

Aveva esattamente lo stesso problema con Ubuntu in esecuzione in VMBox. La soluzione di @ adam820 ha funzionato anche per me.

— Jim

Risposte:

Anche se non sono al 100% sul ragionamento alla base del perché non funziona come previsto, sembra esserci un conflitto molto grande con il servizio mDNS (Avahi in Linux, Bonjour / Zeroconf in Mac / Windows) e le reti Windows che usa .local come nome di routing interno per i domini. Quello che sembra accadere è che quando si esegue il ping di server01, si ignora l'utilizzo di mDNS per la risoluzione e quindi l'aggiunta del dominio di ricerca (foo.local) alla richiesta, eseguendo correttamente la query del server DNS per server01.foo.local. Tuttavia, quando si utilizza mDNS (che utilizza .local come estensione del nome del computer predefinito), quando si tenta di eseguire il ping su server01.foo.local, si sta effettivamente trasmettendo su mDNS alla ricerca di un computer con il nome di "server01.foo"; quando fallisce, non passa al DNS semplice per qualsiasi motivo. Una grande soluzione a questo non è nominare il tuo dominio .local, che probabilmente va contro la maggior parte degli amministratori di Windows per la strutturazione del dominio. Detto ciò:

Se mDNS non ha alcuna conseguenza nella rete (come è comune nell'azienda, che tende a eseguire server DNS dedicati rispetto alla rete domestica, dove viene talvolta utilizzato mDNS), la modifica dell'ordine di ricerca è la soluzione più semplice.

Questo può essere trovato in /etc/nsswitch.conf. La sezione per gli host elencherà l'ordine, che per impostazione predefinita di Fedora 16 è:

hosts:      files mdns4_minimal [NOTFOUND=return] dns myhostname

Se lo cambi in:

hosts:      files dns mdns4_minimal [NOTFOUND=return] myhostname

dove stai spostando avanti nell'ordine di ricerca, questo dovrebbe sistemare le cose per ora. In alternativa, se sai che non ti servirà affatto mDNS, rimuovi semplicemente la parte "mdns4_minimal [NOTFOUND = return]".

Guardando questo bug sul tracker di Red Hat , sembra che si tratti di un problema di vecchia data senza alcuna apparente correzione al momento. Tuttavia, se qualcuno può fornire maggiori informazioni sul perché ciò accada in questo modo, sarebbe apprezzato.

— adam820
fonte

la rimozione della sezione mdns ha risolto il problema

— rhollencamp

Grazie mille per averlo aggiunto. Aveva esattamente lo stesso problema e lo spostamento della voce dns per prima cosa lo ha risolto. Nel mio caso, sto usando Ubuntu più recente, non Fedora, ma la soluzione era esattamente la stessa.

— Jim

non vale niente, ho appena provato questo e ho scoperto che l'utilizzo di VPN Cisco vpncnon può connettersi dopo aver rimosso quelle voci sulla hosts: .*linea in /etc/nsswitch.conf. La sostituzione di queste impostazioni ha risolto il problema.

— Dobbs,

"quando fallisce, non passa al DNS semplice per qualsiasi motivo." . Il motivo è abbastanza ovvio. [NOTFOUND=return]significa "se mDNS ti dice che non è stato trovato un nome .local, allora è autorevole e non ha senso chiedere di più". Spostare DNS prima di mDNS è una soluzione alternativa, ma è già sufficiente rendere non autorevoli gli errori mDNS.

— Salterio

Sì, questo è un commento valido; questo era 7 anni fa e non lo sapevo al momento. Sì, rimuoverlo, rimuovere il pacchetto come indicato di seguito o modificare l'ordine sono soluzioni / soluzioni alternative valide.

— adam820,

Suggerirei un'altra soluzione nel caso in cui si stia utilizzando il .localdominio. Innanzitutto non è una buona idea in quanto sembra uno standard / convenzione da utilizzare .localper alcune scoperte dinamiche multicast.

Ma se insisti, è anche più semplice rimuovere il nss-mdnspacchetto o il libnss-mdnspacchetto in base alla distribuzione e il problema verrà risolto. Se non hai bisogno di quella funzionalità, allora perché persistere lì?

Ecco yum info nss-mdns:

Summary     : glibc plugin for .local name resolution
URL         : http://0pointer.de/lennart/projects/nss-mdns/
License     : LGPLv2+
Description : nss-mdns is a plugin for the GNU Name Service Switch (NSS)
            : functionality of the GNU C Library (glibc) providing host name
            : resolution via Multicast DNS (aka Zeroconf, aka Apple Rendezvous,
            : aka Apple Bonjour), effectively allowing name resolution by common
            : Unix/Linux programs in the ad-hoc mDNS domain .local.
            : 
            : nss-mdns provides client functionality only, which means that you
            : have to run a mDNS responder daemon separately from nss-mdns if
            : you want to register the local host name via mDNS (e.g. Avahi).

— akostadinov
fonte

Alcune cose che puoi controllare:

c'è un ordine in /etc/host.conf, che specifica di controllare / etc / hosts prima di interrogare DNS?
server01 è in / etc / hosts?
c'è un search foo.local/ etc / resolv, conf? Ciò aggiungerebbe foo.local a qualsiasi nome host che stai cercando

Mi chiedo se il tuo nameserver sia impostato correttamente. Se avete ancora nslookup, cosa per tornare server01, server01.foo.locale l'indirizzo IP (ricerca inversa)?

— ott--
fonte

* host.conf non ha nulla a che fare con l'ordine * server01 non è in / etc / hosts * ricerca foo.local è in /etc/resolv.conf (NetworkManager mettilo lì), ma rimuoverlo non aiuta. Ho provato a proteggere la scrittura /etc/resolv.conf dopo averlo modificato in modo che NM non potesse sovrascrivere e riavviare; no dice

— rhollencamp

@rhollencamp: hai nslookup sul tuo sistema?

— ott--