Evitar tiempos de espera de DNS cuando falla un servidor DNS

Tenemos un pequeño centro de datos con aproximadamente cien hosts apuntando a 3 servidores DNS internos (enlace 9). Nuestro problema surge cuando uno de los servidores internos de DNS no está disponible. En ese punto, todos los clientes que apuntan a ese servidor comienzan a funcionar muy lentamente.

El problema parece ser que el solucionador de Linux no tiene realmente el concepto de "conmutación por error" a un servidor DNS diferente. Puede ajustar el tiempo de espera y la cantidad de reintentos que usa (y configurar rotar para que funcione en la lista), pero no importa qué configuración use uno de nuestros servicios, funcionará mucho más lentamente si un servidor DNS primario no está disponible. Por el momento, esta es una de las mayores fuentes de interrupciones del servicio para nosotros.

Mi respuesta ideal sería algo así como "RTFM: tweak /etc/resolv.conf like this ...", pero si esa es una opción, no la he visto.

Me preguntaba cómo otras personas manejaron este problema.

Puedo ver 3 posibles tipos de soluciones:

• Utilice linux-ha / Pacemaker y failover ips (para que los VIP IP de dns estén "siempre" disponibles). Por desgracia, no tenemos una buena infraestructura de cercado, y sin el marcapasos de cercado no funciona muy bien (en mi experiencia, Pacemaker reduce la disponibilidad sin cercado).

• Ejecute un servidor dns local en cada nodo y haga que resolv.conf apunte a localhost. Esto funcionaría, pero nos daría muchos más servicios para monitorear y administrar.

• Ejecute un caché local en cada nodo. La gente parece considerar que nscd está "roto", pero dnrd parece tener el conjunto de características correcto: marca los servidores dns como activos o inactivos, y no usará servidores dns "inactivos".

Any-casting parece funcionar solo en el nivel de enrutamiento ip, y depende de las actualizaciones de ruta para la falla del servidor. La transmisión múltiple parecía ser una respuesta perfecta, pero bind no admite la transmisión ni la transmisión múltiple, y los documentos que pude encontrar parecen sugerir que la DNS multidifusión está más dirigida al descubrimiento de servicios y la configuración automática en lugar de la resolución DNS normal. .

¿Me estoy perdiendo una solución obvia?

Un par de opciones Ambos distribuirán la carga de DNS en sus servidores DNS.

• Intente usar options rotateen resolv.conf. Esto minimizará el impacto de la caída del servidor primario. Si uno de los otros servidores está inactivo, ralentizará las acciones.
• Use un orden de servidor de nombres diferente en diferentes clientes. Esto permitirá que algunos clientes se ejecuten normalmente si el servidor DNS primario está inactivo. Esto extiende el impacto de un servidor DNS fuera de servicio.

Estas opciones se pueden combinar con options timeout:1 attempts:5. Aumente los intentos si disminuye el tiempo de espera para poder manejar servidores externos lentos.

Dependiendo de la configuración de su enrutador, es posible que pueda configurar sus servidores DNS para que se hagan cargo de la dirección IP del servidor DNS principal cuando esté inactivo. Esto se puede combinar con las técnicas anteriores.

NOTA: Ejecuto años sin interrupciones de DNS no programadas. Como otros han señalado, trabajaría para resolver los problemas que hacen que los servidores DNS fallen. Los pasos anteriores también ayudan con servidores DNS mal configurados con la especificación de servidores de nombres inalcanzables.

Echa un vistazo a "man resolv.conf". Puede agregar una opción de tiempo de espera al resolv.conf. El valor predeterminado es 5, pero agregar lo siguiente a resolv.conf debería reducirlo a 1 segundo:

opciones de tiempo de espera: 1

El software de agrupación, como los latidos del corazón o el marcapasos / corosync, es tu amigo aquí Como ejemplo, hemos configurado el marcapasos / corosync de la siguiente manera:

• Empareja cada servidor con otro
• Por par tiene 2 dns vips, generalmente uno en cada
• En caso de enlace o el servidor falla, el vip se mueve al otro servidor en milisegundos

Las horas de producción son 24x7, pero creemos firmemente que debería ser posible que todos los servidores fallen sin afectar a los clientes. la opción rotar es simplemente una solución alternativa, no haría eso.

Ejecute un servidor dns local en cada nodo y haga que resolv.conf apunte a localhost. Esto funcionaría, pero nos daría muchos más servicios para monitorear y administrar.

FWIW, esta es la única solución viable que he encontrado para este problema. Es necesario restringir el servidor para que solo escuche en localhost, pero ha eliminado por completo a los usuarios que notan interrupciones de DNS en nuestro entorno.

Un efecto secundario interesante es que si el servidor localhost se cae por alguna razón, las bibliotecas de resolución estándar parecen manejar la conmutación por error al siguiente servidor mucho más rápido que en el caso estándar.

Hemos estado haciendo esto durante aproximadamente 3 años y no he visto un solo problema que pueda estar relacionado con la falla / interrupción de un servidor DNS que se ejecuta en localhost.

Si un servidor de nombres se cae por mantenimiento, es un procedimiento normal reducir los tiempos de espera en el SOA para ese dominio antes de tiempo, de modo que cuando ocurra el mantenimiento, los cambios (como eliminar registros NS antes del mantenimiento y volver a colocarlos después del mantenimiento) ) se propagan rápidamente. Tenga en cuenta que este es un enfoque del lado del servidor: cambiar los solucionadores es un enfoque del lado del cliente y ... a menos que pueda hablar con todos y cada uno de sus clientes y hacer que hagan este ajuste en su máquina ... podría no ser El enfoque correcto. Bueno, supongo que dijo que solo un centenar de clientes en un centro de datos utilizando servidores DNS internos, pero ¿realmente desea cambiar la configuración en un centenar de clientes cuando solo puede cambiar la zona?

Te diría qué valores en el SOA ajustar, pero estaba navegando por la web para encontrar esa información exacta cuando me encontré con esta pregunta.

¿Quizás pueda poner sus servidores DNS detrás de un equilibrador de carga? Aparentemente, LVS puede equilibrar UDP. Obviamente, haga que su LB esté altamente disponible para que no sea un solo punto de falla.

Sé que esto puede sonar trillado, pero ¿qué hay de construir una infraestructura DNS más estable y resistente como una solución permanente al problema?

Una solución más centrada en la red sería usar dos servidores DNS con el mismo enrutamiento IP (dedicado) y Anycast . (No he notado esta respuesta en este hilo hasta ahora, pero eso es lo que se usa aquí).

Mientras ambos estén activos, se utiliza el servidor más cercano. Si uno se cae, el tráfico de esa IP se enrutará al otro nodo hasta que vuelva a aparecer. Esto tiene sentido especialmente si tiene dos o más ubicaciones o centros de datos.