Esta es una pregunta canónica sobre la redundancia geográfica de DNS.

Es de conocimiento común que los servidores DNS con redundancia geográfica ubicados en ubicaciones físicas separadas son muy deseables al proporcionar servicios web resistentes. Esto está cubierto en profundidad por el documento BCP 16 , pero algunas de las razones más frecuentemente mencionadas incluyen:

• Protección contra desastres del centro de datos. Los terremotos suceden. Los incendios ocurren en bastidores y eliminan servidores cercanos y equipos de red. Varios servidores DNS no le servirán de mucho si los problemas físicos en el centro de datos eliminan ambos servidores DNS a la vez, incluso si no están en la misma fila.

• Protección contra problemas de pares aguas arriba. Múltiples servidores DNS no evitarán problemas si un compañero de red ascendente compartido toma una siesta. Ya sea que el problema ascendente lo desconecte por completo o simplemente aísle todos sus servidores DNS de una fracción de su base de usuarios, el resultado final es que las personas no pueden acceder a su dominio incluso si los servicios mismos se encuentran en un centro de datos completamente diferente.

Eso está muy bien, pero ¿son realmente necesarios los servidores DNS redundantes si ejecuto todos mis servicios desde la misma dirección IP? No puedo ver cómo tener un segundo servidor DNS me proporcionaría algún beneficio si nadie puede obtener nada de mi dominio.

Entiendo que esto se considera una mejor práctica, ¡pero esto realmente parece inútil!

Nota: Contenido en disputa, consulte los comentarios para ambas respuestas. Se han encontrado errores y este Q&A necesita una revisión.

Estoy eliminando la aceptación de esta respuesta por el momento hasta que se aborde adecuadamente el estado de estas preguntas y respuestas canónicas. (eliminar esta respuesta también eliminaría los comentarios adjuntos, lo cual no es el camino a seguir en la OMI. Probablemente lo convierta en una respuesta wiki de la comunidad después de una edición extensa).

Podría citar RFC aquí y usar términos técnicos, pero este es un concepto que muchas personas ignoran en ambos extremos del espectro de conocimiento y voy a tratar de responder esto para una audiencia más amplia.

Entiendo que esto se considera una mejor práctica, ¡pero esto realmente parece inútil!

Puede parecer inútil ... ¡pero en realidad no lo es!

Los servidores recursivos son muy buenos para recordar cuándo los servidores remotos no responden a una consulta, especialmente cuando vuelven a intentarlo y aún no ven una respuesta. Muchos implementan el almacenamiento en caché negativo de estas fallas de comunicación , y colocarán temporalmente servidores de nombres que no responden en el cuadro de penalización por un período de tiempo no mayor a cinco minutos. Finalmente, este período de "penalización" expira y reanudarán la comunicación. Si la consulta incorrecta vuelve a fallar, vuelven directamente a la casilla; de lo contrario, vuelve a la normalidad.

Aquí es donde nos encontramos con el problema del servidor de nombres único:

• El período de penalización es, por naturaleza, la implementación siempre será mayor o igual que la duración del problema de la red. En casi todos los casos será mayor, hasta un máximo de cinco minutos adicionales.
• Si su único servidor DNS entra en el cuadro de penalización, la consulta asociada con la falla estará completamente muerta durante toda la duración.
• Breves interrupciones de enrutamiento ocurren en Internet más de lo que la mayoría de las personas se dan cuenta. Las retransmisiones TCP / IP y las protecciones de aplicaciones similares hacen un buen trabajo al ocultar esto al usuario, pero es algo inevitable. Internet hace un buen trabajo enrutando este daño en su mayor parte debido a las salvaguardas integradas en los diversos estándares que admiten la pila de red ... pero eso también incluye los integrados en DNS, y tener servidores DNS geo-redundantes es un parte de eso.

En pocas palabras, si va con un solo servidor DNS (esto incluye el uso de la misma dirección IP varias veces en los NSregistros), esto va a suceder. También va a suceder mucho más de lo que crees, pero el problema será tan esporádico que las probabilidades de falla 1) se te informan, 2) se reproducen y 3) se vinculan a este problema específico son extremadamente cercanas cero. Ellos prácticamente eran cero si usted entró en este Q & A no saber cómo funcionaba este proceso, pero por suerte que no debería ser el caso ahora!

¿Esto debería molestarte? No es realmente mi lugar decirlo. A algunas personas no les importará este problema de interrupción de cinco minutos, y no estoy aquí para convencerte de eso. Lo que estoy aquí para convencerte es que, de hecho, sacrificas algo al ejecutar un solo servidor DNS y en todos los escenarios.

OP pregunta:

Eso está muy bien, pero ¿son realmente necesarios los servidores DNS redundantes si ejecuto todos mis servicios desde la misma dirección IP? No puedo ver cómo tener un segundo servidor DNS me proporcionaría algún beneficio si nadie puede obtener nada de mi dominio.

Gran pregunta!

La mejor respuesta la proporciona el profesor Daniel J. Bernstein, PhD Berkeley , quien no solo es un investigador, científico y criptólogo de renombre mundial, sino que también ha escrito un conjunto de DNS muy popular y bien recibido conocido como DJBDNS ( lanzado por última vez en 2001- 02-11 , todavía popular hasta el día de hoy).

http://cr.yp.to/djbdns/third-party.html (11-01-2003)

Costos y beneficios del servicio de DNS de terceros

Presta atención a esta parte breve y sucinta:

Argumentos erróneos para el servicio DNS de terceros

...

La segunda táctica es afirmar que los clientes DNS generalizados harán algo particularmente malo cuando no puedan acceder a todos los servidores DNS. El problema con este argumento es que la afirmación es falsa. Cualquiera de estos clientes está claramente defectuoso y no podrá sobrevivir en el mercado: considere lo que sucede si los enrutadores del cliente se caen brevemente o si la red del cliente se inunda temporalmente.

Como tal, la respuesta original a esta pregunta no podría estar más equivocada.

Sí, de vez en cuando ocurren breves interrupciones temporales de la red que duran unos segundos. No, una falla para resolver un nombre durante una interrupción de este tipo no se almacenaría en la memoria caché por ningún número de minutos (de lo contrario, incluso tener la mejor configuración de servidores de nombres autorizados de alta disponibilidad en el mundo no ayudará).

Cualquier software que implemente generosamente la directriz conservadora de los hasta 5 minutos desde el RFC de 1998-03 a las fallas de caché simplemente se rompe por diseño, y tener un servidor geo-redundante adicional no hará mella.

De hecho, según ¿Cuánto tiempo se almacena en caché un tiempo de espera de DNS? , en BIND, la SERVFAILcondición tradicionalmente NO se almacenaba en caché antes de 2014, y desde 2015, se almacena en caché de forma predeterminada durante solo 1 segundo , menos de lo que le tomaría a un usuario promedio alcanzar un tiempo de espera de resolución y presionar el botón Actualizar nuevamente .

(E incluso antes de llegar al punto anterior de si un intento de resolución debe almacenarse en caché o no, se requieren más de un par de paquetes descartados incluso para que se produzca el primer SERVFAIL en primer lugar).

Además, los desarrolladores de BIND incluso han implementado un límite máximo para la función, de solo 30 segundos, que, incluso como límite (por ejemplo, el valor máximo que la característica aceptará), ya es 10 veces menor que la sugerencia de 5 minutos (300 segundos) del RFC, asegurando que incluso los administradores más bien intencionados (de los usuarios del globo ocular) no podrán disparar a sus propios usuarios en el pie.

Además, hay muchas razones por las que es posible que no desee ejecutar un servicio DNS de terceros : lea todo el conjunto djbdns/third-party.htmlpara obtener todos los detalles , y alquilar un pequeño servidor adicional solo para que DNS lo administre usted mismo apenas está garantizado cuando no es necesario aparte de BCP 16 existe para tal esfuerzo.

En mi experiencia "anecdótica" personal de poseer y configurar nombres de dominio desde al menos 2002, puedo decirle con toda certeza y honestidad que en total he tenido un tiempo de inactividad significativo de mis diversos dominios debido a la gestión profesional. los servidores de terceros de mis registradores y proveedores de alojamiento , que, un proveedor a la vez, y durante años, todos tuvieron sus incidentes, no estaban disponibles, redujeron mis dominios innecesariamente, al mismo tiempo que mi propia dirección IP (donde el HTTP y SMTP para un dominio dado fue alojado desde) era completamente accesible de lo contrario. Tenga en cuenta que estas interrupciones ocurrieron con múltiples proveedores independientes, respetados y administrados profesionalmente, y de ninguna manera son incidentes aislados, y ocurren anualmente y, como un servicio de terceros,están completamente fuera de su control ; Sucede que pocas personas hablan de eso a largo plazo.

En breve:

El DNS geo-redundante NO es en absoluto necesario para sitios pequeños.

Si está ejecutando todos sus servicios desde la misma dirección IP , es muy probable que agregar un segundo DNS resulte en un punto de falla adicional, y es perjudicial para la disponibilidad continua de su dominio. La "sabiduría" de siempre tener que hacerlo en cualquier situación imaginable es un mito muy popular, de hecho; Reventado

Por supuesto, el consejo sería totalmente diferente si algunos de los servicios del dominio, ya sea web (HTTP / HTTPS), correo (SMTP / IMAP) o voz / texto (SIP / XMPP), ya son atendidos por terceros. proveedores, en cuyo caso eliminar su propia IP como un punto único de falla sería un enfoque muy inteligente, y la redundancia geográfica sería realmente muy útil.

Del mismo modo, si tiene un sitio particularmente popular con millones de visitantes y, a sabiendas, requiere la flexibilidad y las protecciones adicionales de DNS geo-redundante según BCP 16, entonces ... Probablemente no esté utilizando un solo servidor / sitio para web / mail / voz / texto ya, por lo que esta pregunta y respuesta obviamente no se aplican. ¡Buena suerte!