El popular servicio de resolución de nombres estuvo inactivo durante más de una hora debido a un fallo en la gestión de rutas de red. La compañía confirma que no se trató de un ciberataque.
El pasado 14 de julio, Cloudflare experimentó una interrupción global en su servicio DNS público 1.1.1.1, afectando gravemente a millones de usuarios en todo el mundo durante 62 minutos. La caída comenzó a las 21:52 UTC y se prolongó hasta las 22:54 UTC, provocando que numerosos usuarios no pudieran acceder a servicios básicos de Internet, al depender de este servicio para la resolución de nombres de dominio.
Según explica Cloudflare en su blog oficial, el incidente fue provocado por una errónea configuración interna en su sistema de topologías de servicio, relacionada con su suite de localización de datos (DLS). Esta configuración —introducida el 6 de junio sin impacto inmediato— permaneció latente hasta que una actualización de prueba ejecutada el 14 de julio desencadenó el error. Como consecuencia, las rutas del prefijo 1.1.1.0/24 y otros bloques asociados fueron retiradas de la red global, dejando inaccesible el servicio de resolución DNS desde sus centros de datos.
Una interrupción global con impacto crítico
Durante la ventana de afectación, casi todo el tráfico DNS dirigido a 1.1.1.1 y 1.0.0.1 fue interrumpido. Los protocolos afectados incluyeron UDP, TCP y DNS-over-TLS (DoT). Sin embargo, el tráfico de DNS-over-HTTPS (DoH) —que utiliza el dominio cloudflare-dns.com en lugar de la dirección IP— se mantuvo operativo en gran parte debido a que se basa en un conjunto de IPs diferente.
Además, durante el apagón, Cloudflare detectó un anuncio BGP no autorizado del prefijo 1.1.1.0/24 por parte de Tata Communications (AS4755) en India, lo que generó confusión al parecerse a un intento de secuestro de rutas (BGP hijack). Cloudflare aclaró que este evento fue coincidente pero no causal y que se encuentra en proceso de seguimiento con el operador implicado.
El origen: una transición entre sistemas de configuración
La raíz del problema se encuentra en la coexistencia de sistemas antiguos y modernos para gestionar cómo se anuncian las rutas IP en los distintos centros de datos. El sistema antiguo requería listas explícitas de ubicaciones, lo que resulta propenso a errores y no permite despliegues progresivos ni pruebas parciales. Por el contrario, el sistema moderno emplea descripciones abstractas de servicios, que facilitan un despliegue más controlado y seguro.
El cambio realizado en julio, aunque estaba destinado a un servicio de pruebas no activo, provocó la actualización de la configuración de red global. Como la configuración errónea de junio seguía presente, se eliminaron inadvertidamente las rutas del servicio DNS 1.1.1.1 de todos los centros de datos activos, redirigiéndolas a un centro de pruebas inactivo. La consecuencia fue una pérdida total del servicio.
Restauración y medidas correctivas
A las 22:20 UTC, Cloudflare inició la reversión de la configuración, reanunciando los prefijos afectados. Aunque el tráfico comenzó a recuperarse de forma inmediata, el 23 % de los servidores perimetrales había sido reconfigurado automáticamente durante la caída, y sus rutas no estaban activas. Esto requirió una reconfiguración acelerada para restaurar el servicio en su totalidad, que se completó a las 22:54 UTC.
Entre las medidas anunciadas para evitar futuras interrupciones, Cloudflare destaca:
- Abandonar los sistemas heredados y avanzar en la migración a configuraciones progresivas y controladas por salud del servicio.
- Aplicar despliegues por etapas, especialmente en componentes sensibles como los resolvers DNS.
- Mejorar la cobertura de pruebas y documentación para detectar errores antes de que lleguen a producción.
Conclusión
Este incidente resalta la fragilidad de los sistemas críticos de infraestructura en la era digital y cómo un error interno, aparentemente menor, puede derivar en una caída masiva de servicios en todo el mundo. Cloudflare ha asumido la responsabilidad del fallo y ha prometido mejoras estructurales para evitar su repetición.
Mientras tanto, los usuarios que dependen exclusivamente de 1.1.1.1 para navegar podrían plantearse configurar resolvers alternativos o redundantes, como 8.8.8.8 de Google o 9.9.9.9 de Quad9, para mitigar el riesgo de interrupciones futuras. La resiliencia de la red empieza por la diversidad.
vía: Cloudflare
