La Caída de Cloudflare No Fue un Hackeo — Fue un Cambio de Configuración. Qué Deben Hacer los Developers.

Un día de 2025, millones de sitios web quedaron offline durante casi una hora. No fue ransomware. No fue un DDoS récord. Un cambio de configuración en la infraestructura de Cloudflare se propagó globalmente y tiró su DNS resolver (1.1.1.1 — el mismo que probablemente tienes configurado o que usan tus usuarios).

La caída de Cloudflare DNS fue el recordatorio más caro del año de un concepto que los developers tienden a ignorar: el riesgo operacional de un proveedor único. Tu postura de seguridad no importa cuando la falla viene de adentro de la infraestructura en la que confías.

Qué pasó exactamente con el DNS de Cloudflare

Cloudflare aplicó un cambio de configuración de enrutamiento — relacionado con BGP (Border Gateway Protocol), el protocolo que determina cómo viajan los paquetes por internet — que causó una interrupción en su servicio de DNS resolver.

El resultado: millones de consultas DNS empezaron a fallar o a tener timeouts. Y cuando el DNS falla, tu dominio no resuelve. Tu sitio desaparece de internet aunque el servidor de origen esté perfectamente sano.

La recuperación tomó entre 60 y 90 minutos. El post-mortem de Cloudflare confirmó la causa raíz: una mala configuración interna, no un ataque externo.

Dos detalles que importan:

1. 1.1.1.1 es el resolver DNS más usado del mundo. Cuando cae, el impacto es masivo y simultáneo.
2. El tiempo de recuperación depende completamente de Cloudflare. Tú no tienes palancas para acelerar nada.

Por qué esto golpea diferente que un hackeo

Cuando te hackean, tenés un adversario. Podés desconectar el sistema comprometido, rotar credenciales, hacer un rollback, activar el playbook de incidentes. Hay algo que hacer.

Cuando el ingeniero de tu proveedor aplica una mala configuración, no hay nada que hacer. Esperas.

Tu WAF configurado con cuidado: irrelevante. Tu protección DDoS: irrelevante. Tu arquitectura de microservicios distribuida con alta disponibilidad: irrelevante. El problema está más arriba en el stack, donde no tienes control.

Este es el riesgo operacional que los developers rara vez incluyen en su modelo de amenazas. Pasamos tiempo pensando en "¿qué pasa si me hackean?" y casi ningún tiempo pensando en "¿qué pasa si mi proveedor de infraestructura tiene un incidente?"

La respuesta honesta suele ser: mi sitio se cae y espero.

La trampa del proveedor único

Cloudflare es genuinamente bueno. Es barato, tiene una DX excelente, la documentación es clara, y la capa gratuita es generosa. Tiene sentido usarlo.

El problema no es Cloudflare. El problema es usar Cloudflare para todo al mismo tiempo:

• DNS autoritativo para tu dominio
• CDN y caché
• Protección DDoS
• WAF
• Resolver DNS (1.1.1.1) para tus usuarios
• Workers para lógica de edge
• Tunnel para exponer servicios internos

Cuando todo pasa por un solo proveedor, el blast radius de cualquier incidente de ese proveedor es total. No perdés una capa. Las perdés todas.

Esto no es una crítica a Cloudflare. AWS us-east-1 ha tenido interrupciones que tiraron la mitad de internet. Azure cayó varias veces en 2024. Ningún proveedor tiene SLA del 100%. El riesgo es el modelo de dependencia única, no el proveedor.

Resiliencia DNS: cuáles son tus opciones reales

DNS primario + secundario con diferentes proveedores

La mayoría de los registradores de dominios te permiten configurar múltiples name servers autoritativos. La idea es simple: usás dos proveedores DNS distintos sirviendo los mismos registros. Si uno cae, los resolvers DNS del mundo automáticamente consultan al otro.

Una combinación común: Cloudflare DNS + AWS Route 53, o Cloudflare DNS + NS1.

# Ejemplo: name servers de tu dominio en tu registrador
# En lugar de solo nameservers de Cloudflare:
ns1.cloudflare.com
ns2.cloudflare.com
 
# Configurás dos proveedores:
ns1.cloudflare.com
ns2.cloudflare.com
ns-123.awsdns-12.com      # Route 53 como secundario
ns-456.awsdns-34.net

Los resolvers DNS (como el del dispositivo de tu usuario) intentan múltiples name servers cuando uno no responde. Si el name server de Cloudflare no responde, el resolver pasa al de Route 53 automáticamente.

TTL bajo antes de cambios, TTL alto en estado estable

El TTL (Time to Live) de tus registros DNS determina cuánto tiempo los resolvers guardan en caché tu registro antes de consultarlo de nuevo.

• Estado estable (sin cambios planeados): TTL alto — 3600 segundos o más. Si tu DNS tiene un problema momentáneo, los registros en caché de los usuarios sobreviven la interrupción.
• Antes de un cambio planeado: Bajá el TTL a 60 segundos 24-48 horas antes. Así podés hacer rollback rápido si algo sale mal.

# Registro DNS con TTL alto (estado estable)
# TTL = 3600 = 1 hora de caché en los resolvers
misitioweb.com.  3600  IN  A  203.0.113.10
 
# Registro DNS con TTL bajo (antes de un cambio de infraestructura)
# TTL = 60 = 1 minuto de caché — cambios se propagan en ~1 minuto
misitioweb.com.  60    IN  A  203.0.113.10

Durante la caída de Cloudflare, los sitios con TTL alto estuvieron protegidos por los registros en caché que ya tenían los resolvers del mundo. Los que tenían TTL de 30 segundos o menos se cayeron inmediatamente.

Health check + failover automático

AWS Route 53 tiene una funcionalidad de health checks que puede cambiar automáticamente a qué IP apunta tu registro DNS si el origen no responde. Cloudflare tiene algo similar en sus tiers de pago (Load Balancing).

La configuración básica de Route 53:

# Route 53: crear health check para tu origen principal
aws route53 create-health-check \
  --caller-reference "$(date +%s)" \
  --health-check-config '{
    "IPAddress": "203.0.113.10",
    "Port": 443,
    "Type": "HTTPS",
    "ResourcePath": "/api/health",
    "FullyQualifiedDomainName": "misitioweb.com",
    "RequestInterval": 30,
    "FailureThreshold": 3
  }'

Si el health check detecta que tu origen no responde tres veces seguidas, Route 53 puede cambiar automáticamente el registro A a un IP de fallback — ya sea un servidor de respaldo o una página de mantenimiento estática en S3.

Qué pueden hacer los developers indie de forma realista

Las estrategias enterprise de multi-CDN con failover automático y SLA contractual cuestan dinero que un proyecto de una persona no tiene. Pero hay cosas concretas y baratas que podés hacer.

1. Identificá tus puntos únicos de falla. Escribilos.

Literalmente, abrí un documento y anotá: "Si X cae, pasa Y." Cloudflare, Vercel, Railway, Fly.io, Supabase, Stripe. Cada uno. ¿Tu sitio sobrevive si cada uno de ellos tiene una hora de downtime?

2. Tu origen tiene que ser directamente accesible.

Si usás Cloudflare como proxy (el modo orange cloud), asegurate de saber la URL directa de tu servidor de origen: el dominio de tu app en Vercel, la URL de Railway, el IP de tu VPS. En una emergencia, podés apuntar el DNS directamente a ese origen o poner esa URL en un status page temporario.

3. Configurá un monitor de uptime independiente.

Better Uptime y UptimeRobot tienen tiers gratuitos que hacen ping a tu sitio cada 60 segundos y te avisan por email o Slack cuando cae. Ambos usan infraestructura separada de Cloudflare, entonces te avisarán aunque Cloudflare sea el problema.

4. Guardá tus credenciales fuera del alcance del incidente.

Si tu gestor de contraseñas online usa DNS de Cloudflare para resolver su propio dominio, durante una caída de Cloudflare no podés acceder a tus credenciales de Cloudflare para hacer cualquier cambio. La ironía es real. Guardá un PDF cifrado con tus accesos críticos de infraestructura offline, o usá un gestor con acceso offline (1Password y Bitwarden funcionan offline una vez cacheadas las credenciales).

La lección real: la mala configuración es la superficie de ataque

Los grandes incidentes de infraestructura de 2024-2025 tienen un patrón claro. No es el hacker sofisticado con exploit de zero-day. Es el cambio de configuración que salió mal.

• GitLab (2017): Un ingeniero borró accidentalmente la base de datos de producción en lugar de la de staging. Costó horas de datos de usuarios.
• AWS us-east-1 (2021): Un error en una herramienta interna de gestión de capacidad causó una interrupción masiva que tiró desde Netflix hasta los Roomba.
• CrowdStrike (2024): Una actualización de contenido de su sensor Falcon empujó un archivo de configuración corrupto que causó BSOD en 8.5 millones de máquinas Windows en todo el mundo.
• Cloudflare DNS (2025): Un cambio de configuración de enrutamiento BGP propagado incorrectamente tiró el resolver DNS más usado del planeta.

El denominador común: la configuración causó el daño, no código malicioso.

Esto tiene implicaciones directas para cómo deberías tratar tus propios archivos de configuración. Tu nginx.conf, tu docker-compose.yml, tus workflows de GitHub Actions, tu vercel.json — todos son infraestructura real con el mismo potencial de causar un incidente si tienen un error.

La config es código. Debería pasar por el mismo proceso de revisión que el código.

Escaneá tu configuración antes de que se convierta en un incidente

Data Hogo escanea tus archivos de configuración de infraestructura junto con tu código fuente. Las malas configuraciones en tu nginx.conf, tu Dockerfile, tus workflows de GitHub Actions — son problemas de seguridad antes de ser operacionales. Un Dockerfile que corre como root, un workflow que expone secretos en logs, un nginx.conf que no fuerza HTTPS: todos generan findings con explicación y fix sugerido.

Si querés saber qué tiene tu repo antes de que lo descubra de la peor manera, es gratis empezar.

TL;DR

• La caída del DNS de Cloudflare en 2025 fue causada por una mala configuración interna, no un ciberataque. 60-90 minutos de downtime global.
• Si todo tu stack (DNS, CDN, WAF, workers) depende de un solo proveedor, el blast radius de cualquier incidente de ese proveedor es total.
• TTL alto en estado estable (3600s+) protege a tus usuarios durante interrupciones cortas porque los registros quedan en caché. Bajalo a 60s solo antes de cambios planeados.
• Configurá un DNS secundario con un proveedor diferente a tu CDN. La mayoría de los registradores soportan múltiples name servers autoritativos.
• Usá un monitor de uptime independiente (UptimeRobot o Better Uptime) para enterarte de caídas antes que tus usuarios.
• Tu origen (Vercel, Railway, Fly.io) debe ser directamente accesible sin pasar por Cloudflare en una emergencia.
• Los grandes incidentes de infraestructura son causados por malas configuraciones, no por hackers. Tratá tu config con el mismo rigor que tu código.