Resolution Process

When you click a link or type a URL, you initiate a sophisticated orchestration involving your operating system, local caches, remote resolvers, and potentially dozens of authoritative servers. This entire process typically completes in under 100 milliseconds—often under 10 milliseconds—yet involves multiple layers of caching, protocol exchanges, and fallback mechanisms.

In this page, we synthesize our understanding of recursive and iterative resolution into a complete end-to-end picture of the DNS resolution process. We'll trace every step from user action to IP address delivery, examining what happens at each layer and how optimizations make the system remarkably fast.

DNS resolution involves multiple layers, each with its own caching and processing logic. Understanding this stack is essential for efficient troubleshooting and optimization.

The Resolution Layer Stack:

Cache Hierarchy Behavior:

Queries flow downward through this stack until a cache hit occurs. Responses flow upward, populating each cache along the way:

┌─────────────────────────────────────────────────────────────────┐
│  User clicks: https://www.example.com/page                      │
└───────────────────────────┬─────────────────────────────────────┘
                            ▼
┌─────────────────────────────────────────────────────────────────┐
│  Browser Cache: Is www.example.com cached?                      │
│    ├─ HIT → Return immediately (0ms)                            │
│    └─ MISS → Query OS resolver                                  │
└───────────────────────────┬─────────────────────────────────────┘
                            ▼
┌─────────────────────────────────────────────────────────────────┐
│  OS Cache: Is www.example.com in system cache?                  │
│    ├─ HIT → Return to browser (<1ms)                            │
│    └─ MISS → Query configured DNS server                        │
└───────────────────────────┬─────────────────────────────────────┘
                            ▼
┌─────────────────────────────────────────────────────────────────┐
│  Recursive Resolver: Is www.example.com cached?                 │
│    ├─ HIT → Return to client (1-20ms network)                   │
│    └─ MISS → Begin iterative resolution (50-200ms)              │
└─────────────────────────────────────────────────────────────────┘

Let's trace a complete DNS query for www.example.com assuming all caches are empty—the worst-case (but most instructive) scenario.

Phase 1: Application Request

The user types www.example.com in the browser address bar and presses Enter:

1. Browser parses the URL, extracts hostname www.example.com
2. Browser checks its internal DNS cache (chrome://net-internals/#dns in Chrome)
3. Cache miss: Browser issues a system call to resolve the name

Phase 2: Stub Resolver Processing

The operating system's stub resolver handles the application's request:

1. Check /etc/hosts (or Windows hosts file) for static mappings
2. Check the system DNS cache (systemd-resolved, nscd, or Windows DNS Client)
3. Cache miss: Prepare DNS query packet

DNS Query Packet Contents:

Header:
  ID: 0x4A2F (random 16-bit identifier for matching responses)
  Flags: QR=0 (query), RD=1 (recursion desired), OPCODE=0 (standard query)
  Questions: 1
  Answers: 0, Authority: 0, Additional: 0

Question Section:
  QNAME: www.example.com
  QTYPE: A (or AAAA for IPv6)
  QCLASS: IN (Internet)

4. Look up configured DNS server (from DHCP, static config, or systemd-resolved)
5. Send UDP datagram to configured resolver (usually port 53)

Phase 3: Recursive Resolver Processing

The recursive resolver receives the query and processes it:

1. Parse query, validate format, extract QNAME
2. Check cache for exact match www.example.com A
3. Check cache for cached NS records that shortcut resolution:
   • Do we have NS records for example.com? → Skip to authoritative
   • Do we have NS records for .com? → Skip root
   • Neither? → Start from root hints
4. Begin iteration through DNS hierarchy
5. Cache all responses with their TTLs
6. Return final answer to stub resolver

Phase 4: Response Delivery

The answer propagates back up the stack:

1. Recursive resolver sends UDP response to stub resolver
2. Stub resolver populates OS cache
3. gethostbyname() returns to application
4. Browser caches the result
5. Browser initiates TCP connection to the IP address

Understanding DNS timing is crucial for performance optimization. Let's break down where time is spent:

Component Timing Breakdown:

Timing Distribution in Practice:

A study of production DNS traffic typically shows:

• ~70% of queries: Answered from resolver cache in <20ms
• ~20% of queries: Partial cache hit (some NS cached), 20-100ms
• ~10% of queries: Complete cache miss, 100-300ms

Factors Affecting Resolution Time:

The DNS ecosystem has evolved numerous optimizations to minimize resolution latency:

1. DNS Prefetching

Browsers predict which hostnames will be needed and resolve them in advance:

Browser prefetching behaviors:

• Parse page HTML for links to other origins
• Resolve those hostnames before user clicks
• User hovers over a link? Prefetch that domain
• Maintains a pool of pre-resolved hostnames

2. Resolver Cache Prefetching

Advanced recursive resolvers refresh cache entries before expiration:

Original TTL: 3600 seconds (1 hour)
Cache entry age: 3000 seconds (83% of TTL)
Action: Background refresh query to authoritative
Result: Cache always hot for popular domains

3. Happy Eyeballs (RFC 8305)

When both A (IPv4) and AAAA (IPv6) records exist:

1. Query both A and AAAA simultaneously
2. Start connecting to both address families
3. Prefer IPv6 but fall back to IPv4 quickly if IPv6 is slow
4. Typical delay: 250ms before IPv4 fallback

4. Anycast Deployment

Major DNS infrastructure uses BGP anycast to minimize latency:

• Same IP address advertised from multiple global locations
• Network routing automatically directs queries to nearest instance
• Root servers: 13 identifiers, 1000+ actual instances worldwide
• Public resolvers (8.8.8.8, 1.1.1.1): Present in major IXPs globally

5. EDNS Client Subnet (ECS)

For CDN optimization, resolvers can pass partial client IP to authoritative servers:

Client IP: 192.168.1.100 (private, behind NAT)
Resolver sends: EDNS0 Client Subnet: 203.0.113.0/24 (public prefix)
Authoritative server: Returns IP of nearest CDN edge
Result: Better content delivery performance

DNS resolution can fail in various ways. Understanding failure modes helps with troubleshooting and designing resilient systems.

Failure Categories:

SERVFAIL Deep Dive:

SERVFAIL is the most common and frustrating failure because it indicates something went wrong but not what. Common causes:

1. All authoritative servers unreachable: Network issues, DDoS attack, misconfiguration
2. DNSSEC validation failure: Signature expired, key mismatch, missing RRSIG
3. Lame delegation: NS records point to servers not configured for the zone
4. Timeout cascade: All servers responded too slowly
5. Malformed responses: Authoritative server returning invalid data

Several special cases in DNS resolution require additional handling:

1. CNAME Chain Resolution

When an A query returns a CNAME, the resolver must continue resolving:

Query: www.example.com A

Step 1: www.example.com CNAME webserver.example.com
        (No A record at this name, follow CNAME)

Step 2: webserver.example.com CNAME lb.cdn.net
        (Another CNAME, continue following)

Step 3: lb.cdn.net A 203.0.113.100
        (Final answer)

Resolvers have CNAME chain limits (typically 8-16) to prevent infinite loops from misconfigurations like:

a.example.com CNAME b.example.com
b.example.com CNAME a.example.com  ← Infinite loop!

2. MX Resolution and Additional Records

MX (Mail Exchange) resolution involves additional steps:

Query: example.com MX

Response:
  Answer: example.com MX 10 mail.example.com
          example.com MX 20 backup.example.com
  Additional: mail.example.com A 192.0.2.10
              backup.example.com A 192.0.2.20

Authoritative servers often include A records for MX targets in the Additional section to save a round trip. Resolvers use these but verify them if needed.

3. Split-Horizon DNS

Organizations may return different results based on query source:

Implemented via:

• View-based configuration in BIND
• Separate internal/external DNS servers
• Resolver policies based on client subnet

4. Load Balancing via DNS

DNS can distribute traffic across servers:

Let's examine practical tools and techniques for analyzing DNS resolution:

Using dig for Complete Analysis:

Browser Developer Tools:

Chrome and Firefox expose DNS timing in developer tools:

1. Network panel: Each request shows DNS timing in waterfall
2. Performance panel: DNS resolution appears in timing breakdown
3. chrome://net-internals/#dns: Shows Chrome's DNS cache contents
4. about:networking#dns: Firefox's DNS cache viewer

Wireshark DNS Analysis:

Capturing DNS traffic reveals packet-level details:

Capture filter: port 53
Display filter: dns

Useful columns:
- Time (for latency analysis)
- Source/Destination (query direction)
- Info (query type and domain)
- dns.flags.response (distinguish query from response)
- dns.qry.name (domain being queried)
- dns.resp.ttl (TTL values in responses)