DNS: Why Names Need a Distributed Database

Routing needs numbers — prefixes that can be matched bit by bit and aggregated (The Routing Table and Longest-Prefix Match). Humans need names that survive the server moving to a different address. So there must be a mapping, and the question is only where it lives. The first answer, in the 1970s and early 1980s, was a single file: HOSTS.TXT, maintained at one institute and downloaded by every host on the ARPANET. Your /etc/hosts is its descendant.

A single file fails in three ways as the network grows. It is a single point of update — every change goes through one organisation. It is consistency-blind — hosts download it on their own schedule and disagree for days. And it does not scale — the file, and the traffic to fetch it, grow with the whole network. Replacing the file with a single server fixes nothing: one server for the world is one outage for the world and one queue for every lookup.

The design that survived (Mockapetris, 1983; RFCs 882/883, later 1034/1035) has three ideas. Hierarchy: names are a tree, read right to left. Delegation: each subtree — a zone — is run by its owner on its own servers, and the parent stores only who those servers are. Caching: answers carry a time-to-live so intermediaries can reuse them without asking again. Every property of DNS you will meet later, good or bad, follows from these three.

Read engineer-atlas.dev. from the right. The trailing dot is the root — usually omitted, always implied. Below the root sit the top-level domains: dev, com, de, io. Below dev sits engineer-atlas, a zone owned by whoever registered it. Below that, whatever the owner likes: www, api, eu.api.

Each level knows only its children. The root servers know which servers are authoritative for dev (and for every other TLD) — nothing else. The dev servers, run by the registry, know which servers are authoritative for engineer-atlas.dev — and nothing about what is inside it. The authoritative servers for engineer-atlas.dev hold the actual records: the address of www, the mail servers, and so on. The record that points a parent at a child’s servers is an NS record, and the act is delegation; see DNS Record Types and What They Are For.

The root is thirteen named servers (a.root-servers.net through m), but each name is anycast from many sites — well over a thousand physical instances in total — so the nearest one is usually a few milliseconds away. This is BGP anycast (Internet Routing: Autonomous Systems and BGP) doing the heavy lifting under DNS.

Your application never talks to the root. It calls getaddrinfo() (or whatever the runtime wraps around it), which goes to the OS stub resolver: a small client that checks /etc/hosts, maybe a local cache, and then sends the question to a recursive resolver configured in /etc/resolv.conf or by DHCP — your ISP’s, your company’s, or a public one like 1.1.1.1 or 8.8.8.8.

The recursive resolver does the work. It asks the root, follows the referral to the TLD, follows the referral to the authoritative servers, gets the answer, caches every step, and returns the answer to you. "Recursive" describes what it does for the client (it takes on the whole job); the servers it asks along the way are iterative — they answer only "here is what I know, ask over there". Following One Lookup Through Every Cache follows one query through this chain.

The distinction that trips people up most: an authoritative server holds the truth for a zone and answers only about that zone; a recursive resolver holds no truth at all, only cached copies, and answers about anything. When you change a record, you change the authoritative server. Every resolver in the world will notice on its own schedule — this is the root of almost every DNS incident, and the subject of DNS Failure Modes: What Each One Looks Like.

A DNS query is one message: a 12-byte header (a 16-bit ID the client uses to match the answer, flags, section counts), a question (www.engineer-atlas.dev, type A, class IN), and — in the response — answer, authority and additional sections holding records. It is carried in UDP on port 53 by default: one datagram out, one back, no handshake, which is why a cached answer costs one round trip and a stub-to-resolver query on a LAN takes under a millisecond. UDP: Datagrams and the Contract You Choose explains why this is the right transport here.

Answers were originally capped at 512 bytes over UDP. EDNS(0) raises that (resolvers commonly advertise 1232 bytes to stay under typical path MTUs and avoid fragmentation). If an answer still does not fit, the server sets the TC (truncated) flag and the client retries over TCP on port 53; zone transfers between authoritative servers always use TCP. So "DNS is UDP" is a default, not a rule, and a firewall that blocks TCP/53 will eventually break something — DNSSEC-signed responses and large TXT records are the usual victims.

The modern variants change the hop between *you and the recursive resolver*, which is the only hop a network observer can trivially read and tamper with. DoT (DNS over TLS, port 853) and DoH (DNS over HTTPS, port 443) encrypt it; browsers and phones increasingly use DoH to a resolver of their choosing, bypassing the OS configuration entirely — which is why resolv.conf and the browser can disagree about what a name resolves to. The resolver-to-authoritative hops are still mostly plain UDP.

DNS runs before everything else. No name, no IP; no IP, no TCP connection, no TLS, no HTTP. A DNS failure therefore looks *total* — every site fails, every app fails — even though routing, transport and the servers are all fine. The tell is that things addressed by IP still work: ping 1.1.1.1 succeeds while ping google.com says "could not resolve host". Why Can’t I Connect? puts this at the top of its checklist for that reason.

It is also uniquely exposed to misconfiguration. It is the one piece of infrastructure that every engineer touches (adding a record for a new service) and few understand (the caching). Changes are made in one place and observed everywhere with delays that depend on caches nobody controls. And because it is "just UDP", it is what consumer routers, captive portals, corporate proxies and VPN clients all like to intercept. When something is broken for one person and not another, suspect DNS; when it is broken for everyone at once, suspect DNS first and routing second.