Networking

Cloudflare, en un reciente artículo titulado «What came first- the CNAME or the A record?» (¿Qué vino primero, el CNAME o el registro A?), explica cómo una especificación RFC poco clara provocó una interrupción en el popular servicio 1.1.1.1 de Cloudflare. Tras identificar el fallo y la ambigüedad en las normas DNS más antiguas con respecto al orden de los registros, Cloudflare propone una especificación clarificada.

El 8 de enero, una actualización rutinaria del servicio DNS cambió el orden en que aparecían los registros CNAME en las respuestas, lo que provocó que algunos clientes DNS fallaran al resolver nombres porque esperaban que los registros alias aparecieran primero. Si bien la mayoría del software moderno trata el orden de los registros en las respuestas DNS como irrelevante, el equipo de Cloudflare descubrió que algunas implementaciones esperan que los registros CNAME aparezcan antes que cualquier otro tipo de registro.

Cuando ese orden cambió, la resolución DNS comenzó a fallar, lo que desencadenó una interrupción significativa del popular servicio DNS público 1.1.1.1. Sebastiaan Neuteboom, ingeniero de sistemas de Cloudflare, explica por qué y cuándo se introdujo el cambio:

Mientras realizábamos algunas mejoras para reducir el uso de memoria de nuestra implementación de caché, introdujimos un cambio sutil en el orden de los registros CNAME. El cambio se introdujo el 2 de diciembre de 2025, se lanzó a nuestro entorno de pruebas el 10 de diciembre y comenzó a implementarse el 7 de enero de 2026.

Cuando un resolvedor DNS busca un nombre con un registro CNAME, puede ver una serie de registros alias que vinculan el nombre original a una dirección final, y almacena en caché cada paso con su propio tiempo de expiración. Cloudflare señala que si una parte de esta cadena ha expirado en la caché, el resolvedor solo vuelve a buscar la parte expirada y la combina con las partes válidas para formar la respuesta completa.

Cloudflare destaca que cuando un resolvedor DNS busca un nombre con un CNAME, puede ver una serie de registros alias que vinculan el nombre original a una dirección final, y el resolvedor almacena en caché cada paso con su propio tiempo de expiración. Si una parte de esta cadena ha expirado en la caché, el resolvedor solo vuelve a buscar la parte expirada y luego la combina con las partes aún válidas para formar la respuesta completa. Neuteboom añade:

Anteriormente, el código crearía una nueva lista, insertaría la cadena CNAME existente y luego agregaría los nuevos registros (…) Sin embargo, para ahorrar algunas asignaciones y copias de memoria, el código se cambió para agregar en su lugar los CNAME a la lista de respuestas existente. Como resultado, las respuestas que 1.1.1.1 devolvió ahora a veces tenían los registros CNAME que aparecían en la parte inferior, después de la respuesta resuelta final.

;; QUESTION SECTION:
;; www.example.com.	       IN    A

;; ANSWER SECTION:
cdn.example.com.    300    IN    A      198.51.100.1
www.example.com.    3600   IN    CNAME  cdn.example.com.

Si bien muchas implementaciones de clientes DNS no dependen del orden, por ejemplo, systemd-resolved, otras, incluida la función getaddrinfo en glibc, manejan la cadena en la resolución realizando un seguimiento del nombre esperado para los registros e iterando secuencialmente, esperando encontrar los registros CNAME antes que cualquier respuesta. En Reddit, un usuario comenta:

Por un lado, realmente respeto los detalles en sus análisis post-mortem y el alto nivel de ingeniería. Por otro lado, no puedo evitar pensar que no tienen pruebas adecuadas en su lugar (y una cultura de ello) para comprender el impacto que tienen a nivel mundial.

En un popular hilo de Hacker News, muchos usuarios discuten si el RFC es realmente poco claro, con la sutil distinción entre RRsets y RRs en las secciones de mensajes, o si los desarrolladores de Cloudflare lo malinterpretaron. Patrick May comenta en cambio:

Un gran ejemplo de la Ley de Hyrum: «Con un número suficiente de usuarios de una API, no importa lo que prometas en el contrato: todos los comportamientos observables de tu sistema serán dependidos por alguien», combinado con el fracaso de seguir la Ley de Postel: «Sé conservador en lo que envías, sé liberal en lo que aceptas».

En un Internet-Draft que se discutirá en la IETF, Cloudflare propone un RFC que define explícitamente cómo manejar correctamente los registros CNAME en las respuestas DNS.

Según la cronología publicada, Cloudflare comenzó el despliegue global el 7 de enero y alcanzó el 90% de los servidores el 8 de enero a las 17:40 UTC. La compañía declaró el incidente poco después, comenzó a revertir el cambio a las 18:27 UTC del 8 de enero y completó la reversión a las 19:55 UTC.