Dyn convirtió el DNS gestionado en un límite de responsabilidad por continuidad de ingresos

Resumen

• Confirmado:El 21 de octubre de 2016, Dyn informó de ataques DDoS contra su infraestructura de DNS gestionado. Su declaración pública indicó que la primera oleada comenzó alrededor de las 7:00 a.m., hora del este, afectó a usuarios dirigidos a servidores de Dyn en la costa este de EE. UU. y fue mitigada unas dos horas después. Una segunda oleada, más global, comenzó justo antes del mediodía y fue mitigada en poco más de una hora. Dyn dijo que una tercera oleada intentada fue mitigada sin impacto para los clientes.
• Observado:ThousandEyes midió altas tasas de fallo de consultas DNS desde sus puntos de observación globales e informó que aproximadamente el 75% de sus puntos de observación enviaron consultas que no fueron respondidas por los servidores de Dyn en el pico del ataque. También observó alrededor de 1.200 sitios y servicios afectados entre los que sus clientes monitoreaban, y encontró que muchos clientes vulnerables usaban solo servidores de nombres de Dyn en lugar de múltiples proveedores de DNS.
• Atribución acotada:Dyn dijo que el análisis de Flashpoint y Akamai confirmó que una fuente del tráfico eran dispositivos infectados por Mirai. El DOJ anunció posteriormente declaraciones de culpabilidad de los creadores de Mirai y una declaración de culpabilidad separada de un individuo cuyo ataque de botnet variante de Mirai el 21 de octubre de 2016 afectó a Dyn y dejó inaccesibles o intermitentes durante varias horas sitios como Sony, Twitter, Amazon, PayPal, Tumblr, Netflix y Southern New Hampshire University. El registro público no demuestra que un único actor, una botnet o un vector de ataque explique todo el tráfico que Dyn vio ese día.
• Evaluación:El incidente fue un fallo de dependencia de modo común. Dyn controlaba su plataforma de DNS gestionado, socios de mitigación, comunicaciones y arquitectura de infraestructura. Los clientes controlaban si el DNS autoritativo estaba diversificado entre proveedores y si las prácticas de TTL, conmutación por error y monitoreo coincidían con sus propias afirmaciones de disponibilidad. Los vendedores de IoT, propietarios, ISP, reguladores y atacantes controlaban partes separadas del problema de la botnet.

Registro de evidencia y cómo se utiliza

Este artículo utiliza la declaración pública de Dyn, mediciones independientes de DNS, registros del DOJ, estándares de DNS, investigación de seguridad, guías de DDoS y contexto de mercado como evidencia en capas. La tabla no es una afirmación de que cada fuente citada pruebe la pérdida de cada cliente afectado; explica qué registros públicos respaldan el análisis de responsabilidad.

El DNS falló antes que la aplicación web

Un usuario normalmente experimenta el DNS solo cuando falla. El nombre del sitio parece normal. El navegador funciona. La conexión del usuario puede ser saludable. La aplicación de destino puede seguir funcionando. Sin embargo, si la ruta del DNS autoritativo no puede responder, el servicio puede desaparecer como si los servidores mismos hubieran desaparecido. Eso es lo que hizo el incidente de Dyn tan desconcertante. Muchos servicios no necesariamente estaban dañados en su propia capa de aplicación. Sus nombres no podían resolverse de manera confiable para que los usuarios pudieran alcanzarlos.

El incidente de octubre de 2016 se sitúa en la intersección de dos formas de externalización. Primero, muchas empresas digitales externalizaron el DNS autoritativo a un proveedor gestionado porque ese proveedor podía ofrecer alcance anycast global, direccionamiento de tráfico, experiencia operativa y preparación contra DDoS que muchos clientes no podían construir económicamente por sí solos. Segundo, millones de hogares y organizaciones habían colocado dispositivos conectados inseguros en la Internet pública, a menudo con credenciales predeterminadas débiles o rutas de actualización deficientes.

Mirai convirtió esa segunda opción de externalización en tráfico de ataque contra la primera.

La propia declaración de Dyn, conservada en una copia PDF pública de laDeclaración de Dyn sobre el ataque DDoS del 21/10/2016, dijo que la empresa sufrió ataques DDoS contra su infraestructura de DNS gestionado. Describió una primera oleada que comenzó alrededor de las 7:00 a.m., hora del este, una restauración unas dos horas después, una segunda oleada más global justo antes del mediodía, restauración alrededor de la 1:00 p.m., y una tercera oleada intentada que Dyn dijo fue mitigada sin impacto para los clientes. Dyn también dijo que no experimentó una interrupción en todo el sistema en ningún momento, y que algunos usuarios, como aquellos que accedían a sitios afectados desde la costa oeste de EE. UU. durante la primera oleada, habrían tenido éxito.

Ese detalle importa. El incidente no fue una interrupción binaria limpia donde cada cliente de Dyn desapareció en todas partes. Fue un fallo de disponibilidad moldeado por la geografía, anycast, comportamiento del resolver, tiempo de vida (TTL), configuración del dominio del cliente y la intensidad cambiante del tráfico DDoS. Eso dificultó la comunicación. Un cliente podía probar desde una red y ver éxito mientras que usuarios en otros lugares veían fallo. Un propietario de plataforma podía tener servidores de aplicación saludables y aun así recibir quejas de que el servicio no funcionaba.

Un usuario podía esperar hasta que una respuesta DNS en caché expirara y de repente perder el acceso.

La dependencia compartida era visible en las mediciones

El análisis de ThousandEyes,El ataque DDoS a la infraestructura DNS de Dyn, proporciona la explicación pública más clara de la dependencia del lado del cliente. Su monitoreo vio tres fases: impacto inicial concentrado en la costa este de EE. UU., un impacto global más amplio, y una mitigación posterior con ataques persistentes o blackholing. En el pico del ataque, aproximadamente tres cuartas partes de sus puntos de observación globales enviaron consultas DNS que no fueron respondidas por los servidores de Dyn. También informó aproximadamente 1.200 sitios y servicios afectados entre los dominios que sus clientes monitoreaban.

El punto técnico era simple pero grave. Dyn ejecutaba servidores autoritativos para dominios de clientes. Si un resolver no tenía ya una respuesta fresca en caché y no podía alcanzar los servidores autoritativos de Dyn, no podía obtener la dirección necesaria para conectarse. Los valores más cortos de TTL pueden hacer que la gestión del tráfico sea más ágil en operaciones normales, pero también hacen que los usuarios dependan más frecuentemente de una resolución autoritativa exitosa. Un TTL bajo no es malo por sí mismo; es una compensación.

Durante un evento de DDoS contra un proveedor de DNS, puede acortar el tiempo entre "el caché aún sabe a dónde ir" y "el resolver debe preguntar a la autoridad inalcanzable de nuevo".

ThousandEyes también describió la popularidad de Dyn para el direccionamiento de tráfico. El DNS gestionado no era meramente una guía telefónica estática. Ayudaba a grandes servicios a enrutar usuarios a centros de datos cercanos, cambiar tráfico y optimizar el rendimiento. Eso significa que el producto que mejoraba la resiliencia y la velocidad en condiciones normales también se convirtió en una dependencia cuya degradación podía afectar a muchos clientes a la vez. Cuanto más fuerte era la propuesta de valor del proveedor, más atractivo se volvía como plano de control compartido.

El hallazgo más importante de ThousandEyes para la responsabilidad fue la arquitectura del cliente. Muchos clientes afectados de Dyn usaban solo los servidores de nombres de Dyn en lugar de diversificar entre múltiples proveedores de DNS. El análisis contrastó a los clientes con un único proveedor de DNS gestionado contra Amazon.com, que usaba más de un proveedor y sufrió tiempos de carga más lentos en lugar del mismo patrón de indisponibilidad total visto por muchos otros. Eso no significa que cada cliente pudiera haber activado DNS multiproveedor de la noche a la mañana.

Significa que el riesgo era arquitectónico, visible y parcialmente controlado por los clientes.

Lahistoria de AP reflejada por Chicago Sun-Timescapturó la experiencia pública: efectos en cadena para usuarios que intentaban acceder a sitios web populares en Estados Unidos y Europa, con Twitter, Netflix y PlayStation Network de Sony entre los servicios aparentemente afectados. Elinforme contemporáneo de The Guardianenumeró Netflix, Twitter, Spotify, Reddit, CNN, PayPal, Pinterest, Fox News y principales periódicos entre los servicios reportados como fuera de línea o deteriorados. Esos informes son útiles para el alcance y la percepción pública; no son prueba de que cada servicio nombrado experimentara el mismo modo de fallo técnico o la misma duración.

El fallo de modo común se esconde dentro del DNS "redundante"

El DNS tiene redundancia incorporada en su diseño. Los dominios enumeran múltiples servidores de nombres. Los resuelves pueden probar alternativas. Los servidores autoritativos pueden estar dispersos geográficamente. El problema es que la redundancia puede ser formal sin ser independiente de fallos.

ElRFC 2182ha dicho desde 1997 que una razón importante para múltiples servidores DNS es mantener la información de zona disponible incluso cuando un servidor es inalcanzable, y que los servidores secundarios deben estar dispersos geográfica y topológicamente. Advierte contra configuraciones donde todos los servidores comparten el mismo modo de fallo local. En lenguaje ordinario: múltiples servidores de nombres no son suficientes si fallan juntos.

El caso Dyn tradujo ese principio de ubicación física a dependencia del proveedor. Un cliente podía enumerar varios servidores de nombres de Dyn y aun así tener un proveedor, una relación comercial, una ruta de soporte operativo, un conjunto de credenciales de gestión de DNS y una exposición a un ataque importante contra ese proveedor. Desde la perspectiva del dominio, esos servidores de nombres pueden parecer diversos. Desde la perspectiva de la responsabilidad, siguen siendo parte de una dependencia común del proveedor.

El artículoLa falta de redundancia en la resolución DNS de los principales sitios web y serviciosexaminó la concentración y diversificación en DNS después del incidente de Dyn. Encontró una concentración creciente entre un pequeño número de proveedores de DNS y una fuerte tendencia de los dominios a no usar múltiples proveedores de gestión de DNS. En su muestra, la proporción de dominios que usaban solo un proveedor era aproximadamente del 91% al 93% antes del ataque, y cayó del 92,2% al 89,4% entre octubre de 2016 y noviembre de 2016. Entre los clientes de Dyn, la proporción de dominios no diversificados cayó bruscamente después del incidente y continuó disminuyendo hasta mayo de 2017.

Esas cifras deben tratarse como hallazgos de investigación dentro de un conjunto de datos específico, no como un censo exacto de toda la Internet. Aun así, respaldan la lección práctica. El DNS hacía posible la diversificación de proveedores, pero muchos clientes habían elegido la simplicidad operativa sobre la independencia de fallos. Eso no es irracional.

El DNS autoritativo multiproveedor introduce complejidad: datos de zona consistentes, firma y gestión de claves DNSSEC, comportamiento de verificación de estado, diferencias en el direccionamiento de tráfico, retrasos de propagación, riesgo de cerebro dividido, monitoreo y responsabilidad contractual. El costo de la diversidad es real. El ataque a Dyn mostró que el costo de no diversificar también puede volverse real, y puede llegar a través de un proveedor en lugar de la propia infraestructura del cliente.

Anycast es potente, pero no mágico

La infraestructura de Dyn, como muchas plataformas DNS globales, usaba anycast. Anycast permite que múltiples ubicaciones anuncien la misma dirección IP para que el enrutamiento de Internet pueda enviar un resolver a una instancia cercana o preferida. Mejora la latencia y absorbe muchos fallos locales porque el tráfico puede moverse alrededor de la red. Es una razón por la que los proveedores de DNS gestionado pueden ofrecer un amplio alcance y respuesta rápida.

Anycast no hace infinita la capacidad. Puede distribuir el tráfico, pero también puede distribuir la presión del ataque. Si el ataque es lo suficientemente grande, amplio o dirigido de maneras que congestionen enlaces ascendentes, interconexión o prefijos compartidos, las ubicaciones anycast pueden fallar juntas o fluctuar de maneras complejas. ThousandEyes observó que muchas consultas no podían atravesar los proveedores de servicios de Internet de Dyn o el borde de la red de Dyn, y que los servidores de nombres dentro de la misma constelación y grupo mostraban rendimiento correlacionado.

Esa observación no prueba que el diseño interno de Dyn fuera negligente. Muestra por qué "tenemos múltiples puntos de presencia" no es lo mismo que "tenemos disponibilidad independiente bajo todas las condiciones plausibles de DDoS".

La declaración de Dyn dijo que practicaba escenarios, tenía manuales, usaba socios de mitigación e inició la gestión de incidentes y las comunicaciones con los clientes. También dijo que los ataques estaban altamente distribuidos, involucraban decenas de millones de direcciones IP discretas asociadas con Mirai y usaban múltiples vectores y ubicaciones de Internet. No se debe juzgar a un proveedor como si la mitigación de DDoS fuera una cuestión simple de comprar suficiente ancho de banda.

Los ataques distribuidos muy grandes crean errores de medición, tormentas de reintentos, tráfico colateral, inestabilidad de rutas y difíciles compensaciones entre filtrar tráfico de ataque y preservar consultas legítimas.

Aun así, los clientes compran DNS gestionado porque el proveedor afirma tener experiencia precisamente en este dominio operativo. Por lo tanto, Dyn poseía el lado de la resiliencia del proveedor: planificación de capacidad, coordinación ascendente, arquitectura anycast, diseño de constelaciones de servidores de nombres, comunicación de estado, atención al cliente, preparación de los socios de mitigación y evidencia posterior al incidente. Un relato justo de responsabilidad puede sostener ambas ideas a la vez. El ataque fue malicioso y grande. El negocio de Dyn era mantener el DNS autoritativo alcanzable en condiciones hostiles.

Mirai trasladó el riesgo de los dispositivos de consumo a la infraestructura

Mirai hizo que el ataque fuera culturalmente memorable porque la botnet se construyó en gran parte a partir de dispositivos comunes conectados a Internet: cámaras, routers, grabadoras de video digital y sistemas embebidos similares. El artículo de USENIXComprendiendo la botnet Miraidescribe a Mirai como compuesta principalmente de dispositivos embebidos e IoT y dice que creció hasta un pico de aproximadamente 600.000 infecciones. El artículo argumenta que la simplicidad del método de infección y el rápido crecimiento demostraron que técnicas relativamente poco sofisticadas podían comprometer suficientes dispositivos de gama baja para amenazar objetivos bien defendidos.

El anuncio del Departamento de Justicia de 2017 sobre Mirai,El Departamento de Justicia anuncia cargos y declaraciones de culpabilidad en tres casos de delitos informáticos que involucran ataques DDoS significativos, dijo que Paras Jha, Josiah White y Dalton Norman se declararon culpables de operar la botnet Mirai, que se dirigía a dispositivos IoT como cámaras inalámbricas, routers y grabadoras de video digital. El DOJ dijo que Mirai consistía en cientos de miles de dispositivos comprometidos en su pico, y que la participación de los creadores originales con la variante original de Mirai terminó cuando Jha publicó el código fuente en un foro criminal en el otoño de 2016. Desde entonces, el DOJ dijo que otros actores usaron variantes de Mirai en otros ataques.

El anuncio del Departamento de Justicia de 2020,Individuo se declara culpable de participar en un ciberataque de Internet de las Cosas en 2016, conectó una botnet variante de Mirai más directamente con el día de Dyn. Dijo que un individuo, anteriormente menor de edad, se declaró culpable en relación con un ciberataque de octubre de 2016. Según el DOJ, el individuo y otros usaron una botnet para lanzar varios ataques DDoS el 21 de octubre de 2016 en un esfuerzo por dejar fuera de línea la PlayStation Network de Sony; los ataques impactaron a Dyn, lo que provocó que sitios web como Sony, Twitter, Amazon, PayPal, Tumblr, Netflix y Southern New Hampshire University se volvieran inaccesibles o intermitentes durante varias horas.

Ese registro de atribución debe usarse con cuidado. No dice que el actor menor de edad fuera la única causa de todo el impacto en Dyn, ni significa que toda la mezcla de tráfico de Dyn proviniera de una sola botnet. El propio Dyn dijo que una fuente de tráfico de ataque eran dispositivos infectados por Mirai. El proveedor también describió múltiples vectores y ubicaciones de Internet. La conclusión más segura es que Mirai y las variantes de Mirai estuvieron materialmente involucrados, y que la capa de conducta criminal está separada de la capa de arquitectura de resiliencia.

Laalerta de CISA sobre la amenaza de Miraiadvirtió que el malware Mirai escaneaba en busca de dispositivos IoT vulnerables y que la liberación pública del código fuente de Mirai aumentaba el riesgo de más botnets. El informe posterior de Comercio y Seguridad Nacional alojado por NIST,Mejorando la resiliencia del ecosistema de Internet y comunicaciones contra botnets y otras amenazas distribuidas automatizadas, enmarcó el problema como un problema de todo el ecosistema: los ataques distribuidos automatizados son globales, las herramientas efectivas no se usan ampliamente, los productos deben asegurarse a lo largo de su ciclo de vida, los incentivos están desalineados y ninguna comunidad de partes interesadas puede resolver el problema por sí sola.

Ese marco de ecosistema se ajusta mejor al incidente de Dyn que una historia estrecha de culpa. Los atacantes abusaron de dispositivos que no poseían. Los fabricantes de dispositivos a menudo habían enviado productos de bajo costo sin controles sólidos de actualización, identidad y ciclo de vida. Los propietarios de dispositivos rara vez entendían que una cámara o grabadora en un armario podía participar en un ataque a la infraestructura DNS. Los ISP tenían visibilidad parcial del tráfico de dispositivos infectados pero incentivos mixtos y límites prácticos. Los proveedores de DNS vieron el ataque cuando llegó a su borde.

Los clientes lo vieron cuando sus nombres dejaron de resolverse. Los usuarios lo vieron solo como un sitio que no cargaba.

La posteriorNISTIR 8259A Línea base de capacidades de ciberseguridad para dispositivos IoTno existía en 2016 y no debe tratarse como una obligación legal retroactiva de Dyn. Sigue siendo útil como evidencia de lo que el ecosistema aprendió a valorar: identificación del dispositivo, configuración segura, protección de datos, acceso lógico, capacidad de actualización de software, conciencia del estado de ciberseguridad y documentación. Mirai tuvo éxito porque demasiados dispositivos no podían gestionarse como participantes responsables de Internet.

El control del cliente era real, pero desigual

Los clientes de DNS gestionado no fueron espectadores pasivos. El propietario del dominio controla las opciones de delegación, selección de proveedor, monitoreo, política de TTL, diseño de conmutación por error y si los servicios críticos pueden sobrevivir a la pérdida de un proveedor de DNS. Pero el control no era igual entre los clientes. Una gran plataforma con un equipo de infraestructura profundo podía ejecutar múltiples proveedores autoritativos, autoalojar parte de la pila, mantener automatización de consistencia y probar la resolución desde muchas redes.

Un pequeño editor, minorista, vendedor de software, organización sin fines de lucro o servicio municipal podría haber comprado DNS gestionado precisamente para evitar necesitar esa habilidad.

Aquí es donde la dependencia del servicio en la nube se convierte en un problema de responsabilidad. Un proveedor puede vender experiencia, pero los clientes aún deben decidir qué nivel de fallo del proveedor pueden tolerar. La pregunta no es "¿debería cada sitio web ejecutar una red DNS global a medida?" Eso sería económicamente absurdo. La pregunta es si las promesas de disponibilidad del cliente coinciden con su mapa de dependencias. Una empresa que trata la accesibilidad en línea como crítica para su misión debe saber si un único proveedor de DNS gestionado es un punto único de fallo.

Debe saber qué tan rápido puede cambiar la delegación en el registrador, cuánto tiempo vivirán los registros NS en caché, si un proveedor secundario tiene una zona actualizada, si DNSSEC seguirá validando y si la conmutación por error puede probarse sin crear un incidente público.

Para organizaciones más pequeñas, la respuesta práctica puede no ser una arquitectura multiproveedor perfecta. Puede ser un plan de recuperación más limitado: un segundo proveedor configurado para los registros más importantes, TTLs más largos para activos estables cuando sea apropiado, credenciales de registrador disponibles para más de una persona de confianza, páginas de estado fuera de banda, información de contacto de emergencia en caché y monitoreo que distinga el fallo de resolución DNS del fallo de la aplicación.

Eso es menos elegante que la diversidad totalmente automatizada, pero sigue siendo mejor que descubrir la dependencia durante un incidente global del proveedor.

El riesgo también se extiende a los usuarios finales. Un mercado, editor, proveedor de SaaS o servicio de pago que se vuelve inalcanzable traslada costos a anunciantes, vendedores, equipos de soporte, contratistas y clientes. El usuario no puede ver si la causa raíz es DNS, DDoS, alojamiento en la nube, enrutamiento del ISP o un error de la aplicación. Simplemente no puede realizar transacciones. Debido a que el DNS gestionado se encuentra tan temprano en la ruta, su fallo puede hacer que toda la redundancia posterior sea irrelevante hasta que la resolución de nombres regrese.

La comunicación debía servir a dos audiencias

Dyn tenía dos problemas de comunicación. Debía decir a los clientes directos qué estaba sucediendo y qué podían esperar. También debía comunicarse con la comunidad de Internet en general porque la interrupción era visible mucho más allá de la base de clientes contratados de Dyn. Usuarios públicos, periodistas, reguladores, pares de infraestructura y competidores tenían un interés en comprender si el evento era una interrupción dirigida a la plataforma, una inestabilidad más amplia de Internet, una emergencia de botnet o un problema de concentración de DNS.

La declaración de Dyn dio una narrativa cuidadosa del proveedor: no fue una interrupción en todo el sistema, variable regionalmente, dos oleadas con impacto en clientes, una tercera oleada intentada mitigada, gestión de incidentes activada, socios de mitigación involucrados, Mirai confirmado como una fuente de tráfico, y más detalles retenidos para preservar las defensas futuras. Ese equilibrio es defendible. Un proveedor de DDoS no debe publicar un plan completo de mitigación durante un ataque activo o repetible.

Sin embargo, los clientes necesitaban algo más que tranquilidad. Necesitaban apoyo para la toma de decisiones. ¿Deben cambiar de proveedor de DNS inmediatamente? ¿Deben alterar los TTL? ¿Deben comunicar avisos de interrupción a sus clientes? ¿Se retrasó la propagación de la zona? ¿Estaban todas las regiones afectadas? ¿Estaban intactos los registros DNS de los clientes? ¿Qué grupos de servidores de nombres estaban degradados? ¿Se esperaba que el problema se repitiera? Cuanto más se vende un proveedor como infraestructura de Internet, más su comunicación de estado se convierte en parte del servicio.

El incidente también mostró por qué los clientes necesitan monitoreo independiente. La página de estado de un proveedor puede retrasarse o simplificarse. Las verificaciones de la propia aplicación del cliente pueden perder el fallo de DNS si se ejecutan desde una red con cachés cálidos. El monitoreo debe probar la consulta autoritativa, la resolución recursiva desde múltiples regiones, la accesibilidad de la aplicación y el fallo específico de la dependencia. El análisis público de ThousandEyes fue poderoso porque separó el fallo de consulta DNS de la sensación general del usuario de que "Internet está caído".

Los cachés, los reintentos y la preparación cambiaron la forma del daño

El fallo de DNS no se experimenta de manera uniforme porque la capa recursiva se encuentra entre los usuarios y los proveedores autoritativos. Si un resolver recursivo ya tiene una respuesta válida en caché, un usuario puede continuar accediendo a un servicio incluso mientras los servidores autoritativos están dañados. Si la respuesta en caché expira, o si el resolver no tiene respuesta, el mismo servicio puede volverse repentinamente inalcanzable desde esa red. Dos usuarios en la misma ciudad pueden reportar resultados diferentes porque sus resolvers, cachés y sincronización de consultas difieren.

Ese comportamiento complica tanto la culpa como la respuesta. Un propietario de servicio puede mirar sus servidores de origen y ver salud normal. Un proveedor de DNS gestionado puede ver una mezcla de tráfico de ataque, reintentos legítimos de resolvers, efectos de caché obsoleta y cambios de ruta. Los operadores recursivos pueden aumentar la presión de consultas al reintentar cuando las respuestas expiran. Los usuarios ven accesibilidad intermitente y pueden asumir que la aplicación está rota.

La narrativa pública se convierte en "los principales sitios web están caídos", mientras que la realidad técnica es más como "algunos resolvers no pueden obtener o actualizar respuestas autoritativas para algunos dominios durante algunas ventanas".

Elvistazo rápido al ataque a Dyn de RIPE Labsutilizó mediciones de RIPE Atlas para observar el evento desde sondas distribuidas. Una nota complementaria de RIPE Labs,Especulando sobre DDoS DNS, destacó que el tráfico de reintentos recursivos puede agravar el impacto y que distinguir el tráfico DNS legítimo del tráfico de ataque durante un DDoS del protocolo DNS puede ser difícil. Estos no son juicios legales sobre Dyn. Explican por qué la mitigación de DDoS DNS es más complicada que bloquear una sola fuente hostil o añadir un único servidor de respaldo.

La investigación posterior al incidente hizo el mismo punto desde otro ángulo. El artículoCuando el dique se rompe: Analizando las defensas DNS durante DDoSargumenta que el almacenamiento en caché es un factor importante en la resiliencia DNS y que diferentes capas de DNS pueden experimentar DDoS de manera muy diferente. El artículo utiliza el incidente de Dyn como ejemplo de una interrupción visible que afecta a dominios que usaban a Dyn como proveedor de DNS, mientras señala que otros objetivos DNS, como los servidores raíz, habían absorbido ataques sin interrupciones de servicio visibles. La lección no es que una capa de DNS sea segura y otra débil. Es que la arquitectura, el almacenamiento en caché, la diversidad, el volumen de tráfico y la práctica del operador se combinan para determinar el impacto público.

Para un cliente de DNS gestionado, esto significa que la preparación debe incluir más que el nombre de un proveedor en un registro de riesgos. El cliente necesita saber qué registros son lo suficientemente estables para una vida de caché más larga, qué registros requieren direccionamiento dinámico, qué resolvers recursivos son importantes para sus usuarios y cómo las respuestas obsoletas podrían afectar una conmutación por error. También necesita decidir si un cambio de emergencia de TTL es útil antes de un incidente o mayormente simbólico después de que los cachés ya tienen el valor antiguo.

Los cambios DNS dependen del tiempo; un plan de recuperación que asume propagación global instantánea no es un plan de recuperación.

Las guías generales de DDoS refuerzan la misma disciplina operativa. La colección de guías de denegación de servicio del Centro Nacional de Ciberseguridad del Reino Unido (NCSC)Guía de denegación de servicioenmarca la preparación en torno a cuatro prácticas: entender el servicio, entender las defensas, crear un plan de respuesta y probar la respuesta. La página de CISAComprendiendo los ataques de denegación de servicioexplica el problema básico de disponibilidad: los usuarios legítimos no pueden acceder a sistemas de información, dispositivos o recursos de red. La guía posterior de CISA, FBI y MS-ISACComprendiendo y respondiendo a los ataques distribuidos de denegación de servicioes más amplia que DNS, pero el principio encaja: las organizaciones necesitan preparación anticipada, coordinación con proveedores de servicios, líneas base de tráfico, procedimientos de respuesta y planes de comunicación.

Esas prácticas exponen una verdad incómoda sobre las dependencias en la nube. Un cliente puede externalizar la operación de DNS, pero no puede externalizar el conocimiento de cómo el fallo de DNS afecta a su propio negocio. Dyn podía mitigar ataques a su infraestructura; no podía conocer el estado degradado aceptable de cada cliente. Un banco, mercado, editor, universidad, red de juegos y portal de citas médicas tienen diferente tolerancia a la resolución lenta, respuestas obsoletas y pérdida de accesibilidad regional.

El plan de continuidad del cliente debe traducir el estado del proveedor en decisiones comerciales: si notificar a los usuarios, cambiar de canal, suspender transacciones, fallar abiertamente, fallar cerradamente o aceptar accesibilidad parcial hasta que el DNS se estabilice.

Para Dyn, el mismo principio de preparación funciona en dirección opuesta. Un proveedor de DNS gestionado debe entender que un evento DDoS contra su propia infraestructura no es solo un incidente técnico dentro de su red. Es una crisis simultánea para los clientes. Los clientes necesitan suficiente información para evitar empeorar el evento improvisando cambios de delegación, acortando TTLs, moviendo zonas de manera inconsistente o inundando el soporte. Por lo tanto, los manuales del proveedor deben incluir mitigación, segmentación de clientes, precisión de estado y orientación para clientes con diferentes niveles de sofisticación en DNS.

El incidente de octubre de 2016 fue dañino en parte porque reveló la delgadez de la capa de preparación compartida. Los ingenieros de DNS entendían el almacenamiento en caché, anycast y la resolución autoritativa. Muchos líderes empresariales y usuarios no. Algunos clientes entendían la diversidad de proveedores. Muchos no la habían implementado. Los expertos en seguridad de IoT entendían los riesgos de las credenciales predeterminadas y las flotas de dispositivos no gestionados. Millones de dispositivos ya estaban expuestos.

Un fallo de modo común es a menudo lo que sucede cuando el conocimiento especializado existe en comunidades separadas pero no se ha convertido en compromisos operativos compartidos.

El límite legal es más estrecho que la lección operativa

El registro público establece actividad maliciosa de DDoS, interrupción del servicio de Dyn, problemas de accesibilidad de clientes, participación de Mirai y posteriores declaraciones de culpabilidad penales. No establece que Dyn incumpliera un contrato específico, que cada cliente afectado careciera de arquitectura razonable, que cada fabricante de IoT violara un deber legal, o que todas las pérdidas puedan atribuirse a un demandado.

Los términos de los contratos individuales de Dyn, acuerdos de nivel de servicio con clientes, pólizas de seguro y dependencias de terceros no son públicos de una manera que respalde conclusiones legales amplias.

Ese límite no debe debilitar la lección operativa. La hace más clara. La culpa legal es específica del foro. El control operativo es visible en las elecciones de diseño. Dyn controlaba la resiliencia a nivel de proveedor y las comunicaciones. Los clientes controlaban la diversificación de proveedores de DNS y la planificación de continuidad. Los vendedores de IoT controlaban las credenciales predeterminadas, las rutas de actualización y el soporte del ciclo de vida. Los propietarios de dispositivos controlaban el despliegue y el endurecimiento básico solo en la medida en que los productos lo hicieran práctico.

Los ISP y las empresas de seguridad controlaban las opciones de detección, notificación y mitigación. Los gobiernos controlaban los incentivos, estándares, respuesta de aplicación de la ley y coordinación público-privada.

El incidente pertenece al análisis de responsabilidad porque ninguna capa podía arreglar todo el fallo por sí sola. Un cliente de DNS multiproveedor perfecto aún podría sufrir una botnet masiva en otra parte de su pila. Una línea de productos IoT bien construida no diversificaría el DNS autoritativo de un cliente. Un brillante proveedor de DNS aún podría enfrentar tráfico hostil sin precedentes de dispositivos que no vendió. Un informe gubernamental podría recomendar seguridad del ciclo de vida, pero no reemplazar instantáneamente millones de dispositivos expuestos. El fallo de modo común surgió del ajuste entre estas capas.

La señal del mercado posterior al incidente

Un mes después del ataque, Oracle anunció que había acordado adquirir Dyn. El comunicado de prensa de OracleOracle compra Dyndescribió a Dyn como un proveedor líder de DNS gestionado y rendimiento de Internet basado en la nube, dijo que su red impulsaba 40 mil millones de decisiones de optimización de tráfico diariamente para más de 3.500 clientes empresariales, y nombró a clientes como Netflix, Twitter, Pfizer y CNBC. La adquisición no debe interpretarse como una consecuencia del ataque sin evidencia; el comunicado no lo dijo. Sigue siendo un contexto útil para el papel de mercado de Dyn. No era un servicio de nicho. Era una plataforma importante de DNS gestionado para empresas digitales de alto perfil.

Esa posición de mercado es la razón por la que el incidente sigue siendo relevante. La concentración en la nube a menudo produce beneficios reales: mejor experiencia, mayor alcance global, mitigación más rápida, personal especializado y economías de escala. También cambia el modo de fallo. Cuando muchos clientes convergen en el mismo proveedor, sus afirmaciones independientes de continuidad de negocio pueden correlacionarse. Una plataforma puede externalizar una función y aun así poseer las consecuencias de la arquitectura de externalización.

El informe de 2018 de Comercio y Seguridad Nacional argumentó que los incentivos del mercado estaban desalineados para la resiliencia de botnets. Un problema de incentivos similar existía en el lado del cliente del DNS gestionado. El DNS de un solo proveedor es más simple de comprar, configurar, monitorear y soportar. El DNS multiproveedor reduce el riesgo de modo común pero aumenta la complejidad de ingeniería y la posibilidad de mala configuración. El cliente que evita esa complejidad puede no ser castigado en tiempos normales.

La penalización aparece solo cuando un proveedor falla bajo estrés, y para entonces muchos clientes pueden experimentar el mismo evento juntos.

Pruebas prácticas de responsabilidad

El caso Dyn ofrece a los líderes varias pruebas que siguen siendo útiles.

Dependencia del DNS autoritativo:¿Qué proveedor responde por cada dominio y subdominio crítico? ¿Todos los servidores de nombres listados son operados por el mismo proveedor o a través del mismo plano de control de enrutamiento y gestión? ¿Qué servicios fallan si ese proveedor es inalcanzable desde una región importante?

Independencia del proveedor:¿Existe un segundo proveedor de DNS autoritativo con datos de zona actualizados? Si es así, ¿es realmente independiente en red, plano de control, credenciales, ruta de soporte y mitigación de DDoS? Si no, ¿la organización ha aceptado conscientemente el riesgo de un solo proveedor?

Estrategia de TTL y caché:¿Los TTL de DNS reflejan la necesidad real de la organización de agilidad frente a tolerancia a interrupciones? ¿Los registros más estables tienen suficiente vida de caché para reducir la dependencia evitable de consultas autoritativas frecuentes durante problemas transitorios del proveedor?

DNSSEC y control de cambios:Si DNSSEC está habilitado, ¿pueden las firmas, claves y registros DS sobrevivir a la operación multiproveedor o a un cambio de proveedor de emergencia? Si no, el plan de contingencia puede fallar de manera segura, lo que aún significa que los usuarios no pueden acceder al servicio.

Monitoreo:¿Puede la organización distinguir entre fallo de DNS autoritativo, problemas de resolver recursivo, problemas de CDN, fallo de origen y fallo de aplicación? ¿Se ejecutan pruebas desde suficientes redes y regiones para detectar un problema anycast o regional de DNS?

Recuperación del registrador:¿Están documentadas, protegidas y disponibles durante un incidente las credenciales del registrador, los bloqueos del registro, los contactos de emergencia y los procedimientos de cambio de delegación? Un proveedor de DNS de respaldo no es útil si nadie puede cambiar la delegación de manera segura.

Comunicaciones con el proveedor:¿El proveedor de DNS gestionado proporciona detalles de estado al nivel que los clientes necesitan para tomar decisiones, sin exponer métodos defensivos? ¿Las rutas de soporte al cliente están diseñadas para un evento de impacto simultáneo donde muchos clientes piden ayuda al mismo tiempo?

Exposición a botnets:Para organizaciones que fabrican, despliegan o gestionan dispositivos conectados, ¿las credenciales predeterminadas, la actualización segura, la identidad del dispositivo, la notificación de vulnerabilidades y el soporte al final de la vida útil están diseñados para evitar que la flota de dispositivos se convierta en capacidad DDoS de otro?

Estas pruebas no son pureza de ingeniería abstracta. Son cómo un propietario de dominio aprende si "tenemos servidores de nombres redundantes" significa independencia de fallo genuina o simplemente varios nombres de host dentro de una dependencia de un solo proveedor.

La lección duradera

Dyn no demostró que el DNS gestionado sea malo. Lo contrario está más cerca de la verdad: el DNS gestionado existe porque la disponibilidad de DNS es difícil, especializada y globalmente expuesta. Muchos clientes serían menos resilientes si se vieran obligados a ejecutar su propia infraestructura autoritativa sin experiencia. El incidente demostró que la externalización no borra la arquitectura. Mueve parte de la arquitectura a un proveedor y luego requiere que el cliente decida si el proveedor es un componente o una dependencia de modo común.

Tampoco demostró Mirai que solo el IoT de consumo pueda ser culpado por cada interrupción de infraestructura. Demostró que los dispositivos perimetrales inseguros pueden agregarse en una fuerza lo suficientemente grande como para amenazar servicios centrales. Los hogares y empresas que poseían esos dispositivos no tenían la intención de atacar a Dyn. Los vendedores de dispositivos pueden no haber imaginado sus productos como piezas de infraestructura de Internet. Pero la Internet pública los hizo participantes de todos modos.

La memoria responsable del incidente de Dyn debe ser, por lo tanto, en capas. Actores criminales lanzaron ataques. Dyn defendió una plataforma DNS de alto valor bajo tráfico hostil extremo y aún experimentó interrupción que afectó a los clientes. Muchos clientes dependían de un solo proveedor para DNS autoritativo y descubrieron que múltiples servidores de nombres no siempre significan diversidad de proveedores. Los vendedores y propietarios de IoT habían permitido que dispositivos débiles se convirtieran en recursos de ataque.

Los gobiernos y organismos de normalización posteriormente enmarcaron la resiliencia de botnets como un problema de mercado y ecosistema, no solo como cuestión de castigar a un atacante.

La lección práctica es cruda: la accesibilidad depende del aburrido plano de control. Una empresa puede construir servidores de aplicación redundantes, múltiples nubes, regiones activo-activo y respuesta sofisticada a incidentes, y luego desaparecer de los navegadores de los usuarios si su dependencia de DNS autoritativo es de un solo proveedor e inalcanzable. La delegación de DNS es poder. Tratarla como una línea de adquisición de bajo riesgo es cómo un servicio gestionado se convierte en un fallo de modo común.