DNS: How Domain Name Resolution Works
The distributed, heavily-cached lookup service that turns a name every request starts with into an address every request actually needs.
Beginner
TopNotchNote
Notes that matter
what DNS actually does
Every request in this track starts the same way: a client has a human-readable name (
plateroute.com) and needs a machine-readable IP address to actually open a connection. DNS (Domain Name System) is the distributed lookup service that performs that translation — the internet's equivalent of a phone book, except the phone book itself is a globally distributed, heavily cached system rather than a single file.the resolution path
Typing
plateroute.com into a browser triggers a chain of lookups, each one narrowing down which server actually knows the answer:| Step | Server asked | What it returns |
|---|---|---|
| 1 | Root name server | Which server handles the .com top-level domain |
| 2 | .com TLD name server | Which name server is authoritative for plateroute.com |
| 3 | Authoritative name server for plateroute.com | The actual IP address (an "A" or "AAAA" record) |
In practice, most of this chain is skipped on any given request because of caching (below) — a client rarely walks the full root-to-authoritative chain itself; its ISP's resolver usually already has the answer cached from a recent lookup by someone else.
resource records: more than just an IP address
| Record type | Purpose |
|---|---|
| A / AAAA | Maps a domain to an IPv4 / IPv6 address |
| CNAME | Aliases one domain name to another (e.g. www.plateroute.com → plateroute.com) |
| MX | Points to the mail servers responsible for the domain |
| TXT | Arbitrary text, commonly used for domain verification and email anti-spoofing (SPF/DKIM) |
caching: what keeps DNS from collapsing under global query volume
Every layer in the resolution chain caches results for a duration set by the record's TTL (time to live). A client's OS, its browser, its ISP's resolver, and intermediate name servers all cache aggressively, which is why the vast majority of DNS lookups never reach the authoritative server at all.
This creates a real trade-off: a long TTL means fewer lookups and lower latency, but also means a change to a record (say, moving to a new IP after a datacenter migration) takes longer to propagate everywhere, since cached copies keep answering with the old value until they expire. Teams planning an infrastructure change typically lower the TTL well ahead of time so the eventual cutover propagates fast.
DNS as a load balancer
DNS can do more than return a single fixed IP — a domain can have multiple A records, and the resolver returns them in rotation (round-robin), spreading traffic across several servers or datacenters. This is a coarse, cheap form of load balancing, often used at the global level to route users to their nearest regional datacenter, with a finer-grained load balancer then distributing traffic within that datacenter.
It's coarse because DNS has no visibility into server health or current load — it just cycles through the list. A DNS-level record pointing at a datacenter that's fully down will keep sending users there until it's manually or automatically removed, which is why DNS-based routing is usually paired with active health checks rather than relied on alone.