Dyn mostró que la externalización del DNS puede convertirse en un fallo de modo común

Resumen

• Confirmado:El 21 de octubre de 2016, Dyn reportó ataques DDoS contra su infraestructura de DNS Gestionado. Su comunicado público 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 se mitigó unas dos horas después. Una segunda oleada, más global, comenzó justo antes del mediodía y se mitigó en poco más de una hora. Dyn afirmó que una tercera oleada intentada se mitigó sin impacto para los clientes.
• Observado:ThousandEyes midió altas tasas de fallos en las consultas DNS desde sus puntos de observación globales y reportó que, en el pico del ataque, alrededor del 75 % de sus puntos de observación enviaron consultas que no obtuvieron respuesta de los servidores de Dyn. También observó aproximadamente 1.200 sitios y servicios afectados entre los que monitorizaban sus clientes, y constató que muchos clientes vulnerables usaban solo servidores de nombres de Dyn en lugar de múltiples proveedores de DNS.
• Atribución acotada:Dyn afirmó que los análisis de Flashpoint y Akamai confirmaron que una fuente del tráfico eran dispositivos infectados por Mirai. El Departamento de Justicia anunció más tarde declaraciones de culpabilidad de los creadores de Mirai y una declaración de culpabilidad separada de un individuo cuyo ataque con una botnet variante de Mirai el 21 de octubre de 2016 impactó a Dyn e hizo que sitios como Sony, Twitter, Amazon, PayPal, Tumblr, Netflix y Southern New Hampshire University quedaran inaccesibles o con intermitencias durante varias horas. El registro público no prueba que un único actor, botnet o 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, sus 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 monitorización coincidían con sus propias afirmaciones de disponibilidad. Los fabricantes de IoT, propietarios, ISP, reguladores y atacantes controlaban partes separadas del problema de las botnets.

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 estar bien. La aplicación de destino puede seguir ejecutándose. Sin embargo, si la ruta del DNS autoritativo no puede responder, el servicio puede desaparecer como si los propios servidores no existieran. Eso fue lo que hizo tan desconcertante el incidente de Dyn. Muchos servicios no estaban necesariamente caídos en su propia capa de aplicación. Sus nombres no podían resolverse de manera fiable para que los usuarios pudieran acceder a ellos.

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 global mediante anycast, dirección de tráfico, experiencia operativa y preparación ante DDoS que muchos clientes no podían construir por sí solos de forma rentable. 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 elección de externalización en tráfico de ataque contra la primera.

El propio comunicado de Dyn, conservado en una copia PDF pública de laDeclaración de Dyn sobre el ataque DDoS del 21/10/2016, indicaba que la empresa sufrió ataques DDoS contra su infraestructura de DNS Gestionado. Describía 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, la restauración alrededor de la 1:00 p. m., y una tercera oleada intentada que, según Dyn, fue mitigada sin impacto para los clientes. Dyn también afirmó que no experimentó una caída total del sistema en ningún momento, y que algunos usuarios, como los que accedían a los sitios afectados desde la costa oeste de EE. UU. durante la primera oleada, habrían podido hacerlo con éxito.

Ese detalle es importante. El incidente no fue una interrupción binaria y limpia en la que todos los clientes de Dyn desaparecieron en todas partes. Fue un fallo de disponibilidad condicionado por la geografía, el anycast, el comportamiento de los resolutores, el tiempo de vida (TTL), la 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 tener éxito mientras los usuarios en otros lugares experimentaban fallos.

El propietario de una plataforma podía tener servidores de aplicaciones en buen estado y aun así recibir quejas de que el servicio no funcionaba. Un usuario podía esperar hasta que una respuesta DNS en caché caducara y entonces perder de repente el acceso.

La dependencia compartida era visible en las mediciones

El análisis de ThousandEyes,El ataque DDoS a la infraestructura DNS de Dyn, ofrece la explicación pública más clara de la dependencia por parte del cliente. Su monitorización observó 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 residuales o blackholing. En el punto álgido del ataque, aproximadamente tres cuartas partes de sus puntos de observación globales enviaron consultas DNS que no obtuvieron respuesta de los servidores de Dyn. También reportó alrededor de 1.200 sitios y servicios afectados entre los dominios que monitorizaban sus clientes.

La cuestión técnica era sencilla pero grave. Dyn operaba servidores autoritativos para los dominios de sus clientes. Si un resolutor no tenía una respuesta en caché vigente y no podía contactar con los servidores autoritativos de Dyn, no podía obtener la dirección necesaria para conectarse. Los valores bajos de tiempo de vida (TTL) pueden hacer que la gestión del tráfico sea más ágil en condiciones normales, pero también hacen que los usuarios dependan con más frecuencia de una resolución autoritativa exitosa. Un TTL bajo no es malo en sí mismo; es una compensación.

Durante un evento de DDoS contra un proveedor de DNS, puede acortar el intervalo entre «la caché aún sabe a dónde ir» y «el resolutor debe preguntar de nuevo a la autoridad no disponible».

ThousandEyes también describió la popularidad de Dyn para la dirección del tráfico. El DNS gestionado no era simplemente una guía telefónica estática. Ayudaba a los grandes servicios a dirigir a los usuarios hacia centros de datos cercanos, redirigir 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 sólida 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 únicamente los servidores de nombres de Dyn en lugar de diversificar entre varios proveedores de DNS. El análisis contrastaba a los clientes con un único proveedor de DNS gestionado con Amazon.com, que utilizaba más de un proveedor y solo experimentó tiempos de carga más lentos, no el mismo patrón de inaccesibilidad total que vieron muchos otros. Eso no significa que todos los clientes pudieran implantar un DNS multiproveedor de la noche a la mañana.

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

Elreportaje de AP reflejado por el Chicago Sun-Timescaptó la experiencia pública: efectos en cadena para los usuarios que intentaban acceder a sitios web populares en Estados Unidos y Europa, con Twitter, Netflix y la 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 grandes periódicos entre los servicios reportados como fuera de línea o con problemas. Esos reportajes son útiles para el alcance y la percepción pública; no prueban que cada servicio mencionado experimentara el mismo modo de fallo técnico ni 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 listan varios servidores de nombres. Los resolutores pueden probar alternativas. Los servidores autoritativos pueden estar dispersos geográficamente. El problema es que la redundancia puede ser formal sin ser independiente ante fallos.

RFC 2182ha dicho desde 1997 que una razón principal para tener múltiples servidores DNS es mantener disponible la información de la zona incluso cuando un servidor no es accesible, 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 corriente: varios servidores de nombres no son suficientes si fallan juntos.

El caso de Dyn trasladó ese principio de la ubicación física a la dependencia del proveedor. Un cliente podía listar varios servidores de nombres de Dyn y aun así tener un solo proveedor, una sola relación comercial, una sola vía de soporte operativo, un solo juego de credenciales de gestión de DNS y una sola 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 formando 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 la diversificación en el DNS tras el incidente de Dyn. Encontró una concentración creciente entre un pequeño número de proveedores de DNS y una fuerte tendencia a que los dominios no usaran múltiples proveedores de gestión de DNS. En su muestra, la proporción de dominios que usaban un solo proveedor era de aproximadamente el 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, el porcentaje de dominios no diversificados cayó bruscamente después del incidente y siguió bajando hasta mayo de 2017.

Estas cifras deben tratarse como resultados 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 posibilitaba la diversificación de proveedores, pero muchos clientes habían optado por la simplicidad operativa en lugar de la independencia ante fallos. Eso no es irracional.

El DNS autoritativo multiproveedor introduce complejidad: datos de zona coherentes, firma y gestión de claves DNSSEC, comportamiento de las comprobaciones de estado, diferencias en la dirección del tráfico, retardos de propagación, riesgo de cerebro dividido, monitorización y responsabilidad contractual. El coste de la diversidad es real. El ataque a Dyn demostró que el coste 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.

El anycast es potente, pero no es magia

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

El anycast no hace que la capacidad sea infinita. Puede distribuir el tráfico, pero también puede distribuir la presión del ataque. Si el ataque es lo bastante grande, lo bastante amplio o está dirigido de manera que congestione los enlaces ascendentes, el peering o los prefijos compartidos, las ubicaciones anycast pueden fallar juntas o fluctuar de formas complejas. ThousandEyes observó que muchas consultas no podían llegar a los proveedores de servicios de Internet de Dyn o al borde de su red, y que los servidores de nombres dentro de la misma constelación y grupo mostraban un 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 en todas las condiciones plausibles de DDoS».

El comunicado de Dyn afirmaba que practicaban escenarios, tenían libros de procedimientos, usaban socios de mitigación e iniciaron la gestión del incidente y las comunicaciones con los clientes. También decía que los ataques estaban muy distribuidos, implicaban decenas de millones de direcciones IP discretas asociadas a Mirai y utilizaban múltiples vectores y ubicaciones de Internet. No se debe juzgar a un proveedor como si la mitigación de DDoS fuera una simple cuestión 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 compromisos entre filtrar el tráfico de ataque y preservar las consultas legítimas.

Aun así, los clientes compran DNS gestionado porque el proveedor afirma tener experiencia precisamente en este ámbito operativo. Dyn era, por tanto, responsable de la parte de resiliencia del proveedor: planificación de capacidad, coordinación con los proveedores de tránsito, arquitectura anycast, diseño de la constelación de servidores de nombres, comunicación del estado, soporte al cliente, preparación de los socios de mitigación y evidencia posterior al incidente. Un análisis de responsabilidad justo puede sostener ambas ideas a la vez. El ataque fue malicioso y grande.

El negocio de Dyn era mantener el DNS autoritativo accesible 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 medida a partir de dispositivos ordinarios conectados a Internet: cámaras, routers, grabadoras de vídeo digital y sistemas embebidos similares. Elartículo de USENIX Entendiendo la botnet Miraidescribe a Mirai como compuesta principalmente por dispositivos IoT y embebidos, y afirma que llegó a un pico de aproximadamente 600.000 infecciones. El artículo sostiene 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 como para amenazar objetivos bien defendidos.

El anuncio de Mirai de 2017 del Departamento de Justicia,El Departamento de Justicia anuncia cargos y declaraciones de culpabilidad en tres casos de delitos informáticos relacionados con importantes ataques DDoS, indicaba que Paras Jha, Josiah White y Dalton Norman se declararon culpables de operar la botnet Mirai, que tenía como objetivo dispositivos IoT como cámaras inalámbricas, routers y grabadoras de vídeo digital. El Departamento de Justicia dijo que Mirai llegó a contar con 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 otoño de 2016. Desde entonces, según el Departamento de Justicia, otros actores utilizaron variantes de Mirai en otros ataques.

El anuncio de 2020 del Departamento de Justicia,Un individuo se declara culpable de participar en un ciberataque de Internet de las Cosas en 2016, vinculó una botnet variante de Mirai al día de Dyn de manera más directa. Decía que un individuo, antes menor de edad, se declaró culpable en relación con un ciberataque de octubre de 2016. Según el Departamento de Justicia, el individuo y otras personas utilizaron una botnet para lanzar varios ataques DDoS el 21 de octubre de 2016 con el objetivo de tumbar 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 quedaran inaccesibles o con intermitencias durante varias horas.

Ese registro de atribución debe usarse con cuidado. No dice que el joven actor fuera la única causa de todos los impactos de Dyn, ni significa que todo el tráfico de Dyn procediera de una sola botnet. El propio Dyn dijo que una fuente del 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 sus variantes estuvieron materialmente implicados, y que la capa de conducta delictiva está separada de la capa de arquitectura de resiliencia.

Laalerta de CISA sobre la amenaza de Miraiadvertía de que el malware Mirai escaneaba en busca de dispositivos IoT vulnerables y que la publicación del código fuente de Mirai aumentaba el riesgo de más botnets. El posterior informe del Departamento de Comercio y de Seguridad Nacional, alojado por el NIST,Mejora de la resiliencia del ecosistema de Internet y comunicaciones contra las botnets y otras amenazas automatizadas y distribuidas, enmarcaba el problema como algo que afectaba a todo el ecosistema: los ataques distribuidos automatizados son globales, las herramientas eficaces no se utilizan ampliamente, los productos deben protegerse 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 encuadre ecosistémico encaja mejor con el incidente de Dyn que una historia de culpa estrecha. Los atacantes abusaron de dispositivos que no poseían. Los fabricantes de dispositivos a menudo habían enviado productos de bajo coste sin controles sólidos de actualización, identidad y ciclo de vida. Los propietarios de los dispositivos rara vez entendían que una cámara o una grabadora en un armario podía participar en un ataque contra la infraestructura de DNS. Los ISP tenían una visibilidad parcial del tráfico de dispositivos infectados, pero con 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 básicas de ciberseguridad para dispositivos IoTno existía en 2016 y no debe tratarse como un deber legal retroactivo para 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 del DNS gestionado no eran simples espectadores pasivos. El propietario del dominio controla las elecciones de delegación, la selección del proveedor, la monitorización, la política de TTL, el diseño de la 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 para todos los clientes. Una gran plataforma con un equipo de infraestructura profundo podía operar múltiples proveedores autoritativos, autoalojar parte de la pila, mantener la automatización de la consistencia y probar la resolución desde muchas redes.

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

Aquí es donde la dependencia del servicio en la nube se convierte en una cuestión 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 operar 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 considera 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 con qué rapidez 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 las 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, TTL más largos para activos estables cuando sea apropiado, credenciales del 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 monitorización que distinga el fallo de resolución DNS del fallo de la aplicación.

Eso es menos elegante que una 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 posteriores. Un mercado, editor, proveedor de SaaS o servicio de pago que se vuelve inaccesible traslada los costes 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 pueden realizar transacciones. Dado que el DNS gestionado se sitúa tan temprano en la ruta, su fallo puede hacer que toda la redundancia posterior sea irrelevante hasta que la resolución de nombres vuelva.

La comunicación debía servir a dos públicos

Dyn tenía dos problemas de comunicación. Tenía que informar a sus clientes directos de lo que estaba ocurriendo y de lo que podían esperar. También tenía que 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. Los usuarios públicos, los periodistas, los reguladores, los pares de infraestructura y los competidores tenían interés en entender si el evento era una interrupción de una plataforma específica, una inestabilidad más amplia de Internet, una emergencia de botnet o un problema de concentración de DNS.

El comunicado de Dyn ofrecía una cuidada narrativa del proveedor: no fue una caída de todo el sistema, fue variable según la región, hubo dos oleadas con impacto en los clientes, una tercera oleada intentada mitigada, se activó la gestión del incidente, participaron los socios de mitigación, se confirmó a Mirai como una fuente del tráfico, y se reservaron más detalles para preservar las defensas futuras. Ese equilibrio es defendible. Un proveedor de DDoS no debe publicar un plano completo de mitigación durante un ataque activo o repetible.

Sin embargo, los clientes necesitaban algo más que tranquilidad. Necesitaban apoyo para tomar decisiones. ¿Debían cambiar de proveedor de DNS inmediatamente? ¿Debían modificar los TTL? ¿Debían emitir avisos de interrupción a sus propios clientes? ¿Se retrasó la propagación de la zona? ¿Estaban afectadas todas las regiones? ¿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 se convierte la comunicación de su estado en parte del servicio.

El incidente también mostró por qué los clientes necesitan una monitorización independiente. La página de estado de un proveedor puede ir con retraso o simplificar. Las propias comprobaciones de la aplicación de un cliente pueden pasar por alto un fallo de DNS si se ejecutan desde una red con cachés calientes. La monitorización debería probar la consulta autoritativa, la resolución recursiva desde múltiples regiones, la accesibilidad de la aplicación y los fallos específicos de la dependencia.

El análisis público de ThousandEyes fue poderoso porque separó el fallo de la consulta DNS de la sensación general del usuario de que «Internet no funciona».

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

El fallo del DNS no se experimenta de manera uniforme porque la capa recursiva se sitúa entre los usuarios y los proveedores autoritativos. Si un resolutor recursivo ya tiene una respuesta en caché válida, un usuario puede seguir accediendo a un servicio incluso mientras los servidores autoritativos están afectados. Si la respuesta en caché caduca, o si el resolutor no tiene respuesta, el mismo servicio puede volverse de repente inaccesible desde esa red. Dos usuarios en la misma ciudad pueden, por tanto, reportar resultados diferentes porque sus resolutores, cachés y tiempos de consulta difieren.

Ese comportamiento complica tanto la atribución de culpa como la respuesta. El propietario de un servicio puede mirar sus servidores de origen y ver un estado normal. Un proveedor de DNS gestionado puede ver una mezcla de tráfico de ataque, reintentos legítimos de los resolutores, efectos de cachés obsoletas y cambios de ruta. Los operadores recursivos pueden aumentar la presión de consulta reintentando cuando las respuestas caducan. Los usuarios ven una 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 bien «algunos resolutores no pueden obtener o refrescar respuestas autoritativas para algunos dominios durante algunas ventanas temporales».

Elvistazo rápido de RIPE Labs al ataque a Dynutilizó mediciones de RIPE Atlas para observar el evento desde sondas distribuidas. Una nota complementaria de RIPE Labs,Especulando sobre DDoS de 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 contra el protocolo DNS puede ser difícil. No se trata de juicios legales sobre Dyn. Explican por qué la mitigación de DDoS de DNS es más complicada que bloquear una única fuente hostil o añadir un único servidor de respaldo.

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

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

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

Las directrices generales sobre DDoS refuerzan la misma disciplina operativa. Lacolección de guías sobre denegación de servicio del NCSC del Reino Unidoenmarca la preparación en torno a cuatro prácticas: entender el servicio, entender las defensas, crear un plan de respuesta y probar la respuesta. Laguía de CISA para entender los ataques de denegación de servicioexplica el problema básico de disponibilidad: los usuarios legítimos no pueden acceder a los sistemas de información, dispositivos o recursos de red. La posteriorguía de CISA, FBI y MS-ISAC para entender y responder a ataques distribuidos de denegación de servicioes más amplia que el DNS, pero el principio encaja: las organizaciones necesitan preparación previa, coordinación con los 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 del DNS, pero no puede externalizar el conocimiento de cómo afecta un fallo del DNS a su propio negocio. Dyn podía mitigar los ataques contra su infraestructura; no podía conocer el estado degradado aceptable de cada cliente. Un banco, un mercado, un editor, una universidad, una red de juegos y un portal de citas hospitalarias tienen diferentes tolerancias a una resolución lenta, a respuestas obsoletas y a la pérdida de accesibilidad regional.

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

Para Dyn, el mismo principio de preparación funciona en sentido contrario. 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 TTL, moviendo zonas de manera inconsistente o saturando el soporte.

Los libros de procedimientos del proveedor deben, por tanto, incluir la mitigación, la segmentación de clientes, la precisión del estado y la 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 la caché, el 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 implantado. 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 ocurre 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 una actividad DDoS maliciosa, una interrupción del servicio de Dyn, problemas de accesibilidad para los clientes, la implicación de Mirai y posteriores declaraciones de culpabilidad penal. No establece que Dyn incumpliera un contrato específico, que todos los clientes afectados carecieran de una arquitectura razonable, que todos los fabricantes de IoT violaran un deber legal o que todas las pérdidas puedan atribuirse a un solo acusado.

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

Ese límite no debería debilitar la lección operativa. La hace más clara. La culpa legal depende del foro. El control operativo es visible en las decisiones de diseño. Dyn controlaba la resiliencia y las comunicaciones a nivel de proveedor. Los clientes controlaban la diversificación del proveedor de DNS y la planificación de la continuidad. Los fabricantes 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 hacían 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, los estándares, la respuesta policial y la coordinación público-privada.

El incidente pertenece al análisis de responsabilidad porque ninguna capa por sí sola podía solucionar todo el fallo. 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 enfrentarse a un tráfico hostil sin precedentes procedente de dispositivos que no vendió. Un informe gubernamental podría recomendar la seguridad del ciclo de vida, pero no reemplazar instantáneamente millones de dispositivos expuestos.

El fallo de modo común surgió del encaje entre estas capas.

La señal del mercado tras el incidente

Un mes después del ataque, Oracle anunció que había acordado adquirir Dyn. Elcomunicado de prensa de Oracledescribió a Dyn como un proveedor líder de rendimiento de Internet y DNS basado en la nube, dijo que su red impulsaba 40 mil millones de decisiones de optimización de tráfico al día 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 pruebas; el comunicado no lo decía. Sigue siendo un contexto útil para el papel de mercado de Dyn. No era un servicio de hobby de nicho. Era una importante plataforma de DNS gestionado para empresas digitales de alto perfil.

Esa posición de mercado es la razón por la que el incidente sigue importando. 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 del negocio pueden correlacionarse. Una plataforma puede externalizar una función y aun así ser responsable de las consecuencias de la arquitectura de externalización.

El informe de 2018 del Departamento de Comercio y de Seguridad Nacional sostenía que los incentivos del mercado estaban desalineados para la resiliencia ante 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 sencillo de comprar, configurar, monitorizar y soportar. El DNS multiproveedor reduce el riesgo de modo común pero aumenta la complejidad de ingeniería y la posibilidad de una configuración errónea. El cliente que evita esa complejidad puede no ser penalizado nunca 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 de 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? ¿Están todos los servidores de nombres listados 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 no es accesible desde una región importante?

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

Estrategia de TTL y caché:¿Reflejan los TTL de DNS la necesidad real de agilidad de la organización frente a la tolerancia a las interrupciones? ¿Se da a los registros más estables 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 una operación multiproveedor o a un cambio de emergencia de proveedor? Si no, la alternativa puede fallar de forma segura, lo que sigue significando que los usuarios no pueden acceder al servicio.

Monitorización:¿Puede la organización distinguir el fallo del DNS autoritativo, los problemas del resolutor recursivo, los problemas de CDN, el fallo del origen y el fallo de la aplicación? ¿Se ejecutan las pruebas desde suficientes redes y regiones para detectar un problema de DNS regional o de anycast?

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 forma segura.

Comunicaciones con el proveedor:¿Proporciona el proveedor de DNS gestionado detalles de estado al nivel que los clientes necesitan para tomar decisiones, sin exponer los métodos defensivos? ¿Están diseñadas las rutas de soporte al cliente para un evento de impacto simultáneo en el que muchos clientes piden ayuda a la vez?

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

Estas pruebas no son pureza de ingeniería abstracta. Son la forma en que el propietario de un dominio aprende si «tenemos servidores de nombres redundantes» significa una verdadera independencia ante fallos o solo varios nombres de host dentro de la dependencia de un 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 del DNS es difícil, especializada y está expuesta globalmente. Muchos clientes serían menos resilientes si se les obligara a operar su propia infraestructura autoritativa sin experiencia. El incidente demostró que la externalización no borra la arquitectura. Traslada parte de la arquitectura a un proveedor y luego exige que el cliente decida si el proveedor es un componente o una dependencia de modo común.

Mirai tampoco demostró que solo se pueda culpar al IoT de consumo de cada interrupción de la infraestructura. Demostró que los dispositivos de borde inseguros pueden agregarse en una fuerza lo bastante grande como para amenazar servicios centrales. Los hogares y las empresas que poseían esos dispositivos no tenían la intención de atacar a Dyn. Es posible que los fabricantes de dispositivos no imaginaran sus productos como piezas de la infraestructura de Internet. Pero la Internet pública los convirtió en participantes de todos modos.

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

Los gobiernos y los organismos de normalización enmarcaron más tarde la resiliencia ante botnets como un problema de mercado y de ecosistema, no solo como una 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 aplicaciones redundantes, múltiples nubes, regiones activo-activo y una sofisticada respuesta a incidentes, y luego desaparecer de los navegadores de los usuarios si su dependencia del DNS autoritativo es de un solo proveedor y no está accesible. La delegación de DNS es poder. Tratarla como una línea de adquisición de bajo riesgo es la forma en que un servicio gestionado se convierte en un fallo de modo común.