Ricerca e dominio in risolv.conf = ricerca lente su Ubuntu

Ho una macchina che esegue server ubuntu 10.04. Ho iniziato a get lunghi ritardi (5-10 secondi) quando si collegano (alcuni) siti esterni alla LAN utilizzando strumenti come curl e wget .

Utilizzando tcpdump e wireshark, ho trovato che il problema si trova nelle ricerche DNS che vengono eseguite per impostare la connessione:

  • Vantaggi / svantaggi di spostamento da un gruppo di lavoro al dominio
  • Perché nslookup non utilizza mdns mentre ping fa?
  • il secondo server di nomi in /etc/resolv.conf non prelevato da wget
  • Come è configurata la ricerca DNS per OSL Mountain Lion?
  • Configurare i record DNS corretti per il server web separato e il server di posta elettronica
  • Come configurare i nomi di dominio multiplo in resolv.conf?
  • ESEMPIO

    Quando corrono:

     wget www.site1.com 

    Vedo il seguente comportmento:

     LOOKUP: AAAA www.site1.com # => fail, no delay, site1 doesn't have an IPv6 AAAA record LOOKUP: AAAA www.site1.com.mydomain.lan # => fail, BIG DELAY, crazy domain doesn't exist LOOKUP: A www.site1.com # => success, no delay, resolves as expected (site1 has IPv4 A record) CONNECTION PROCEEDS ... 

    MY SETUP

    Il resolv.conf del mio server ha il seguente aspetto:

     nameserver 192.168.0.1 # my router domain mydomain.lan # made up domain name, for my lan search mydomain.lan 

    Il file dell'host del server ha il seguente aspetto:

     127.0.0.1 localhost.localdomain localhost 192.168.0.10 server1.mydomain.lan server1 # The following lines are desirable for IPv6 capable hosts ::1 localhost ip6-localhost ip6-loopback fe00::0 ip6-localnet ff00::0 ip6-mcastprefix ff02::1 ip6-allnodes ff02::2 ip6-allrouters 

    RISOLUZIONI?

    Perché il mio elenco di ricerca resolv.conf viene utilizzato per build il nome della seconda ricerca, quando la pagina man di resolv.conf suggerisce che viene utilizzata solo quando si esegue la ricerca di nomi host (senza puntini):

    "Le query di risoluzione con punti di dimensione minore di punti (il valore predefinito è 1) verranno tentati utilizzando each componente del path di ricerca finché non viene trovata una corrispondenza".

    Sono sotto l'impressione, la seconda ricerca è errata e non dovrebbe essere eseguita affatto …

    Se rimuovo il domain e search righe di search da resolv.conf, la seconda ricerca non è più stata eseguita ei miei ritardi andranno via.

    (anche se impongo a wget di occuparsi solo di IPv4, le ricerche AAAA non vengono fatte, quindi i ritardi si dissetano):

     wget --inet4-only www.site1.com 

    2 Solutions collect form web for “Ricerca e dominio in risolv.conf = ricerca lente su Ubuntu”

    Questo comportmento è di progettazione.

    Si preferisce IPv6, quindi viene determinato innanzitutto lo stato della risorsa in termini AAAA . Viene NXDOMAIN risposta NXDOMAIN – in modo che il cliente abbia bisogno di aggiungere il path di search .

    Si noti che l'osservazione di ndots che hai fatto è corretto – ma non tutta la storia. Se il numero di ndots supera il nome in questione (se si trattasse di un singolo nome di etichetta, in questo caso), l'unica differenza al comportmento della query è che la query con il suffisso appaia prima di tentare il nome grezzo. Dal momento che sei al di sopra della soglia di ndots , il nome viene prima provato, come previsto. Vedi ulteriormente nella pagina man:

    L'impostazione predefinita per n è 1, il che significa che se ci sono punti in un nome, il nome verrà prima eseguito come nome assoluto prima che gli elementi dell'elenco di ricerca siano stati aggiunti.

    Quella query non è rioutput, quindi è necessario utilizzare l'elenco di ricerca. Notare la differenza nel comportmento della query con wget http://site1/ .


    Quello che stai vedendo è il comportmento previsto – quello che penso che è necessario risolvere è la confluenza di fattori che provocano questa ricerca lenta.

    • Fissare il tuo server DNS o risolvere il metodo a monte che ricorre. Un recursore dovrebbe facilmente memorizzare la NXDOMAIN che viene dalle radici quando cerca di cercare un TLD inesistente. Poiché distriggersndo l'interface IPv6, è ansible che tu abbia un server DNS nel path che non è in grado di eseguire la cache quando sono coinvolti i look AAAA . Prova a cambiare il resolver in 8.8.8.8 per verificare.
    • Interrompere l'aggiunta di un path di ricerca per una zona DNS che non è ansible eseguire ricerche. Se il tuo server DNS fosse autorevole per quella zona (che è ciò che whereva essere per quella impostazione di search per essere di qualsiasi uso, in quanto non è un nome valido nella gerarchia pubblica), risponderebbe immediatamente. Probabilmente non è necessaria questa configuration di search – ma impostala su qualcosa che risolverà, in modo che non cerchi di indovinarlo dal nome host della macchina. search com dovrebbe fare bene.

    Se ad un prompt shell si dice $ hostname e ritorna foo.bar.baz , il resolver DNS capisce che il tuo hostname è foo e il tuo nome di dominio è bar.baz . Generalmente le righe "dominio" e "ricerca" in /etc/resolv.conf sono solo utili se questo non è vero (o se intendi provocare un comportmento insolito).

    Se il tuo nome di dominio è veramente bar.baz , probabilmente non dovresti specificare né le righe "dominio" né "ricerca" in /etc/resolv.conf. Contrariamente a quanto spesso è vero in altri luoghi, in /etc/resolv.conf essendo "prissy" re-specificando le informazioni già disponibili da hostname solitamente comportmenti bizzarri e indesiderati (inclusi i lunghi timeout scioccati). Ciò è vero in ambiti commerciali sia in grandi ambienti domestici.

    (Caveat: Ogni programma applicativo può potenzialmente interpretare /etc/resolv.conf un po 'in modo diverso, quindi in teoria questo potrebbe non essere universalmente vero. Nei sisthemes più moderni, sebbene il 99% delle richieste del resolver passa attraverso GLIBC è quasi sempre vero.)

    Suggerimenti per Linux e Windows Server, quali Ubuntu, Centos, Apache, Nginx, Debian e argomenti di rete.