How DNS Resolution Actually Works, Step by Step

You type pickuma.com and hit enter. Before a single byte of HTML moves, your machine has to turn that name into an IP address like 104.21.43.7. That translation is DNS resolution, and on a warm cache it finishes in single-digit milliseconds; on a cold one it can touch four or five separate servers that have never heard of each other and still return in 20–120 ms. Here is each hop, in order, with no hand-waving.

Where the lookup starts: caches on your own machine

The first servers queried aren’t on the network at all. Your browser keeps its own DNS cache (Chrome’s is visible at chrome://net-internals/#dns), and it checks that first. On a miss, it asks the operating system’s stub resolver, which checks the OS cache and the hosts file (/etc/hosts on macOS and Linux, C:\Windows\System32\drivers\etc\hosts on Windows). An entry in hosts wins over everything downstream — that’s why a stale line there can override DNS for a domain and produce a bug that survives every cache flush you try.

If nothing local answers, the stub resolver forwards the query to a recursive resolver: the IP in your network settings, often your ISP’s, or a public one like 1.1.1.1 (Cloudflare) or 8.8.8.8 (Google). The query travels over UDP port 53 by default. If the answer is too large for a single UDP datagram, the resolver retries over TCP port 53. Encrypted transports change the port: DNS over TLS uses 853, and DNS over HTTPS rides ordinary 443 so it blends into web traffic.

The recursive resolver walks the tree

If the recursive resolver has the record cached and the TTL hasn’t expired, it answers immediately. On a cache miss, it does the iterative work, descending the DNS tree one level at a time.

1. Root servers. The resolver asks a root server for pickuma.com. There are 13 root server identities (named a.root-servers.net through m.root-servers.net), but each is anycast to hundreds of physical sites worldwide, so your query hits a nearby instance. The root doesn’t know pickuma.com. It answers with a referral: “go ask the .com nameservers,” and hands over their addresses.
2. TLD nameservers. The resolver asks a .com top-level-domain server. It also doesn’t know the IP, but it knows who’s authoritative for pickuma.com — it returns the domain’s NS records, the authoritative nameservers you set at your registrar (for many sites, something like *.ns.cloudflare.com).
3. Authoritative nameservers. The resolver asks the authoritative server, which holds the actual zone file. This is the server that finally returns the answer: an A record (IPv4) or AAAA record (IPv6). If the name is a CNAME, it points to another name, and the resolver follows that alias and resolves it too.

Each step narrows the search. The root knows only TLDs, the TLD knows only which nameservers own each domain, and the authoritative server knows the records themselves. No single server holds the whole map, which is exactly what lets DNS scale to hundreds of millions of domains.

The resolver then caches the answer for the duration of its TTL and returns it to your stub resolver, which caches it too and hands the IP to the browser. Only now does the TCP (or QUIC) connection to the web server begin.

Record types you’ll meet along the way: A and AAAA map names to addresses; CNAME aliases one name to another; NS delegates a zone to nameservers; MX routes mail; TXT holds arbitrary text used for SPF, DKIM, and domain-ownership checks. A single lookup can chain several of these together.

TTLs, caching, and the propagation myth

Every record carries a TTL — time to live, in seconds — that tells resolvers how long to cache it. A record with TTL 3600 may be served from cache for an hour before anyone re-queries the authoritative server. This is what people mean by “DNS propagation,” and the word is misleading: nothing propagates. When you change a record, the authoritative server updates instantly. What you’re waiting on is the old value timing out of caches that grabbed it before your change.

A couple of integrity layers sit on top of all this. DNSSEC signs records cryptographically so a resolver can verify an answer came from the real authoritative server and wasn’t forged in transit — it doesn’t encrypt anything, it authenticates. Encryption of the query itself is the job of DoT and DoH, which hide which names you’re looking up from anyone watching the network. The two solve different problems and are often deployed together.

If you want to watch the hierarchy resolve live, dig +trace pickuma.com shows the referrals from root to TLD to authoritative, one block per hop, and dig pickuma.com +noall +answer shows just the final records and their remaining TTLs. Running these against your own domain after a change is the fastest way to tell whether a stale answer is coming from the authoritative server or from a cache in the middle.