Visual walkthrough — DNS — recursive vs iterative query, hierarchy, record types (A, AAAA, CNAME, MX, NS)

---

Step 0 — The one thing a computer cannot do

Nothing above is assumed anywhere later. Every symbol on this page traces back to these five words.

---

Step 1 — The players, laid out on a map

Look at the picture: your laptop (violet) sits far left. The recursive resolver (magenta) is the only one your laptop talks to. The three tiers (orange) stack on the right — root at top, then TLD .com, then the authoritative server for example.com. Not one arrow has been drawn yet; we're just naming the board.

---

Step 2 — The first arrow: the recursive ask

The single magenta arrow flies from laptop to resolver, labelled recursive. Notice the resolver has a little notepad drawn on it — that's the cache, empty for now. We will fill it in Step 7.

The message carries one field that matters:

$\underset{\text{the name we want}}{\underbrace{\text{QNAME}}}=\text{www.example.com},\underset{\text{what kind of record}}{\underbrace{\text{QTYPE}}}=\text{A}$

• QNAME — the name being asked about, the star of our quest.
• QTYPE = A — we specifically want the IPv4 mapping (the A record). If we'd wanted IPv6 we'd write AAAA.

---

Step 3 — The resolver knocks on the root

The orange arrow up is the question; the violet arrow down is the reply. Root reads the name right-to-left, sees the rightmost meaningful part is com, and answers with an NS referral:

$\text{Root replies: }\underset{\text{the zone it knows}}{\underbrace{\text{com.}}}\text{NS}\underset{\text{who is authoritative for it}}{\underbrace{\text{a.gtld-servers.net}}}$

• com. — the zone being delegated (the whole .com branch).
• NS — the record type meaning "the authoritative name server for this zone is…". NS records are the glue that links one tier of the tree to the next.
• a.gtld-servers.net — the name of the TLD server to visit next.

Root did not know example.com's IP — and that is correct. Root only knows the next level down.

---

Step 4 — The resolver knocks on the .com TLD

Reading www.example.com one level deeper, the TLD sees example under com and returns another NS referral:

$\text{TLD replies: }\underset{\text{the zone}}{\underbrace{\text{example.com.}}}\text{NS}\underset{\text{its authoritative server}}{\underbrace{\text{ns1.example.com}}}$

• example.com. — now the delegated zone is one step more specific.
• ns1.example.com — the authoritative name server, the machine that actually stores the answer.

We have descended the tree exactly one level per hop: . → com → example.com. That descent is the entire structure of DNS in motion.

---

Step 5 — The authoritative server: the final word

The violet reply arrow now carries an actual A record:

$\underset{\text{name}}{\underbrace{\text{www.example.com}}}\underset{\text{type: IPv4}}{\underbrace{\text{A}}}\underset{\text{value}}{\underbrace{\text{93.184.216.34}}}\underset{\text{cache for 300 s}}{\underbrace{\text{TTL}=300}}$

• A — the record type meaning name → IPv4 address. This is the basic forward lookup, the thing we've been chasing since Step 0.
• 93.184.216.34 — the value: the number packets route to.
• TTL = 300 — this answer may be remembered for 300 seconds. Remember this number for Step 7.

The quest is answered. But two more steps make it scale.

---

Step 6 — Edge case: the name is a CNAME, not an A

The picture shows the fork: asked for ftp, the server hands back a CNAME (magenta), and a loop-back arrow sends the resolver to re-ask for www, which finally yields the A record (orange).

---

Step 7 — Why the second lookup is nearly free (caching)

The bar chart contrasts the tall uncached bar ($4t$) with the tiny cached average ($0.4t$). The notepad on the resolver, empty back in Step 2, now holds the mapping with a ticking TTL countdown.

---

The one-picture summary

One diagram, the whole journey: the single recursive arrow (laptop → resolver, magenta), then three iterative hops down the tree (resolver → root → TLD → authoritative, orange), the answer returning, and the resolver's cache short-circuiting all future asks (dashed violet). This is the very first thing that happens before any web page loads; the same tree is walked to find mail servers via MX records and to reach a nearby edge in CDN and Load Balancing.

Recall Feynman retelling — explain the whole walk to a 12-year-old

You want a friend's phone number but only know their name. You ask the school office once and say "just get it, I'll wait" — that's the recursive ask; you never run around yourself. The office doesn't know it, so the office asks the city directory: "which neighbourhood?" → it points. Then the office asks that neighbourhood manager: "which house?" → it points. Then the office asks the house's front desk, which finally reads out the number — that's the authoritative answer, the real thing. If the name turned out to be a nickname (a CNAME), the office starts over for the real name. Every "which… ?" answer was just a pointer, never the number — that's why the big directories never get tired. Finally the office scribbles the number on a sticky note (the cache) with an expiry time (TTL), so the next kid who asks gets it in one second. You did the least work; the office did the running; the big servers only pointed. That is DNS.

Recall Self-test (cover the answers)

• How many arrows leave your laptop for one lookup? → One (recursive).
• Does the root know www.example.com's IP? → No, only the .com TLD's location.
• What record type gives IPv4? → A.
• What restarts the whole walk mid-way? → hitting a CNAME.
• With $p=0.9,H=4$, average cost as a multiple of $t$? → $0.4t$.