Una caída de más de una hora del popular servicio 1.1.1.1 dejó sin conexión a millones de usuarios. La lección: diversificar los servidores DNS es clave para garantizar la continuidad de acceso a Internet.
El pasado lunes 14 de julio de 2025, Cloudflare, uno de los proveedores más populares de servicios DNS gratuitos y de baja latencia, sufrió una interrupción global de su servicio 1.1.1.1 que duró 62 minutos. Durante ese tiempo, millones de usuarios en todo el mundo vieron cómo la navegación en Internet se detenía por completo. El fallo, reconocido públicamente al día siguiente por la propia compañía, tuvo su origen en una mala configuración interna que afectó a la forma en que se anuncian las direcciones IP de sus resolvers al resto de Internet.
La interrupción no fue producto de un ciberataque ni de un secuestro BGP, sino de un error humano introducido semanas antes, que permaneció inactivo hasta que una actualización de configuración global desactivó la accesibilidad de las direcciones IP utilizadas por el servicio DNS 1.1.1.1. Esto provocó una retirada masiva de los prefijos IP en los centros de datos de Cloudflare, haciendo que la mayoría de peticiones DNS no encontraran respuesta.
Cuando falla tu único DNS, falla Internet
Durante el incidente, quienes tenían configurado únicamente 1.1.1.1 y 1.0.0.1 como servidores DNS vieron cómo todas las conexiones a Internet dejaban de funcionar, incluyendo navegación web, mensajería, aplicaciones y servicios en la nube. Muchos usuarios perdieron tiempo reiniciando routers y dispositivos sin sospechar que el problema estaba en la capa de resolución de nombres.
Este caso pone de manifiesto una práctica común y peligrosa: configurar los DNS primario y secundario del mismo proveedor. Si ambos comparten infraestructura, como ocurre con Cloudflare o Google, una caída técnica puede afectar a ambas direcciones simultáneamente.
La solución: usar DNS de distintos proveedores
Para garantizar una mayor resiliencia frente a este tipo de fallos, los expertos recomiendan mezclar proveedores de DNS. Es decir, asignar un servidor primario de un proveedor y un secundario de otro. Así, si uno falla, el otro seguirá respondiendo y evitará cortes totales de navegación.
Por ejemplo:
| Proveedor | DNS Primario | DNS Secundario |
|---|---|---|
| Cloudflare | 1.1.1.1 | 1.0.0.1 |
| 8.8.8.8 | 8.8.4.4 | |
| Quad9 (IBM) | 9.9.9.9 | 149.112.112.112 |
| DNS4EU (UE) | 194.242.2.2 | 2a0d:2a00:1::2 |
| Yandex | 77.88.8.8 | 77.88.8.1 |
| OpenDNS (Cisco) | 208.67.222.222 | 208.67.220.220 |
Una configuración robusta, por ejemplo, podría usar 1.1.1.1 (Cloudflare) como primario y 8.8.8.8 (Google) como secundario. De esta forma, incluso si un proveedor sufre una caída, el otro seguirá resolviendo nombres y manteniendo la conexión activa.
⚠️ Eso sí, esta estrategia no es recomendable si se usan servicios DNS con filtrado de contenidos (como bloqueo de publicidad o control parental), ya que el comportamiento del filtrado puede no ser uniforme entre proveedores.
¿Cómo gestiona Windows las consultas DNS?
Según la documentación de Microsoft, el sistema operativo envía primero la solicitud al servidor DNS principal. Si no responde en un segundo, pasa al secundario. Si este tampoco responde, repite la consulta. Tras varios intentos y sin respuesta, da por fallida la petición.
Esto significa que incluso una breve caída del primer servidor puede causar lentitud o interrupciones si el secundario también pertenece al mismo proveedor y sufre el mismo problema. De ahí la importancia de diversificar.
El contexto técnico del fallo en Cloudflare
El incidente, detallado por Cloudflare en su análisis oficial, se debió a una mala configuración introducida el 6 de junio en un servicio preproducción de su plataforma de localización de datos. Al activarse semanas después, dicha configuración desvinculó la red mundial del resolver 1.1.1.1, retirando los anuncios BGP en todos los centros de datos de producción.
Esto supuso que las direcciones IP utilizadas por millones de usuarios ya no estuvieran visibles en la tabla de enrutamiento global de Internet. Aunque el fallo fue revertido rápidamente (en 62 minutos), la pérdida de resolución DNS tuvo efectos visibles e inmediatos.
Un hecho curioso es que, durante la interrupción, se detectó un anuncio no autorizado de la red 1.1.1.0/24 por parte de Tata Communications (AS4755), que si bien no fue causa del problema, sí se hizo visible por la retirada de los prefijos legítimos.
Lecciones aprendidas para usuarios y administradores
- Nunca uses ambos DNS del mismo proveedor sin una alternativa.
- Guarda una lista de DNS públicos fiables y actualizados. Puedes consultar opciones en DNSgratis.com.
- Ten en cuenta las implicaciones si utilizas filtrado de contenido, ya que combinar servicios puede neutralizar ese filtrado.
- Si administras redes o servidores, considera implementar DNS redundantes a nivel de sistema, router y firewall, con monitorización activa.
Este episodio subraya cómo un único punto de fallo en la resolución DNS puede dejar fuera de servicio incluso a usuarios avanzados. Aunque Cloudflare respondió con transparencia y rapidez, su incidente global refuerza la importancia de aplicar buenas prácticas en la configuración del acceso a Internet.
Para más información técnica y alternativas de DNS gratuitas, puedes visitar: https://dnsgratis.com. Y si estás buscando mayor control y privacidad, también puedes explorar soluciones de cloud privado como las ofrecidas por Stackscale.
vía: blog.cloudflare.com
