Recursive from the user's side, iterative going outward
In Chapter 2 we saw how delegation splits responsibility between parent and child zones. In this chapter we follow the flow of queries — how that hierarchy is actually walked to reach the final answer.
Browsers and apps do not typically query root servers directly. What the user sees is the recursive resolver, and they ask it: "please return the final answer."
Meanwhile, when the recursive resolver goes out, it typically walks root → TLD → authoritative servers iteratively (step by step, one referral at a time). Once you separate these two layers, the words recursive (asking one party for the whole answer) and iterative (asking each level in turn) fall into place more easily.
0 / 6 correct. Correctness is stored only in this browser's localStorage.
Practice 3-1 — Walk the full-miss path by hand
First, confirm the basic path for a cache miss.
Q11. When the recursive resolver's cache is empty, which is closest to the typical flow for resolving www.example.com A?
Show hint
The root first tells you where to go for the TLD; the TLD tells you the authoritative servers beyond it.
Q12. Suppose the recursive resolver already has valid cached entries for the NS of .com and the NS of example.com, but not for www.example.com A itself. How many additional outbound queries are needed to obtain this final A record?
Show hint
You already know where to go, so you only need to ask the place that holds the authoritative data.
Follow it with the simulator
The simulator below walks through an example of looking up www.example.com A. Toggling cache hits shows that outbound queries drop drastically in one stroke. In the practice questions, we count that difference as numbers.
Simulator behavior in plain text: On a full miss with empty caches, the recursive resolver first asks a root server and receives a referral to the .com NS. Next it asks the .com TLD server and gets a referral to the example.com NS. Finally it asks the example.com authoritative server and receives the final RRset for www.example.com A. That is 3 outbound queries in total. By contrast, when the recursive resolver already holds a valid cached copy of that RRset, it can answer with 0 outbound queries. When only some of the intermediate caches (root / TLD / parent NS) are present, the number drops by exactly that much.
Practice 3-2 — How many queries disappear with the cache
When many users share the same resolver, the gap between the first lookup and subsequent ones becomes enormous.
Q13. When the recursive resolver still has a valid cached entry, what happens with outbound queries to root / TLD / authoritative servers for the same name and type?
Show hint
Recall the cache-hit case from the simulator.
Q16. 20 users share the same recursive resolver. Only the first lookup is a full miss, and the remaining 19 lookups for the same www.example.com A happen inside the TTL. What is the total number of outbound queries to root / TLD / authoritative servers?
Show hint
Only the first lookup walks root → TLD → authoritative server; after that the cache takes over.
Distinguish referral from authoritative answer
root and TLD servers usually do not return the final A / AAAA. Instead they return a referral: "for that, please go to this NS group." An authoritative server, by contrast, returns the authoritative data of the zone it is responsible for as an authoritative answer.
| Response kind | Meaning | How it looks |
|---|---|---|
| referral | I do not hold the final answer, but I know where to go next | NS or glue appears in AUTHORITY / ADDITIONAL |
| authoritative answer | Returns the authoritative data of the zone it is responsible for | The final RRset appears in ANSWER |
| cached answer | Reuses previously obtained data while its TTL lasts | Looks like the final answer from the user's side, but is not necessarily straight from the authoritative server |
You also need to distinguish NXDOMAIN (the name does not exist) from a NODATA-equivalent state (the name exists but only certain types are missing).
Practice 3-3 — Tell referral, NXDOMAIN, and NODATA apart
In troubleshooting, just separating "does the name not exist, or does the type not exist" already moves you forward.
Q14. Which is the most appropriate description of what root and TLD servers tend to return?
Show hint
It is the response "I do not hold the final answer, but I know where to go next."
Q15. Suppose the name mail.example.com itself exists and has only MX, with no A record. What is the closest description of the result of looking up mail.example.com A?
Show hint
"The name does not exist" is different from "data of that type does not exist."
Key takeaways from this chapter
- The user asks the recursive resolver for the final answer
- The recursive resolver walks root → TLD → authoritative servers iteratively
- On a cache hit, that long walk is skipped entirely