How DNS actually works: nobody has the whole list

You typed a name and got a page. Somewhere in the gap, four different servers were asked a question, three of them said I have never heard of that, and the fourth answered — and none of it left a mark in the address bar. Here’s that gap, in output you can reproduce on your own machine in the next thirty seconds.

The phone book is the wrong picture

“DNS is like a phone book” is the sentence that makes this harder to learn. A phone book is one object holding every entry. DNS has no such object. Nothing anywhere holds a list of every name. The space is cut into zones, each with authority over its own slice, and the only thing a server can tell you about a name outside its slice is who to ask next (RFC 1034 §2.1, §4.2).

So the mental model isn’t lookup, it’s referral: a chain of servers, each answering a smaller question — who is closer? — until one of them holds the answer.

Two different jobs, one name

Every box in the diagram gets called “a DNS server,” which is the conflation that makes the referral chain confusing: why would a DNS server not know a DNS answer? They’re two different jobs (RFC 9499 §6):

Job	What it is	What it does
Stub resolver	the one in your OS	asks one server, waits for a final answer
Recursive resolver	your ISP’s, or a public one	does the walking; caches everything
Authoritative server	the one your registrar points at	answers for its own zone only

Your machine is a stub resolver — it sets one bit, “recursion desired,” and waits. The recursive resolver is the one that does the actual work: RFC 1034 §4.3.1 says a server in recursive mode “returns either an error or the answer, but never referrals.” All the referrals happen behind it, where you never see them. Every server it talks to along the way is authoritative for its own slice and nothing else — it has no cache to consult and no upstream to ask.

The walk, on the wire

dig +norec turns off recursion, so the server answers with only what it personally knows. That’s the flag that makes the chain visible:

dig +norec @a.root-servers.net google.com A

;; ->>HEADER<<- status: NOERROR
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 27

;; AUTHORITY SECTION:
com.  172800  IN  NS  a.gtld-servers.net.

status: NOERROR with ANSWER: 0. Nothing went wrong and nothing was answered — that pair is the referral. The root never looked at google; it matched com and handed back the .com nameservers. Ask one of those and you get referred again, one level down, to google.com’s own nameservers. Only the third server answers for real:

dig +norec @ns1.google.com google.com A

;; flags: qr aa; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 1

;; ANSWER SECTION:
google.com.  300  IN  A  173.194.208.100

There’s the aa bit — authoritative answer. This server holds the zone; every server before it was handing you a copy of someone else’s delegation. Three queries, and nobody was ever asked the whole question.

The rule that will bite you: no CNAME at your apex

A CNAME is not a redirect. It’s another name, and the resolver restarts the query against it (RFC 1035 §3.3.1):

www.sqlite.org.  3600  IN  CNAME  sqlite.org.
sqlite.org.       300  IN  A      194.195.208.62

RFC 1034 §3.6.2, one sentence: “If a CNAME RR is present at a node, no other data should be present.” Your zone apex — example.com with no label in front — is required to have other data: its SOA and NS records, the things that make it a zone. So a CNAME can never live there, and this isn’t a limitation a DNS provider imposed on you.

The failure mode is the nasty part: some servers accept the record anyway and then serve a zone where the apex MX and TXT are unreachable, because the CNAME shadows everything at that name. Your website works. Your email and your SPF record silently stop, and the connection between those two facts isn’t obvious at 2am. The workaround registrars sell — ALIAS, ANAME, “CNAME flattening” — isn’t a DNS record type at all; it’s the provider resolving the target itself and serving a synthesised A record, which works but ties you to that one provider’s behaviour.

TTL, and why your change hasn’t propagated

Every record arrives with a number. RFC 1035 §3.2.1: the TTL “specifies the time interval that the resource record may be cached before the source of the information should again be consulted.” Read that precisely — it’s a permission, not a schedule. Nothing is pushed anywhere, and “propagation” is a word that describes something DNS does not do.

A five-minute A record TTL means every resolver that asked in the last five minutes still holds the old address and is entitled to keep it. The fix is to lower the TTL before the change, not after — a resolver holding a cached 24-hour record will hold it for 24 hours no matter what you edit now.

Failures are cached too, and this is the part that catches people. RFC 2308 made negative caching mandatory: an NXDOMAIN comes back with the zone’s SOA, and its last field sets how long the absence may be remembered. Add the record you forgot, and everyone who asked in the last minute still gets NXDOMAIN — on a zone with a one-day minimum, that’s a day.

The records you will actually meet

Type	Holds	Defined in
A / AAAA	an IPv4 / IPv6 address	RFC 1035 §3.4.1 / RFC 3596 §2.2
NS	a nameserver’s name — every referral is made of these	RFC 1035 §3.3.11
CNAME	another name, not an address	RFC 1035 §3.3.1
SOA	a zone’s own serial, refresh, retry, expire, minimum	RFC 1035 §3.3.13
MX	a mail exchanger, with a preference number	RFC 1035 §3.3.9
TXT	arbitrary text — in practice SPF, DKIM, domain verification	RFC 1035 §3.3.14

MX is the one worth a second look, because the number in front of the name isn’t decoration:

ietf.org.  60  IN  MX  0 mail2.ietf.org.

Lower is tried first, and mail2.ietf.org then needs its own A lookup — an MX can’t point straight at a CNAME, for the same reason a CNAME can’t sit at your apex: the record it names has to be free to hold ordinary data alongside it.

Glue records, and the loop they break

The .com referral above told you google.com is served by ns1.google.com — a name inside the zone you’re trying to reach. To ask it anything you need its address, and to get its address you’d need to ask it. Glue records break the loop: the .com servers don’t own ns1.google.com, but RFC 9499 §7 has them hand out its address anyway, alongside the referral, because otherwise the delegation would be unusable. When a domain’s nameservers live outside it — a different registrar entirely — there’s no glue to give, and the resolver has to pause and run a whole second resolution just to find the nameserver it was trying to ask in the first place. That’s the practical cost of putting your nameservers on someone else’s name.