Cloudflare resolvió fallos de Gateway y Workers

Cloudflare registró y resolvió dos incidentes distintos el 2 de noviembre: problemas de conectividad de DNS-over-TLS sobre IPv4 en Gateway y retrasos en los despliegues de Workers. Las fichas públicas sitúan los eventos en horas diferentes y los atribuyen a servicios separados. No describen una caída general de la plataforma ni establecen una causa común entre ambos.

El incidente de Gateway empezó a las 22:12 UTC y terminó a las 00:34 UTC del 3 de noviembre, unas dos horas y 22 minutos después. Durante ese intervalo, los clientes afectados podían encontrar timeouts y fallos de resolución al usar DoT sobre IPv4. Cloudflare limitó explícitamente el alcance: DoT sobre IPv6, DNS-over-HTTPS y DNS estándar por UDP o TCP no estaban afectados. La ficha no dice que un cliente cambiara de transporte automáticamente; eso depende de su configuración.

-InfraCrew dice: “el DNS estaba caído” es un diagnóstico demasiado grande para una incidencia que la propia ficha limita a DoT por IPv4.-

El segundo evento afectó a despliegues de Cloudflare Workers. Comenzó a las 16:41 UTC y se dio por resuelto a las 17:30, con una duración de 49 minutos. El aviso dice que algunos clientes podían observar retrasos al desplegar actualizaciones; no detalla el número de cuentas o publicaciones afectadas ni identifica una causa técnica. La notificación describe el proceso de despliegue, no declara una interrupción general del servicio de ejecución de Workers.

Dos síntomas, dos comprobaciones

Las ventanas no coinciden: el retraso de Workers quedó resuelto más de cuatro horas antes de que comenzara el problema de Gateway. No hay base en los avisos para conectar ambos incidentes o interpretarlos como fases de una misma avería. En operaciones, esa separación importa: una resolución DNS lenta puede afectar a clientes que consultan Gateway, mientras una cola de despliegue retrasada bloquea la entrega de cambios. Son planos distintos y requieren comprobar señales distintas.

Para los equipos de red, la pista concreta es el transporte configurado para las consultas DNS. Si una política corporativa usa Gateway mediante DoT sobre IPv4, la incidencia sí encaja con los síntomas descritos; si emplea DoH, DoT sobre IPv6 o DNS por UDP/TCP, Cloudflare dice que esas rutas no estaban afectadas. Eso no demuestra que todo cliente tuviera una alternativa funcional: una ruta disponible en el servicio no sirve si el resolver local no está configurado para usarla.

-InfraCrew dice: tener IPv6 y DoH en el diagrama no equivale a tenerlos como salida cuando falla el camino que usa producción.-

Para desarrollo y plataforma, el aviso de Workers apunta a demora en publicar una actualización, no a pérdida confirmada de la versión ya desplegada. Si el pipeline mostró una operación lenta durante esa ventana, conviene comprobar qué versión quedó activa antes de repetirla; la ficha no permite concluir que todos los despliegues fallaran ni que el código en ejecución se interrumpiera. Es una inferencia operativa a partir del alcance publicado, no un detalle confirmado por Cloudflare.

Cómo leer el estado resuelto

Cloudflare marcó ambos eventos como resueltos: Gateway a las 00:34 UTC del día 3 y Workers a las 17:30 UTC del día 2. “Resuelto” describe esos incidentes concretos; no es una garantía de que no hubiera otros avisos en servicios diferentes ni una explicación de la causa raíz. Ninguna de las dos fichas publica un análisis posterior con mecanismo, región afectada o número de clientes.

La respuesta práctica es conservar la hora del síntoma, el servicio y el transporte implicado antes de abrir una incidencia o rehacer una configuración. Para Gateway, separar fallos de resolución de consultas de otros problemas de conectividad evita cambiar registros a ciegas. Para Workers, distinguir retraso de despliegue de error de ejecución evita convertir una cola lenta en un rollback innecesario. Los avisos públicos permiten acotar el impacto, pero no sustituyen las métricas del tenant ni un postmortem que aún no aparece en esas páginas.

-InfraCrew dice: cuando una página de estado cierra el ticket sin contar la causa, la línea temporal sigue siendo lo más útil para el runbook.-

Diccionario de la Crew

DoT — DNS-over-TLS, transporte que protege consultas DNS dentro de una conexión TLS.
DoH — DNS-over-HTTPS, consultas DNS enviadas mediante HTTPS.
Gateway — Servicio de Cloudflare que aplica políticas de seguridad y filtrado a las consultas de red de una organización.
Worker — Aplicación serverless que Cloudflare ejecuta en su red perimetral.
UTC — Tiempo universal coordinado, referencia usada en las marcas horarias de los incidentes.

Fuentes

Cloudflare Status — Gateway DoT over IPv4 | https://www.cloudflarestatus.com/incidents/3bv9locsg7ln
Cloudflare Status — Worker Deployments Delayed | https://www.cloudflarestatus.com/incidents/7he1pmetw77p