Photo of a storm over a city

Lecciones de la interrupción de Cloudflare 1.1.1.1: Una perspectiva de resiliencia

Picture of Amreesh Phokeer
Internet Resilience Insights, Internet Society
Twitter logo
LinkedIn logo
Facebook logo
July 22, 2025
En resumen
  • Una interrupción de una hora de uno de los servicios mundiales 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 usuarios de Internet también pueden mejorar la resistencia de su 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 se derivó de 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 DNS grandes y centralizados.

En esta entrada de blog, analizamos lo que esta interrupción revela sobre la resiliencia de Internet, especialmente sobre la diversidad de resoluciones DNS, y las mejores prácticas que los ISP y los usuarios deberían tener en cuenta de cara al futuro para mejorar la higiene operativa y la resiliencia del DNS.

¿Por qué importaba tanto?

En esencia, el DNS es la libreta de direcciones de Internet. Si falla la resolución DNS, no se puede acceder a los sitios web ni a las aplicaciones, aunque la red subyacente funcione correctamente.

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 gestionaba aproximadamente 1,9 billones de consultas DNS al día, atendiendo a usuarios de unos 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 países en los que Cloudflare suele ser el proveedor de DNS preferido (ya sea por rendimiento o por política).

Implicaciones para los PSI y los Operadores de Resolver

Para los ISP y los operadores de red, la interrupció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, sobre todo en regiones en desarrollo, tienen recursos limitados para ejecutar y mantener sus propios resolvedores de caché. En estos casos, es habitual subcontratar un resolutor público como 1.1.1.1 u 8.8.8.8 (DNS de Google). 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 resolvedores locales pueden seguir reenviando consultas a proveedores externos, pero con la ventaja añadida del almacenamiento en caché y una lógica de reserva que ayuda a garantizar la continuidad del servicio, incluso cuando un proveedor de acceso se queda sin servicio.

Lecciones para los usuarios finales

Es posible que los usuarios finales que configuran manualmente 1.1.1.1 en sus dispositivos (normalmente para obtener un mejor rendimiento o ventajas 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 de DNS, deberían configurarse al menos dos proveedores de DNS. Otra recomendación es utilizar el resolvedor de tu ISP si es compatible con las normas y prácticas de privacidad modernas.

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. Abrazando 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

Contenido traducido

El contenido en francés y español disponible en Internet Society Pulse puede haber sido generado usando servicios de traducción automática, por lo que podría no reflejar con total precisión el texto original.

La versión oficial es el texto en inglés.