1. What DNS is, and why it exists

Before DNS there was a text file.

   HOSTS.TXT
   maintained at the Stanford Research
   Institute, downloaded by FTP, by every
   host on the ARPANET, periodically.

   10.0.0.51   sri-nic
   10.2.0.11   ucb-vax
   10.1.0.2    mit-ai
   …

   ONE FILE. ONE AUTHORITY. EVERY MACHINE
   PULLING A FULL COPY.

By 1983 that was failing in three ways at once: the file was growing faster than the network could distribute it, every new host required a request to one overworked person at SRI, and two sites that both wanted the name frodo had to negotiate. The problems were scale, administration and naming collisions, and Paul Mockapetris’s answer solved all three with one idea.

DNS’s founding decision: make the namespace a tree, and let the owner of each node delegate the subtree beneath it to somebody else.

                        . (root)
             ┌──────────┼──────────┐
            com        org        uk
          ┌──┴──┐       │       ┌──┴──┐
      example  bbc    wikipedia co    ac
        │                        │     │
       www                      bbc  cam

Nobody holds the whole tree. The root operators know who runs com; the com registry knows who runs example.com; the owner of example.com decides what www.example.com means and asks no one’s permission to do it. Scale is solved because no single server holds everything; administration is solved because each delegation is a handoff of authority; collisions are solved because frodo.example.com and frodo.example.org are simply different names.

It is a database, and worth calling one

   A LOOKUP IS A KEY, AND THE KEY HAS
   THREE PARTS

   NAME    www.example.com.
   CLASS   IN            (always, in
                          practice)
   TYPE    A | AAAA | MX | TXT | SRV | …

   → a set of RESOURCE RECORDS, plus a TTL

Calling DNS “a phone book” undersells it in one specific way: a phone book maps names to numbers, and DNS maps a name and a type to a set of values. example.com A and example.com MX are different keys with different answers, which is why one name can be a web server, a mail destination, a domain-ownership proof and a service locator simultaneously.

dig +short example.com A
dig +short example.com MX
dig example.com ANY        # mostly refused now, and rightly

What delegation actually buys

   WITHOUT DELEGATION
     one authority must approve, store and
     serve every name on earth.

   WITH DELEGATION
     each zone's operator publishes an NS
     record saying "ask these servers about
     everything below here", and the
     hierarchy stops caring.

   THE ROOT ZONE IS ABOUT 2 MB.
   it names ~1,500 top-level domains and
   nothing else. every other name on the
   internet hangs off a delegation it
   points at.

That is the number worth remembering. The entire global namespace is reachable from a two-megabyte file, because the root’s only job is to say who to ask next.

And what caching cost

Delegation alone would still mean a walk from the root for every lookup, which no root server could survive. The second design decision pays for the first.

Every answer carries a TTL, and anyone may cache it for that long.

   THE BARGAIN

   you get:  a system where the root sees a
             tiny fraction of real traffic,
             and a repeat lookup costs
             nothing.

   you pay:  you no longer control when a
             change takes effect. there is
             no invalidation, no callback,
             no "flush the world". you set
             a TTL, and you wait.

Note

This is the origin of the single most persistent misconception in the field. DNS changes do not “propagate” — nothing is pushed anywhere. An old answer simply expires out of each cache independently, on its own schedule, and until it does, different users genuinely get different answers. Chapter 6 is the full account, and it is the chapter to read before any migration.

The three roles

Almost every confusion about DNS is a conflation of these.

   STUB RESOLVER
     in your operating system or your
     library. knows almost nothing. asks
     one configured server and believes
     the answer.
     → /etc/resolv.conf, getaddrinfo()

   RECURSIVE RESOLVER (a "resolver")
     does the actual work: walks the tree
     from the root, caches everything,
     returns a final answer.
     → your ISP's, 8.8.8.8, 1.1.1.1,
       your corporate resolver, dnsmasq

   AUTHORITATIVE SERVER
     holds a zone. answers only about that
     zone. never asks anybody anything.
     → the root servers, the .com servers,
       Route 53, NS1, your own BIND

   THE RULE THAT CLEARS UP EVERYTHING

   RECURSIVE servers CACHE and never have
   authority.
   AUTHORITATIVE servers have AUTHORITY and
   never cache.

   a server that does both is misconfigured,
   and was a standard open-relay hazard
   for twenty years.

The one query, the whole design

It is worth seeing how little the protocol asks of itself, because the minimalism is the reason it survived.

   A QUESTION IS: a name, a type, a class.
   AN ANSWER IS:  a set of records, and a
                  number of seconds.

   NO SESSION. NO STATE. NO NEGOTIATION.
   NO VERSIONING BEYOND AN OPTIONAL
   PSEUDO-RECORD BOLTED ON IN 1999.

A DNS server does not know who you are, what you asked a moment ago, or whether it will ever hear from you again. Every query is complete in one packet and every answer is complete in one packet, which is what makes caching trivial, anycast viable, and a single machine capable of answering a million questions a second.

It is also why every extension since — EDNS0, DNSSEC, cookies, encrypted transports — has had to be squeezed into a format designed when a 512-byte packet was a generous allowance. The protocol’s longevity and its awkwardness have exactly the same cause.

Four decades of mostly not changing

   1983  RFC 882/883 — the design
   1987  RFC 1034/1035 — the version still
         in force
   1997  dynamic update
   1999  EDNS0
   2005  DNSSEC, as deployed
   2016  DoT
   2018  DoH
   2023  HTTPS/SVCB records

Six substantive additions in forty years, every one of them backwards-compatible with a 1987 resolver. That constraint explains most of what looks strange in the chapters ahead.

Why it still matters this much

   EVERY REQUEST STARTS HERE.

   open a page → 10–80 DNS lookups
   connect to a database → a lookup
   call an internal service → a lookup
   send mail → MX, SPF, DKIM, DMARC: four
   validate a certificate → CAA, and
     ACME's DNS-01 challenge

   AND IT IS A CONTROL PLANE
     failover, blue/green, geo-routing,
     service discovery, ownership proofs,
     email policy, and the kill switch for
     an entire company's internet presence.

The last line is not rhetorical. A DNS mistake is one of very few changes that can take an organisation completely off the internet in a way that is also hard to undo quickly, because the broken answer is now cached in a million places that will not ask you again for an hour. Chapter 14 collects the real incidents.

The vocabulary

   ZONE          a unit of administrative
                 control: a chunk of the
                 tree held by one operator

   DELEGATION    an NS record handing a
                 subtree to other servers

   RR / RRSET    a resource record; all
                 records of one name+type

   TTL           how long an answer may be
                 cached, in seconds

   AUTHORITATIVE the answer came from the
                 zone's owner

   REFERRAL      "I don't know, but ask
                 these servers"

   NXDOMAIN      the name does not exist
                 (different from "exists
                 with no records of this
                 type", which is NODATA)

   GLUE          an address record for a
                 nameserver inside the zone
                 it serves — without it,
                 resolution cannot start

The NXDOMAIN / NODATA distinction is the one that catches people. dig AAAA example.com returning nothing with status: NOERROR means the name exists and has no IPv6 address; status: NXDOMAIN means the name does not exist at all. Code that treats them the same misreports a working domain as missing.

What it costs

   NO TRANSACTIONS, NO CONSISTENCY MODEL
     a change is eventually visible,
     on a schedule nobody controls.

   UDP, AND A 512-BYTE PACKET
     an ancient constraint that still
     shapes the protocol. chapter 7.

   SECURITY WAS AN AFTERTHOUGHT
     no authentication in the original
     design at all. DNSSEC bolted it on
     in 2005 and adoption is still partial.

   CENTRALISATION BY ACCIDENT
     a handful of resolvers and a handful
     of managed providers now serve most
     of the world's queries.

   CACHING IS A DEBUGGING NIGHTMARE
     "it works for me" is usually literally
     true, and usually a cache.

What to read next, if you are in a hurry

Read the namespace and the architecture in order; everything else assumes them. If you are about to migrate a domain, read caching and TTL first — it is the chapter that prevents the outage. If something is broken right now, failure modes is written for that.

What to take from this chapter

• DNS replaced a single HOSTS.TXT file that was failing at scale, administration and naming collisions, and one idea solved all three: a tree whose nodes delegate their subtrees.
• No server holds the whole namespace. The root zone is about 2 MB and names only the top-level domains — everything else hangs off a delegation it points at.
• A lookup key has three parts: name, class and type. One name can be a web server, a mail destination and an ownership proof at once, because those are different types.
• Delegation alone would overwhelm the root, so the second decision pays for the first: every answer carries a TTL and anyone may cache it.
• The price of that bargain is no invalidation. Nothing “propagates”; old answers expire independently in each cache, and until they do, different users get different answers.
• Three roles, never to be conflated: a stub resolver that believes what it is told, a recursive resolver that walks the tree and caches, and an authoritative server that holds a zone and never asks anyone anything.
• Recursive servers cache and have no authority; authoritative servers have authority and do not cache. A server doing both is misconfigured.
• NXDOMAIN and NODATA are different. “The name does not exist” is not “the name exists with no record of this type”, and conflating them misreports working domains as missing.
• The costs are no consistency model, a protocol still shaped by a 512-byte UDP packet, security bolted on afterwards, accidental centralisation, and caching that makes “works for me” literally true.

Next: the namespace — labels, the trailing dot, what a zone actually is, and where one ends and the next begins.