Recursive Resolution

A recursive resolver (your ISP's DNS, 8.8.8.8, 1.1.1.1, your browser's DNS) walks the DNS tree on your behalf.

For www.example.com A:

1. Ask a root server (a.root-servers.net through m.root-servers.net): "what NS handles .com?"
2. Root replies with NS records: a.gtld-servers.net, b.gtld-servers.net, etc.
3. Ask one of those: "what NS handles example.com?"
4. They reply: ns1.example.com, ns2.example.com.
5. Ask ns1.example.com: "what's the A for www.example.com?"
6. They reply with the A record.

This is iterative from the resolver's perspective; it's "recursive" because the client asked for full resolution.

Each step the resolver might also receive glue records — A records for the NS servers themselves (so you don't have to do a separate lookup).

Caching is critical: a recursive resolver caches root NS forever (well, for the TTL — typically days), TLD NS for hours, then per-domain NS for whatever the SOA's minimum TTL says.

Real-world resolvers (BIND, Unbound, dnsmasq, systemd-resolved) implement this recursion. Public ones (Google, Cloudflare, Quad9) serve from caches with smart fallbacks for cache misses.

For this lesson: simulate the iterative walk.