How DNS Finds a Website in Milliseconds

Computers do not connect to names. They connect to numbers. When a domain name is typed into a browser, something has to translate that readable name into an IP address, and it has to do it fast enough that nobody notices. That something is the Domain Name System, or DNS.

A phone book, distributed

DNS is often compared to a phone book, but it is really a hierarchy. No single server knows every address. Instead, the work is split up, and each level points to the next one that knows a little more.

At the top are the root servers, which know where to find the servers for top-level domains like .com, .org, and .de. Those servers, in turn, know where to find the authoritative servers for individual domains. An authoritative server is the final source of truth for its own domain: it holds the actual records that map a name to an address.

A typical lookup, called a resolver, walks this chain. It asks the root where .com lives, asks the .com server where the domain lives, and asks the domain's server for the address. Each answer narrows the search until there is nowhere left to go.

Why it is usually instant

If every lookup walked the full chain from scratch, browsing would feel sluggish. In practice, almost nothing does.

Answers are cached at every step. A resolver remembers recent results for as long as the domain owner allows, a period called the time to live. Browsers cache results too, and so do operating systems. That means a popular site is usually answered from a nearby cache in a millisecond or two, without ever reaching an authoritative server.

Caching also explains a familiar frustration: when a website moves to a new server, some visitors see the new site immediately and others see the old one for hours. The old answer is still sitting in a cache somewhere, waiting for its time to live to expire.

The records behind the scenes

The best-known record is the A record, which maps a name to an IPv4 address, and its IPv6 equivalent, the AAAA record. But DNS carries much more than addresses. MX records say where email for a domain should go. TXT records carry verification strings and policy settings. CNAME records point one name at another, which is how many services alias a friendly name to infrastructure they control.

None of this is visible in normal use, and that is the point. DNS was designed to be boring infrastructure: a naming layer that lets humans use words while machines use numbers, with enough caching and distribution that a single failure rarely takes the whole system down.

The next time a page loads before the finger has left the keyboard, that is not luck. It is a short chain of questions, most of them already answered, doing exactly what it was built to do.