On January 8, 2026, a routine update to Cloudflare's 1.1.1.1 DNS resolver triggered widespread resolution failures across the Internet. The culprit? A subtle change in the order of DNS records that exposed a 40-year-old protocol ambiguity.

The Incident Timeline

The problematic code change was introduced on December 2, 2025, aimed at reducing memory usage in Cloudflare's cache implementation. After passing through testing environments, the update rolled out globally on January 7, 2026. By January 8 at 18:19 UTC, Cloudflare declared an incident as DNS resolution failures mounted. The change was fully reverted by 19:55 UTC, ending the impact.

What Actually Happened

The update modified how 1.1.1.1 handles CNAME (Canonical Name) chains in DNS responses. Previously, CNAME records appeared first, followed by the final resolved addresses. The optimization reversed this order, placing CNAMEs after A/AAAA records.

While most modern DNS software treats record order as insignificant, some widely-deployed implementations—including glibc's getaddrinfo() function used on Linux systems—expect CNAME records to appear before any other answer records. When records arrived in the new order, these clients failed to resolve domains correctly.

Even more dramatically, three models of Cisco ethernet switches experienced spontaneous reboot loops when their DNSC process received reordered CNAMEs.

The RFC Ambiguity

RFC 1034, published in 1987, states that recursive DNS responses should include "the answer to the query, possibly preface by one or more CNAME RRs." The word "preface" has guided implementation behavior for nearly four decades, yet it was never formalized as a strict requirement using modern RFC terminology like MUST or SHOULD.

This ambiguity exists because RFC 1034 clearly states that record order within an RRset (Resource Record Set) is insignificant, but doesn't specify ordering requirements between different RRsets in a message section. Later specifications like RFC 4035 for DNSSEC use more explicit language, but for unsigned zones, the ambiguity remains.

Moving Forward

Cloudflare has reverted the CNAME ordering change and committed to maintaining CNAMEs before other records. More importantly, they've submitted an Internet-Draft proposal to the IETF to explicitly define correct CNAME handling in DNS responses, helping prevent future confusion across the industry.

The incident serves as a reminder that even well-intentioned optimizations can expose hidden assumptions in decades-old protocols that billions depend on daily.

Source: Cloudflare Blog