CNAME before A? The DNS record order bug that crashed Cisco switches

On January 14, 2026, Cloudflare published a post mortem about a bug in its public 1.1.1.1 DNS resolver that caused some DNS responses to list CNAME records after the final A record answer instead of before it. For people who are not familiar with these terms, the Domain Name System (DNS) is the internet's phonebook that turns human friendly names such as www.example.com into numeric IP addresses that computers use to connect. A CNAME record is like a forwarding address, saying that one name is an alias for another, while an A record gives the final numeric IP address. A resolver is the server that receives your request and follows these forwarding steps until it finds the A record.

The bug emerged from a performance optimization. In an effort to save some memory allocations and copies, Cloudflare engineers changed the resolver's code to append CNAME records to an existing answer list instead of inserting them at the beginning. As a result, responses sometimes placed CNAME entries at the bottom of the answer section, after the resolved A record. Many DNS client programs assume a specific order when they read an answer. They start by looking for records matching the original query name, then when they see a CNAME, they update the name they are looking for and continue down the list. If the CNAME appears after the final A record, the client first sees the A record for the alias, ignores it because it does not match the expected original name, then later sees the CNAME and updates its expected name, but by then there are no records left, so the client thinks the answer is empty.

One prominent implementation that broke was the getaddrinfo function in glibc, a core software library used on many Linux systems for DNS resolution. Its internal getanswer_r routine expects CNAME records before any address records; when the order was reversed, it failed to return the answer, causing name resolution failures. The impact was not limited to software on ordinary computers. Cloudflare said that the DNSC process in three models of Cisco ethernet switches experienced spontaneous reboot loops when those switches were configured to use 1.1.1.1 and received a response with reordered CNAMEs. Cisco has published a service document describing the issue. Not every DNS client is affected. Cloudflare noted that systemd-resolved, which is common on modern Linux distributions, first parses all response records into an ordered set and can search the entire set when following a CNAME chain, so the order does not matter for it.

The standards themselves left room for this confusion. The foundational DNS specification, RFC 1034, published in 1987, says that a recursive response may include the answer to the query, possibly preceded by one or more CNAME records. The word "precede" suggests CNAMEs should come first, but RFC 1034 does not use the normative language that modern standards use, such as MUST or SHOULD. That language was only standardized later, in RFC 2119, published in 1997. A further subtlety is the difference between a Resource Record Set (RRset) and the overall answer section. RFC 1034 says that the order of records within an RRset, which is a group of records with the same name, type, and class, is not significant. But the specification does not clearly state how an answer section containing multiple RRsets should be ordered. Modern DNS specifications have shown that a message section can contain multiple RRsets, for example in DNSSEC responses, but the older text was ambiguous.

Cloudflare's post mortem notes that the resolver originally implemented the specification correctly, with CNAMEs first, but there were no automated tests asserting that behavior. The performance optimization that saved memory inadvertently changed the order, and because the RFC language was not strict, the regression went unnoticed until real users and devices started failing. This incident highlights a broader lesson: even widely used, well-run public resolvers can encounter edge cases in old protocol specifications, and the lack of explicit normative requirements combined with insufficient test coverage can allow subtle bugs to reach production.

For everyday internet users, businesses, and IT teams, the story is a reminder that DNS is a foundational part of nearly every online activity, and its reliability depends on both client and server correctly interpreting decades-old standards. A privacy-first DNS service such as AEU DNS, which offers encrypted DNS lookups to help prevent snooping and tampering, also has a responsibility to handle these protocol details correctly, because a resolver that returns records in an unexpected order can break connectivity just as effectively as one that is down. The best defense is to keep your devices and network equipment updated, use a resolver with active maintenance and testing, and understand that even seemingly minor optimizations can have real-world consequences.