¿Es posible tener un proveedor de DNS administrado secundario para delegar rápidamente cuando ocurre un ataque DDOS en nuestro proveedor de DNS externo * primario *?

Por lo tanto, nuestro proveedor de DNS, de vez en cuando, experimenta ataques DDOS en sus sistemas que hacen que nuestros sitios web frontales caigan.

¿Cuáles son algunas opciones en términos de reducir la dependencia de un solo proveedor de DNS administrado externo? Mi primer pensamiento fue usar TTL de menor caducidad y otros TTL de SOA, pero parece que estos afectan el comportamiento del servidor DNS secundario más que cualquier otra cosa.

es decir, si experimenta una interrupción de DNS (debido a DDOS, en este ejemplo) que dura más de, por ejemplo, 1 hora, delegue todo a un proveedor secundario.

¿Qué hacen las personas cuando se trata de su DNS externo y el uso de otro proveedor de DNS administrado como respaldo?

Nota para nuestros moderadores amigables: esta pregunta es mucho más específica que las preguntas de "" ataque genérico de mitigación de DDOS ".

EDITAR: 2016-05-18 (Unos días después): Entonces, en primer lugar, gracias AndrewB por su excelente respuesta. Tengo más información para agregar aquí:

Así que nos comunicamos con otro proveedor de servicios de DNS y conversamos con ellos. Después de pensar y hacer un poco más de investigación, en realidad es MUCHO más complicado de lo que pensé ir con dos proveedores de DNS. ¡Esta no es una respuesta nueva, en realidad es más carne / información a la pregunta! Aquí está mi entendimiento:

- Muchos de estos proveedores de DNS ofrecen características patentadas como 'DNS inteligente', por ejemplo, equilibrio de carga de DNS con keepalives, cadenas lógicas para configurar cómo se devuelven las respuestas (según la ubicación geográfica, varios pesos de registros, etc., etc.) . Entonces, el primer desafío es mantener sincronizados a los dos proveedores administrados . Y los dos proveedores administrados tendrán que estar sincronizados por el cliente que debe automatizar la interacción con sus API. No es ciencia de cohetes, sino un costo operativo continuo que puede ser doloroso (dados los cambios en ambos lados en términos de características y API).

- Pero aquí hay una adición a mi pregunta. Digamos que alguien usó dos proveedores administrados según la respuesta de AndrewB. ¿Estoy en lo cierto en que no hay DNS 'primario' y 'secundario' aquí según las especificaciones? Es decir, registra sus cuatro direcciones IP de servidor DNS con su registrador de dominio, dos de ellos son uno de sus proveedores de DNS, dos de ellos son servidores DNS del otro. Por lo tanto, esencialmente solo estaría mostrando al mundo sus cuatro registros NS, todos los cuales son 'primarios'. Entonces, ¿la respuesta a mi pregunta es "No"?

Primero, abordemos la pregunta en el título.

¿Es posible tener un proveedor DNS administrado secundario para delegar rápidamente a

"Rápido" y "delegación" no pertenecen a la misma oración cuando hablamos de la delegación para la parte superior del dominio. Los servidores de nombres operados por los registros de dominio de nivel superior (TLD) generalmente ofrecen referencias que tienen TTL medidos en días. Los NSregistros autorizados que viven en sus servidores pueden tener TTL más bajos que terminan reemplazando las referencias de TLD, pero usted no tiene control sobre la frecuencia con la que las empresas en Internet eligen dejar todo su caché o reiniciar sus servidores.

Simplificando esto, es mejor suponer que va a tomar al menos 24 horas para que Internet detecte un cambio de servidor de nombres para la parte superior de su dominio. Con la parte superior de su dominio como el eslabón más débil, eso es lo que tiene que planificar más.

¿Cuáles son algunas opciones en términos de reducir la dependencia de un solo proveedor de DNS administrado externo?

Esta pregunta es mucho más solucionable y, contrariamente a la opinión popular, la respuesta no siempre es "encontrar un mejor proveedor". Incluso si utiliza una empresa con un historial muy bueno, los últimos años han demostrado que nadie es infalible, ni siquiera Neustar.

• Las grandes empresas de hosting DNS bien establecidas con buena reputación son más difíciles de aplastar, pero son objetivos más grandes. Es menos probable que se apaguen porque alguien está tratando de desconectar su dominio, pero es más probable que se desconecten porque alojan dominios que son objetivos más atractivos. Puede que no suceda con frecuencia, pero aún sucede.
• En el extremo opuesto, ejecutar sus propios servidores de nombres significa que es menos probable que comparta servidores de nombres con un objetivo que sea más atractivo que usted, pero también significa que es mucho más fácil eliminarlo si alguien decide apuntarle específicamente. .

Para la mayoría de las personas, la opción # 1 es la opción más segura. Un corte de luz solo puede ocurrir una vez cada pocos años, y si ocurre un ataque, será tratado por personas que tengan más experiencia y recursos para enfrentar el problema.

Eso nos lleva a la opción final y más confiable: un enfoque mixto con dos compañías. Esto proporciona resistencia contra los problemas que conlleva tener todos sus huevos en una canasta.

Por el bien del argumento, supongamos que su actual empresa de alojamiento de DNS tiene dos servidores de nombres. Si agrega dos servidores de nombres administrados por otra compañía a la mezcla, entonces se necesita un DDoS contra dos compañías diferentes para desconectarlo. Esto lo protegerá incluso contra el raro evento de que un gigante como Neustar tome una siesta de tierra. En cambio, el desafío es encontrar una manera de entregar actualizaciones confiables y consistentes para sus zonas DNS a más de una compañía. Por lo general, esto significa tener un maestro oculto frente a Internet que permita a un socio remoto realizar transferencias de zona basadas en claves. Ciertamente, son posibles otras soluciones, pero personalmente no soy fanático de usar DDNS para cumplir con este requisito.

El costo de la forma más confiable de disponibilidad del servidor DNS es, desafortunadamente, más complejidad. Ahora es mucho más probable que sus problemas sean el resultado de problemas que provocan que estos servidores no estén sincronizados. El firewall y los cambios de ruta que rompen las transferencias de zona son los problemas más comunes. Peor aún, si un problema de transferencia de zona pasa desapercibido durante un largo período de tiempo, SOAse puede alcanzar el temporizador de caducidad definido por su registro y los servidores remotos abandonarán la zona por completo. El monitoreo exhaustivo es tu amigo aquí.

Para concluir todo esto, hay una serie de opciones, y cada una tiene sus inconvenientes. Depende de usted equilibrar la fiabilidad con las respectivas compensaciones.

• Para la mayoría, es suficiente tener su DNS alojado en una empresa que tiene una gran reputación para hacer frente a los ataques DDoS ... el riesgo de caer una vez cada pocos años es lo suficientemente bueno para la simplicidad.
• Una empresa con una reputación menos férrea para hacer frente a los ataques DDoS es la segunda opción más común, especialmente cuando se buscan soluciones gratuitas. Solo recuerde que gratis generalmente significa que no hay un representante de SLA, y si ocurre un problema no tendrá forma de impulsar la urgencia con esa compañía. (o una persona a demandar, si su departamento legal requiere ese tipo de cosas)
• La opción menos común es, irónicamente, la opción más robusta de usar múltiples compañías de alojamiento de DNS. Esto se debe al costo, la complejidad operativa y los beneficios percibidos a largo plazo.
• Lo peor, al menos en mi opinión, es decidir alojar el tuyo. Pocas compañías tienen administradores de DNS experimentados (que tienen menos probabilidades de crear interrupciones accidentales), experiencia y recursos para lidiar con ataques DDoS, disposición para invertir en un diseño que cumpla con los criterios descritos por BCP 16 , y en la mayoría de los escenarios una combinación de los tres. Si desea jugar con servidores autorizados que solo se enfrentan al interior de su empresa, eso es una cosa, pero el DNS con conexión a Internet es un juego de pelota completamente diferente.

Hay claramente cosas que un proveedor de servicios de DNS debe hacer, y muchas más que podrían hacer, para garantizar que el servicio sea lo más confiable posible.

Si parece que el proveedor de servicios tiene problemas irrazonables, probablemente tenga sentido considerar reemplazarlos por completo, pero también hay clases o problemas en los que tener servicios operados por separado es útil en sí mismo.

Como cliente, creo que la opción más obvia para ir más allá de depender de un proveedor probablemente sería cubrir sus apuestas haciendo que sus dominios sean delegados a servidores de nombres de múltiples proveedores de servicios DNS en todo momento (en lugar de cambiar la delegación en caso de problemas).

Lo que debe tratarse para que eso funcione es esencialmente mantener sincronizados los datos de la zona entre los servidores de nombres de estos diferentes proveedores.

La solución clásica para eso sería simplemente usar la funcionalidad de transferencia de zona maestro / esclavo que es parte del protocolo DNS en sí (esto obviamente requiere servicios que le permitan hacer uso de estas instalaciones), ya sea que uno de los proveedores de servicios sea el maestro o posiblemente ejecutando su propio servidor maestro.