Errore temporaneo nella risoluzione dei nomi

Continuo a ricevere un messaggio di errore ogni volta che faccio qualcosa che richiede una ricerca DNS sul mio server CentOS. Per esempio:

[root @ 15557 ecc.) # wget http://www.whitehouse.gov/sites/default/files/rss_viewer/birth-certificate-long-form.pdf
--2011-05-03 20: 55: 35-- http://www.whitehouse.gov/sites/default/files/rss_viewer/birth-certificate-long-form.pdf
Risoluzione di www.whitehouse.gov ... non riuscita: errore temporaneo nella risoluzione dei nomi.
wget: impossibile risolvere l'indirizzo host `www.whitehouse.gov '

Se riavvio il server, questo problema scompare per un breve periodo, ma ritorna sempre dopo circa un'ora. Se cambio gli IP dei nameserver elencati in resolv.conf, il problema non viene risolto, anche se li sostituisco con nameserver comuni come quelli di Google 8.8.8.8. Se svuoto la cache degli host dopo la modifica resolve.conf, non risolve nemmeno il problema. Dopo il riavvio del server, resolv.confviene ripristinato i valori predefiniti (suppongo che alcuni DHCP).

— whitelines222
fonte

Qualche perdita di pacchetti in uscita sul tuo server? Accenderei uno sniffer di pacchetti e vedere come appare il traffico DNS quando ciò accade.

— SEE

Puoi consigliare uno sniffer di pacchetti? Non ho installato un software simile prima. Grazie.

— whitelines222

tcpdumpè prontamente disponibile nella maggior parte delle distribuzioni tramite il loro repository di pacchetti. Tuttavia, consiglierei di cercare su Google un tutorial su tcpdump prima di iniziare. Inoltre, è possibile utilizzare tcpdump per acquisire i pacchetti e scriverli in un file di registro, quindi è possibile aprire quel file di registro in uno strumento GUI chiamato Wireshark, che è un po 'più intuitivo rispetto all'utilizzo della CLI.

— SEE

tcpdump -Ani <your_interface> -s0 port domain (-w my.log &)

— 3molo

Risposte:

Questo potrebbe essere un problema causato dal server DHCP, in realtà, da un server DHCP errato o un altro server configurato in modo errato sulla rete.

Probabilmente , questo è ciò che accade: quando il tuo server si avvia, riesce a ottenere i parametri precisi ( indirizzo IP, gateway, server DNS, ecc. ) Dal server DHCP legittimo e, di conseguenza, non avrai alcun problema fino al leasing rinnovo. Dopo un periodo di tempo relativamente breve ( dipende dalla configurazione del client e del server dhcp), il client DHCP tenterà di rinnovare il contratto di locazione, contattando il server DHCP legittimo (tramite trasmissione unicast). Se questo per qualche motivo fallisce o il tuo client DHCP per qualche motivo non ottiene una risposta dal server DHCP legittimo, entrerà in stato di rebinding e trasmetterà una richiesta per prolungare il tempo di leasing. Se il ladro / un altro server DHCP non configurato correttamente riesce a rispondere per primo, potrebbe inviare al client DHCP parametri inaccurati , ad esempio un indirizzo del server DNS "errato" e, di conseguenza, non sarà possibile risolvere i nomi host.

Se la mia speculazione è corretta, il riavvio del server non risolve sempre il problema, poiché potrebbero esserci momenti in cui il server DHCP non autorizzato risponde per primo e, di conseguenza, si verifica il problema menzionato.

In ogni caso, prova a configurare indirizzi IP statici, disabilitare DHCP e impostare manualmente i server DNS. Inoltre, dovresti probabilmente verificare se sulla tua rete sono in esecuzione altri server DHCP, oltre a quello che stai utilizzando.

— dkaragasidis
fonte

Come faccio a sapere se nella mia rete è presente un server DHCP non autorizzato? serverfault.com/questions/8526/…

— Elijah Lynn

Nel mio caso, avrei impostato le regole fw per l'interfaccia sbagliata. Quindi la porta 53 non era aperta e il server non ha potuto effettuare un req DNS

— grahamrhay
fonte