Skip to content

CONCEPT Cited by 1 source

Stub vs recursive resolver

The stub vs recursive resolver dichotomy describes the two fundamentally different kinds of DNS client software. RFC 1034 §5 uses the word "resolver" for both, but the resolver behaviour it describes assumes the full recursive variant — which is not what most end-user applications actually run. This split is load-bearing for understanding which half of the DNS population implements which half of the RFC, and for understanding why the 2026-01-08 1.1.1.1 incident broke some clients but not others.

Recursive resolver

A recursive resolver (also called a full resolver) is the server-side of the DNS protocol. It accepts a query, walks the authoritative hierarchy (root → TLD → authoritative server), follows CNAME chains by restarting the query at the new name, and eventually returns a fully-resolved answer.

Examples:

RFC 1034 §5.2.2 ("In most cases a resolver simply restarts the query at the new name when it encounters a CNAME") was written with these in mind.

Stub resolver

A stub resolver is the client-side library that most applications actually link against. It does not walk the authoritative hierarchy — it forwards queries to a configured recursive resolver (e.g. 1.1.1.1) and parses the response. Stubs are the last-mile layer between userspace code and DNS.

Examples:

  • glibc getaddrinfo — Linux userspace default; sequential expected-name parser.
  • systems/systemd-resolved — systemd's system stub; parses into an ordered set.
  • musl libc's resolver, macOS's <dns_sd.h>, Windows' GetAddrInfoEx, browser-built-in resolvers.
  • Embedded DNS stacks in routers, switches, IoT devices (Cisco's Catalyst DNSC process is an example).

Why the split matters

Stub resolvers are simpler — they don't need to understand NS/glue/delegation or walk zones; they just need to extract addresses from the response their recursive sent them. This simplicity means stubs often:

  • Skip CNAME-restart logic (they aren't resolving; they're parsing).
  • Assume specific wire-format layouts that aren't RFC-mandated (e.g. CNAMEs before A records).
  • Are embedded in firmware and never updated once shipped — the long tail Cloudflare explicitly invokes in the 1.1.1.1 post-mortem.

Why "RFC-compliant" can still break stubs

RFC 1034 §5.2.2's CNAME-restart language doesn't apply to stub resolvers because stubs don't restart queries — they process responses. So a resolver behaviour that the full-resolver spec permits (e.g. reordering A and CNAME records inside an answer section) can still break stubs that read the response with stricter assumptions.

This is the structural reason the 2026-01-08 Cloudflare incident affected glibc getaddrinfo (stub) and Cisco Catalyst DNSC (stub) but did not affect 1.1.1.1-the-recursive-resolver as a downstream (another recursive hitting Cloudflare): other recursives do CNAME-restart and never encounter a full merged chain in the response.

Implication for protocol evolution

DNS standards evolve through full recursive resolvers (where the bar is "does Unbound/BIND/Knot implement it") but deploy into a world dominated by stubs (where the bar is "does every embedded device shipped in the last 20 years tolerate the change"). The second bar is much higher. This is why the Cloudflare post settles for a conservative "require CNAMEs in order" wire format and a companion Internet-Draft rather than relying on the RFC's technically-permissive language.

Last updated · 200 distilled / 1,178 read