You type www.example.com in your browser. Half a second later, you’re looking at a website. In that brief moment, a remarkable chain of events unfolds — potentially involving servers on three continents and a system designed 40 years ago.
Let’s trace exactly what happens.
The Three Actors
Every DNS resolution involves three types of participants:
1. Stub Resolver
The stub resolver lives on your device — your laptop, phone, or server. It’s called a “stub” because it’s minimal: it can formulate queries and parse responses, but it doesn’t do any heavy lifting.
When an application needs to resolve a domain name, it calls a system function (like getaddrinfo() on Unix or gethostbyname() on older systems). The stub resolver takes over:
- Check local caches (browser, OS)
- If no cached answer, send a query to a configured recursive resolver
- Wait for an answer
- Return the result to the application
The stub resolver doesn’t query authoritative servers directly. It delegates that work.
2. Recursive Resolver
The recursive resolver (also called a “caching resolver” or just “resolver”) does the heavy lifting. It’s typically operated by your ISP, your organization, or a public DNS provider like Google (8.8.8.8) or Cloudflare (1.1.1.1).
When the recursive resolver receives a query from a stub resolver:
- Check its cache — if the answer is cached and still valid (TTL hasn’t expired), return it immediately
- If not cached, begin the recursive resolution process (more on this below)
- Cache the result for future queries
- Return the answer to the stub resolver
Recursive resolvers do a lot of work so your stub resolver doesn’t have to. One recursive resolver might serve thousands or millions of stub resolvers.
3. Authoritative Server
Authoritative servers are the source of truth for zone data. They don’t do recursive lookups — they simply answer questions about the zones they’re authoritative for.
When asked about www.example.com, an authoritative server for example.com will either:
- Return the answer (if
www.example.comexists in its zone) - Return a referral (if part of the name is delegated to another zone)
- Return NXDOMAIN (if the name doesn’t exist in its zone)
The authoritative server sets the AA (Authoritative Answer) flag in responses to indicate “this answer comes from the source of truth.”
The Full Query Walkthrough
Let’s trace a complete query for www.example.com, assuming cold caches everywhere.
Step 1: Application Makes a Request
Your browser wants to load https://www.example.com. Before it can establish a TCP connection, it needs an IP address. The browser calls the operating system’s resolver library.
Step 2: Browser Cache Check
Modern browsers maintain their own DNS cache. Chrome, Firefox, Safari — they all cache DNS results independently of the OS. If www.example.com is cached and the TTL hasn’t expired, the browser uses the cached IP immediately.
Cache miss. Move on.
Step 3: Operating System Cache Check
The OS maintains a system-wide DNS cache. On Linux, this might be systemd-resolved or nscd. On Windows, it’s the DNS Client service. On macOS, it’s mDNSResponder.
If the OS cache has a valid entry, it returns the IP to the browser without any network activity.
Cache miss. Move on.
Step 4: The hosts File
Before contacting any DNS server, most operating systems check the local hosts file:
- Unix/Linux/macOS:
/etc/hosts - Windows:
C:\Windows\System32\drivers\etc\hosts
The hosts file can override DNS:
# /etc/hosts
127.0.0.1 localhost
192.168.1.100 my-local-dev.test
93.184.216.34 www.example.com # Would override DNS!
Modern uses of the hosts file:
- Local development (mapping domains to
127.0.0.1) - Ad blocking (pointing ad domains to
0.0.0.0) - Testing (overriding production domains during QA)
- Breaking circular dependencies during migrations
No hosts file entry. Move on.
Step 5: Stub Resolver Queries Recursive Resolver
The stub resolver constructs a DNS query packet and sends it to the configured recursive resolver. This configuration comes from:
- DHCP (most home networks)
- Manual configuration
/etc/resolv.confon Unix systems- Network adapter settings on Windows
The query says: “What is the A record for www.example.com?” (Or AAAA for IPv6.)
Step 6: Recursive Resolver Cache Check
The recursive resolver checks its cache. Unlike local caches that might hold hundreds of entries, a busy recursive resolver might cache millions of records.
If the answer is cached and TTL-valid, return immediately. Done.
Cache miss. Time to recurse.
Step 7: Query the Root Servers
The recursive resolver starts at the top of the DNS tree: the root. It picks one of the 13 root server identities (a.root-servers.net through m.root-servers.net) and sends a query.
Query: “What is the A record for www.example.com?”
Root server response: “I don’t know, but here are the nameservers for .com:”
com. 172800 IN NS a.gtld-servers.net.
com. 172800 IN NS b.gtld-servers.net.
; ... plus additional glue records
a.gtld-servers.net. 172800 IN A 192.5.6.30
This is a referral — the root server doesn’t have the answer, but it knows who might. The recursive resolver caches this information (for 172800 seconds = 48 hours).
Step 8: Query the TLD Servers
The recursive resolver queries one of the .com TLD nameservers.
Query: “What is the A record for www.example.com?”
TLD server response: “I don’t know, but here are the nameservers for example.com:”
example.com. 172800 IN NS a.iana-servers.net.
example.com. 172800 IN NS b.iana-servers.net.
Another referral. The resolver caches this and continues.
Step 9: Query the Authoritative Server
Finally, the recursive resolver queries the authoritative nameserver for example.com.
Query: “What is the A record for www.example.com?”
Authoritative response:
www.example.com. 300 IN A 93.184.216.34
This response has the AA flag set — it’s authoritative. The record has a TTL of 300 seconds (5 minutes).
Step 10: Response Propagation
The recursive resolver:
- Caches the answer (with the 300-second TTL)
- Returns the answer to the stub resolver
The stub resolver:
- Returns the answer to the application
- The OS might cache it
The browser:
- Caches the answer
- Opens a TCP connection to 93.184.216.34
Total queries made: 3 (root → TLD → authoritative)
Time elapsed: Typically 20-100ms for a cold cache resolution, depending on network latency to each server.
Recursive vs Iterative Queries
There are two modes of DNS querying, defined in RFC 1034 §4.3.1 and §4.3.2:
Recursive Query (RD flag set)
When a client sets the RD (Recursion Desired) flag, it’s asking the server: “Please give me the final answer. Do whatever you need to do.”
Stub resolvers almost always set RD=1. They’re saying: “I can’t do recursion myself. Please handle it.”
If the server can and will do recursion (indicated by RA = Recursion Available in responses), it will chase down the answer before responding.
Iterative Query (RD flag not set)
When RD is not set, the query is iterative. The server responds with either:
- The answer (if it’s authoritative or has it cached)
- A referral (pointing to other servers that might know)
The client is then responsible for following the referrals.
Recursive resolvers use iterative queries when talking to authoritative servers. They don’t ask the root server to recursively resolve the whole thing — that would defeat the distributed design. Instead, they follow the referral chain themselves.
The Typical Pattern
[Browser] → [Stub Resolver] → (recursive query) → [Recursive Resolver]
↓
(iterative query)
↓
[Root Server] → referral
↓
(iterative query)
↓
[TLD Server] → referral
↓
(iterative query)
↓
[Authoritative Server] → answer
Optimizations in Practice
The walkthrough above assumed cold caches everywhere. In reality, caching dramatically reduces the work:
Root and TLD Caching
Root server addresses are essentially hardcoded (the “hints file”). TLD delegations are cached for 48 hours. So for most queries, the recursive resolver skips straight to step 9 — querying the authoritative server.
Negative Caching
If a domain doesn’t exist (NXDOMAIN), that fact is also cached. The SOA record’s minimum TTL field determines how long. This prevents repeated queries for typos and non-existent domains.
Prefetching
Some resolvers “prefetch” popular records before they expire, ensuring they’re always fresh in cache without clients experiencing latency.
QNAME Minimization
Modern resolvers implement QNAME minimization (RFC 7816): instead of sending the full query (www.example.com) to the root and TLD servers, they send only what’s needed (com?, then example.com?). This improves privacy by not revealing the full query to every server in the chain.
Diagnosing Resolution
The dig command is your friend:
# Trace the full resolution path
dig +trace www.example.com
# Query a specific server
dig @8.8.8.8 www.example.com
# See the full response with all flags
dig +noall +answer +authority +additional www.example.com
Understanding the resolution process is essential for diagnosing DNS issues. When something isn’t resolving, you can now pinpoint where in the chain the problem lies.
Key Takeaways
- Stub resolvers handle queries on your device, delegating to recursive resolvers
- Recursive resolvers do the heavy lifting, caching aggressively
- Authoritative servers are the source of truth for zone data
- Resolution walks down from root → TLD → authoritative (when caches are cold)
- Recursive queries ask for final answers; iterative queries return referrals
- Caching at every layer makes DNS fast — most queries never go past the recursive resolver
- The hosts file still works and has legitimate modern uses
Next, we’ll explore the different types of DNS records — the data that authoritative servers actually serve.