CONCEPT Cited by 1 source

Resource Record Set¶

A Resource Record Set (RRset) is a DNS protocol primitive defined in RFC 1034 §3.6: a collection of records that share the same owner name, type, and class. An RRset is the atomic unit over which RFC 1034 defines ordering — and this narrowness is at the heart of the ambiguity exposed by the 2026-01-08 1.1.1.1 incident.

RFC 1034 §3.6 definition¶

Records inside a single RRset are unordered:

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.

Two A records for example.com → 192.0.2.1 and example.com → 192.0.2.2 form a single RRset; a resolver can return them in either order.

Scope: RRset vs message section¶

A DNS message's Answer section can contain multiple RRsets of different types and owner names. RFC 1034 does not say anything about their relative order:

www.example.com.    3600   IN    CNAME  cdn.example.com.        # RRset #1
cdn.example.com.    300    IN    A      198.51.100.1            # RRset #2

Each of these is its own RRset (different owner name). The "intra-RRset order is insignificant" rule does not constrain whether RRset #1 precedes RRset #2 or vice versa. This is the gap the DNS message ordering ambiguity lives in.

Relevance to DNSSEC¶

RFC 4035 introduced RRSIG RRsets — cryptographic signatures covering a target RRset. DNSSEC treats message sections as containing multiple RRsets (signature RRset + signed RRset) — so the "message sections contain multiple RRsets" reality was formalised in DNSSEC even though RFC 1034's language continues to treat message sections as sequences of individual records (RRs) rather than RRsets.

Relevance to CNAME chains¶

Each CNAME in a CNAME chain has a distinct owner name and is therefore its own RRset:

www.example.com.        CNAME  cdn.example.com.            # RRset A
cdn.example.com.        CNAME  server.cdn-provider.com.    # RRset B
server.cdn-provider.com. A      198.51.100.1               # RRset C

The "intra-RRset order is insignificant" rule says nothing about whether RRset A precedes RRset B precedes RRset C. RFC 1034's §6.2.1 examples all show a single RRset, so they do not clarify the inter-RRset case either. This is the structural reason a sequential parser with a single expected_name variable can silently fail if the CNAME chain appears out of chain-traversal order — each CNAME lives in its own RRset, and the spec permits any ordering of them.

Significance on the wiki¶

The RRset concept is the vocabulary Cloudflare uses to cleanly separate intra-RRset order (spec-settled: insignificant) from inter-RRset order (spec-unsettled: de facto implementation- bound). Any future DNS-ordering discussion on the wiki should disentangle the two axes using this primitive.