SubnetLayerProtocols

How a Name Becomes an Address

Nobody holds the whole directory — and that is the design

Step 1 of 2 — understand the idea. Read this first and the packet trace will confirm what you already expect, instead of teaching you two things at once.

What you'll be able to do

Before this lesson — it builds directly on:
The obvious way to map names to addresses is one big list everyone can consult. That is genuinely how it worked at first — a single file, copied around by hand. It stopped working for two reasons. It got too large to distribute, and every change had to go through one authority, so nobody could rename their own machine without asking permission. DNS fixes both by splitting the list up. Whoever owns a domain holds its records and changes them without consulting anyone. Nobody holds the whole thing, and nobody needs to.
Finding someone in a very large organisation without a central directory. You ask the front desk, who do not know but say "that will be the Bristol office". Bristol do not know either, but say "third floor". The third floor knows exactly. Nobody in that chain held the answer — each one held only the next question.
the front desk
→ a root server
"that will be Bristol"
→ a referral to the TLD servers
the third floor, who actually know
→ the authoritative server for the domain
you, doing the asking each time
→ the recursive resolver — not your own machine
remembering the answer for next time
→ the cache, for as long as the TTL says

Where it breaks down: A receptionist who is out of date sends you to the wrong floor and you find out immediately, because nobody is there. A stale DNS cache sends you to an address where something is still listening, and everything appears to work until it does not — which is why cached records cause failures that look nothing like DNS.

✗ Common misunderstanding: There is a DNS server somewhere that knows every domain name.

Why that's wrong: No server holds more than its own slice. Root servers know only which servers run each top-level domain; those know only the next level down. The complete picture exists nowhere.

Correct model: DNS is a tree of delegations. A lookup walks down it, and each server contributes only the one fact it owns: who to ask next.

The packets prove it: In the recursive-lookup trace the root and TLD both return responses with ZERO answer records — they had nothing to give but a referral.

Watch these fields in the lab: dns.answerCount

Stub resolver
The tiny piece inside your own machine. It asks one question and expects a final answer — it does no chasing itself.
Recursive resolverglossary
The server your machine asks. It does the walking: root, then TLD, then authoritative, following referrals until it has a real answer. Then it caches it.
Authoritative serverglossary
Holds the actual records for a zone. Its answers carry the Authoritative Answer flag, which is how you know you have reached the source rather than a copy.
Referral
A response with no answer that names a better server to ask. Not a failure — it is how delegation works.
Glue
The address of the nameserver a referral just named, included so the resolver need not resolve a name in order to resolve a name.
TTLglossary
How long an answer may be cached, chosen by whoever owns the record. It is why a DNS change takes time to be seen everywhere.

Watch these fields in the lab: dns.flags · dns.authorityCount

✓ Concept check — before you open the packets

These test the idea, not the trace. You should be able to answer them from the explanation above.

Why can no single server hold the whole namespace?

A resolver caches an answer with a 300-second TTL. What does that number actually control?

Now that you understand the concept, observe how it appears in the packet exchange.

The lab runs a real simulated capture — pause, step, click any packet, and inspect every byte.