Why is DNS hierarchical?

DNS could have been a giant flat lookup table — one machine somewhere mapping every name in the world to an IP. It isn't, and the reason is less about technology than about who gets to be in charge of what.

The picture version

The whole idea in seven pictures, for a reader who knows nothing about DNS. The prose below fills in the seams the pictures skip.

Why it exists

You register example.com for the price of a sandwich. Ten minutes later you have mail.example.com, api.example.com, and staging.example.com, and you invented all three yourself — no application form, no committee, nobody at ICANN even aware they exist. That’s odd if you think of DNS as a big global directory: how does the world’s directory let a stranger add rows without asking? It’s the delegation, and mail.example.com is the example this whole post follows.

In the early 1980s the entire internet’s name-to-address mapping lived in a single text file called HOSTS.TXT, maintained by the SRI-NIC and copied around by every host that wanted to know what mit-multics resolved to. This worked when “the internet” was a few hundred machines run by people who knew each other. It stopped working the moment it didn’t.

Three things broke at once:

1. Name collisions. Only one machine in the world could be called vax. With one global file, every new host had to ask a central authority before picking a name.
2. Update lag. Every host pulled HOSTS.TXT periodically. Adding a machine meant waiting for the file to propagate, and the file kept getting bigger.
3. A single point of administrative failure. SRI-NIC was the bottleneck for every name change anywhere on the network. Worse, it was the wrong group of humans to be deciding what a university lab in Berlin should call its server.

DNS — the Domain Name System — was the redesign. The technical pieces — caching, UDP queries, resource records — are interesting, but the load-bearing idea is the shape of the namespace. It’s a tree. And the tree exists primarily so that authority can be delegated.

Why it matters now

Every modern system that has to name things at scale ends up with the same shape: Kubernetes namespaces, Java packages, npm scopes, AWS resource ARNs, S3 bucket subpaths, even file systems. The reason is the same reason DNS is hierarchical, and once you see it once you see it everywhere: hierarchy is how you split naming from control without losing either.

For an engineer this matters in concrete ways. When you register example.com, you’re not buying a row in some giant database — you’re being delegated authority over the entire subtree below example.com. Nobody at the root needs to know or approve when you create api.staging.example.com. That delegation is also what lets DNS scale, what lets caching work, and what determines whose key signs what under DNSSEC.

The short answer

DNS = tree of names + delegation of authority at every edge + caching

Picture to keep: a chain of receptionists, each holding one index card — the root’s card says “for .com, ask these servers,” .com’s card says “for example.com, ask these nameservers,” and only the last card in the chain has an actual address written on it. Where the picture breaks: in practice you rarely walk the chain, because a resolver near you kept a photocopy of the last card it fetched.

DNS is hierarchical because the names are the cheap part. The expensive part is deciding who’s allowed to say what something.com resolves to, and the tree is the data structure that lets that authority be handed off cleanly at every level. Caching then makes the whole thing fast enough to be invisible.

How it works

Naive fix for HOSTS.TXT: keep the flat table, just put it on a big server everyone queries. That solves propagation lag and nothing else. Your new mail.example.com still has to be entered by whoever runs that server, name collisions still need a global referee, and the whole internet’s naming now depends on one operator’s uptime and one operator’s judgment. The fix has to remove the central decision, not just the central file.

So: read a domain name right-to-left. mail.example.com is really com → example → mail, with an invisible root . at the very end. Each dot is a hand-off point.

The root is tiny on purpose. The root zone — the contents of . — only needs to know one thing per TLD: where to find the name servers for com, for org, for uk, and so on. That’s a small list. It’s served by the 13 root server letters, each of which is actually many machines spread around the world via anycast. The root almost never changes, so this works.

Each TLD operator runs its own zone. The .com registry operator (Verisign) doesn’t have to know your domain’s IP — it only has to know which name servers you’ve declared as authoritative. When a resolver asks .com “where is example.com?”, it doesn’t get an answer, it gets a referral: the NS records naming your nameservers, plus glue records with their IP addresses when those nameservers live inside the domain being delegated.

You run the leaves. Or your DNS provider does. Either way, the authoritative servers for example.com are the source of truth for mail.example.com — the only place the record is decided. Copies live all over the internet in resolver caches, but no level above you stores your records as anything but a delegation pointing down. That’s the trick: each level only knows enough to point further down.

flowchart TD
    Root["· root — knows where each TLD lives"] -->|delegates .com| COM[".com / Verisign — knows your nameservers"]
    Root -->|delegates .org| ORG[".org"]
    Root -->|delegates .uk| UK[".uk"]
    COM -->|delegates example.com| EX["example.com nameservers — knows the actual IPs"]
    EX --> MAIL["mail.example.com"]
    EX --> API["api.example.com"]

Each edge is a hand-off of authority, not a copy of data: the root never learns your IPs, and .com never learns what lives under example.com. Every level only knows enough to point one step further down.

A typical resolution looks like this:

client → resolver:           "mail.example.com?"
resolver → root:             "mail.example.com?"
root → resolver:             "ask the .com servers, here they are"
resolver → .com:             "mail.example.com?"
.com → resolver:             "ask example.com's nameservers, here they are"
resolver → example.com NS:   "mail.example.com?"
example.com NS → resolver:   "203.0.113.42"
resolver → client:           "203.0.113.42"

In practice most queries never do this walk. Your resolver did some of it earlier — the root and .com referrals in particular tend to sit in cache for a long time — and serves the rest from whatever it still holds. Each record carries a TTL, which is a ceiling on caching, not a promise of freshness: it says “don’t keep this longer than N seconds,” and a resolver is free to discard it sooner.

Why a tree, not a hash table?

You could imagine an alternative universe with a flat namespace and a distributed hash table — example.com is just a key, and some peer-to-peer protocol stores the value. People have built this; it doesn’t replace DNS, and the reason is mostly social, not technical.

A flat namespace forces a single answer to “who decides which names are allowed?” A tree lets that question be answered differently in every subtree. ICANN coordinates which TLDs exist. .com names are sold by registrars under policy set for that registry, with Verisign operating the zone. You decide what lives under your .com. Your team lead decides what lives under team.example.com. The same data structure that organizes the names also organizes the politics, and that turns out to be the thing you can’t skip.

Show the seams

A few places the clean story doesn’t quite hold:

• The root isn’t really the root. ICANN coordinates the root zone, but the content (which TLDs exist and who runs them) is the result of policy processes, contracts, and in some cases government involvement for country-code TLDs. The “tree” has a political base, not a technical one.
• Caching makes propagation messy. “DNS changes can take 24–48 hours to propagate” is shorthand for “every cache between you and the world has its own TTL countdown.” Lower TTLs trade load on your servers for faster changes. There isn’t a clean answer; it’s a tuning knob.
• The “13 root servers” number is a historical artifact. It’s 13 named identities (A-root through M-root), originally because of UDP packet size limits in the early DNS protocol. Each identity is now backed by hundreds of physical instances via anycast.
• DNSSEC is the part that makes the hierarchy cryptographic, not just administrative. Each zone signs its records, and the parent zone signs a hash of the child’s key. The chain of trust runs from the root key downward, mirroring the delegation tree. Adoption is uneven and I don’t have a current global number I’d defend — coverage varies a lot by TLD and by organization.
• Modern resolution often skips most of this. Your laptop usually asks a recursive resolver (your ISP’s, or 1.1.1.1, or 8.8.8.8) which has cached half the internet. The full root-to-leaf walk is rare in practice but is the fallback the system is designed around.

You started with DNS = tree of names + delegation + caching. What did the walk down the tree add that the one-liner hides? — + each edge is a hand-off of authority, not a copy of data. That single property is why you could invent mail.example.com unilaterally, why the root zone stays tiny enough to fit on 13 named identities, and why DNSSEC’s chain of signatures has an obvious shape to follow: it just retraces the delegations.

Check yourself

Before you go — you cut the TTL on mail.example.com from 86400 to 60, wait five minutes, then change the IP. A colleague still gets the old address. What are the plausible explanations?

And one more — if .com’s nameservers went down entirely for an hour, would mail.example.com stop resolving for everyone?

Famous related terms

• TLD — TLD = the rightmost label in a domain name — .com, .org, .uk. The first level of delegation under the root.
• Authoritative vs recursive server — authoritative = "I own this zone", recursive = "I'll go ask on your behalf and cache the answer" — the two roles every DNS deployment splits into.
• TTL — TTL = the maximum seconds a record may be cached — an upper bound the operator sets on every downstream resolver, not a guarantee the answer stays valid that long.
• Anycast — anycast = same IP, many machines, routing picks the nearest — how a “single” root server is actually hundreds.
• DNSSEC — DNSSEC = DNS records + signatures rooted at the root key — turns the administrative tree into a cryptographic one.

Going deeper

• RFC 1034 and RFC 1035 (Mockapetris, 1987) — the primary source for “what is a zone, a delegation, a resource record,” written plainly enough that the design intent still shows through.
• “Development of the Domain Name System” (Mockapetris and Dunlap, SIGCOMM 1988) — read this for the retrospective question: which design choices did the authors think mattered, and which surprised them in deployment?
• Julia Evans, “Implement DNS in a Weekend” — the explainer for “what does a resolver actually do,” answered by making you write one that walks the tree from the root.
• The IANA root zone database — the answer to “who actually runs each TLD,” which makes the political layer concrete in a way the protocol docs never do.