Recursive vs Authoritative — the query lifecycle

The cast

The rules

1. Recursion is a configured service, not a reflex (recursion yes; in BIND → server advertises RA). Roots/TLDs have it off by design, forever.
2. Every level knows only its own zone. Nobody holds the full map; the complete answer emerges from the resolver stitching referrals together.
3. A referral IS an authoritative answer — delegation records from the server’s own zone. Referral ≠ recursion.
4. Jurisdiction rule: NXDOMAIN may only be declared for names inside the answering server’s zone. Fake TLD → root says it. Unregistered .com → TLD says it. Missing subdomain → only the domain’s own servers say it.
5. Hub, not chain. The resolver originates every query. Root/TLD/authoritative never talk to each other; the authoritative only ever sees resolver IPs.
6. The resolver caches everything — answers AND referrals — so full walks are rare.
7. An authoritative server matches the deepest suffix it has data for, then answers/refers/denies. That’s all it ever does.

Lifecycle (nothing cached)

stub → resolver:            "A for app.example.com?" (RD=1)
resolver → root:            referral: ".com is delegated to these servers"
resolver → .com TLD:        referral: "example.com → ns1/ns2.exampledns.net"
resolver → ns1:             ANSWER (aa): app.example.com A 203.0.113.10, TTL 300
resolver → stub:            the IP (cached for next time)

RD / RA — two independent switches

• RD (Recursion Desired): set by the client. Plain dig = RD 1; +norecurse = RD 0. +norecurse flips one bit in the outgoing packet — it changes what dig asks for, never what dig does. dig never recurses; @server only changes the recipient.
• RA (Recursion Available): set by the server — the fingerprint of a resolver.

THE troubleshooting move

Disagree → stale caches (TTL problem): wait or flush. Agree but wrong → the zone data is wrong: fix the record. One pair of commands halves the problem space.