Lecciones de la interrupción de Cloudflare 1.1.1.1: Una perspectiva de resiliencia
En resumen
- La interrupción durante una hora de uno de los servicios globales más populares del Sistema de Nombres de Dominio (DNS) puso de manifiesto la necesidad de una mayor diversidad de esta infraestructura crítica de Internet.
- Los proveedores de servicios de Internet deben configurar sus redes para consultar múltiples servicios DNS o ejecutar sus propios resolutores recursivos locales siempre que sea posible.
- Los internautas también pueden mejorar su resistencia a la conectividad configurando sus dispositivos para que consulten más de un servicio DNS.
La semana pasada (14 de julio de 2025), el popular servicio de resolución de dominios públicos (DNS) de Cloudflare-1.1.1.1-experimentó una importante interrupción que afectó a usuarios de todo el mundo.
Según el informe de Cloudflare posterior al incidente, el problema tuvo su origen en una mala configuración de los sistemas heredados utilizados para mantener la infraestructura que anuncia las direcciones IP de Cloudflare en Internet.
El incidente, aunque duró relativamente poco (62 minutos), puso de manifiesto una debilidad esencial en lo mucho que el ecosistema de Internet -en particular los proveedores de servicios de Internet (ISP), los operadores de resolución y los usuarios finales- ha llegado a depender de unos pocos servicios de resolución de DNS grandes y centralizados.
En esta entrada de blog, desmenuzamos lo que esta interrupción revela sobre la resistencia de Internet, especialmente sobre la diversidad de resoluciones DNS, y qué mejores prácticas deberían considerar los ISP y los usuarios de cara al futuro para mejorar la higiene operativa y la resistencia del DNS.
¿Por qué importa tanto?
En esencia, el DNS es la libreta de direcciones de Internet. Si falla la resolución DNS, los sitios web y las aplicaciones se vuelven inaccesibles, incluso si la red subyacente funciona por lo demás.
El servicio 1.1.1.1 de Cloudflare es uno de los resolvedores de DNS abiertos más utilizados del mundo. A principios de 2025, 1.1.1.1 gestiona aproximadamente 1,9 billones de consultas DNS diarias, atendiendo a usuarios de ~250 países y territorios.
Diseñado para ofrecer velocidad y privacidad, ha ganado popularidad entre los usuarios finales y los ISP, que lo configuran como su resolvedor recursivo predeterminado. Según W3Techs, la cuota de mercado de Cloudflare para la resolución DNS se estima en torno al 14,6% de todos los sitios web.
Leer: ¿Se está imponiendo el gran DNS?
El 14 de julio, muchos de estos usuarios se encontraron de repente sin poder acceder a Internet, no porque su conexión a Internet estuviera caída, sino porque los nombres de dominio ya no se resolvían. Los efectos fueron especialmente notables en los países en los que Cloudflare suele ser el proveedor de DNS preferido (ya sea por rendimiento o por política).
Implicaciones para los ISP y los operadores de resolución
Para los ISP y los operadores de red, el apagón ofrece una clara advertencia de que depender de un único resolvedor DNS ascendente, por muy fiable que parezca, introduce un único punto de fallo.
Muchos ISP pequeños o regionales, especialmente en regiones en desarrollo, disponen de recursos limitados para ejecutar y mantener sus propios resolutores de caché. En estos casos, es habitual subcontratar un resolutor público como 1.1.1.1 u 8.8.8.8 (Google DNS). Sin embargo, este modelo sólo funciona de forma fiable si el proveedor seleccionado sigue estando disponible. Cuando falla, también lo hace el servicio DNS para todos los clientes, rompiendo esencialmente la experiencia de Internet.
Esta situación subraya la necesidad de resiliencia por diseño, y uno de los principios básicos es la diversidad, que es una práctica recomendada por KINDNS. En lugar de confiar en un único proveedor de DNS ascendente, los operadores deben configurar sus sistemas para que consulten a varios resolutores, como Cloudflare (1.1.1.1), Google (8.8.8.8), Quad9 (9.9.9.9) u OpenDNS (208.67.222.222). Con numerosos proveedores en rotación, un fallo en un servicio no se traduce en una pérdida completa de la funcionalidad DNS: las consultas pueden seguir resolviéndose a través de rutas alternativas.
Los ISP deben ejecutar sus propios resolutores recursivos locales siempre que sea posible, idealmente con almacenamiento en caché y validación DNSSEC. Esta configuración mejora el rendimiento, la seguridad y la privacidad del usuario y proporciona a los ISP un mayor control operativo. Estos resolutores locales pueden seguir reenviando consultas a proveedores externos, pero con la ventaja añadida del almacenamiento en caché y la lógica de reserva que ayuda a garantizar la continuidad del servicio, incluso cuando un proveedor ascendente se queda a oscuras.
Lecciones para los usuarios finales
Es posible que los usuarios finales que configuran manualmente el 1.1.1.1 en sus dispositivos (normalmente para obtener un mejor rendimiento o ventajas en materia de privacidad) también hayan notado la interrupción.
La mayoría de los usuarios no saben cómo evaluar la fiabilidad del DNS ni se dan cuenta de las posibles consecuencias de codificar un único proveedor de DNS en sus teléfonos, routers u ordenadores portátiles. Por lo tanto, al establecer manualmente las configuraciones DNS, deberían configurarse al menos dos proveedores DNS. Otra recomendación es utilizar el resolver de su ISP si es compatible con los estándares modernos y las prácticas de privacidad.
El incidente del DNS de Cloudflare nos recuerda que incluso los sistemas bien diseñados fallan. El objetivo de una Internet resistente no es eliminar todos los fallos, sino mitigar su impacto y garantizar una rápida recuperación cuando se produzcan.
Los ISP, los usuarios finales y los operadores de resolución tienen todos un papel que desempeñar. Adoptando la redundancia, adoptando las mejores prácticas y reduciendo las dependencias estructurales, podemos garantizar una Internet más resistente e inclusiva para todos.
Foto de Nahil Naseer en Unsplash