How DNS Resolution Works

Every time you type a domain name into a browser, send an email, or make an API call, DNS resolution happens behind the scenes. The process converts a human-readable domain name like example.com into a machine-routable IP address like 93.184.216.34. It typically completes in under 100 milliseconds, but involves a surprising number of systems and steps.

Understanding how DNS resolution works is foundational to diagnosing performance issues, planning DNS changes, and understanding why some changes take time to propagate.

The DNS Resolution Chain

DNS resolution follows a hierarchical chain from local caches to the global DNS infrastructure. Here is what happens when you type www.example.com into your browser, assuming no caches have the answer.

Browser DNS cache

The browser checks its own internal DNS cache first. If you visited www.example.com recently (within the last 60 seconds or so), the browser already has the IP address stored and skips the rest of the process. Each browser manages its own cache independently.

Operating system DNS cache

If the browser cache misses, the query goes to the operating system's stub resolver. The OS maintains its own DNS cache that serves all applications. On Windows, the DNS Client service handles this. On macOS, it is mDNSResponder. If the OS cache has a valid (non-expired) entry, it returns the IP immediately.

Recursive resolver

If neither local cache has the answer, the OS forwards the query to the configured recursive resolver. This is typically your ISP's DNS server, or a public resolver like Google (8.8.8.8) or Cloudflare (1.1.1.1). The recursive resolver is responsible for doing the heavy lifting of finding the answer.

Recursive resolver cache

The recursive resolver checks its own cache first. Because it serves potentially millions of users, there is a good chance someone else already queried www.example.com recently and the answer is cached. If so, it returns the cached answer and the process is done.

Root nameserver query

If the recursive resolver has no cached answer, it begins the iterative resolution process. It queries one of the 13 root nameserver clusters (labeled a.root-servers.net through m.root-servers.net). The root server does not know the IP for www.example.com, but it knows which servers are authoritative for the .com TLD and returns a referral.

TLD nameserver query

The recursive resolver follows the referral and queries a .com TLD nameserver. The TLD server does not know the IP for www.example.com either, but it knows which nameservers are authoritative for example.com and returns another referral.

Authoritative nameserver query

The recursive resolver queries the authoritative nameserver for example.com. This server has the actual DNS zone file and returns the definitive answer: the IP address associated with www.example.com.

Response returned to client

The recursive resolver caches the answer (according to the TTL) and returns it to the OS, which caches it and returns it to the browser, which caches it and initiates a TCP connection to the IP address.

The Root Server System

The root nameservers are the starting point for all DNS resolution when no cache is available. Despite the common description of "13 root servers," there are actually hundreds of physical servers distributed globally using anycast routing. The 13 root server identifiers (A through M) each map to a cluster of servers.

Root servers handle an enormous volume of queries but their job is simple: for any query, they return a referral to the appropriate TLD nameserver. They do not hold records for individual domains.

Root servers are rarely the bottleneck

Because recursive resolvers cache root server responses aggressively (TLDs don't change often), actual queries to root servers are a small fraction of total DNS traffic. Most resolution chains start at the recursive resolver's cache.

TLD Nameservers

TLD (Top-Level Domain) nameservers are responsible for knowing which authoritative nameservers handle each domain within their TLD. The .com TLD nameservers know the NS records for every .com domain. The .org TLD nameservers know the NS records for every .org domain.

When a registrar sets nameservers for a domain, that information is published at the TLD level. This is why changing nameservers at your registrar is a separate (and more impactful) operation than changing records at your DNS provider.

Authoritative Nameservers

The authoritative nameserver is the source of truth for a domain's DNS records. When the recursive resolver reaches the authoritative server, it gets the definitive answer. This is where your A records, MX records, TXT records, and everything else in your DNS zone are served from.

Most domains have at least two authoritative nameservers for redundancy. If one is unreachable, the resolver tries the other. The NS records in your zone and at the TLD level specify which servers are authoritative.

Recursive vs. Iterative Queries

DNS resolution involves two types of queries, and understanding the distinction clarifies why the process works the way it does.

Aspect	Recursive Query	Iterative Query
Who makes it	Client → Recursive resolver	Recursive resolver → DNS servers
Expectation	Give me the final answer	Give me the best answer you have
Response type	Final IP address or error	Final answer or referral to another server
Who does the work	The recursive resolver	The recursive resolver follows referrals

When your browser asks its configured resolver for www.example.com, it sends a recursive query. This means "I need the final answer; you figure out how to get it."

The recursive resolver then makes a series of iterative queries to root servers, TLD servers, and authoritative servers. Each response is either the final answer or a referral saying "I don't know, but ask this server." The resolver follows the referrals until it gets the final answer.

Your browser never talks to root servers

End-user devices send recursive queries to their configured resolver and wait for the answer. The resolver does all the work of iterating through the DNS hierarchy. This is why the recursive resolver is sometimes called a "caching resolver" — it does the lookup and caches the result for the next user who asks.

What Happens at Each Step

To make the resolution chain concrete, here is what the actual DNS protocol exchanges look like for resolving www.example.com.

Query to Root Server

Query:    www.example.com.  IN  A
Response: Referral to .com TLD servers
          com.  172800  IN  NS  a.gtld-servers.net.
          com.  172800  IN  NS  b.gtld-servers.net.
          (plus glue records with IPs of TLD servers)

The root server says: "I don't know about www.example.com, but here are the servers responsible for .com."

Query to TLD Server

Query:    www.example.com.  IN  A
Response: Referral to example.com authoritative servers
          example.com.  172800  IN  NS  ns1.dnsprovider.com.
          example.com.  172800  IN  NS  ns2.dnsprovider.com.
          (plus glue records if available)

The TLD server says: "I don't know about www.example.com, but here are the nameservers for example.com."

Monitor your DNS resolution chain

DNS Monitor checks that your nameservers are responding correctly and consistently, catching resolution failures before your users experience them.

Query to Authoritative Server

Query:    www.example.com.  IN  A
Response: Answer
          www.example.com.  300  IN  CNAME  example.com.
          example.com.       300  IN  A      93.184.216.34

The authoritative server provides the final answer. In this case, www.example.com is a CNAME pointing to example.com, which has an A record pointing to 93.184.216.34. The resolver follows the CNAME chain and returns the final IP to the client.

DNS Resolution Performance

The full iterative resolution process involves multiple network round trips: one to the root server, one to the TLD server, and one to the authoritative server. Each round trip adds latency.

Uncached resolution: 50-200ms

A full resolution from scratch requires 3-4 round trips. With servers distributed globally via anycast, each round trip is typically 10-50ms. Total resolution time is usually 50-200ms.

Cached resolution: 1-10ms

When the recursive resolver has the answer cached, it responds from memory. This is nearly instant, typically 1-10ms depending on network distance to the resolver.

Partial cache hits

The resolver may have the TLD referral cached but not the final answer. This eliminates the root server query and requires only 1-2 round trips, cutting resolution time roughly in half.

This is why TTL and caching matter so much. The difference between a cached and uncached lookup is an order of magnitude in latency.

CNAME Chains and Additional Lookups

When a DNS record is a CNAME, the resolver must perform additional lookups to follow the chain. If www.example.com is a CNAME to cdn.provider.com, the resolver needs to also resolve cdn.provider.com to get the final IP.

Long CNAME chains add latency because each link requires its own resolution. A chain of www → cdn.provider.com → edge.provider.com → 93.184.216.34 requires three resolution sequences. This is why DNS best practices recommend keeping CNAME chains short.

When Resolution Fails

Several things can go wrong during DNS resolution.

NXDOMAIN

If the authoritative server has no record for the queried name, it returns NXDOMAIN (Non-Existent Domain). This is cached according to the SOA record's minimum TTL field, which is the negative caching TTL.

SERVFAIL

If the recursive resolver cannot complete the resolution (authoritative servers are unreachable, DNSSEC validation fails, etc.), it returns SERVFAIL. This is a temporary error that usually resolves when the underlying issue is fixed.

Timeout

If no response is received within the timeout period, the resolver tries the next server in its list. If all servers time out, the query fails. Users see this as "DNS_PROBE_FINISHED_NXDOMAIN" or "This site can't be reached" in their browser.

Lame Delegation

If the TLD nameserver refers the resolver to an authoritative server that does not actually serve the zone, this is called lame delegation. The resolver gets an unexpected response and may return SERVFAIL.

Why Understanding Resolution Matters

When you change DNS records, you are changing the answer that the authoritative server gives at step 7 of the resolution chain. But steps 1 through 4 involve caches that still hold the old answer. This is why propagation takes time, and why it takes exactly as long as the TTL of the previously cached record.

When you troubleshoot DNS issues, knowing where in the chain the problem occurs determines the fix. A problem at the registrar level (wrong NS records at the TLD) is different from a problem at the authoritative server (wrong A record in the zone) which is different from a caching problem (stale record at a resolver).

DNS resolution is an elegant system that translates human-readable names into machine-routable addresses in milliseconds. Understanding each step, from browser cache to authoritative response, gives you the knowledge to manage DNS confidently, diagnose issues quickly, and plan changes that propagate predictably.

Keep your DNS resolution healthy

DNS Monitor watches your authoritative nameservers, tracks record changes, and checks resolution from multiple global locations. Catch problems before they affect your users.

How DNS Resolution Works (Step by Step)