<aside> 🧭
Module 03 · Delegation, Recursion & Caching
Module 01 said a recursive resolver "does the work". Module 02 said an NS record hands authority over. This module is the machinery in between — how a resolver walks from the root to an answer, what it stores along the way, and why a change you made an hour ago is still invisible to half the world.
🧠 concept → 🧪 exercise → ✅ expected result (hidden) → 🎯 interview questions (answers hidden)
Prerequisite: Modules 01 and 02. You need NS and SOA records, the aa flag, NXDOMAIN vs NODATA, and how to read a dig header.
</aside>
<aside> 📓
The analogy. Think of the one phone number written inside the cover of your notebook. You cannot look up the phone book's number in the phone book — so one number gets printed on the cover.
You call it once, and the first thing you ask for is the current, correct list. The printed number only has to be good enough to make that first call, which is why it can be years out of date and everything still works.
</aside>
<aside> 📖
Official docs: RFC 1034 §5.3.3 — the resolver algorithm · IANA Root Servers · BIND 9 — Name Server Operations
</aside>
A resolver starting from nothing has a bootstrapping problem: to look anything up it must ask a server, but to find a server it must look something up.
The problem is solved by not solving it — the answer is shipped in the software. Every recursive resolver ships a small file, conventionally called named.root or root hints, containing the names and IP addresses of the 13 root server identities. That file is the only DNS data a resolver is given; everything else it learns.
<aside> 🔑
Why they are called "hints" and not "configuration". The file is not treated as authoritative. On start-up the resolver uses it to contact any one root server, then asks that server for the current root NS set and caches the real answer. The file only has to be good enough to get one packet through. That is why it can be years out of date and everything still works — a design decision that has quietly saved the internet from a great deal of pain.
</aside>
🧪 Exercise A1.1 — Fetch the root zone's own view of itself
dig . NS +noall +answer | head -4
dig +short a.root-servers.net A
dig +short a.root-servers.net AAAA
<aside> 🏬
The analogy. Think of "not my department — try the third floor". Nothing went wrong. Nobody was unhelpful. You did not get your answer, but you got one step closer, and that is a successful outcome.
The trick is telling that apart from "this is my department, and we have nothing for you" — which sounds similar and means something completely different.
</aside>
<aside> 📖
Official docs: RFC 1034 §4.3.2 — the algorithm, including referrals · RFC 9499 — definitions of referral and delegation
</aside>
In Module 01 C4.1 you queried a root server and got this, and I promised to explain it later:
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 27