Para despejar las dudas y frenar los rumores sobre un posible ciberataque o un secuestro BGP, Cloudflare aclaró con una explicación: la reciente caída del servicio DNS 1.1.1.1 no fue provocada por actores externos, sino por un error interno de configuración.
El apagón ocurrió el 14 de julio y afectó a usuarios de todo el mundo. En muchos casos, esto dejó a millones sin acceso a sitios web y servicios esenciales en Internet.
“La causa raíz fue un error de configuración interna, no un ataque ni un secuestro de BGP”, confirmó Cloudflare en su informe posterior al incidente.
La aclaración de Cloudflare llega después de que muchas personas comenzaran a especular en redes sociales que la caída del servicio 1.1.1.1 había sido causada por un secuestro de BGP, uno de los escenarios más temidos en el mundo del enrutamiento de Internet. Pero la realidad fue mucho menos dramática (aunque igual de impactante): todo se debió a un error de configuración interna.
¿Qué fue lo que pasó realmente?
Para entender el origen del problema, hay que remontarse al 6 de junio, cuando Cloudflare hizo un cambio en su sistema de configuración como parte de una futura integración con su nueva suite de localización de datos, conocida como DLS (Data Localization Suite). El problema: se asignaron por error los prefijos IP del DNS público 1.1.1.1 a una versión inactiva (y no apta para producción) de DLS.
Todo parecía estar funcionando bien… hasta que el 14 de julio, a las 21:48 UTC, se lanzó una nueva actualización que incluyó una ubicación de prueba dentro de ese servicio DLS. El cambio aplicó la configuración incorrecta a nivel global, lo que provocó que los prefijos IP de 1.1.1.1 se desvincularan de los centros de datos de producción y se redirigieran a una única ubicación fuera de línea. Resultado: el servicio DNS de Cloudflare se volvió inaccesible en todo el mundo.
Conoce más sobre: DNS 1.1.1.1 de Cloudflare: ¿Qué es y por qué utilizarlo?
Así fue cómo se desarrolló la caída
-
21:48 UTC: Se despliega la actualización que activa la configuración incorrecta globalmente.
-
Menos de 4 minutos después: El tráfico hacia 1.1.1.1 comienza a caer abruptamente.
-
22:01 UTC: Cloudflare detecta el problema y lo anuncia públicamente.
-
22:20 UTC: Se revierte el error de configuración y se reanuncian los prefijos de BGP afectados.
-
22:54 UTC: El servicio se restablece completamente en todas las regiones.
¿Qué servicios se vieron afectados?
El impacto no fue menor. La interrupción afectó a múltiples rangos de IP clave del sistema DNS de Cloudflare:
-
1.1.1.1: su solucionador DNS principal. -
1.0.0.1: su solucionador DNS secundario. -
2606:4700:4700::1111y2606:4700:4700::1001: sus equivalentes en IPv6. -
Además de otros bloques de IP usados dentro de su infraestructura global.
En otras palabras, millones de dispositivos, redes domésticas, empresas y aplicaciones que dependían de estos solucionadores experimentaron caídas, lentitud o fallos de conexión.
Interrupciones que afectan a rangos de IP clave (Fuente: Cloudflare)
En cuanto al impacto técnico del incidente, la mayoría de los protocolos de consulta DNS se vieron seriamente afectados. Las solicitudes hechas a través de UDP, TCP y DNS sobre TLS (DoT) hacia las direcciones afectadas sufrieron una caída considerable en volumen. Sin embargo, el tráfico DNS sobre HTTPS (DoH) se mantuvo bastante estable.
¿La razón? DoH utiliza una ruta distinta para llegar a su destino, pasando por cloudflare-dns.com, lo que lo protegió en gran medida de la interrupción general.
Impacto del incidente para cada protocolo (Fuente: Cloudflare)
Podría interesarte leer: Cloudflare Bloquea un Ataque DDoS Récord de 73 Tbps
¿Qué hará Cloudflare para evitar que esto vuelva a pasar?
Después de analizar el incidente, Cloudflare reconoció que el error de configuración podría haberse evitado si hubieran usado un sistema con despliegues progresivos. En otras palabras, el fallo se coló porque todavía dependen de sistemas heredados que no permiten probar los cambios de forma gradual antes de aplicarlos globalmente.
Por eso, uno de los principales pasos que tomarán será acelerar la migración a una infraestructura más moderna, basada en topologías de servicio abstractas en lugar de rutas IP estáticas. Esta nueva arquitectura permitirá:
-
Desplegar cambios de forma escalonada
-
Monitorear el estado del sistema en cada etapa
-
Revertir rápidamente cualquier modificación que cause problemas
Además, Cloudflare admitió que la configuración errónea pasó por revisión de pares sin que nadie la detectara, en gran parte por una falta de documentación clara sobre cómo están estructuradas sus topologías de servicio y cómo se comporta el enrutamiento interno. Esto también está en la lista de tareas pendientes: mejorar la documentación y los procesos de revisión para minimizar riesgos en el futuro.