In a recent article titled “What came first- the CNAME or the A record?” Cloudflare explains how an unclear RFC specification caused the popular Cloudflare’s 1.1.1.1 service to break. After identifying the breakage and the ambiguity in older DNS standards regarding record order, Cloudflare proposes a clarified specification.
On January 8, a routine update to the DNS service changed the order in which CNAME records appeared in responses, causing some DNS clients to fail when resolving names because they expected the alias records to come first. While most modern software treats the order of records in DNS responses as irrelevant, the Cloudflare team found that some implementations expect CNAME records to appear before all other record types.
When that order changed, DNS resolution started failing, triggering a significant outage of the popular public 1.1.1.1 DNS service. Sebastiaan Neuteboom, systems engineer at Cloudflare, explains why and when the change was introduced:
While making some improvements to lower the memory usage of our cache implementation, we introduced a subtle change to CNAME record ordering. The change was introduced on December 2, 2025, released to our testing environment on December 10, and began deployment on January 7, 2026.
When a DNS resolver looks up a name with a CNAME record, it may see a series of alias records linking the original name to a final address, and it caches each step with its own expiry time. Cloudflare notes that if part of this chain has expired in the cache, the resolver only re-fetches the expired portion and combines it with the valid parts to form the complete response.
Cloudflare highlights that when a DNS resolver looks up a name with a CNAME, it may see a series of alias records linking the original name to a final address, and the resolver caches each step with its own expiry time. If part of this chain has expired in cache, the resolver only re-fetches the expired piece and then combines it with the still valid parts to form the complete response. Neuteboom adds:
Previously, the code would create a new list, insert the existing CNAME chain, and then append the new records (…) However, to save some memory allocations and copies, the code was changed to instead append the CNAMEs to the existing answer list. As a result, the responses that 1.1.1.1 returned now sometimes had the CNAME records appearing at the bottom, after the final resolved answer.
;; 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.
While many DNS client implementations do not depend on the order, for example, systemd-resolved, others, including the getaddrinfo function in glibc, handle the chain in the resolution by keeping track of the expected name for the records and iterating sequentially, expecting to find the CNAME records before any answers. On Reddit, a user comments:
On the one hand, I really respect the details in their post-mortems and really high standard in engineering, but on the other hand, I can’t help to think that they do not have proper testing in place (and culture thereof) to understand the impact they have globally.
On a popular Hacker News thread, many users discuss whether the RFC is actually unclear, with the subtle distinction of RRsets versus RRs in message sections, or whether developers at Cloudflare misunderstood it. Patrick May comments instead:
A great example of Hyrum’s Law: “With a sufficient number of users of an API, it does not matter what you promise in the contract: all observable behaviors of your system will be depended on by somebody.” combined with failure to follow Postel’s Law: “Be conservative in what you send, be liberal in what you accept.”
In an Internet-Draft to be discussed at the IETF, Cloudflare proposes an RFC that explicitly defines how to correctly handle CNAME records in DNS responses.
According to the published timeline, Cloudflare began the global rollout on January 7 and reached 90% of servers by January 8 at 17:40 UTC. The company declared the incident soon after, began reverting the change at 18:27 UTC on January 8, and completed the rollback by 19:55 UTC.
