• On January 8, 2026, a routine update to 1.1.1.1 aimed at reducing memory usage accidentally triggered a wave of DNS resolution failures for users across the Internet. • The root cause wasn’t an attack or an outage, but a subtle shift in the order of records within our DNS responses. • While most modern software treats the order of records in DNS responses as irrelevant, we discovered that some implementations expect CNAME records to appear before everything else. • When that order changed, resolution started failing. • This post explores the code change that caused the shift, why it broke specific DNS clients, and the 40-year-old protocol ambiguity that makes the “correct” order of a DNS response difficult to define. • All timestamps referenced are in Coordinated Universal Time (UTC).
Article Summaries:
- On January 8, 2026, a routine update to 1.1.1.1 aimed at reducing memory usage accidentally triggered a wave of DNS resolution failures for users across the Internet. The root cause wasn’t an attack or an outage, but a subtle shift in the order of records within our DNS responses. While most modern software treats the order of records in DNS responses as irrelevant, we discovered that some implementations expect CNAME records to appear before everything else. When that order changed, resolution started failing. This post explores the code change that caused the shift, why it broke specific DNS
- On January 8, 2026, a routine memory‑usage update to Cloudflare’s 1.1.1.1 DNS service triggered widespread resolution failures. The change, introduced on December 2, 2025, reordered DNS response records so that CNAMEs were appended after A/AAAA records instead of preceding them. While most resolvers ignore order, some clients expect CNAMEs first, causing lookups to fail. The incident was detected at 18:19 UTC, the release was reverted by 18:27 UTC, and the revert completed at 19:55 UTC, restoring normal operation. The event highlighted a 40‑year‑old ambiguity in the DNS protocol regarding record ordering.
Sources: