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

---

The scenario matrix

Before solving anything, let us list every distinct case class this topic can produce. Each worked example below is tagged with the cell it fills.

Cell	Case class	What makes it different	Example
C1	Full cache-miss (cold cache)	Every hop must happen: root → TLD → auth	Ex 1
C2	Cache-hit (warm cache)	Zero hops — the limiting "best case"	Ex 2
C3	Partial cache (mixed)	Some levels cached, some not — the realistic middle	Ex 3
C4	Alias resolution (CNAME chain)	Answer is a name, not an IP → extra lookups	Ex 4
C5	Mail routing, MX tie + fallback	Equal priorities, and lowest-first ordering	Ex 5
C6	IPv4 vs IPv6 (A vs AAAA), both degenerates	Same name, two record types; "no AAAA" and "only AAAA"	Ex 6
C7	Degenerate/illegal config (apex CNAME, missing glue)	Config that cannot work — recognise & fix	Ex 7
C8	Limiting behaviour of caching (cost model $p\to 0,p\to 1$)	Boundary values of the scaling formula	Ex 8
C9	Real-world word problem (latency budget)	Turn a story into hop-counting + numbers	Ex 9
C10	Exam twist (TTL expiry / stale record timing)	Reasoning about when a cache entry dies	Ex 10

Every row is covered below. Let us go.

---

Example 1 — Full cache-miss (Cell C1)

Forecast: guess the number of hops before reading on. Root? TLD? Authoritative? How many round trips total?

1. Laptop → resolver (recursive). Why this step? Your laptop is a "stub" — it can only ask one recursive question and wait. This is 1 round trip that wraps everything below it; it does not add to the resolver's internal iterative hop count.
2. Resolver → root (iterative). Why this step? The empty cache means the resolver knows nothing, so it starts at the top. Root replies "ask the .com TLD." → 1 iterative hop.
3. Resolver → TLD .com (iterative). Why this step? The referral pointed here. TLD replies "ask ns1.example.com." → 2nd iterative hop.
4. Resolver → authoritative (iterative). Why this step? The authoritative server actually stores the record. It replies "A = 93.184.216.34." → 3rd iterative hop.
5. Count the time. Let $H_{\text{iter}}=3$ be the resolver's iterative hops (root, TLD, auth), and add the 1 stub round trip. Time $=3\times 30+30=120\text{ ms}$ (3 chase hops + 1 laptop hop).

Verify: count arrows in the figure — root, TLD, auth = 3 iterative arrows, plus the recursive arrow to/from the laptop. $H_{\text{iter}}=3$, total time $=(3+1)\times 30=120\text{ ms}$. Units: ms per hop × hops = ms. ✓

---

Example 2 — Cache-hit, the best case (Cell C2)

Forecast: how many of root/TLD/auth do we contact this time?

1. Laptop → resolver (recursive). Why this step? Same stub behaviour — one recursive question. This stub round trip never disappears: even a perfect cache still needs your laptop to ask the resolver and hear back.
2. Resolver checks cache first. Why this step? The whole point of caching: before touching the network, look locally. The entry www.example.com → 93.184.216.34 is present and TTL > 0.
3. Resolver answers immediately. Why this step? No referral chasing needed → 0 iterative hops. Latency = just the one laptop↔resolver round trip $=30\text{ ms}$.

Verify: iterative hops = 0 (all three servers skipped), but the stub hop remains. Latency = $30\text{ ms}$ vs $120\text{ ms}$ uncached — a $4\times$ speedup, matching $H_{\text{iter}}+1=4$ round trips collapsing to $1$. ✓ See Caching and TTL.

---

Example 3 — Partial cache, the realistic middle (Cell C3)

Forecast: which levels get skipped — root, TLD, both?

1. Resolver checks cache. Why this step? Cache stores referrals too, not just final answers. It finds ".com → gtld server" and "example.com → ns1". Root and TLD are already known.
2. Skip root and TLD. Why this step? Because those referrals are cached and unexpired, there is no reason to re-ask them. This is the key insight: caching helps even for names never seen before, as long as their ancestors were seen.
3. Resolver → authoritative only (iterative). Why this step? Only the leaf record blog.example.com is missing. One hop fetches it. → 1 iterative hop.
4. Time $=1\times 30+30=60\text{ ms}$ (1 chase hop + 1 laptop hop).

Verify: iterative hops = 1 (vs 3 cold). Time $=(1+1)\times 30=60\text{ ms}$, sitting neatly between the $120\text{ ms}$ cold case and the $30\text{ ms}$ hit case. ✓

---

Example 4 — Alias resolution / CNAME chain (Cell C4)

Forecast: does one query return the IP, or does the CNAME force a second lookup? How long in total?

1. Resolver → auth: "A record for ftp.example.com?" Why this step? The client wants an IPv4 address, so it asks for type A. Because the authoritative NS is already cached, this is the 1st iterative hop (root and TLD are skipped).
2. Auth returns a CNAME, not an A. Why this step? ftp has no A record — it is an alias. The server answers "ftp is really www.example.com," which is a name, not the number the client needs.
3. Resolver re-asks: "A record for www.example.com?" Why this step? An IP is still not in hand. The alias must be followed to reach a real A record. This is the 2nd iterative hop and it yields 93.184.216.34. (Well-behaved authoritative servers often bundle the target's A in the same reply to save this hop — but logically it is a second lookup, and we count it as such.)
4. Resolver returns 93.184.216.34 to the client, and total the time. Why this step? The client only ever cared about the final IP; the CNAME indirection is invisible to it. Counting hops: 2 iterative (the two authoritative queries) + 1 stub round trip $=(2+1)\times 30=90\text{ ms}$.

Verify: the CNAME target www.example.com resolves to A = 93.184.216.34, so ftp and www share the same IP. Hops = 2 iterative + 1 stub, latency $=(2+1)\times 30=90\text{ ms}$. Changing www's A record would automatically move ftp too — the whole point of an alias. ✓

---

Example 5 — MX priority: tie + fallback (Cell C5)

Forecast: which server first — and what does the tie at 10 mean?

1. Sort by MX priority number, ascending. Why this step? Lower number = preferred (counter-intuitive but by definition — think "rank #1"). So priority 10 servers come before 20. See SMTP and Email Delivery.
2. Break the tie at priority 10 by random/round-robin. Why this step? Two equal-priority MX records are meant to share load; the sender picks either mail1 or mail2 at random. This distributes mail across both.
3. Fall back to backup (20) only if both 10s fail. Why this step? Priority 20 is the last resort — a lower-preference server used solely when every higher-preference one is unreachable.

Verify: ordering is $\{\text{mail1},\text{mail2}\}$ (any order, priority 10) then backup (priority 20). Minimum priority value $\min (10,10,20)=10\Rightarrow$ a tie between the two mail hosts. Backup is strictly last. ✓

---

Example 6 — A vs AAAA: both degenerate cases (Cell C6)

Forecast: does the IPv6 client always get an IPv6 address? Can an IPv4-only client reach v6 at all?

1. For dual, an IPv6-preferring client asks AAAA first. Why this step? Modern clients try IPv6 when available. AAAA returns 2001:db8::7 → connect over IPv6. If that failed, it would "Happy-Eyeballs" fall back to the A record 198.51.100.7.
2. For old (no AAAA), the client asks AAAA and gets an empty answer. Why this step? This is the degenerate "no IPv6" case. An empty AAAA response is not an error; it just means "no record of this type." The client falls back to the A record 198.51.100.8 — even an IPv6 client uses IPv4 here.
3. For v6 (only AAAA), the IPv6 client asks AAAA and succeeds. Why this step? This is the symmetric "only IPv6" case. AAAA returns 2001:db8::9 and there is no A to fall back to — nor is one needed.
4. A legacy IPv4-only client asking v6 gets nothing usable. Why this step? It queries A, receives an empty answer, and has no IPv6 stack to use the AAAA. It cannot reach v6 at all — the edge case that motivates dual-stacking public services.

Verify: dual → 2 address families (AAAA preferred, A backup). old → AAAA empty, A 198.51.100.8 used (1 family). v6 → AAAA 2001:db8::9, no A (1 family); an IPv4-only client sees 0 usable addresses. ✓ See IP Addressing — IPv4 vs IPv6.

---

Example 7 — Degenerate / illegal config (Cell C7)

Forecast: which lines cannot legally coexist, and why?

1. Line 1 — apex CNAME is illegal. Why this step? The zone apex example.com. must carry SOA and NS records. A CNAME says "I am nothing but an alias — ignore all my other records," which directly contradicts the required SOA/NS. Fix: use an A/AAAA record (or a provider's ALIAS/ANAME) at the apex instead.
2. Line 2+3 — NS and A on the same name is a delegation clash. Why this step? An NS record on www.example.com delegates that subtree to another server — meaning "I no longer answer for www." But line 3 tries to answer for www with an A record locally. You cannot both delegate away and keep answering. Fix: drop the NS if www is a normal host (keep the A), or drop the local A if you truly delegate.
3. State the general rule. Why this step? CNAME cannot coexist with any other record type; NS-delegation and locally-served records for the same name are mutually exclusive. Both broken lines violate "one authority per name/type."

Verify: apex CNAME conflicts with mandatory apex SOA/NS ⇒ illegal (matches the parent note's mistake #3). NS + A on identical name ⇒ ambiguous authority ⇒ illegal. Two problems found. ✓

---

Example 8 — Limiting behaviour of the cache cost model (Cell C8)

Forecast: which limit is "the internet melts" and which is "instant"? And does $p\to 1$ really give 0 ms?

1. Fix what the symbols mean here. Why this step? The parent's $H=4$ secretly included the stub hop. If a reader jumps straight to this page, that hidden convention would confuse the algebra. So on this page $H_{\text{iter}}=3$ is purely the chase hops and the stub $t$ stands alone — which is exactly why our formula carries a standalone $+t$.
2. Limit $p\to 0$ (nothing cached). Why this step? Worst case — every query is a full miss. Total $\to 30+(1-0)\cdot 3\cdot 30=30+90=120\text{ ms}$. This is the cold-cache Ex 1 number: the model's upper bound.
3. Limit $p\to 1$ (everything cached). Why this step? Best case — the chase term vanishes, but the stub hop stays. Total $\to 30+(1-1)\cdot 3\cdot 30=30+0=30\text{ ms}$. This matches Ex 2 exactly — not 0 ms, because your laptop must always ask the resolver and wait.
4. Realistic $p=0.9$. Why this step? Real resolvers hit ~90%. Total $=30+(1-0.9)\cdot 3\cdot 30=30+0.1\cdot 90=30+9=39\text{ ms}$ average. The chase portion collapsed from $90$ ms down to $9$ ms — a 10× cut in network work — while the fixed stub keeps the floor at $30$ ms. This is why DNS scales: most of the expensive tree-walking is served from cache, leaving only the unavoidable stub round trip.

Verify: $p=0\Rightarrow 120$, $p=1\Rightarrow 30$ (floor = stub hop, consistent with Ex 2), $p=0.9\Rightarrow 39$. The total is linear in $p$ with slope $-H_{\text{iter}}t=-90$, endpoints $120$ and $30$. ✓

---

Example 9 — Real-world latency word problem (Cell C9)

Forecast: is DNS a big or small slice of the wait?

1. DNS time = (3 chase + 1 stub) × 40. Why this step? Same hop accounting as Ex 1, just at $40\text{ ms}$: $(3+1)\times 40=160\text{ ms}$.
2. Add the HTTP fetch. Why this step? Only after the IP is known can the browser open the connection and request the page. Total $=160+200=360\text{ ms}$. See HTTP and the Web request lifecycle.
3. DNS fraction. Why this step? To judge whether caching/CDN is worth it: $160/360\approx 0.444$, i.e. ~44% of the wait is DNS on a cold cache.
4. On the second visit (cache hit), DNS drops to the stub floor of 40 ms. Why this step? This shows the payoff and is consistent with Ex 8's floor: the chase term disappears but the one stub round trip remains. Total becomes $40+200=240\text{ ms}$ — a $120\text{ ms}$ saving purely from caching. A CDN/anycast resolver would shrink the miss path further.

Verify: cold total $=160+200=360\text{ ms}$; DNS fraction $=160/360=0.4\overline{4}$; warm total $=40+200=240\text{ ms}$; saving $=360-240=120\text{ ms}$. ✓

---

Example 10 — Exam twist: TTL expiry timing (Cell C10)

Forecast: does the $t=200\text{ s}$ query see the new IP?

1. Cache is valid until $t=0+300=300\text{ s}$. Why this step? TTL is the record's lifetime in cache from the moment it was stored. Until it expires, the resolver serves the cached value without re-asking.
2. Query at $t=200\text{ s}$ → OLD IP. Why this step? $200<300$, so the entry is still fresh. The admin's change at $t=120$ is invisible — the resolver never re-checked. This is why DNS changes "take time to propagate."
3. At $t=300\text{ s}$ the entry expires. Why this step? Now the next query forces a fresh authoritative lookup.
4. Query at $t=350\text{ s}$ → NEW IP. Why this step? $350>300$, cache expired, resolver re-fetches from authoritative → sees the updated record. See Caching and TTL.

Verify: expiry at $t=300$. Query at $200$: $200<300\Rightarrow$ old IP. Query at $350$: $350>300\Rightarrow$ new IP. The window of staleness after the change is $300-120=180\text{ s}$. ✓

---

Active Recall

Recall Cover the answers

Cold-cache lookup with 3 iterative levels + stub round trip at 30 ms each — total? ::: $(3+1)\times 30=120$ ms. Same name one second later (cache hit) — iterative hops and time? ::: 0 iterative hops, 30 ms (the stub floor). New name in a domain whose TLD+auth are cached — iterative hops? ::: 1 (authoritative only). CNAME lookup with auth cached, 30 ms/hop — total latency? ::: 90 ms ((2 iterative + 1 stub) × 30). Two MX records both at priority 10 — what happens? ::: Load-shared randomly; both tried before any priority 20. A host with only an AAAA record — can an IPv4-only client reach it? ::: No — it queries A, gets empty, has no IPv6 stack. Why does a query at $t=200$ s (TTL 300 s, changed at 120 s) return the OLD IP? ::: Cache still fresh (200 < 300); the change hasn't propagated. Cache total-cost model at $p=0.9$, $H_{\text{iter}}=3$, $t=30$ ms — average? ::: $30+(1-0.9)\times 3\times 30=39$ ms.

Recall Feynman: the coffee-shop story (Ex 9)

First time you open a site on café Wi-Fi, ~44% of your wait is just finding the server (DNS), not downloading the page. The second time, the resolver remembers, and finding it costs almost nothing — the wait drops from 360 ms to 240 ms. Caching literally cuts your page load, and that is why big sites obsess over it.

---

Flashcards