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

Two words you must have in hand before line one:

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

For each mapping, name the single record type that stores it: (a) blog.site.com → 203.0.113.7 (b) blog.site.com → 2606:4700::6810:85e5 (c) shop.site.com → the name www.site.com (d) site.com → mail server mail.site.com with preference 10 (e) site.com → its authoritative server ns1.site.com

Recall Solution 1.1

(a) A — a name to an IPv4 address (32-bit, dotted decimal). See IP Addressing — IPv4 vs IPv6. (b) AAAA — a name to an IPv6 address (128-bit, the colon-hex form). "Quad-A" = four times the 32 bits of an A record. (c) CNAME — an alias: a name pointing at another name, not an address. (d) MX — a domain to a mail exchanger, carrying a preference number. (e) NS — the delegation record naming the zone's authoritative server.

Problem 1.2

True or false, with one-line reasons: (a) A root server stores the A record for example.com. (b) Your laptop sends an iterative query to the root server. (c) An MX value of 10 is preferred over 20.

Recall Solution 1.2

(a) False. A root server knows only where TLD servers live (.com, .org, …). It never stores an individual domain's address. (b) False. Your laptop never talks to the root at all. It sends one recursive query to its resolver; the resolver sends iterative queries to root/TLD/authoritative. (c) True. Lower preference number = tried first = preferred. Read the number as "rank," where #1 beats #2.

L2 — Application

Problem 2.1

Trace, step by step, a full uncached resolution of mail.shop.example.com. Label each arrow recursive or iterative and say what each server replies.

Recall Solution 2.1

Read the name right-to-left: root → com → example.com → shop.example.com → host mail. Follow the arrows in the figure above.

Laptop → resolver: recursive — "give me mail.shop.example.com, I'll wait."
Resolver → root: iterative. Root: "I don't have it. Ask the .com TLD server."
Resolver → .com TLD: iterative. TLD: "Ask example.com's authoritative server ns1.example.com."
Resolver → ns1.example.com: iterative. It may hold a further NS delegation for the sub-zone shop.example.com, replying "ask ns1.shop.example.com."
Resolver → ns1.shop.example.com: iterative. It returns the A record for mail.shop.example.com, e.g. 203.0.113.55.
Resolver caches the answer and returns it recursively to your laptop. Total: 1 recursive (laptop side) + 4 iterative (resolver side) hops.

Problem 2.2

A zone file contains:

example.com.        IN  NS      ns1.example.com.
example.com.        IN  MX  10  mail1.example.com.
example.com.        IN  MX  20  mail2.example.com.
www.example.com.    IN  A       93.184.216.34
web.example.com.    IN  CNAME   www.example.com.

(a) What IPv4 address does web.example.com resolve to, and how many record lookups does it take? (b) A mail server wants to deliver to example.com. Which host does it try first, and if that host is down, which next?

Recall Solution 2.2

(a) web is a CNAME to www. So resolving web first returns "the canonical name is www.example.com," then a second lookup on www returns its A record 93.184.216.34. That is 2 lookups: CNAME → then A. This indirection is why you edit www's IP once and every alias follows — see Caching and TTL for how each of those is cached separately. (b) Lowest MX preference first: mail1 (pref 10). If mail1 is unreachable, fall back to mail2 (pref 20). Lower number = higher preference. (See SMTP and Email Delivery for what the sender does after picking the host.)

L3 — Analysis

Problem 3.1 (caching cost model)

A resolver serves queries where a fraction $p$ hit its cache (near-zero cost) and $(1 - p)$ miss and need a full resolution of $H$ hops, each hop costing time $t$ . The expected cost per query is $Avg = (1 - p) H t .$ Given $H = 4$ and $t = 20 ms$ : (a) Compute the average cost for $p = 0$ , $p = 0.9$ , $p = 0.99$ . (b) By what factor does moving from $p = 0.9$ to $p = 0.99$ cut the average cost?

Recall Solution 3.1

First, why this formula? It is an expected value over exactly two outcomes — hit (cost ≈ 0) or miss (cost $H t$ ) — weighted by their probabilities $p$ and $1 - p$ . The hit term $p \cdot t_{c}$ vanishes because a cache hit is essentially free, leaving $(1 - p) H t$ . A full miss costs $H t = 4 \times 20 = 80 ms$ . (a)

$p = 0$ : $(1 - 0) \times 80 = 80 ms$ .
$p = 0.9$ : $(1 - 0.9) \times 80 = 0.1 \times 80 = 8 ms$ .
$p = 0.99$ : $(1 - 0.99) \times 80 = 0.01 \times 80 = 0.8 ms$ . (b) Factor $= \frac{8}{0.8} = 10 \times$ cheaper. Caching is the reason DNS survives billions of queries.

Problem 3.2 (a lookup breaks)

Users report www.example.com is "not found," yet the authoritative server clearly has the A record. Diagnosis reveals: the .com TLD lists the domain's NS as ns1.example.com, but there is no A/AAAA record telling anyone the IP of ns1.example.com itself. Explain the failure and name the fix.

Recall Solution 3.2

This is the classic missing glue record problem. To reach the authoritative server, the resolver must know the IP of ns1.example.com. But ns1.example.com lives inside the very zone example.com it is supposed to answer for — a chicken-and-egg loop: you need the server's address to ask the server for its own address. Fix: the parent (.com TLD) must publish a glue record — an A/AAAA for ns1.example.com stored at the TLD level, breaking the loop. Without glue, resolution circles forever and times out.

L4 — Synthesis

Problem 4.1 (design a zone)

Design the minimal correct set of records for startup.io so that:

The bare domain startup.io (the apex) serves the website at IPv4 198.51.100.10.
www.startup.io shows the same site.
Email for @startup.io goes to Google's servers (aspmx.l.google.com, preference 1).
The zone is served by ns1.startup.io and ns2.startup.io.

State each record and justify any place you cannot use a CNAME.

Recall Solution 4.1

startup.io.       IN  NS     ns1.startup.io.
startup.io.       IN  NS     ns2.startup.io.
startup.io.       IN  A      198.51.100.10
startup.io.       IN  MX  1  aspmx.l.google.com.
www.startup.io.   IN  CNAME  startup.io.

Why the apex uses A, not CNAME: the apex startup.io already carries NS (and an implicit SOA) records. A CNAME is not allowed to coexist with any other record at the same name — and the apex is forced to have NS/SOA — so a CNAME at the apex is illegal. We therefore point the apex straight at the IP with an A record. Why www can use CNAME: www.startup.io is an ordinary sub-name with no NS/SOA of its own, so a CNAME to the apex is fine, and it inherits the apex's IP automatically. Change 198.51.100.10 once and both names follow. (If a hosting provider gives you only a name for the apex target, you'd need their ALIAS/ANAME flattening feature — but with a fixed IP, plain A is cleanest.)

L5 — Mastery

Problem 5.1 (root under load — why iterative saves the world)

Suppose the entire internet sends $Q = 1 0^{12}$ (a trillion) DNS queries per day. Imagine two hypothetical worlds:

World A (root does recursion): every query's full chain is executed by the root server on the client's behalf, so each query lands $H = 4$ units of work on the root.
World B (reality, iterative + caching): the root is asked only on cache misses, fraction $(1 - p)$ of queries, and each such query costs the root just 1 referral unit (it points and stops). With $p = 0.99$ : (a) Root work per day in World A vs World B. (b) The ratio A : B. Explain in one sentence why the iterative + caching design keeps the root alive.

Recall Solution 5.1

World A: every query, full chain on the root: $Q \times H = 1 0^{12} \times 4 = 4 \times 1 0^{12}$ units/day. World B: only misses reach root, each costing 1 unit: $Q \times (1 - p) \times 1 = 1 0^{12} \times 0.01 = 1 0^{10}$ units/day. (a) $4 \times 1 0^{12}$ vs $1 0^{10}$ . (b) Ratio $= \frac{4 \times 1 0 ^{12}}{1 0 ^{10}} = 400$ . So the real design imposes 400× less work on the root. One-sentence why: iterative queries let the root do the minimum (one pointer, never the whole chain), and caching means the root is contacted only on the rare miss — two multiplicative savings stack into hundreds-fold relief, which (together with anycast replication, see Anycast Routing) is why 13 logical root names survive planet-scale traffic.

Problem 5.2 (end-to-end reasoning)

You type https://www.startup.io into a fresh browser (empty cache). List, in order, the DNS-relevant events until the browser can open a TCP connection, and mark where Caching and TTL, CDN and Load Balancing, and HTTP and the Web request lifecycle each enter.

Recall Solution 5.2

Browser stub resolver → OS cache: empty (fresh). Ask the recursive resolver — recursive query.
Resolver, also empty, runs the iterative chain: root → .io TLD → ns1.startup.io authoritative.
www.startup.io is a CNAME to the apex → resolver does a second resolution of startup.io → gets the A record 198.51.100.10.
If a CDN were in front, the authoritative answer might instead be a CNAME to a CDN hostname whose A record is chosen by geography/load — that's where CDN and Load Balancing and Anycast Routing enter.
Resolver caches every record for its TTL (Caching and TTL) and returns the final IP recursively to the browser.
Browser now has an IP → opens a TCP+TLS connection and issues the HTTP request — HTTP and the Web request lifecycle takes over from here.

Wrap-up Recall

Recall One-line answers (cover them)

How many lookups does a CNAME add? ::: One extra (redirect, then resolve the target).
Why is A used at the apex, not CNAME? ::: CNAME can't coexist with the apex's mandatory NS/SOA records.
What breaks if an in-zone name server has no glue record? ::: A chicken-and-egg loop; resolution can never reach the server.
Moving cache hit rate 0.9 → 0.99 cuts average cost by what factor (H=4, t=20ms)? ::: 10×.
Why does iterative + caching save the root ~400× at p=0.99? ::: Root does 1 pointer instead of a 4-hop chain, and only on the 1% of misses.

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

L1 — Recognition

Problem 1.1