Domain Name System

Machines on a network find each other by number. That is a poor format for people to hold in their heads — roughly like memorizing a ten-digit phone number, except that using twenty services means twenty numbers.

The early workaround was a list file pairing names with numbers, copied onto every computer. With a few hundred connected machines it held up. It stopped holding up as the count grew. Every time an address changed somewhere, a fresh copy of the list had to reach everyone, and whoever missed the update kept dialing an address that no longer existed.

Moving a server therefore became an announcement exercise. You sent out a notice saying the address would change next week, and customers who never read the notice simply lost access on moving day. Nothing was broken on the server side, only on the using side, which made the cause slow to find. DNS replaced the copy-everywhere list with a structure where the mapping lives in one place and machines ask for it when they need it.

Three problems go away once names are looked up instead of memorized.

1. Nobody has to keep numbers. People work with the name, and the machine fetches the number each time. That works because one authoritative record connects the two.
2. Address changes stop needing distribution. Move a service to a different machine and you edit the single line joining that name to a number. Everyone using it does nothing, and no notice goes out.
3. One name can stand for several servers. Attach several addresses to the same name and requests spread across them; when one machine dies, its address comes off the list. Returning different addresses depending on where the visitor is comes from the same mechanism.

Asking for a name and getting back a number runs through four stages.

1. The machine checks what it already stored. If it asked for the same name a moment ago, the answer comes from there and nothing leaves the device.
2. Otherwise it asks a resolver run by the internet provider or the company, which takes over the job of hunting the answer down.
3. The resolver works from the top down. A root server points it to whichever server knows .com, and that one points to the server actually responsible for the domain.
4. The last server returns the number. The resolver keeps that answer for a set period and serves it directly the next time the same question arrives.

The storage period in stage 4 is called the TTL and is written in seconds — 3600 means one hour. A long TTL means fewer trips outside and faster answers, but when an address changes, every place holding the old answer keeps it for that long. So a server move starts days earlier with the TTL dropped to 60 seconds, and the value goes back up afterward. The same record can carry more than an address, too: separate entries say which machines accept mail for the domain, and others hold short text values that a service reads to confirm the domain really belongs to whoever is claiming it.

Nothing replaces DNS wholesale. Finding each other by name is part of what being on the internet means, so declining to use it amounts to declining to be reachable. What exists instead are narrower ways of stepping around it.

1. Using the numeric address directly. Fine for standing up an internal tool in a hurry, but the moment that address changes, every place it was written down breaks at once.
2. The per-machine list file pairing names with numbers. It still ships on every computer and gets used to send a service under development to a different address on one laptop only. Applying to that single machine is both the purpose and the limit, and it is also a frequent source of confusion, since a site that works on one laptop and nowhere else usually traces back to a line someone added there months ago.
3. Service discovery inside a company network. Internal programs start and stop constantly, and this keeps track of which addresses are alive right now, but it has nothing to say about requests coming in from outside.

The real choice, then, is not whether to use DNS but who runs it for you. The company that sold you the domain includes it by default, and so do providers of content delivery networks (CDNs), the distribution networks that serve files from a location near the visitor. Going with the latter buys features on top: answers that vary by the visitor's region, or a failing region dropped from the rotation automatically.

"We're waiting on DNS to propagate. The TTL is 3600, so give it an hour."

The address is already changed, but places holding the old answer mean the change hasn't reached everyone yet.

"That's not the server, that's DNS. Our side is fine — the name is pointing at the old address."

Separating a fault in the service from a fault in the mapping between name and address.

"We bought the domain but haven't switched the name servers, so nothing loads."

The servers actually responsible for the domain were never designated, so the question goes to the wrong place.

When Pagedeck moved servers last month, the first thing Theo did was lower the TTL. Dropping it from 3600 to 60 three days ahead meant that on moving day, once the address changed, anything holding the old answer cleared within a minute. Skip that preparation and for the hour after the move some customers land on the new server while others land on an old one that is already switched off.

Once the move finished, he put the value back to 3600. Leaving it at 60 sends the same question outside over and over, which makes every first connection a little slower.

The most common assumption is that a change takes effect immediately. You edit a value, a confirmation appears, and it reads as done. What changed is the one authoritative record, though; resolvers around the world go on serving the old answer until their TTL runs out. Without knowing that, a team sees the new page on their own laptops while support tickets keep arriving, treats it as an outage, and spends hours searching a server that was never broken.

Believing DNS carries the traffic is the other one. It takes part only in the step where an address is handed over; everything after that is direct between the machine and the server. A load balancer spreading requests across machines, or a reverse proxy receiving requests and passing them backward, sits in the path of every byte — DNS does not. So DNS can slow down the first question and nothing else, and a page that stays slow throughout has its cause somewhere else.