¿Por qué los cachés de DNS del navegador no mitigan los ataques DDOS a los proveedores de DNS?

Usted tiene razón en que la memoria caché de DNS mitigaría que un servidor de nombres no estuviera disponible. Es extremadamente común tener un TTL de 5 minutos o menos. Por lo tanto, 5 minutos después de que el ataque DDOS derribara a Dyn, tu caché no habría sido válido y no hubieras podido golpear Github, etc.

Un pequeño cambio en el diseño de los cachés de DNS podría hacer una gran diferencia. La mayoría de los cachés de DNS eliminan una entrada cuando el TTL caduca. En cambio, una memoria caché podría conservar la entrada, pero marcarla como caducada. Si llega una consulta para una entrada caducada, el caché primero intentaría resolver el nombre en sentido ascendente y, si eso falla, devolverá la entrada caducada. Espero que esto sea técnicamente una violación del protocolo DNS, pero aún así es un mejor comportamiento de falla.

Sin embargo, no espero ver que esto suceda. El impacto de la caída de los servidores DNS aún sería significativo: todos los sitios que no tiene en su caché. El enfoque se mantendrá en mantener la infraestructura DNS operativa.

Actualización: @MatthieuM ha señalado que EdgeDNS hace esto.

@Shackledtodesk es correcto (+1), la memoria caché del navegador se mantiene por un corto tiempo. Irónicamente, algunas de las mejores referencias sobre este hecho han sido publicadas por Dyn:

  

Un programa simple que escribí para consultar los 1000 sitios web principales (según Alexa) muestra 212 hits con un valor TTL de 300 (5 mins), 192 hits con un TTL de 3600 (1 hr), 116 hits con un TTL de 600 (10 minutos) y 79 hits con un TTL de 86400. El resto de los resultados tuvieron éxitos en los 50 y menos, variando desde un TTL de 5 (1 golpe) hasta un TTL de 864000 (1 golpe). / p>

Esta es una cita de Ben Anderson, investigador y escritor técnico de Dyn.

Mirando esos resultados, puedes verlo en una pequeña cantidad si el tiempo de tu navegador invalida el caché de DNS. Y tu resolución de DNS comienza a fallar.

Referencia

• Por qué el almacenamiento en caché de DNS del navegador web puede ser una cosa mala

_{PS: para agregar un insulto a la lesión, el artículo vinculado de Dyn sostiene que el caché de DNS del navegador es algo malo.}

Los navegadores no almacenan en caché los registros DNS

Esta es una función de la resolución que es un complemento de la pila de red.

El almacenamiento en caché de DNS no ayudaría mucho

Los dispositivos esclavos mirai son capaces de llevar a cabo cualquier número de diferentes Ataca según lo dirigido por el CnC. En el caso del ataque tanto a la seguridad de Krebbs como a DYN, los atacantes simplemente llenaron su ancho de banda con tráfico, en realidad no importaba de qué se tratara. Si bien el DNS puede ser explotado para un ataque de amplificación indirecta, tengo entendido que esto no se aplica en el caso de los ataques a Krebss y DYN. El DNS se usó en el último ataque, ya que no era práctico filtrar el tráfico real del tráfico de ataque.

Si los registros de DNS se almacenaran en caché en otro lugar accesible para los usuarios normales (en los cachés de DNS, no en los navegadores), el ataque habría tenido un impacto mucho menor, sin embargo, el modelo de negocio DYN apunta principalmente al alojamiento de DNS y la provisión del usuario final. Este último habría sido interrumpido a pesar de todo. La presencia de los datos en cachés intermedios / otros proveedores de usuarios finales se basa en el volumen de tráfico y el tiempo de caducidad (es mi experiencia que los tiempos de caducidad de menos de 2 horas no son efectivos). Además, un sitio de alto tráfico tendrá múltiples puntos geográficos de presencia junto con varios registros A en cada POP: las direcciones de multidifusión son costosas y (debido a edns-client-subnet) no son necesarias más que para DNS (en ausencia de ataques de DOS) ).

El DNS se diseñó principalmente para proporcionar una asignación estable (y poco coherente ) de nombres a direcciones. En los buenos tiempos, el Tiempo de vida (TTL) en los registros de DNS estuvo generalmente en el rango de 3600 a 86400 segundos. Se esperaba que quienquiera que solicitara un registro en particular siempre obtendría la misma respuesta .

Luego, algunas personas pensaron que si utilizaban TTL realmente cortos podían realizar Stupid DNS Tricks® que obligan al DNS a hacer cosas que no estaba destinado a hacer .

Por ejemplo, algunos dispositivos de equilibrio de carga tienen servidores DNS integrados que supervisan el estado de los servidores de servicios de fondo y ofrecen una respuesta diferente a cada solicitud de entrada en función de su carga actual.

Algunos operadores miran la dirección de origen de la consulta entrante y envían respuestas diferentes para redirigir al cliente al clúster de aplicaciones más cercano (también conocido como "Global Server Load Balancing").

Apropos del ataque de la semana pasada a Dyn: una buena práctica de DNS solía ser que distribuyera sus servidores DNS autorizados a través de múltiples redes (y / o operadores), de modo que un ataque o una interrupción en uno aún lo dejaría con DNS en funcionamiento.

Sin embargo, los "trucos" antes mencionados involucran algoritmos a medida e "inteligencia" que no son inherentes al DNS en sí, por lo que se vuelve muy difícil (si no imposible) confiar en la resistencia integrada del DNS. Un sistema que genera respuestas sintetizadas en lugar de usar un archivo de zona no puede compartirse entre varios operadores que utilizan AXFR.

La memoria caché de DNS mitiga los ataques DDOS en los proveedores de DNS, pero la memoria caché solo DEBE durar poco tiempo.

El servidor, llamado TTL, especifica el tiempo máximo que se debe almacenar en caché el registro de un recurso.

  

El significado del campo TTL es un límite de tiempo sobre la duración de un RR   guardado en un caché. Este límite no se aplica a los datos autorizados en   zonas también está agotado, pero por las políticas de actualización para el   zona. El TTL es asignado por el administrador para la zona donde el   Los datos se originan. Mientras que los TTL cortos se pueden usar para minimizar el almacenamiento en caché, y   un TTL cero prohíbe el almacenamiento en caché, las realidades del rendimiento de Internet   sugerir que estos tiempos deben estar en el orden de días para el típico   anfitrión. Si se puede anticipar un cambio, el TTL se puede reducir antes de   el cambio para minimizar la inconsistencia durante el cambio, y luego   aumentado de nuevo a su valor anterior tras el cambio.

(tomado de RFC 1034)

El servidor puede decirle al solucionador que el registro se puede almacenar en caché durante más de 68 años, lo que suele ser lo suficientemente largo como para que se pueda corregir un ataque. Pero los servidores generalmente no lo hacen. Los grandes sitios web no quieren que una falla en la red los afecte por mucho tiempo. Una forma de hacerlo es establecer el TTL de sus registros de recursos en un tiempo relativamente corto, como 5 minutos. De esa manera, pueden cambiar su registro DNS en caso de que algunos de sus servidores fallen. Y los clientes que consultan el RR cada 5 minutos no tienen demasiada sobrecarga que solo una vez.

Además, las aplicaciones generalmente almacenan en caché el RR en la RAM. Así que los registros se pierden una vez que se reinicia la aplicación. (Hay excepciones. Puede volcar el caché de BIND al sistema de archivos, por ejemplo).

Quiero mencionar Namecoin aquí. Almacena los nombres de dominio en el disco, en una cadena de bloques. Si su sitio web utiliza un dominio .bit, es poco probable que se caiga solo por el proveedor de DNS.