Incidente de caída de Cloudflare 1.1.1.1 del 14 de julio de 2025

• Cloudflare sufrió una caída total de 62 minutos en el resolver DNS público 1.1.1.1 el 14 de julio de 2025 durante un cambio en la topología del servicio
• La mayoría de los usuarios globales se vio afectada directamente y experimentó imposibilidad de usar Internet
• La causa fue una configuración incorrecta en un sistema legado interno, sin relación con un ataque externo ni con un secuestro de BGP
• La caída se desencadenó por la acumulación de cambios de configuración incorrectos junto con un restablecimiento a escala de toda la red
• Como medidas para evitar recurrencias, se prepara la introducción de un sistema de despliegue gradual y el retiro del sistema de configuración legado

---

Resumen

El 14 de julio de 2025, Cloudflare provocó una falla global de red en el resolver DNS público 1.1.1.1 durante un cambio en la topología del servicio. Debido a esta caída, los usuarios que utilizaban 1.1.1.1 y el servicio Gateway DNS experimentaron durante 62 minutos indisponibilidad de Internet o una degradación severa del servicio. La causa fue un error de configuración en un sistema legado interno, y no un ataque externo ni un secuestro de BGP.

Alcance e impacto de la caída

• Entre 21:52 UTC y 22:54 UTC, el resolver 1.1.1.1 quedó prácticamente inoperable a nivel mundial
• La mayoría de los clientes globales no pudo resolver nombres de dominio, por lo que el uso de Internet en sí resultó imposible
• La situación de la caída puede verificarse en Cloudflare Radar
• La causa de la caída fue una configuración incorrecta en un sistema legado que administra la infraestructura encargada de anunciar en Internet las direcciones IP que posee Cloudflare
• Se produjo un impacto crítico en todo el tráfico que llegaba a Cloudflare a través del canal 1.1.1.1

Causa y contexto del incidente

• Cloudflare utiliza enrutamiento Anycast para servicios globales como el resolver DNS
• Aunque presta servicio en distintas regiones, algunos servicios que requieren localización de datos se limitan a regiones específicas
• El 6 de junio, durante un cambio de configuración para preparar futuros servicios DLS (data localization), el rango de IP del resolver 1.1.1.1 se incluyó sin intención en el nuevo DLS
  • Este error no se aplicó de inmediato y en la práctica no tuvo impacto, por lo que no se generó ninguna alerta
• El 14 de julio se aplicó un cambio para añadir una ubicación offline de prueba a la topología DLS
  • Ese cambio forzó una actualización global de la configuración de red, lo que dejó expuesto el error previo
  • Los prefijos de 1.1.1.1 fueron retirados de los centros de datos de todo el mundo, interrumpiendo el servicio

Línea de tiempo del incidente (resumen)

• 2025-06-06 17:38: el cambio de configuración para el servicio DLS incluye los prefijos de 1.1.1.1 (sin impacto, error latente)
• 2025-07-14 21:48: un cambio de configuración refresca la configuración de toda la red y comienza el retiro global de los prefijos de 1.1.1.1
• 2025-07-14 21:52: caída abrupta del tráfico global de DNS
• 2025-07-14 22:01: alerta interna y declaración oficial del incidente
• 2025-07-14 22:20: rollback a la configuración anterior e inicio del procedimiento de recuperación del servicio
• 2025-07-14 22:54: normalización del tráfico, desactivación de alertas y fin del incidente

IP y protocolos afectados por la caída

• Alcance del impacto: prefijos amplios de IPv4 e IPv6, como 1.1.1.0/24, 1.0.0.0/24 y 2606:4700:4700::/48
• Se observó una caída abrupta del tráfico en consultas que usan UDP, TCP y DoT (DNS over TLS)
• DoH (DNS over HTTPS) casi no se vio afectado, ya que en muchos casos se basa en el dominio cloudflare-dns.com

Explicación técnica de la caída

Caída del servicio del resolver 1.1.1.1

• El 6 de junio se introdujo un error en los prefijos durante un cambio previo de configuración para DLS
• El 14 de julio se añadió una ubicación offline con fines de prueba y se actualizó la configuración de toda la red
• En ese proceso, los prefijos del resolver 1.1.1.1 quedaron limitados globalmente a una sola ubicación offline y el servicio fue retirado

Análisis de la causa técnica

• Actualmente, Cloudflare opera en paralelo con un sistema legado y un nuevo sistema estratégico, sincronizando los anuncios de enrutamiento por espacio de direcciones

• El sistema legado depende de actualizaciones manuales y carece de despliegue gradual, lo que aumenta la probabilidad de errores

  • Hubo peer review y revisión por otros ingenieros, pero no existía una estructura que garantizara una aplicación gradual, como un despliegue canario

• El nuevo enfoque, en lugar de depender de hardcoding, está centrado en la topología e incorpora cambios graduales y un sistema de monitoreo

• A las 22:01 se activó una alerta del resolver DNS

• Se confirmó que todas las rutas del resolver habían desaparecido de la tabla interna de enrutamiento BGP

• Tras el retiro de los prefijos, la subred 1.1.1.0/24 recibió un intento de anuncio BGP por parte de Tata Communications India (AS4755)

  • Esto se asemejó a un secuestro temporal de prefijo, pero no estuvo directamente relacionado con el incidente

Procedimiento de recuperación y acciones posteriores

• A las 22:20 UTC se hizo rollback a la configuración anterior y se volvieron a anunciar los prefijos
  • Aproximadamente el 77% del tráfico se recuperó de inmediato
  • Algunos servidores edge se reiniciaron automáticamente, por lo que fue necesario volver a aplicar cambios mediante el sistema manual de gestión de cambios
  • Por seguridad de la red, normalmente se hace un rollout gradual, pero en este incidente se aplicó rápidamente tras la validación
• A las 22:54, todas las ubicaciones volvieron a la normalidad

Próximas mejoras

• Implementación de un esquema de despliegue gradual (Stage Deployment): retiro del método de despliegue legado e incorporación de una estructura de rollback automático basada en health checks
• Aceleración del retiro del sistema legado: eliminación de configuraciones manuales riesgosas y del método de despliegue asociado, con refuerzo de la documentación y de la cobertura de pruebas

Conclusión

La caída del resolver DNS 1.1.1.1 de Cloudflare fue causada por un error de configuración interna, y la empresa está concentrando esfuerzos en introducir mejoras de estabilidad y medidas para prevenir recurrencias. También ofreció disculpas a sus clientes por los inconvenientes y planea seguir reforzando acciones para minimizar incidentes similares en el futuro.

[GN⁺]

Opiniones en Hacker News

• Para muchos usuarios, que el resolvedor 1.1.1.1 (DNS) no funcione significa quedarse sin acceso a casi todos los servicios de Internet. Pero normalmente, ¿no se configuran dos servidores DNS en todos los dispositivos? Me pregunto si el segundo también se cayó, o si no, por qué no cambió a ese servidor

  • Cloudflare recomienda configurar ambos, 1.1.1.1 y 1.0.0.1, como servidores DNS. Pero por el error de configuración que causó esta caída, se detuvieron los anuncios BGP de Cloudflare para los prefijos 1.1.1.0/24 y 1.0.0.0/24
  • En Android, en Configuración > Red e Internet > DNS privado, solo se puede ingresar un solo "Private DNS provider hostname" (hasta donde sé). Y no entiendo por qué no acepta una IP (1.1.1.1) y exige necesariamente una dirección (one.one.one.one). Al especificar un servidor DNS, parece mucho más lógico configurarlo por IP
  • Poner dos es mejor que no poner ninguno, pero no es perfecto. Si uno falla, como no se hace seguimiento de cuál está funcionando bien, normalmente terminas con latencias largas e intermitencias. Pasa lo mismo a menos que uses una configuración más avanzada, como un proxy DNS local con caché y varios upstreams
  • Si crees que sabes hablar de DNS, te recomendaría operar tu propio servicio. El dominio raíz . ha funcionado bien durante décadas; la razón principal de que 1.1.1.1 tenga problemas no es DNS en sí, sino Anycast. Cloudflare (y Google, etc.) insisten en usar IPs "vanity"; para hacer posible ese tipo de IPs hay que usar Anycast, así que el problema real no es DNS sino Anycast. Recomiendo elegir y configurar más de un proveedor
  • La configuración recomendada por Cloudflare es usar 1.0.0.1 como DNS secundario de respaldo, pero durante este incidente ese servidor también se vio afectado

• Es interesante que, durante una caída de unos 20 minutos, el tráfico de 1.1.1.1 solo bajara alrededor de un 20%. Sorprende que Cloudflare siga tropezando con un problema tan simple y tan viejo (ni es la primera vez, ni parece que será la última). El 8.8.8.8 y 8.8.4.4 de Google prácticamente no han tenido ni un segundo de downtime global en casi 10 años. (1: hubo algunos problemas regionales, pero eso fue culpa de Internet; incluso cuando otros servicios de Google han sufrido caídas graves, el DNS en sí siguió funcionando bien)

  • No solo importa la disponibilidad; en DNS también son importantes la velocidad y la privacidad. Si eres usuario en Europa, podrías usar esta lista de alternativas europeas de DNS en lugar de una empresa estadounidense sujeta al CLOUD Act
  • A la opinión de que no se entiende cómo no pueden resolver fácilmente problemas de ingeniería en una red del tamaño y complejidad de Cloudflare, se responde que, en realidad, son problemas que solo experimenta el 0.001% de la industria
  • Cloudflare tiene una cultura razonable de respuesta a incidentes, pero le faltan incentivos para fomentar activamente medidas preventivas
  • Ese 20% mencionado significa que algunos clientes/resolvedores, después de varios fallos de respuesta, marcan temporalmente al servidor DNS como inactivo para que el usuario no tenga que esperar 500 timeouts por cada solicitud. A largo plazo, en el gráfico de tráfico el volumen vuelve a la normalidad
  • Estoy de acuerdo en que mucha gente no quiere usar Google DNS

• Sorprende que haya tardado más de 5 minutos en detectarse el impacto (aunque el tráfico del protocolo principal cayó al 10% y se mantuvo ahí). Nunca he operado un sistema tan grande, pero esperaría una alerta inmediata. Me gustaría saber si a los expertos esto les parece razonable

  • Siempre hay una tensión constante entre la velocidad de detección y la tasa de falsos positivos. Sistemas de monitoreo como Nagios o Icinga normalmente requieren 3 fallos consecutivos para disparar un evento, porque los errores transitorios son comunes. Si hay demasiadas alertas, los responsables se insensibilizan y aumenta la reacción de "esperemos un poco". No he operado un servicio global como Cloudflare, pero una detección confiable en 8 minutos no me sorprende
  • Como en los antiguos NOC (centros de operaciones de red), si estos gráficos estuvieran colgados en la pared, alguien los habría visto, habría dicho "qué raro" y se habría lanzado de inmediato
  • Creo que cuando empezó el impacto el servicio no estaba completamente caído (especialmente si era el inicio de un despliegue global), así que habría tomado tiempo hasta que el efecto pudiera medirse
  • Si haces que la alerta suene en menos de 1 minuto, al final solo estarás poniendo a prueba el rendimiento de la infraestructura de alertas. La pregunta real es si puedes recopilar y calcular los datos de forma estable cada minuto
  • Cuando se cae un servicio de agregación de métricas, los indicadores pueden retrasarse hasta que el sistema se vuelva a desplegar y parecer una caída del 100%. Si envías la alerta al minuto, despiertas innecesariamente a mucha gente a las 2 a. m.; y si eso se repite, al final las alertas se relajan cada vez más, así que se termina ajustando a algo como 5 minutos

• Es un buen resumen. Me pareció interesante la parte donde dice que DoH (DNS sobre HTTPS) se accede en su mayoría mediante el dominio cloudflare-dns.com (ya sea por configuración manual o por el navegador), y que, como no usa una IP directamente, se vio relativamente menos afectado por la caída. A mí sí me afectó ayer; aunque tenía DoH activado en el router, no resolvía nada, y al cambiar a 8.8.8.8 se solucionó

  • Me pregunto cómo funciona DoH. Tienes que conocer la IP de cloudflare-dns.com, y quizá el router estaba usando 1.1.1.1 para eso
  • Hoy estaba configurando un dominio nuevo y, durante unos 20 minutos, solo podía acceder desde Firefox en una laptop. La herramienta de Google DNS decía que el dominio estaba activo, y también podía hacer SSH al servidor en AWS, pero en mi red local no había resolución DNS. Limpié caché e intenté de todo, pero resultó que solo ese navegador Firefox estaba configurado por separado para usar Cloudflare DoH
  • No estoy de acuerdo. La causa raíz real queda escondida detrás de terminología pedante y ambigua, lo que termina confundiendo incluso a administradores con experiencia. El término "legacy" no es claro; más bien se siente abstracto y opaco. Si lees algo como "los componentes legacy no aprovechan despliegues graduales, y Cloudflare introducirá un enfoque moderno con despliegue gradual y rollback", se entiende lo que quieren decir, pero no había necesidad de escribirlo de una forma tan difícil de entender
  • Mi router Unifi parece usar DoH automático con Cloudflare y Google al mismo tiempo. No noté el impacto, así que o el DoH de Cloudflare siguió funcionando o cambió a Google de inmediato
  • En general es un buen resumen, pero la parte de la cronología al principio del texto no coincide con los hechos

• Si usas dnsmasq, puedes configurar varios servidores DNS al mismo tiempo y usar el que responda más rápido. Incluso si un servicio se cae, casi no lo notas

  • Al usar all-servers sin la configuración strict-order, dnsmasq reintenta automáticamente contra todos los servidores. Pero si usas systemd-resolved, los reintentos se hacen solo en orden, así que es importante alternar servidores de distintos proveedores. Si además combinas IPv4 e IPv6 como en el ejemplo, el failover será más rápido. La IP correspondiente de Quad9 tiene activado el filtrado por defecto, mientras que las otras dos no, así que los resultados de resolución pueden ser distintos. Personalmente, si te importa la validación de DNSSEC (extensiones de seguridad del sistema de nombres de dominio), no deberías mezclar resolvedores que validan con otros que no. (Los DNS del ejemplo sí son compatibles con DNSSEC)
  • Preguntan si existe una configuración más privada para quienes no quieren exponer todo su historial DNS a Big Tech (Cloudflare, Google, etc.) y tampoco quieren DoH. Parecería buena idea usar en dnsmasq una lista de DNS pequeños y confiables, pero queda la duda de si es mala etiqueta enviar solicitudes a varios proveedores cada vez. Tampoco está claro dónde encontrar una lista estable de DNS centrados en privacidad
  • Los distintos proveedores de DNS tienen políticas y prioridades diferentes, así que yo no los consideraría intercambiables. Más bien elegiría uno y dejaría el DNS del ISP como respaldo
  • Si usas systemd-resolved, ya tienes soporte por defecto para DoT y DNSSEC, así que puedes lograr algo parecido. Si quieres evitar por completo el DNS centralizado, puedes correr un demonio de Tor y exponer un resolvedor DNS en tu red. También puedes tener varios resolvedores
  • Incluso sin la configuración all-servers, dnsmasq hace periódicamente una carrera de solicitudes entre los servidores (por defecto reintenta cada 20 segundos). Aunque haya una caída repentina, probablemente no te afectará por más de unos segundos

• Incluso una caída de alrededor de 1 hora equivale a 0.13% en un mes y 0.0114% en un año. Me pregunto cuál es el SLO (objetivo de nivel de servicio) que Cloudflare aplica a este servicio. Encontré este enlace, pero es solo para servicios de pago. Con esta caída, la disponibilidad de julio cae en la banda de "< 99.9% but >= 99.0%", y en ese caso te reembolsan el 10% de la tarifa

  • Creo que, para mantener la reputación de la marca, debe apuntar a 99.9% anual o más

• Es interesante que, incluso después del incidente, el tráfico no haya vuelto completamente a la normalidad. Últimamente uso luci-app-https-dns-proxy de OpenWrt para enviar solicitudes a Cloudflare y Google DNS al mismo tiempo; como DoH casi no se vio afectado, no noté la caída (si DoH también hubiera fallado, habría cambiado automáticamente a Google)

  • Más adelante en el texto se explica con más detalle por qué el tráfico no se recuperó de inmediato justo después del incidente. Parece que algunos servidores requerían intervención directa
  • Cuando ocurre una caída, muchas veces simplemente dejas de tener Internet y haces otra cosa por un rato. Supongo que casi nadie se pone a cambiar de proveedor DNS durante ese tiempo
  • Como los clientes cachean temporalmente los resultados DNS, también puede pasar que sigan usando valores anteriores durante un tiempo después de la caída

• Sorprende que tanto 1.1.1.1 como 1.0.0.1 hayan sido afectados por el mismo cambio. Ahora parece que para respaldo DNS habrá que usar un proveedor completamente distinto (por ejemplo: 8.8.8.8, 9.9.9.9)

  • En realidad, ambas direcciones son parte del mismo servicio. Nunca se anunciaron como respaldos independientes entre sí
  • El propósito original del diseño de DNS es usar el resolvedor más cercano. Conviene diversificar bien entre varios proveedores, backbones y regiones (y, si es posible, también evitar direcciones Anycast). Pero en este caso, por cómo funciona DNS, también puedes encontrarte con problemas inesperados
  • En realidad, siempre fue así
  • Yo ya lo tengo configurado mezclando OpenDNS, Quad9 y Cloudflare en dos Pi-hole. La mayoría de mis dispositivos usan esos dos Pi-hole como DNS respectivos
  • En realidad, el concepto mismo de "respaldo DNS" no tiene mucho sentido. La mayoría de los clientes simplemente eligen una dirección al azar y la usan; si una falla, no necesariamente cambian automáticamente a la otra. Es una situación donde el comportamiento real no coincide con lo que uno esperaría

• La topología interna de Cloudflare ha ido evolucionando de forma que los sistemas "legacy" y "strategic" se mantengan sincronizados. Es un texto que explica claramente el estado actual de forma comprensible tanto para técnicos como para no especialistas. Incluso hace que el proceso de migración resulte interesante. También da una buena impresión que pidan disculpas por las molestias del incidente y transmitan que van a trabajar en mejoras y prevención de recurrencias. Valoro mucho esa actitud de la empresa

  • "legacy" es un término que usan sobre todo los técnicos, mientras que "strategic" lo suelen usar marketing o líderes no técnicos; mezclarlos puede terminar confundiendo y fastidiando a ambos lados

• Sorprende que, aunque varios ingenieros revisaron el rebranding, nadie detectara el error de agregar 1.1.1.0/24 a la lista de rerouting. Me pregunto qué clase de error humano, o incluso malicia, pudo haber causado esto. Parece que haría falta una excepción hardcodeada en DLS (Domain List Service) para impedir que 1.1.1.1/32 y 1.0.0.1/32 se asignen a una sola ubicación

  • Quizá la causa fue la confianza de "si lo hizo Jerry, debe estar bien"
  • Yo suelo inclinarme más por culpar a las herramientas que a las personas. Según cómo esté estructurado el sistema o cómo se generen los archivos de configuración, este tipo de errores puede pasar fácilmente desapercibido (sobre todo si el diff es autogenerado). Al final, el code review también lo hacen personas, así que este tipo de fallo es un problema de proceso. En la práctica, para evitar que un servicio realmente grande se caiga, hace falta una estrategia defensiva con múltiples salvaguardas en varias capas