Skip to content

CONCEPT Cited by 1 source

DNS message ordering

DNS message ordering is the question of what order records must appear in within a DNS response message's Answer section — and the 40-year-old ambiguity in RFC 1034 that makes this question hard to answer from the spec alone. The 2026-01-19 Cloudflare post is the cleanest public articulation of the ambiguity and its practical consequences.

Two axes of ordering

The Cloudflare analysis separates ordering into two distinct axes:

  1. Intra-RRset order — records within a single RRset (same name, type, class). RFC 1034 §3.6 is explicit:

    The order of RRs in a set is not significant, and need not be preserved by name servers, resolvers, or other parts of the DNS.

  2. Inter-RRset order within a message section — records belonging to different RRsets but sharing a message section (e.g. a CNAME and the A record it aliases, or two CNAMEs in a chain with different owner names). Not specified by RFC 1034. §6.2.1 shows an order-insignificance example but the example contains only two A records for the same name — i.e. one RRset — so it doesn't address inter-RRset ordering.

The "preface" non-normative hint

RFC 1034 §4.3.1:

The answer to the query, possibly preface by one or more CNAME RRs that specify aliases encountered on the way to an answer.

"Preface" reads as a constraint to modern readers ("the CNAME records come before the answer") but RFC 1034 predates RFC 2119 MUST/SHOULD/MAY by 10 years, so the word carries no formal requirement force. A spec- conformant implementation can place CNAMEs before, after, or interleaved with the terminal A record. A spec-conformant parser can assume any of those orderings.

How RFC 4035 (DNSSEC) improves the language

RFC 4035 — written after RFC 2119 — uses explicit normative keywords:

When placing a signed RRset in the Answer section, the name server MUST also place its RRSIG RRs in the Answer section. The RRSIG RRs have a higher priority for inclusion than any other RRsets that may have to be included.

This mandates which RRsets must be included but — notably — not where they must appear within the section. So even the modernised language focuses on inclusion rather than order.

Practical consequence: sequential parsers

Widely-deployed stub resolvers parse the Answer section sequentially with a single expected_name variable (glibc getaddrinfo's getanswer_r is the reference implementation). These parsers require:

  • CNAMEs before the terminal A/AAAA record, AND
  • CNAME chain itself in order (each CNAME's owner matching the expected name at the moment it is encountered).

RFC 1034 does not require either of these invariants. The 2026-01-08 1.1.1.1 incident detonated exactly on the first: Cloudflare's cache-merge refactor changed from CNAMEs-before to CNAMEs-after; glibc getaddrinfo returned "no answer" for affected hostnames; the Cisco DNSC process in three Catalyst models crashed (reboot loop) on the unexpected layout. Resolvers with ordered-set parsing (systems/systemd-resolved) absorbed the change transparently.

The Internet-Draft remediation

Cloudflare has filed draft-jabley-dnsop-ordered-answer-section at the IETF DNSOP working group to formalise both ordering invariants as RFC-level MUST — so future implementations can statically assume them rather than discovering them via production regressions.

Last updated · 200 distilled / 1,178 read