Skip to content

CONCEPT Cited by 1 source

CNAME chain

A CNAME chain is a sequence of DNS alias records traversed during name resolution:

www.example.com → cdn.example.com → server.cdn-provider.com → 198.51.100.1

Each step is a CNAME record ("Canonical Name" — one name is an alias for another) except the terminal step, which is a concrete A/AAAA record resolving the last name to an IP address. A recursive resolver such as systems/cloudflare-1-1-1-1-resolver|1.1.1.1 is responsible for following the full chain before returning an answer.

Per-hop TTLs and partial expiry

Each record in the chain has its own TTL and is cached independently:

www.example.com → cdn.example.com (TTL: 3600)   # still cached
cdn.example.com → 198.51.100.1   (TTL: 300)     # expired

When some records in the chain are still valid and others have expired, the chain is partially expired. A resolver that caches each record separately can re-resolve only the expired portion and merge the freshly-resolved records with the cached chain to form the response — this is the optimisation that motivated the regression documented in sources/2026-01-19-cloudflare-what-came-first-the-cname-or-the-a-record.

Chain traversal at the parser

On the client side, the stub resolver receiving the response must follow the chain to find the final address. Two common implementation shapes:

  1. Sequential expected-name parse — track a single expected_name variable, start it at the QNAME; each CNAME whose owner matches advances it; the final A/AAAA whose owner matches the last expected_name is the answer. Used by glibc getaddrinfo (getanswer_r) and — from the 2026-01-08 incident — apparently by Cisco's DNSC process in three Catalyst switch models. Requires CNAMEs to appear in chain order, before the terminal A/AAAA record.
  2. Ordered-set search — parse all records into a set, then repeatedly search the set for the record whose owner matches the current expected name. Used by systems/systemd-resolved. Tolerates any legal record ordering.

Ordering invariants (from 2026-01-19 Cloudflare post)

The load-bearing result of the Cloudflare write-up is that two separate ordering invariants both affect sequential parsers, only one of which is constrained by RFC 1034:

  • Intra-RRset order (RFC 1034 §3.6) — "the order of RRs in a set is not significant."
  • Inter-RRset order within a message section — not specified by RFC 1034 either way. Each CNAME in a chain is its own RRset (different owner name), so RFC 1034's "RRset order is insignificant" does not constrain whether www.example.com. CNAME cdn.example.com. appears before or after cdn.example.com. CNAME server.cdn-provider.com..

Sequential parsers can therefore break in two ways: (a) A record before any CNAME (the detected regression); (b) CNAME chain internally out-of-order even with CNAMEs before the A record — e.g. cdn→server before www→cdn, because the first CNAME is skipped (owner doesn't match QNAME), the second is accepted (owner now matches), but the skipped first one is never revisited.

Last updated · 200 distilled / 1,178 read