Cómo vaciar la caché de DNS local en CentOS

Estoy buscando una manera de vaciar el caché de DNS local en un CentOS 6.

El sistema no está ejecutando ningún servidor DNS ni nada, y deseo que cada consulta DNS se envíe al servidor de nombres configurado, incluso para los duplicados.

La mayor parte de lo que encontré en línea me dice que haga service nscd restart, recargue o haga nscd -i hosts. Sin embargo, ninguno parece vaciar el caché.

Así que me pregunto si alguien tiene una idea de cómo podría hacer esto. ¿Hay algún tipo de cambio en el kernel que necesito cambiar? Cualquier tipo de trabajo también está bien.

— zee
fuente

¿Qué está haciendo para verificar si el caché se ha vaciado o no?

— John

ok, es un poco complicado, tengo un programa en mi sistema escuchando en el puerto 53 y reenvío las consultas DNS de cierta manera, y también un proxy http que usa localhost como 'servidor DNS'; en la primera consulta (por ejemplo wget -e 'http_proxy=localhost:3128' xxx.com) puedo ver que la consulta se reenvía correctamente, pero no todas las posteriores. Si espero lo suficiente (el caché caduca), funcionará nuevamente.

— zee

Y también configuré el proxy (calamar) para que no guarde en caché ningún objeto, por lo que supongo que el sistema todavía está almacenando en caché la respuesta de alguna manera

— zee

nscd -i hosts -> funciona todo el tiempo. Reinicié nscd 3 veces seguidas y no quería borrar el caché.

— Danie

nscd no parece ser una cosa en CentOS 7 minimal. Sé que la pregunta llama a CentOS 6, pero el título llama a CentOS en general. ¿Cuál es la forma de CentOS 7?

— duct_tape_coder

Respuestas:

No es su caja local la que está almacenando en caché las solicitudes de DNS, pero es la resolución de DNS que está utilizando en su /etc/resolv.confalmacenamiento en caché.

Para evitar que esas consultas en caché respondan:

Cambiar el resolutor.

$ dig @<resolve-ip> www.google.com
Vacíe el caché DNS en el resolutor, si puede acceder al servidor DNS.

$ sudo /etc/init.d/bind restart

— Pradeepchhetri
fuente

Hmm, pero dns_nameservers 127.0.0.1configuré el archivo de configuración del proxy y el oyente solo reenvía consultas al servidor de nombres preconfigurado, ¿no debería ser el caso de que resolv.conf ni siquiera sea consultado?

— zee

"bash: /etc/init.d/bind: No existe tal archivo o directorio" Y el método del OP obtiene "No se pudo reiniciar nscd.service: la unidad nscd.service no se pudo cargar: No existe tal archivo o directorio". Supongo que estos se han movido / cambiado. ¿Por qué no pueden simplemente dejar cosas que funcionan en su lugar, o al menos mantener alias? Lo suficientemente malo como para tener que convertirse en un especialista en sistemas operativos para usar simplemente una caja de Linux. Peor cuando tiene que volver a aprender el sistema operativo con cada versión.

— JosephK

Incluso después de actualizar o vaciar el caché DNS en la máquina del cliente si no funciona, mire su servidor o la máquina del cliente está vinculada a cualquier servidor NIS, en caso afirmativo, cambie los "hosts: archivos nis dns" a "hosts: archivos dns nis" entrada en el archivo /etc/nsswitch.conf y también debe cambiar la dirección IP en la lista de hosts del servidor maestro NIS.

— Vilas Addagatla
fuente

Esto llevó a mi solución. Dentro de / etc / hosts estaba la dirección IP anterior configurada estáticamente anteriormente. Algo que había hecho hace un tiempo. Eliminar esa línea (o reemplazarla con la nueva ip) resolvió el problema y me permitió hacer ping a mi máquina usando su nombre de host.

— Paul

Estoy casi seguro de que no es el sistema el que almacena la respuesta: esa parte (el almacenamiento en caché del sistema) solo es manejada por el nscddemonio. Reiniciar (o detener por completo) que el demonio restablece o elimina el almacenamiento en caché del sistema operativo de las respuestas de solicitud de servicio de nombres.

Ofreceré dos posibilidades, aunque el oyente personalizado que ha configurado en el puerto 53 enturbia considerablemente las aguas:

A) Su sistema está emitiendo consultas en sentido ascendente, pero el solucionador de nombre en sentido ascendente inmediato está almacenando en caché la respuesta en función de su configuración o del TTL del registro.
B) Su escucha personalizada está almacenando en caché las respuestas internamente y solo está devolviendo esa respuesta al sistema cuando se le pregunta nuevamente antes de que el tiempo de caché haya expirado.

— John
fuente

Gracias por la entrada, pero el oyente no hace nada más que reenviar la consulta y la respuesta, después de todo, es solo como 200 líneas de código. Entonces no debería ser el segundo caso; Además, el oyente está imprimiendo todo lo que recibe, así que estoy seguro de que no está recibiendo nada: |

— zee