The DNS deep dive.
Beyond the surface explanation. Six animated chapters covering the DNS namespace, recursive versus iterative resolution, cache layers with their TTLs, glue records, NXDOMAIN caching, and what `dig +trace` actually shows you.
DNS deep dive animated tutorial. Covers recursive vs iterative resolution, root and TLD servers, authoritative nameservers, cache layers, TTLs, glue records, NXDOMAIN negative caching, and dig +trace.The DNS surface is "name to IP". The deep version is a hierarchical tree, cache layers everywhere, TTLs that decide what stales when, and a debug tool that bypasses your cache to show the truth.
- ·Comfortable with the URL flow lesson (have seen DNS once)
- ·Know roughly what an IP address is
- ·Helpful: you've run `dig` or `nslookup` at the terminal
Name the four roles in the chain (client, recursive, root/TLD, authoritative), explain TTLs, identify when glue records matter, and read `dig +trace`.
pace: 12 minutes
The DNS namespace is a tree
DNS isn't one giant database — it's a hierarchical tree. The root is at the top ("."), then top-level domains like .com / .net / .org, then second-level domains like example.com, then any subdomains. Each level is run by different organizations that delegate down. Reading a hostname right to left is reading the tree top to bottom.
DNS feels mysterious because every observer sees a different answer — your browser's cache, your OS's resolver, your ISP's recursive, the authoritative server. They're probably all right; they're just synced at different points in TTL time. When in doubt: ask the authoritative server directly (dig +trace finds it for you).
$dig example.com$dig example.com @1.1.1.1$dig example.com +short$dig example.com A AAAA MX TXT$dig +trace example.com$dig +noall +answer example.com$dig -x 1.1.1.1$dig SOA example.com$dig NS example.com$nslookup example.com$host example.com$getent hosts example.com$systemd-resolve --flush-caches$resolvectl statistics$/etc/resolv.conf$/etc/nsswitch.confWho does the actual iterative work when you type a URL?
You change your website's IP on Friday and want users to see the new address fast. What should you do BEFORE the change?
Why are GLUE records needed for example.com when its nameservers are ns1.example.com and ns2.example.com?
`dig example.com` returns the old IP, but `dig +trace example.com` returns the new IP. What's most likely going on?
These aren't graded — they're just for active recall, which is what actually makes the lesson stick.
DNS lookup, in your browser
Resolve any hostname against a public resolver and see the record types, TTLs, and answer chain — the same things `dig` would show you locally.
Read this lesson as text6 chapters · quiz answers
01The DNS namespace is a tree
DNS isn't one giant database — it's a hierarchical tree. The root is at the top ("."), then top-level domains like .com / .net / .org, then second-level domains like example.com, then any subdomains. Each level is run by different organizations that delegate down. Reading a hostname right to left is reading the tree top to bottom.
02Recursive vs iterative — who does the work
Your laptop asks ONE question: 'what's the IP for example.com?' That goes to your RECURSIVE resolver (e.g. 1.1.1.1, 8.8.8.8, your ISP's). The resolver does all the ITERATIVE work — asking root, then the TLD nameservers, then the authoritative nameserver — and returns the final answer. Your laptop never talks to the root directly.
03Cache layers — everyone remembers
Every step in the chain caches answers. Your browser caches for seconds. The OS (systemd-resolved or nscd) caches a bit longer. The recursive resolver caches for the TTL the authoritative server published. That's why a fresh nslookup is fast — the resolver served it from cache without asking anyone. The first lookup after a TTL expires is the slow one.
04TTLs and negative caching
Every DNS record carries a TTL (Time To Live) in seconds. Cache it for that long, then re-ask. Common defaults: 300 (5 min) to 86400 (1 day). NEGATIVE answers — 'no such record' (NXDOMAIN) — also get cached, controlled by the SOA's minimum TTL field. Lower the TTL before a planned IP change so the cutover is fast; bump it back up afterwards to reduce query load.
05Glue records — chicken-and-egg fix
Suppose example.com's NS records say 'go ask ns1.example.com'. To ASK ns1.example.com, you need its IP. To get its IP, you'd query DNS for ns1.example.com — but the answer is on ns1.example.com itself. Deadlock. The fix: the parent (.com TLD) serves an extra A record for ns1.example.com alongside the NS delegation. That's a GLUE record. It only matters when the nameserver is INSIDE the domain it serves.
06dig +trace — simulate iterative resolution
dig +tracemakes YOUR machine do the iterative walk that a resolver normally does. It queries root, follows the NS responses to the TLD, follows the next NS responses to the authoritative server, and finally asks for the record. You see every hop and its TTL. Great for debugging — if dig +trace gets a different answer thandig, your local resolver is serving stale cache.
Quiz — answers
- Who does the actual iterative work when you type a URL?
- →The recursive resolver (e.g. 1.1.1.1, 8.8.8.8, your ISP's) — it does the walk and returns one answer to your laptop.Your laptop sends ONE recursive query to your configured resolver. The resolver does the iterative walk (root → TLD → authoritative) on your behalf and returns the final answer. Root servers explicitly don't recurse for you.
- You change your website's IP on Friday and want users to see the new address fast. What should you do BEFORE the change?
- →Lower the TTL on the A record (e.g. from 1 day to 60 seconds) at least 1 day in advance.Caches hold the OLD record for up to the old TTL. Lower the TTL well before the change so by the time you cut over, most caches are checking back every 60 seconds. Raise the TTL again after — large TTLs are good for resolver load and user latency.
- Why are GLUE records needed for example.com when its nameservers are ns1.example.com and ns2.example.com?
- →They prevent a chicken-and-egg lookup — you'd need ns1.example.com's IP to query example.com, but that IP is only served by ns1.example.com itself.When the nameserver is inside the domain it serves, the parent zone has to publish an A record (the glue) alongside the NS delegation. If the nameservers are outside the domain (e.g. ns1.cloudflare.com), no glue is needed.
dig example.comreturns the old IP, butdig +trace example.comreturns the new IP. What's most likely going on?- →Your local recursive resolver is serving stale cache; +trace bypasses it by walking the hierarchy from root.+trace queries root and walks down the hierarchy itself, bypassing your normal resolver. If the answers disagree, the difference is whatever your resolver still has cached. Wait for the TTL to expire, flush the resolver, or use a different one.
keep going — these pair well with what you just learned.
What happens when you type a URL?
The most-asked interview question, animated. Five chapters: DNS → TCP → TLS → HTTP → Render. Step through each at your own pace.
OSI / TCP-IP layers
A packet wrapped layer-by-layer, then unwrapped on the other side. Watch headers stack and peel off — OSI 7 and TCP/IP 4 side by side.
NAT and routing
How packets cross networks. Source NAT, destination NAT, conntrack, routing tables — visualized with real IPs.