¿Forma correcta de configurar DNS primario / secundario / ... para reducción de redundancia y latencia?

Pensé que DNS primario / secundario para fines de redundancia era sencillo. Tengo entendido que debe tener un primario y al menos uno secundario, y que debe configurar su secundario en una ubicación geográficamente diferente, pero también detrás de un enrutador diferente (consulte, por ejemplo, /server/48087 / why-are-there-varios-nameservers-for-my-domain )

Actualmente, tenemos dos servidores de nombres en nuestro centro de datos principal. Recientemente, hemos sufrido algunas interrupciones por varias razones que eliminaron ambos servidores de nombres y nos dejaron a nosotros y a nuestros clientes sin DNS durante algunas horas. Le he pedido a mi equipo de administrador de sistemas que termine de configurar un servidor DNS en otro centro de datos y que lo configure como el servidor de nombres secundario.

Sin embargo, nuestros administradores de sistemas afirman que esto no ayuda mucho si el otro centro de datos no es al menos tan confiable como el centro de datos principal. Afirman que la mayoría de los clientes aún no podrán buscar correctamente, o que el tiempo de espera será demasiado prolongado, cuando el centro de datos primario esté inactivo.

Personalmente, estoy convencido de que no somos la única compañía con este tipo de problema y que lo más probable es que ya sea un problema resuelto. No puedo imaginar que todas esas compañías de internet se vean afectadas por nuestro tipo de problema. Sin embargo, no puedo encontrar buenos documentos en línea que expliquen qué sucede en los casos de falla (por ejemplo, tiempos de espera de los clientes) y cómo solucionarlos.

¿Qué argumentos puedo usar para hacer agujeros en el razonamiento de nuestros administradores de sistemas? ¿Algún recurso en línea que pueda consultar para comprender mejor los problemas que afirman que existen?

Algunas notas adicionales después de leer las respuestas:

• estamos en Linux
• tenemos necesidades adicionales de DNS complicadas; nuestras entradas de DNS son administradas por algún software personalizado, con BIND actualmente como esclavo de una implementación de Twisted DNS, y algunas vistas en la mezcla también. Sin embargo, somos completamente capaces de configurar nuestros propios servidores DNS en otro centro de datos.
• Estoy hablando de DNS autorizado para que los extraños encuentren nuestros servidores, no servidores DNS recursivos para nuestros clientes locales.

Existe un documento realmente bueno, aunque bastante técnico, de "Mejores prácticas" que puede resultar útil para combatir su administrador de sistemas. http://www.cisco.com/web/about/security/intelligence/dns-bcp.html

Si él / ella no reconoce la validez de los artículos escritos por Cisco, entonces también podría dejar de discutir con el administrador del sistema: subir un nivel de gestión.

Muchos otros documentos de "Mejores prácticas" recomiendan separar sus servidores de nombres primario y secundario no solo por bloqueo de IP, sino por ubicación física. De hecho, RFC 2182 recomienda que los servicios DNS secundarios estén separados geográficamente. Para muchas empresas, esto significa alquilar un servidor en otro centro de datos o suscribirse a un proveedor de DNS alojado como ZoneEdit o UltraDNS .

Sin embargo, nuestros administradores de sistemas afirman que esto no ayuda mucho si el otro centro de datos no es al menos tan confiable como el centro de datos principal. Afirman que la mayoría de los clientes aún no podrán buscar correctamente, o que el tiempo de espera será demasiado prolongado, cuando el centro de datos primario esté inactivo.

Ah, el enfoque es confiable . Parece que están tomando un jab en su enlace al exterior, en lugar de configurar un DNS secundario. De todos modos, configure el DNS secundario y proceda desde allí. Ayudará con la carga y apoyará las cosas en un apuro ... pero pregunte por qué piensan que la otra ubicación no es confiable .

Personalmente, estoy convencido de que no somos la única compañía con este tipo de problema y que lo más probable es que ya sea un problema resuelto. No puedo imaginar que todas esas compañías de internet se vean afectadas por nuestro tipo de problema.

No eres la única compañía, y esto probablemente ha sido revisado un millón de veces en compañías de todo el mundo.

Sin embargo, no puedo encontrar buenos documentos en línea que expliquen qué sucede en los casos de falla (por ejemplo, tiempos de espera de los clientes) y cómo solucionarlos.

¿Qué argumentos puedo usar para hacer agujeros en el razonamiento de nuestros administradores de sistemas? ¿Algún recurso en línea que pueda consultar para comprender mejor los problemas que afirman que existen?

• Estoy hablando de DNS autorizado para que los extraños encuentren nuestros servidores, no servidores DNS recursivos para nuestros clientes locales.

Puede hacer todo tipo de cosas, incluida la configuración de un servicio DNS externo que está registrado como la autoridad de su zona, pero en secreto hacer que los servidores autorizados (externos) sean secundarios a sus propios servidores DNS (internos). Esta configuración es horrible, incorrecta, muestra que soy realmente un malvado SysAdmin, y un gatito muere cada vez que lo recomiendo. Pero hace dos cosas:

• Obtiene su servicio DNS para manejar la mayor parte de la carga, generando preguntas sobre la capacidad de su propio DNS (interno) como discutible.
• Obtiene su servicio DNS para mantenerse activo mientras que sus servidores DNS internos pueden estar inactivos, por lo que no importa cuán confiable sea su enlace; lo importante es cuán confiable es su proveedor de servicios DNS .

Las razones por las que esto es incorrecto :

• Estaría configurando lo que se llama un "servidor de nombres oculto", porque si bien aparecerá en sus registros de zona, y puede consultar la IP para el nombre del servidor, nunca será tocado por el exterior. Las consultas del cliente nunca lo alcanzarán.
• Si bien su DNS continuaría funcionando bien (porque su servicio alojado resolvería el problema) no significa que ningún sitio web que tenga funcione si su conexión a Internet no funciona, es decir, solo aborda la mitad del problema . Realmente parece que hay otros problemas que preocupan a los administradores.

Desafortunadamente, el solucionador DNS de Linux no parece tener soporte directo para detectar y realizar failovers para servidores DNS. Sigue enviando solicitudes a su servidor de nombres de resolución principal, espera un tiempo de espera configurado, intenta nuevamente, etc.

Esto a menudo significa retrasos de hasta 30 segundos para cualquier solicitud. Sin probar primero el secundario siempre que el primario esté inactivo.

Quería resolver esto ya que nuestro servidor de nombres de resolución Amazon EC2 es inalcanzable para muchos de nuestros trabajadores. Esto causa grandes retrasos en nuestros procesos e incluso tiempo de inactividad en algunos casos porque confiamos en la resolución. Quería una buena conmutación por error a los servidores de nombres de Google / Level3 en caso de que Amazon volviera a caer. Y retroceda CUANTO ANTES, porque Amazon resolverá los nombres de host a las direcciones locales donde corresponda, resolviendo en latencia más baja, por ejemplo, la comunicación de instancia.

Pero sea cual sea el caso de uso, existe la necesidad de una mejor conmutación por error. Yo quería resolver esto. Quería mantenerme alejado de los demonios proxy, servicios, etc. Como eso solo introduciría más puntos únicos de fallas. Quería usar una tecnología tan arcaica y robusta como pudiera.

Decidí usar crontab & bash, y escribí nsfailover.sh . Espero que esto ayude.

Parece que el problema es que los clientes, que podrían ser cualquiera, en cualquier lugar, ven dos servidores DNS y, si uno falla, no se conmutan por error al servidor secundario o hay un tiempo de espera prolongado antes de hacerlo.

Estoy de acuerdo en que los servidores DNS primarios y secundarios deben ubicarse en diferentes instalaciones como una mejor práctica, pero no veo cómo eso solucionaría este problema en particular.

Si el cliente va a insistir en consultar una dirección IP específica, ignorando la dirección IP del secundario (o tomando un tiempo para agotar el tiempo de espera), simplemente tiene que encontrar una solución que mantenga esa dirección IP funcionando, incluso si el El servidor primario está inactivo.

Algunas instrucciones para explorar serían un equilibrador de carga que puede redirigir el tráfico de una sola dirección IP a varios servidores en diferentes centros de datos; o quizás enrutamiento de difusión ilimitada.

Siempre que cada uno de sus centros de datos esté en circuitos diferentes (idealmente con diferentes proveedores ascendentes en la nube), puede configurar DNS bastante confiable con solo los dos centros de datos. Simplemente necesita asegurarse de que su registrador de elección complete los registros de pegamento apropiados para los grandes servidores en el cielo.

Nuestra configuración es:

• 2 centros de datos físicos (circuitos separados, ISP y proveedores ascendentes)
• 2 servidores de consulta física en un clúster detrás de un SLB en cada instalación
• 2 dispositivos de equilibrio de carga para servir registros específicos de los que queremos gestionar el equilibrio entre los dos centros de datos
• maestro oculto accesible internamente por ambos clústeres de servidores (creo firmemente en las configuraciones de maestro oculto por seguridad)

Esta configuración ha sido lo suficientemente efectiva como para darnos aproximadamente 5 9 de tiempo de actividad en los últimos 6 o 7 años, incluso con el tiempo de inactividad ocasional del servidor para actualizaciones, etc. Si está dispuesto a gastar unos pocos dólares adicionales, puede buscar servicios externos hosting de la zona con alguien como ultradns ...

En cuanto a la conversación de carga que mencionó KPWINC, eso es 100% correcto. Si su centro de datos más pequeño no puede manejar el 100% de su carga, entonces es probable que esté deshuesado de todos modos porque su interrupción ocurrirá cuando menos lo desee =)

Tomo la carga máxima de todos mis enrutadores de borde, los agrego todos juntos, y luego divido por 0.65 ... ese es el ancho de banda mínimo que debemos tener en cada centro de datos. Puse en práctica esa regla hace unos 5 años, con algunos documentos para justificar que reuní de CCO y de Internet, y nunca nos ha fallado. Sin embargo, debe verificar esas estadísticas al menos trimestralmente. Nuestro tráfico aumentó casi 3 veces entre noviembre y febrero del año pasado y no estaba preparado para ello. Lo bueno es que la situación me permitió generar algunos datos duros muy claros que dicen que con una carga del 72% en nuestro circuito WAN, comenzamos a descartar paquetes. Nunca se me ha requerido una justificación adicional para obtener más ancho de banda.

Al leer su descripción, me di cuenta de que no está claro si se refiere a DNS autorizado para que extraños encuentren sus servidores, o servidores DNS recursivos para sus clientes locales. El comportamiento de esos dos es muy diferente.

Para servidores DNS autorizados, los "clientes" serán otros servidores DNS que tienen almacenamiento en caché y mucha inteligencia. Tienden a probar varios servidores a la vez si el primero es lento, y tienden a preferir el que les da respuestas más rápidas. El tiempo de inactividad para un centro de datos en ese caso tendría un impacto muy leve en el rendimiento.

Para los servidores DNS recursivos, los clientes son sus clientes locales que probablemente tengan los servidores DNS enumerados en DHCP. Probarán sus servidores en el orden indicado cada vez, con un tiempo de espera dolorosamente largo (varios segundos) antes de pasar del primer servidor al segundo servidor.

Si su centro de datos principal está inactivo, nadie podrá acceder a esos servidores de todos modos, pero a menudo los errores son más inteligibles que los errores de servidores DNS inaccesibles. "no se pudo contactar con el servidor" o "se agotó el tiempo de espera de la conexión" en lugar de "no se pudo encontrar el servidor" o "no existe ese servidor". Por ejemplo, la mayoría de los servidores SMTP pondrán en cola el correo durante una semana si ven el servidor en DNS pero simplemente no pueden acceder a él; Si no pueden encontrarlo en el DNS, pueden negarse de inmediato a intentar entregarlo en su dominio.

El DNS secundario que está geográficamente y separado de la red es algo bueno. Es posible que pueda intercambiar DNS secundario con una empresa amiga, y hay muchos proveedores de DNS que puede pagar para hacerlo por usted. Algunos registradores también tienen un DNS secundario como servicio.

Thomas

Después de leer su actualización, revisé mi publicación (la publicación anterior hace referencia al software de Windows).

Casi me parece que sus administradores de sistemas le están diciendo que su ubicación secundaria no tiene el hardware necesario para manejar la CARGA COMPLETA?

Parece que está diciendo: "Hola amigo, si nuestra ubicación principal (que incluye el DNS primario) se cae, DNS es la MENOR de nuestras preocupaciones porque si COLO1 está caído, COLO2 no puede manejar la carga de todos modos".

Si ESE es el caso, le sugiero que revise su infraestructura e intente encontrar un mejor diseño. Esto es más fácil decirlo que hacerlo, especialmente ahora que vives en un entorno de producción.

Aparte de eso, en un mundo perfecto, COLO1 y COLO2 podrían estar solos y manejar su carga.

Una vez que estuvo en su lugar ... el DNS no es más que tener suficientes servidores DNS con una actualización lo suficientemente rápida y si un lado falla, puede reescribir su DNS para que apunte a los servidores que están ARRIBA.

He usado este método en entornos de tamaño pequeño a razonable y funciona muy bien. La conmutación por error suele tardar menos de 10 minutos.

Solo tiene que asegurarse de que sus servidores DNS puedan manejar la carga adicional de un TTL corto (tiempo de vida).

Espero que esto ayude.

Sus administradores de sistemas están (en su mayoría) equivocados.

Los servidores recursivos que consultan a sus servidores autorizados notarán muy rápidamente si alguno de los sitios no responde.

Sí, existe la posibilidad de que los clientes experimenten retrasos muy modestos en la resolución de DNS cuando hay una interrupción, pero solo serán uno o dos segundos, y una vez que los propios servidores DNS del cliente sepan que uno de los servidores está inactivo, usarán los servidores restantes en preferencia al fallido.

Si es necesario (para apaciguar a los administradores del sistema), continúe ejecutando dos servidores en su centro de datos primario, pero coloque al menos uno más afuera.

Un servidor DNS secundario nunca está de más, dependiendo de dónde esté alojado, le dará más o menos funcionalidad.

Si su host primario falla, un secundario puede hacerse cargo sin importar si está sentado al lado o en una ubicación remota. Sin embargo, si el enlace ascendente de su centro de datos falla, es posible que aún reciba respuestas DNS del servidor en otro centro de datos, pero de todos modos no podrá llegar a sus servidores. Por lo tanto, sus usuarios finales no se beneficiarán directamente del DNS secundario en la ubicación remota.

Los diferentes clientes reaccionan de otras maneras a los servidores DNS que no están disponibles, por lo que hay algo de verdad en que los clientes caducan, pero no todos.

Sin embargo, un DNS secundario en un centro de datos remoto seguirá siendo capaz de resolver la dirección IP del servidor al que desea acceder para que pueda depurar el enrutamiento y ver cuándo vuelven a aparecer. Y si ha configurado los servidores MX secundarios correctamente, ni siquiera perderá ningún correo.