fundamentals

How DNS Resolution Works

The step-by-step journey from domain name to IP address

The 120 milliseconds you never notice

You click a link to www.example.com. Before your browser can fetch a single byte of HTML, it needs an IP address. What follows is a chain of queries that bounces between up to four different types of servers, spanning data centers on multiple continents — and the whole thing finishes in under 120 milliseconds. Usually, much less.

This process is called DNS resolution, and it happens every time you visit a website, send an email, or open an app. Understanding how it works is the key to understanding why the internet feels fast, and what can go wrong when it does not.

The four actors

DNS resolution involves four distinct types of servers, each with a specific role. Think of them as a chain of increasingly specific information desks.

Actor	Role	Example
Stub Resolver	Lightweight client built into your OS; initiates DNS queries	Built into Windows, macOS, Linux
Recursive Resolver	Performs the full lookup on your behalf; caches results	Google Public DNS (`8.8.8.8`), Cloudflare (`1.1.1.1`), your ISP’s resolver
Root Name Server	Directs queries to the correct TLD server	13 logical servers (A–M), ~1,954 physical instances worldwide
TLD Name Server	Directs queries to the authoritative server for a specific domain	Managed by registry operators (e.g., Verisign for `.com`)
Authoritative Name Server	Holds the actual DNS records and returns the final answer	e.g., `ns1.example.com`

The stub resolver is the only one running on your machine. Everything else happens over the network.

Step-by-step: resolving an uncached query

Let us trace the full journey for resolving www.example.com when nothing is cached — the cold-start scenario. In practice, most of these steps are skipped thanks to caching, but understanding the full chain matters.

User's Browser
     |
     | 1. "What is the IP for www.example.com?"
     v
Stub Resolver (OS)
     |
     | 2. Forwards query to configured recursive resolver
     v
Recursive Resolver (e.g., 8.8.8.8)
     |
     | 3. "Where can I find .com?" --> Root Server
     |    Root responds: "Ask the .com TLD servers at 192.5.6.30"
     |
     | 4. "Where can I find example.com?" --> .com TLD Server
     |    TLD responds: "Ask ns1.example.com at 93.184.216.34"
     |
     | 5. "What is the A record for www.example.com?" --> Authoritative Server
     |    Authoritative responds: "93.184.216.34, TTL 86400"
     |
     | 6. Returns answer to stub resolver (caches it)
     v
Stub Resolver (OS)
     |
     | 7. Returns answer to browser (OS caches it)
     v
Browser
     | 8. Connects to 93.184.216.34 (browser caches the DNS result)
     v
Web Server

Let us break down each step.

Step 1–2: Your machine asks for help

When your browser needs to resolve www.example.com, it calls the operating system’s stub resolver — a minimal DNS client that does not perform lookups itself. The stub resolver checks the OS cache, and if it has no cached answer, it forwards the query to the recursive resolver configured in your network settings.

The recursive resolver is typically provided by your ISP, or you may have configured a public resolver like Google (8.8.8.8), Cloudflare (1.1.1.1), Quad9 (9.9.9.9), or OpenDNS (208.67.222.222).

Step 3: The recursive resolver asks the root

The recursive resolver starts at the top of the DNS hierarchy. It sends a query to one of the 13 root name servers: “I need to find www.example.com — where should I look?”

The root server does not know the answer, but it knows who handles .com. It responds with a referral: “Ask the .com TLD servers,” along with the IP addresses of those servers (e.g., a.gtld-servers.net at 192.5.6.30).

Step 4: The TLD server narrows it down

The recursive resolver follows the referral and queries the .com TLD server: “Where can I find example.com?”

The TLD server responds with another referral: “The authoritative name servers for example.com are ns1.example.com and ns2.example.com,” along with their IP addresses.

Step 5: The authoritative server provides the answer

The recursive resolver queries the authoritative name server directly: “What is the A record for www.example.com?”

This time, the server has the actual answer. It returns the IP address — 93.184.216.34 — along with a TTL value (e.g., 86,400 seconds, or 24 hours) that tells the resolver how long it can cache this answer.

Steps 6–8: The answer flows back

The recursive resolver caches the result and returns it to the stub resolver. The OS caches it again. The browser caches it once more and finally initiates a TCP connection to 93.184.216.34.

Each layer of caching means that the next query for the same domain will be faster. After this initial lookup, subsequent requests for www.example.com will resolve in single-digit milliseconds rather than requiring the full chain.

Timing breakdown

Each step in the resolution chain has a measurable cost:

Step	Description	Typical Latency	Notes
Browser to stub resolver	Local IPC call	< 1 ms	In-process or local socket
Stub to recursive resolver	Network round-trip	1–30 ms	Depends on distance to resolver
Recursive to root server	Network round-trip	2–30 ms	Anycast keeps this fast; usually cached
Recursive to TLD server	Network round-trip	5–40 ms	Geographic distance matters
Recursive to authoritative	Network round-trip	5–50 ms	Depends on server location
Return path	Passing results back	< 1 ms each	Cached at each layer
Total (uncached)	Full resolution	20–120 ms	Typical range
Total (cached at resolver)	Cache hit	1–5 ms	Common for popular domains

The industry targets for production applications reflect these ranges:

p50 target: under 50 ms for globally distributed consumer applications
p95 target: under 150 ms
Googlebot observed average: 130 ms for name servers that respond; 300–400 ms when factoring in packet loss and failures

The three query types

Not all DNS queries work the same way. There are three modes of operation:

Recursive queries

The client (typically a stub resolver) asks the recursive resolver to find the complete answer, no matter how many steps it takes. The resolver accepts full responsibility — it will query root servers, TLD servers, and authoritative servers as needed. This is the standard mode for end-user queries.

# A recursive query from your machine (default behavior of dig)
dig www.example.com

;; QUESTION SECTION:
;www.example.com.         IN      A

;; ANSWER SECTION:
www.example.com.  86400   IN      A       93.184.216.34

Iterative queries

The queried server returns the best answer it currently has — which is often a referral to another server rather than the final answer. The querying resolver then follows up with the referred server. This is how the recursive resolver communicates with root, TLD, and authoritative servers.

# Force iterative behavior with +norecurse
dig +norecurse www.example.com @a.root-servers.net

;; AUTHORITY SECTION:
com.              172800  IN      NS      a.gtld-servers.net.
com.              172800  IN      NS      b.gtld-servers.net.

The root server does not try to find the answer itself. It returns a referral to the .com TLD servers and lets the resolver follow up.

Non-recursive queries

The resolver already has the answer cached, or it is querying the authoritative server directly for a record that server owns. No referrals or additional lookups are needed — the response comes back immediately.

Why exactly 13 root servers?

This is one of the most frequently asked questions about DNS, and the answer comes down to packet size math.

The original DNS specification (RFC 1035) limits UDP response packets to 512 bytes. Each root server entry in a response includes a name and an IPv4 address. Fitting 13 root server names and their addresses into a single 512-byte UDP packet was the practical maximum.

Today, EDNS0 (RFC 6891) extends the UDP payload size well beyond 512 bytes, so the technical constraint no longer applies. But the 13-server convention persists for backward compatibility. Changing it would require updating every DNS implementation worldwide.

The important thing to understand is that “13 root servers” does not mean 13 physical machines. Each of the 13 logical root server names (A through M) maps to a cluster of physical servers distributed globally using anycast routing. As of December 2025, the 13 names correspond to approximately 1,954 physical server instances across all six populated continents.

Root server operators

The 13 root servers are operated by 12 independent organizations:

Letter	Operator
A	Verisign
B	USC-ISI
C	Cogent Communications
D	University of Maryland
E	NASA Ames Research Center
F	Internet Systems Consortium (ISC)
G	US DoD Network Information Center
H	US Army Research Lab
I	Netnod (Sweden)
J	Verisign
K	RIPE NCC (Netherlands)
L	ICANN
M	WIDE Project (Japan)

This diversity — spanning government agencies, universities, nonprofits, and private companies across multiple countries — is deliberate. No single organization’s failure or compromise can take down root DNS.

What happens in practice: the role of caching

The full eight-step chain described above is the worst case. In practice, recursive resolvers cache aggressively, and most of the chain is skipped.

A busy recursive resolver like Google Public DNS or Cloudflare serves millions of clients. The odds that someone has already queried for .com’s TLD servers, or for example.com’s authoritative servers, are very high. The resolver likely has these referrals cached, meaning it can skip straight to the authoritative server.

For extremely popular domains (think google.com, facebook.com, amazonaws.com), the final A record itself is almost always cached at the resolver level. These queries resolve in 1–5 ms with no network round-trips beyond the client-to-resolver hop.

This is why caching and TTL are so central to DNS performance. The resolution chain is elegant, but caching is what makes it fast enough for the modern internet.

Edge cases and failure modes

SERVFAIL responses

If an authoritative server is unreachable or returns an error, the recursive resolver returns a SERVFAIL status code to the client. The browser typically retries with a different resolver or shows a “DNS resolution failed” error.

NXDOMAIN responses

If the queried domain does not exist (e.g., you mistyped a URL), the authoritative server returns NXDOMAIN — a definitive “this name does not exist” answer. This negative response is also cached (see negative caching) to avoid repeated lookups for non-existent names.

Truncated responses and TCP fallback

When a DNS response exceeds the UDP payload size (512 bytes without EDNS0, or the negotiated EDNS0 size), the server sets a “truncated” flag. The resolver then retries the query over TCP, which has no practical size limit. This is common for domains with many records or DNSSEC-signed responses.

Timeout and retry behavior

Recursive resolvers typically wait 2–5 seconds for a response before retrying. If all configured authoritative servers for a zone fail to respond, the resolver returns SERVFAIL after exhausting its retries. From the user’s perspective, this manifests as a slow page load followed by an error — typically taking 15–30 seconds.

Seeing it yourself

You can observe DNS resolution in real time using dig with the +trace flag, which mimics the recursive resolver’s behavior step by step:

dig +trace www.example.com

; <<>> DiG 9.18.18-0ubuntu0.22.04.1-Ubuntu <<>> +trace www.example.com
;; global options: +cmd
.                       86400   IN      NS      a.root-servers.net.
.                       86400   IN      NS      b.root-servers.net.
;; Received 239 bytes from 127.0.0.53#53(127.0.0.53) in 0 ms

com.                    172800  IN      NS      a.gtld-servers.net.
com.                    172800  IN      NS      b.gtld-servers.net.
;; Received 1170 bytes from 198.41.0.4#53(a.root-servers.net) in 24 ms

example.com.            172800  IN      NS      a.iana-servers.net.
example.com.            172800  IN      NS      b.iana-servers.net.
;; Received 830 bytes from 192.5.6.30#53(a.gtld-servers.net) in 15 ms

www.example.com.        86400   IN      A       93.184.216.34
;; Received 56 bytes from 199.43.135.53#53(a.iana-servers.net) in 9 ms

Each stanza shows one hop in the chain: root referral, TLD referral, and finally the authoritative answer — with real round-trip times on the right.

Next steps

Now that you understand how DNS resolution works, two natural paths open up. To understand what the resolver is actually fetching — the A records, CNAME records, MX records, and others that make up the DNS database — read DNS Record Types. To understand how the caching system described above works in detail, including TTL mechanics and the multi-layer cache hierarchy, read Caching and TTL.

Related Resources

What Is Dns

Caching And Ttl