Fallo temporal en la resolución de nombres

Sigo recibiendo un mensaje de error cada vez que hago algo que requiere una búsqueda de DNS en mi servidor CentOS. P.ej:

[root @ 15557, etc.] # 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
La resolución de www.whitehouse.gov ... falló: falla temporal en la resolución de nombres.
wget: no se puede resolver la dirección del host `www.whitehouse.gov '

Si reinicio el servidor, este problema desaparece por un corto tiempo, pero siempre vuelve después de una hora más o menos. Si cambio las direcciones IP de los servidores de nombres que figuran en la lista resolv.conf, el problema no se soluciona, incluso si las sustituyo por servidores de nombres comunes como el de Google 8.8.8.8. Si elimino el caché de hosts después de cambiarlo resolve.conf, tampoco soluciona el problema. Después de reiniciar el servidor, resolv.confse vuelve a cambiar a sus valores predeterminados (supongo que algunos DHCP).

— whitelines222
fuente

¿Alguna pérdida de paquetes salientes en su servidor? Encendería un sniffer de paquetes y vería cómo se ve el tráfico DNS cuando esto sucede.

— EEAA

¿Me puede recomendar un sniffer de paquetes? No he instalado dicho software antes. Gracias.

— whitelines222

tcpdumpestá disponible en la mayoría de las distribuciones a través de su repositorio de paquetes. Sin embargo, recomendaría buscar en Google un tutorial de tcpdump antes de comenzar. Además, puede usar tcpdump para capturar los paquetes y escribirlos en un archivo de registro, luego puede abrir ese archivo de registro en una herramienta GUI llamada Wireshark, que es un poco más fácil de usar que usar la CLI.

— EEAA

tcpdump -Ani <your_interface> -s0 puerto dominio (-w my.log &)

— 3molo

Respuestas:

Esto podría ser un problema causado por el servidor DHCP, en realidad, por un servidor DHCP mal configurado u otro mal configurado en su red.

Probablemente , esto es lo que sucede: cuando su servidor arranca, logra obtener los parámetros precisos ( dirección IP, puerta de enlace, servidores DNS, etc. ) del servidor DHCP legítimo y, como resultado, no experimentará ningún problema hasta el arrendamiento renovación. Después de un período de tiempo relativamente corto ( depende de la configuración del servidor y el cliente dhcp), el cliente DHCP intentará renovar el contrato de arrendamiento contactando al servidor DHCP legítimo (a través de la transmisión de unidifusión). Si por alguna razón esto falla o su cliente dhcp por alguna razón no obtiene una respuesta del servidor DHCP legítimo, entrará en estado de reenlace y transmitirá una solicitud para extender el tiempo de arrendamiento. Si el servidor DHCP no autorizado / mal configurado se las arregla para responder primero, podría enviarle a su cliente DHCP parámetros incorrectos, por ejemplo, una dirección de servidor DNS "incorrecta" y, como resultado, no podrá resolver los nombres de host.

Si mi especulación es correcta, reiniciar su servidor no siempre resuelve el problema, ya que puede haber ocasiones en que el servidor DHCP falso responda primero y, como resultado, experimente el problema que mencionó.

En cualquier caso, intente configurar direcciones IP estáticas, deshabilite DHCP y configure manualmente los servidores DNS. Además, probablemente debería verificar si algún otro servidor DHCP se está ejecutando en su red, además del que está utilizando.

— dkaragasidis
fuente

¿Cómo puedo encontrar si hay un servidor DHCP falso en mi red? serverfault.com/questions/8526/…

— Elijah Lynn el

En mi caso, configuraría las reglas fw para la interfaz incorrecta. Por lo tanto, el puerto 53 no estaba abierto y el servidor no podía hacer una solicitud de DNS

— grahamrhay
fuente