- El 8 de enero de 2026, una actualización del servicio 1.1.1.1 de Cloudflare cambió el orden de los registros dentro de las respuestas DNS, lo que provocó fallas de resolución DNS para algunos usuarios en todo el mundo
- La causa del problema fue un cambio de código que movió los registros CNAME detrás de los registros A/AAAA, y algunas implementaciones de clientes DNS dependían de ese orden
- En particular, se vieron afectados la función
getaddrinfo de glibc y el proceso DNSC de switches Cisco, y en este último caso incluso se produjeron bucles de reinicio
- El RFC 1034 solo indica que “los CNAME pueden ir al inicio (possibly preface)”, por lo que no existe un estándar claro sobre el orden de los registros
- Cloudflare volvió a colocar siempre primero los CNAME y presentó ante la IETF un Internet-Draft para definir un estándar más claro
1. Resumen del incidente
- El 8 de enero de 2026 se desplegó una actualización para reducir el uso de memoria en 1.1.1.1, lo que cambió el orden de los registros dentro de las respuestas DNS
- El cambio se introdujo en la base de código el 2 de diciembre de 2025, se desplegó al entorno de pruebas el 10 de diciembre y comenzó su lanzamiento global el 7 de enero de 2026
- El incidente se declaró el 8 de enero a las 18:19 UTC, el rollback comenzó a las 18:27 y la recuperación se completó a las 19:55
- La mayoría de los clientes DNS modernos ignoran el orden de los registros dentro de la respuesta, pero algunas implementaciones asumen que el CNAME siempre debe aparecer primero
- Cuando ese orden cambió, algunos clientes trataron la respuesta como si estuviera vacía, causando fallas de resolución
2. Cadena de CNAME y comportamiento de caché
- Al consultar un dominio, por ejemplo
www.example.com, este puede resolverse hasta la IP final pasando por varias cadenas de CNAME
- Ejemplo:
www.example.com → cdn.example.com → server.cdn-provider.com → 198.51.100.1
- Cada enlace CNAME tiene un TTL (Time-To-Live) y solo algunas partes pueden expirar
- 1.1.1.1 vuelve a consultar solo la parte expirada y luego combina la caché existente con los registros nuevos para construir la respuesta
3. Detalles del cambio de código
- En el código anterior, primero se insertaba la cadena de CNAME y luego se agregaban los registros A/AAAA
answer_rrs.extend_from_slice(&self.records); // CNAMEs first
- En el código modificado, los CNAME se agregaban al final
entry.answer.extend(self.records); // CNAMEs last
- Como resultado, los CNAME se movieron a la parte inferior de la respuesta y algunos clientes no pudieron procesarlos
4. Casos de implementaciones afectadas
- La función
getaddrinfo de glibc analiza la respuesta secuencialmente y necesita que el CNAME aparezca primero para poder seguir el siguiente nombre
- Si el CNAME aparece después, el “nombre esperado” no se actualiza y el resultado queda vacío
- El proceso DNSC de tres modelos de switches Cisco Catalyst también se vio afectado y, cuando usaban 1.1.1.1, se producía un bucle de reinicio por error fatal
- Cisco publicó la documentación de servicio relacionada
5. Implementaciones no afectadas
- systemd-resolved analiza la respuesta usando una estructura OrderedSet, por lo que puede recorrer el conjunto completo sin importar la posición del CNAME
- Por eso siguió funcionando normalmente pese al cambio en el orden de los registros
6. La ambigüedad del RFC 1034
- El RFC 1034 (1987) dice que una respuesta puede estar precedida (preface) por uno o más CNAME
- Sin embargo, como no usa palabras normativas como MUST/SHOULD, no es un requisito explícito
- Recién con el RFC 2119 (1997) se estandarizaron esas palabras clave, así que el documento original carecía de una expresión clara de obligatoriedad
- Cloudflare colocaba primero los CNAME en su implementación inicial, pero no lo garantizaba mediante pruebas
7. Diferencia entre RRset y secciones del mensaje
- El RFC 1034 §3.6 aclara que el orden dentro de un RRset (conjunto de registros con el mismo nombre, tipo y clase) no es importante
- Pero no menciona el orden entre RRset distintos
- El ejemplo de §6.2.1 solo trata dos registros A con el mismo nombre, y no aborda el orden relativo entre CNAME y A
- Por eso, la definición del orden entre registros CNAME y A sigue siendo un vacío
8. Problema de orden dentro de la cadena CNAME
- Si un CNAME tiene varias etapas, el simple hecho de mezclar el orden de la cadena puede hacer que el análisis secuencial falle
- Ejemplo: si
cdn.example.com CNAME server.cdn-provider.com aparece primero, no se puede encontrar www.example.com CNAME cdn.example.com
- El RFC 1034 tampoco define requisitos sobre el orden dentro de una cadena CNAME
9. Criterio de funcionamiento del resolvedor
- El RFC 1034 §5.2.2 indica que, cuando el resolvedor encuentra un CNAME, debe reiniciar la consulta con el nuevo nombre
- Pero esa explicación está dirigida al resolvedor completo (por ejemplo, 1.1.1.1), mientras que los stub resolvers como glibc no implementan esa lógica
- Como resultado, algunos stub resolvers no siguen el comportamiento esperado por el RFC
10. Comparación con la regulación explícita en DNSSEC
- El RFC 4035 (DNSSEC) sí especifica con MUST la prioridad de inclusión de registros RRSIG
- Aun así, eso regula la “inclusión”, no el “orden”
- DNSSEC aporta reglas claras de inclusión, pero en las zonas no firmadas (Unsigned zones) sigue existiendo la ambigüedad del RFC 1034
11. Conclusión y medidas de Cloudflare
- Aunque según el RFC el orden del CNAME no es obligatorio, algunos clientes lo dan por hecho, así que Cloudflare volvió a la política de colocar siempre primero el CNAME
- Para evitar el mismo problema en el futuro, presentó un Internet-Draft ante la IETF
- A partir de este incidente, Cloudflare confirmó que la ambigüedad de un protocolo de 40 años sigue afectando las operaciones reales
12. Información adicional
- Cloudflare, a través de Connectivity Cloud que incluye 1.1.1.1, ofrece
protección de redes empresariales, aceleración de aplicaciones a escala de Internet, defensa contra DDoS y soporte para implementar Zero Trust
- Con la app gratuita 1.1.1.1 es posible obtener un acceso a Internet más rápido y seguro
1 comentarios
Comentarios de Hacker News
A mí me pareció que la redacción del RFC no era tan ambigua
La expresión “possibly preface” se lee como “si hay un registro CNAME, se pone antes”, no como “si quieres, puedes ponerlo en cualquier lado”
Pero esto no es solo un problema de interpretación de una frase, sino que el punto clave es que el equipo que opera uno de los servidores DNS más importantes del mundo cambió la lógica de respuesta de CNAME
Eso debió romperse claramente en las pruebas, y sorprende que nadie haya preguntado “¿importa este orden?”
Cloudflare últimamente publica estos problemas con transparencia, pero esta vez suena más como “un dato curioso”
Que algo así haya pasado las pruebas en un sistema a gran escala parece un error bastante serio
Como el ejemplo puede generalizarse, deja margen para malinterpretarlo como “el orden no importa en ningún caso”
Al final, lo que para una persona es “una comprensión clara” para otra puede verse como “¿de verdad leíste todo el documento?”
Este caso muestra la importancia del lenguaje normativo (normative language)
La discusión relacionada puede verse en la lista de correo del IETF
La frase “las diferencias de orden no son importantes” solo aplica a ese ejemplo concreto, y no significa que haya que ignorar la regla general
Se dice que RFC 1034 definió RRset, pero en realidad no hay una definición formal de ese término
La interpretación de Cloudflare parece ser confundir una excepción con la regla general
Aun así, como no hay una regla clara sobre el orden de una cadena de CNAME, ahí sigue quedando algo de ambigüedad
Este parece un caso donde actuaron al mismo tiempo la Ley de Hyrum y la Ley de Postel
La idea de que “si suficientes usuarios usan una API, alguien terminará dependiendo de cualquier comportamiento observable del sistema”
choca con el principio de “sé conservador al enviar y liberal al aceptar”
Aquí el punto es que se rompió el resolver de glibc: no es una situación rara en absoluto
La verdadera noticia es que Cloudflare no probó esto correctamente
Este bug me hizo recordar algo viejo
Fue en 2011, cuando Cloudflare ignoró el RFC y permitió CNAME en el apex del dominio
En la entrada del blog de ese entonces decían básicamente que “ignoraremos el RFC y resolveremos el problema real”
Pero CNAME es un concepto de alias a nivel de nombre, así que ponerlo en el apex rompe el caché de NS, MX y SOA
En ese momento muchos ingenieros lo advirtieron, pero era la lógica de “move fast and break things”
Aun así, ver que esta vez analizan con detalle la cadena de CNAME y el orden de los registros A muestra que algo han avanzado
El concepto de CNAME y alias lleva mucho tiempo causando confusión, y el lenguaje no normativo de RFC1034 hizo crecer esa confusión
Todo esto es resultado de ambigüedades acumuladas, pero sigue siendo difícil de aceptar que un proveedor grande haya cometido un error así
Yo diría que más bien el problema era la propia especificación
Sorprende que una búsqueda DNS común en glibc dependa del orden de los registros
Es increíble que no haya dado grandes problemas en más de 20 años
Probablemente la mayoría de los operadores DNS aprendieron empíricamente durante las pruebas que el orden sí importa
Solo llamó la atención porque en Cloudflare afectó a cientos de millones de dispositivos en todo el mundo
Eso sí, me pregunto si Cloudflare ya envió parches a resolvers open source como glibc
CNAME realmente es algo muy difícil de manejar (ver las notas de DJB)
Un resolver simple como el de glibc no tiene caché, así que implementarlo requeriría cambios grandes en el código
Que Cloudflare dijera “el RFC no exige un orden para CNAME” suena a aferrarse a tecnicismos del lenguaje
Que no aparezca un “MUST” no significa que “cualquier orden vale”
Creo que admitir el error y seguir adelante hace del mundo un lugar mejor
Esquivar la responsabilidad con debates de redacción solo termina erosionando la confianza
Parece que Cloudflare no entendió bien RFC1034
Su interfaz DNS bloquea A y AAAA cuando hay un CNAME, pero permite otros registros
Por eso, cuando coexisten CNAME y TXT, se producen resultados dependientes del caché
En internet.nl también detectaron este problema
Algunos usuarios hicieron su configuración siguiendo la guía de mxtoolbox, pero eso entra en conflicto con RFC1034
Una es “cómo delegar un servicio DMARC con CNAME”, y la otra es “cómo alojarlo directamente”
Parece que la captura de pantalla fue lo que generó la confusión
Es razonable que Cloudflare haya llegado finalmente a la conclusión de que CNAME debe ir antes que otros registros
Administrando DNS en la empresa, he sentido de primera mano varias limitaciones de DNS
En especial, cuando ocurre un SERVFAIL, el cliente no puede distinguir cuál servidor está fallando
Como resultado, varios servidores DNS y capas de caché generan una avalancha innecesaria de reintentos
Además, el search path repite consultas NXDOMAIN contra dominios equivocados
Según RFC2308 sección 7.1, está permitido cachear respuestas SERVFAIL
Es un estándar antiguo, pero sigue siendo un enfoque válido
Cloudflare a veces rompe estándares y luego justifica eso escribiendo un nuevo RFC
Casos como RFC 8482 me parecen una vergüenza para la industria
Por eso suena irónico leer “esta vez también enviaron un nuevo Internet-Draft para evitar confusión”
En un servidor DNS de gran escala como 1.1.1.1 deberían existir pruebas de integración con resolvers reales como glibc
Por eso cuesta entender por qué algo así solo se descubrió en producción
Tal vez las pruebas individuales pasaban, pero faltó el caso donde coincidían ambas condiciones