CNAME Record Ordering Issue in 1.1.1.1 DNS Resolver

On 8 January 2026 a routine memory‑saving change in Cloudflare’s 1.1.1.1 resolver altered the placement of CNAME records inside DNS answers. Some stub resolvers assumed CNAMEs appear before other records; the new order caused resolution failures and device reboots, exposing a long‑standing ambiguity in the original DNS specifications.

Deep Technical Analysis

The following sections detail the original merging logic, the memory‑optimized modification, the affected client implementations, and the normative gaps in the DNS standards that allowed the regression.

Original Merging Logic

The resolver built a fresh answer vector, first inserting cached CNAMEs and then appending newly fetched A/AAAA records. This guaranteed that every CNAME appeared at the start of the answer section, matching the expectations of many stub resolvers.

Memory‑Optimized Change

To reduce allocation overhead the code was altered to extend the existing answer list with the new CNAMEs, effectively placing them after the already‑present address records. The change eliminated one vector copy but unintentionally reordered the response.

Impact on Stub Resolvers

Clients such as glibc’s getaddrinfo iterate the answer section sequentially, updating an “expected name” when a CNAME is seen. When a CNAME appears after the final A record, the expected name never matches, and the resolver treats the response as empty. A similar bug in certain Cisco Ethernet switch firmware caused reboot loops when processing the reordered answer.

RFC Ambiguity

RFC 1034 (1987) describes CNAMEs as “possibly prefacing” the answer but lacks normative language like MUST or SHOULD. The specification defines ordering significance only within a single RRset, not across different RRsets. Later documents such as RFC 4035 introduce explicit MUST statements for DNSSEC records but do not address CNAME ordering for unsigned zones, leaving implementers to infer behavior.

Mitigation and Future Proposal

Cloudflare reverted the code to restore original ordering and issued an Internet‑Draft that proposes a clear requirement for CNAMEs to precede other answer records. The draft aims to close the RFC 1034 gap and provide consistent guidance for both recursive and stub resolvers, reducing the risk of similar outages.