How DNS Resolution Works Step by Step

Your browser has a problem. You typed "example.com" but computers don't route traffic to names—they route to IP addresses. Somewhere in the world, a server at a specific numeric address holds the website you want. Your browser needs to find it.

This is DNS resolution: turning a name into a number. It typically completes in under 100 milliseconds, but those milliseconds contain a journey through multiple caching layers and a global hierarchy designed to answer one question: where is this domain?

The Browser Cache: Checking Memory First

Before asking anyone else, your browser checks its own cache. Modern browsers store recently resolved domain names along with their IP addresses and a TTL (time-to-live) value.

If you visited example.com recently and the TTL hasn't expired, your browser already knows the answer. It skips the entire resolution process and begins connecting immediately.

But if the cache is empty or expired, the browser asks the operating system.

The Operating System Cache

Your OS maintains its own DNS cache, separate from any browser. When Chrome doesn't have an answer, Firefox might have resolved the same domain moments ago—and that answer lives in the OS cache.

If found, the OS returns the IP address immediately. If not, the query leaves your machine entirely.

The Recursive Resolver: Your Representative

Your computer doesn't query the global DNS system directly. It sends its question to a recursive DNS resolver—typically operated by your ISP or a service like Cloudflare (1.1.1.1) or Google (8.8.8.8).

The recursive resolver is named for what it does: it recursively queries the DNS hierarchy on your behalf. You ask once; it does all the work. It contacts as many servers as necessary and returns only the final answer.

Recursive resolvers also cache aggressively. If another user recently asked for example.com, the resolver returns that cached answer instantly. This is why popular sites often resolve faster—someone else already asked.

But when the cache is empty, the resolver begins at the top of the hierarchy.

Root Nameservers: The Starting Point

Thirteen root nameserver systems sit at the apex of DNS. They don't know where example.com lives. They know something more fundamental: who's responsible for each top-level domain.

The recursive resolver asks a root server: "Where can I find example.com?"

The root server responds with a referral: "I don't know example.com, but here are the nameservers that handle everything under .com."

This is an iterative query. The root server doesn't find the answer—it points toward who might know.

TLD Nameservers: Narrowing Down

The recursive resolver now contacts a .com TLD nameserver with the same question.

The TLD server also doesn't know the IP address for example.com. But it knows which nameservers are authoritative for that specific domain. It responds: "Here are the nameservers that handle example.com."

Two queries in, and we've narrowed from "somewhere on the Internet" to "these specific nameservers know."

Authoritative Nameservers: The Final Authority

The recursive resolver contacts an authoritative nameserver for example.com. This server holds the actual DNS records for the domain.

The resolver asks: "What is the IP address for example.com?"

The authoritative nameserver responds: "The A record for example.com is 93.184.216.34, valid for 3600 seconds."

The Return Journey

The recursive resolver returns the IP address to your OS, which returns it to your browser. At each step, the answer is cached according to the TTL.

The next user who asks that resolver for example.com gets an instant answer. If you visit again within the hour, your OS answers without any network query. Your browser finally has what it needed: an IP address. It begins establishing a TCP connection to 93.184.216.34.

Recursive vs. Iterative: Two Types of Queries

Your computer makes a recursive query to the resolver: "Find the answer, whatever it takes."

The resolver makes iterative queries to the DNS hierarchy: "Tell me what you know, even if it's just a referral."

This division of labor is the design. You make one query. You get one answer. The resolver handles the complexity so you don't have to.

Why Caching Makes DNS Possible

A cold resolution—nothing cached anywhere—requires four network round trips: to the resolver, root server, TLD server, and authoritative server. That's 80-200ms.

But caching collapses this dramatically. Recursive resolvers cache TLD nameserver addresses, skipping root queries entirely. They cache authoritative nameserver addresses, skipping TLD queries. They cache final answers for the full TTL.

Popular domains live in cache almost everywhere. Obscure domains require the full resolution chain. This is why returning to Google feels instant while visiting a new site has that slight hesitation.

TTL values control this tradeoff. A 60-second TTL means constant queries to authoritative servers. A 24-hour TTL means most queries answer from cache—but DNS changes take a full day to propagate.

What This Means

Every connection starts with DNS. Before your browser can fetch a page, download an image, or open a websocket, it needs an IP address.

Understanding resolution explains why DNS propagation takes time (caches must expire), why some sites load faster than others (caching at every layer), and why DNS outages are catastrophic (nothing can find anything).

The system is elegant: a hierarchy that narrows billions of possibilities to one, with caching at every level to make the common case fast. You ask your resolver. Your resolver asks the world. The world answers. And then everyone remembers—for a while.

Sources