A recent change to 1.1.1.1 accidentally altered the order of CNAME records in DNS responses, breaking resolution for some clients. This post explores the technical root cause, examines the source code of affected resolvers, and dives into the inherent ambiguities of the DNS RFCs.

Cloudflare's platform is a leading provider of internet security and performance solutions, offering insights into web security, content delivery, and DNS management. Through documentation, blog posts, and webinars, Cloudflare provides insights into protecting websites and applications from cyber threats and improving performance. Developers and IT professionals can learn about CDN (Content Delivery Network), DDoS mitigation, and firewall configurations to secure and accelerate web traffic.

Cloudflare

A routine memory optimization to Cloudflare's 1.1.1.1 resolver accidentally changed the order of CNAME records in DNS responses, breaking resolution for clients like glibc's getaddrinfo and causing Cisco switches to reboot. The incident revealed that while RFC 1034 uses the word "preface" to suggest CNAMEs should appear first, it lacks normative language (MUST/SHOULD) making the requirement ambiguous. Some DNS clients use sequential parsing that expects CNAMEs before A records, while others search the entire answer set. Cloudflare reverted the change and proposed an Internet-Draft to formally clarify CNAME ordering requirements in DNS responses.

What came first: the CNAME or the A record?

The DNSSEC specifications provide contrast

<p>Very interesting and Informative read about some subtle internals of DNS resolution; sometimes you think you know something enought, just to realize that there are (often) levels to this.</p>
