5.5 — DNS: The Internet's Phone Book

Before your browser can open a TCP connection to google.com, something must turn that name into 142.250.187.238. That lookup happens billions of times a second, across a system with no central server, no single owner, and no company that could switch it off.

It is also the most common cause of "the internet is broken" that turns out not to be the internet. This chapter is how it works, and — more usefully — why it fails in the specific ways it does.

1. Why names exist at all, and the file that did not scale

In the early ARPANET, name-to-address mapping was a single text file called HOSTS.TXT, maintained by hand at Stanford Research Institute. Every machine on the network downloaded a copy by FTP.

That worked for a few hundred hosts and then failed for reasons worth listing, because each one motivates a design decision in what replaced it:

• One organisation had to approve every name change on the entire network.
• Every machine downloaded the whole file even to learn one new host.
• Name collisions had to be resolved by a human, since the namespace was flat.
• The download traffic grew with the square of the network — more hosts meant a bigger file and more machines fetching it.

Paul Mockapetris designed DNS in 1983 to fix all four at once, and the fix in every case is the same idea: hierarchy plus delegation.

2. The name is a tree, read right to left

A domain name is a path through a tree, and it reads backwards from how you say it:

www . google . com .
 │      │       │   └── the root (the trailing dot, almost always omitted)
 │      │       └────── top-level domain (TLD)
 │      └────────────── second-level domain — this is what an organisation buys
 └───────────────────── a subdomain, chosen freely by the owner

The trailing dot is real. google.com. is the fully qualified name; the dot is the root of the tree. Browsers hide it, but you can type it and it works, and some configuration files require it.

Each level delegates the level below it, and this is the whole architecture.

• The root does not know where google.com is. It knows who runs .com.
• The .com servers do not know where www.google.com is. They know which nameservers Google runs.
• Google's nameservers know everything below google.com, and Google can add, change or delete mail.google.com at any moment without asking anybody.

That is why the system scales and why it has no central authority over content. ICANN (Chapter 5.1) decides which top-level domains exist and who operates them. Nobody above Google decides what google.com resolves to.

There are 13 root server addresses, named a.root-servers.net through m.root-servers.net. Thirteen is not thirteen machines — it is the number of addresses that fit in a single 512-byte UDP response, which was the original size limit. Each address is served by hundreds of physical machines worldwide via BGP anycast (Chapter 5.3.2): advertise the same IP from many locations and every router sends traffic to the nearest. Over 1,500 physical root servers answer on those 13 addresses.

3. The full resolution, step by step

Say your machine has never heard of www.example.com. Here is every step, in order. Being able to walk this is the single most-asked DNS interview question.

The client asks one question and gets one answer. The recursive resolver does all the work — and note that steps 3 and 5 are referrals, not answers. Nobody in the chain except the last server knows the address.

Step 0 — the caches, checked in order. Before any packet is sent: the browser's own DNS cache, then the operating system's cache, then the hosts file (/etc/hosts, or C:\Windows\System32\drivers\etc\hosts), which overrides everything and is why editing it is the classic local-testing trick.

Step 1 — ask the recursive resolver. Your machine runs a stub resolver — a minimal client that knows how to ask one question and wait. It sends the query to a recursive resolver, whose address came from DHCP (Chapter 5.3.1) or was configured manually: your ISP's, or a public one like 1.1.1.1 or 8.8.8.8.

Step 2–3 — the resolver asks a root server. "Where is www.example.com?" The root does not know. It replies with a referral: "I do not know, but the .com nameservers do, and here they are."

Step 4–5 — the resolver asks a .com server. Same question, same kind of answer: "Ask ns1.example.com, at this address."

Step 6–7 — the resolver asks the authoritative nameserver. This one is authoritative for the zone, so it answers: 93.184.216.34.

Step 8 — the resolver caches it and replies to you.

The distinction that matters: recursive versus iterative. Your machine asks a recursive question — "give me the final answer, do whatever it takes". The resolver then asks a series of iterative questions — "tell me what you know", accepting referrals. The root and TLD servers only ever answer iteratively, and that is deliberate: recursion is expensive, so the servers at the top of the tree refuse to do it and push the work to the millions of resolvers below.

In practice almost none of this happens. The .com referral is cached for two days, the root referral for weeks. A typical lookup is one packet to the resolver and one packet back, in a millisecond or two.

4. Records: DNS is a general key-value store, not just names to addresses

A domain does not map to an address. It maps to a set of resource records, each with a type.

Type	Holds	Used for
A	an IPv4 address	the basic lookup
AAAA	an IPv6 address	"quad-A", four times the size of an A
CNAME	another name	an alias
MX	a mail server name + priority	email routing
TXT	arbitrary text	domain verification, SPF, DKIM
NS	a nameserver name	delegation to a child zone
SOA	zone metadata	serial number, timers
PTR	a name, from an address	reverse lookup
SRV	host + port for a service	service discovery
CAA	which authorities may issue certificates	certificate control

Three of these have real traps.

CNAME points at a name, and the resolver must then resolve that name too. So www.example.com CNAME example-lb.provider.net costs an extra lookup. Two rules follow, and both bite in practice:

• A CNAME cannot coexist with any other record for the same name. The alias means "everything about this name is over there", so there is nowhere for an MX or TXT record to live.
• Therefore the apex of a domain cannot be a CNAME, because the apex must carry NS and SOA records. Section 6 is about the consequences.

TXT records are how the internet proves domain ownership. When a service asks you to add a TXT record with a random string, the reasoning is that only someone who controls the domain's DNS can do it — so it is proof of control. The same mechanism carries SPF (which servers may send mail as this domain), DKIM (public keys for signing mail) and DMARC (what to do with mail that fails those checks). Email anti-spam is, in large part, three TXT records.

PTR reverse lookups are a separate tree. Mapping 93.184.216.34 back to a name uses the special domain 34.216.184.93.in-addr.arpa — the octets reversed, because DNS delegates left to right and IP addresses are hierarchical left to right. Reversing them aligns the two hierarchies. Reverse DNS is controlled by whoever owns the address block, not the domain, which is why you cannot set it yourself on most cloud instances and why mail servers use it as a weak trust signal.

5. Caching, TTL, and the propagation myth

Every record carries a TTL (time to live) in seconds: how long a resolver may cache it.

This is the most consequential number in DNS operations, and the trade is direct:

• Short TTL (60 s) — changes take effect quickly, at the cost of far more queries and more latency on cache misses.
• Long TTL (86,400 s) — cheap and fast, but a change takes up to a day to reach everyone.

The standard practice: lower the TTL to 60 seconds a day before a planned migration, make the change, then raise it again afterwards. Lowering it at the moment of the change does nothing, because resolvers are already holding the old record with the old long TTL.

"DNS propagation" is a misleading term and worth correcting. Nothing propagates. Authoritative servers are updated instantly — your change is live the moment you save it. What takes time is caches expiring. Every resolver worldwide holds the old answer until its own TTL countdown finishes, and those countdowns started at different moments.

Two things make it worse than the TTL suggests. Some resolvers ignore short TTLs and enforce a minimum of their own. And some devices — particularly older home routers — cache far more aggressively than they should, which is why "it works everywhere except at my house" is a real and infuriating symptom.

Negative caching is a separate mechanism people forget. A "this name does not exist" answer (NXDOMAIN) is also cached, for a duration set by the SOA record's minimum field. So if you query a name before creating it, the failure is cached — and creating the record does not immediately fix it. This is the reason a newly added subdomain sometimes stays broken for exactly the length of the negative TTL, and it is a genuinely common source of confusion during a deployment.

6. The apex problem, and why www is disappearing

Here is a real constraint with real architectural consequences.

You want example.com (the apex, or "naked domain") to point at a cloud load balancer. The load balancer has no fixed IP address — it is a name like my-lb-1234.elb.eu-west-1.amazonaws.com, and its addresses change as the provider scales it.

So you need a CNAME. But the apex cannot be a CNAME, because it must hold NS and SOA records, and CNAME cannot coexist with anything.

Three ways out:

A provider-specific pseudo-record. AWS's ALIAS, Cloudflare's CNAME flattening, Azure's alias records. These behave like a CNAME at the apex, but the resolution happens inside the DNS provider, which returns real A records to the client. There is no protocol change — the provider does the extra lookup on your behalf. The cost is that it ties your DNS to that provider.

Redirect the apex to www. Point the apex at a tiny always-on service that returns a 301 to www.example.com, and let www be a CNAME. This is why so many sites still redirect one way or the other.

SVCB and HTTPS records (RFC 9460) are the proper protocol-level fix, allowing apex aliasing plus advertising supported protocols and parameters in DNS. Browser support is arriving; it will take years to be universal.

Now the www question, which people ask constantly.

www was a subdomain convention from when a single organisation ran several distinct services — www for the web server, ftp for file transfer, mail for mail, gopher for gopher. Naming the service made sense because they were different machines.

Today an organisation usually has one web presence, so the prefix carries no information. Hence github.com, x.com, openai.com with no www, and hence browsers hiding it in the address bar.

But there is a genuine technical argument for keeping it, and it is more interesting than the aesthetics:

Cookies set on the apex are sent to every subdomain. A cookie set on example.com is transmitted with every request to api.example.com, blog.example.com, static.example.com — including static asset requests where it is pure overhead, and including any subdomain you later hand to a third party. A cookie set on www.example.com stays on www. Chapter 5.6 covers cookie scoping in full, and this is one of its sharpest practical consequences.

The apex CNAME limitation above is the second reason, and it is why large sites that appear to have no www frequently redirect the apex to it behind the scenes, or use a provider-specific alias to work around the restriction.

7. Where DNS fails, and how it is being secured

DNS was designed with no authentication at all. A response is believed if it arrives on the right port with the right query ID. That is a 16-bit number plus a 16-bit source port, and it is not much of a defence.

Cache poisoning is the classic attack: flood a resolver with forged responses for a name it is currently looking up, guessing the query ID, and if one lands before the real answer, the resolver caches the attacker's address and serves it to everyone behind it. Dan Kaminsky's 2008 discovery made this far more practical than previously believed and prompted an emergency coordinated patch across the industry. The mitigation deployed then was source port randomisation, adding 16 bits of entropy — a delaying tactic rather than a fix.

DNSSEC is the real fix, and its adoption is partial. It signs records cryptographically, with a chain of trust running from the root down through each delegation, so a resolver can verify that an answer genuinely came from the zone's owner and was not modified. It does not encrypt anything — DNSSEC provides authenticity, not privacy. Adoption remains limited, mainly because it is operationally fragile: an expired signature takes your domain offline completely, which is a worse failure than the attack it prevents.

Privacy is a separate problem with separate fixes. Plain DNS is unencrypted, so your ISP and anyone on the path sees every name you look up — a remarkably complete record of your activity. Two protocols address it:

• DoT (DNS over TLS) — DNS on port 853, wrapped in TLS. Distinguishable as DNS traffic by port, so it can be blocked or observed as a category.
• DoH (DNS over HTTPS) — DNS inside ordinary HTTPS on port 443, indistinguishable from web traffic.

DoH is genuinely contested, and the argument is worth understanding. It hides lookups from your network operator, which is good for privacy and bad for a corporate network that relies on DNS filtering for security policy, and bad for a school or parent relying on it for content filtering. It also centralises: browsers that default to a single DoH provider concentrate a global view of everyone's lookups in one company. That is a privacy improvement against one adversary and a privacy risk against another, and reasonable people disagree about the trade.

The operational failure modes worth recognising:

• A resolver is down — everything appears broken while the network is fine. This is why 1.1.1.1 and 8.8.8.8 exist and why configuring a second resolver matters.
• A stale cache after a migration — some users hit the old server for the length of the TTL.
• Negative caching after creating a record too late — covered in section 5.
• A single DNS provider is a single point of failure. The 2016 Dyn attack took down Twitter, Reddit, Spotify and GitHub simultaneously — not by attacking any of them, but by attacking the DNS provider they shared. The fix is nameservers at two independent providers, and it is one of the highest-value, lowest-cost resilience measures available.

dig www.example.com            # the query and full answer, with TTLs
dig +trace www.example.com     # every referral from root down — the section 3 walk, live
dig example.com MX             # a specific record type
dig @1.1.1.1 example.com       # bypass your configured resolver

dig +trace is the single best learning tool on this page. Run it and you will watch the root return a referral to .com, .com return a referral to the authoritative servers, and those return the answer — exactly the eight steps above.

What the interviewer will push on

"Walk me through a DNS lookup." They want the cache layers first (browser, OS, hosts file), then stub resolver → recursive resolver → root → TLD → authoritative, with the referral distinction made explicit and the note that root and TLD servers answer only iteratively.

"Why can the apex of a domain not be a CNAME?" Because CNAME cannot coexist with other records, and the apex must hold NS and SOA. Then give the three workarounds — provider ALIAS records, apex-to-www redirect, and the HTTPS/SVCB record type.

"You changed a DNS record and some users still hit the old server. Why?" Caches holding the record for the remainder of its TTL, which started at different times. Nothing propagates — authoritative servers updated instantly. The fix is lowering the TTL before the change, and the trap is negative caching if the name was queried before it existed.

"What TTL would you set, and why?" Ask about the change frequency and the query volume. Sixty seconds during a migration, hours or a day at rest. Then the point most candidates miss: a low TTL is also a resilience choice, because it shortens how long a mistake persists.

"What does a TXT record have to do with security?" It is proof of domain control, because only the DNS operator can set one. It carries SPF, DKIM and DMARC, which is most of email anti-spoofing.

"Is DNSSEC encryption?" No — authenticity, not privacy. Encryption is DoT or DoH, which are separate and solve a different problem. Conflating them is the common error.

"Your site is down and the servers are healthy. Where do you look?" DNS resolution first — dig from several networks, check the resolver, check TTL and recent changes. Then note the shared-provider risk from the Dyn incident, and that two independent DNS providers is the standard mitigation.

One thing to volunteer: point out that the apex CNAME restriction is what pushes so many organisations into a redirect between the apex and www, and that the choice also determines cookie scope — a cookie on the apex is sent to every subdomain including third-party-controlled ones, while a cookie on www is not. Connecting a DNS constraint to a security consequence is the observation that shows you have operated a domain rather than read about one.

Recall

• DNS replaced a hand-edited HOSTS.TXT with hierarchy plus delegation: each level knows only who runs the level below, which is why there is no central authority over what a domain resolves to.
• A name is a tree read right to left, ending at the root's trailing dot. The 13 root addresses are served by 1,500+ machines via BGP anycast.
• Resolution: caches → stub resolver → recursive resolver → root → TLD → authoritative. Root and TLD servers answer only iteratively, returning referrals — they push the work outward on purpose.
• A CNAME points at a name and cannot coexist with other records, which is why the apex cannot be a CNAME — hence provider ALIAS records, apex-to-www redirects, and the HTTPS/SVCB record type.
• TXT records prove domain control, which is how verification, SPF, DKIM and DMARC all work.
• Nothing "propagates." Authoritative servers change instantly; TTL caches expire at different times. Lower the TTL before a change. Negative caching means querying a name before it exists caches the failure.
• DNSSEC gives authenticity, not privacy; DoT and DoH give privacy, and DoH is contested because it also centralises lookups and breaks network-level filtering.
• A single DNS provider is a single point of failure (Dyn, 2016) — use two.

Self-test: What is the difference between a recursive and an iterative query, and who does each? · Why can example.com not be a CNAME, and give two workarounds · Why does lowering a TTL at the moment of a change not help? · What does negative caching break during a deployment? · Is DNSSEC encryption? · Why does putting a cookie on the apex rather than on www matter?

Next: 5.6 is the protocol everything above this runs on — HTTP, from its one-line 1991 original to today's multiplexed version, including the full anatomy of the cookie and why browsers are ending third-party ones.