DNS Caching Levels: The Complete Cache Hierarchy

DNS caching is not implemented at a single location—it's distributed across multiple levels of the resolution path, creating a layered defense against unnecessary upstream queries. Each layer serves distinct populations, operates under different constraints, and contributes uniquely to overall caching efficiency.

Understanding these caching levels is essential for:

• Debugging resolution issues — Knowing which cache might hold stale data helps isolate problems
• Change propagation planning — Understanding cache populations helps predict propagation timing
• Performance optimization — Leveraging appropriate cache layers improves user experience
• Security analysis — Cache behavior affects vulnerability to cache poisoning attacks

This page explores each caching level in depth, from the browser's internal cache to enterprise DNS infrastructure, examining their behavior, configuration options, and operational characteristics.

When an application needs to resolve a domain name, the query traverses a series of potential caches before reaching authoritative servers. At each level, a cache hit can immediately satisfy the request; only cache misses propagate to the next level.

The Cache Hierarchy (Client to Server):

1. Application/Browser Cache — Most immediate; highest locality, smallest scope
2. Operating System/Stub Resolver Cache — System-wide; serves all applications
3. Local Network Resolver — Home router or enterprise DNS; serves local network
4. Recursive Resolver (ISP/Public) — Large-scale; serves millions of clients
5. Authoritative Server — Source of truth; no caching (responds authoritatively)

Each layer exhibits different characteristics in terms of scope, population, cache capacity, and administrative control.

Modern web browsers maintain their own internal DNS cache, independent of the operating system's resolver cache. This application-level cache provides the fastest possible dns resolution for recently visited domains.

Why Browsers Implement DNS Caching:

1. Eliminating syscall overhead — Each OS resolver query requires system calls; avoiding them improves performance
2. Predictable behavior — Browser has direct control over cache policy and behavior
3. Connection optimization — Browser can pre-resolve domains while parsing HTML
4. Privacy features — Some browsers isolate DNS cache per-origin or per-session

Browser-Specific Caching Behavior:

Viewing and Flushing Browser DNS Cache:

Chrome / Edge (Chromium-based):

1. Navigate to chrome://net-internals/#dns
2. View "Host resolver cache" section showing cached entries
3. Click "Clear host cache" to flush

Firefox:

1. Navigate to about:networking#dns
2. View DNS cache entries with TTL remaining
3. Use about:config → network.dnsCacheExpiration to adjust behavior

Browser DNS Prefetching:

Browsers proactively resolve domains before they're needed, hiding DNS latency during user think-time:

<!-- Explicit prefetch hints -->
<link rel="dns-prefetch" href="//cdn.example.com">
<link rel="dns-prefetch" href="//api.example.com">

<!-- Browsers also auto-prefetch hrefs in <a> tags -->
<a href="https://other-site.com">Link</a>  <!-- domain pre-resolved -->

Prefetching trades bandwidth (speculative DNS queries) for latency reduction. High-traffic sites typically prefetch CDN, API, and analytics domains.

The operating system's DNS resolver—often called the stub resolver—provides system-wide DNS caching for all applications. When applications call standard resolver functions (e.g., getaddrinfo(), gethostbyname()), the OS stub resolver handles the request, checking its cache before forwarding to configured nameservers.

Windows DNS Client Service:

Windows implements DNS caching through the "DNS Client" service (dnscache). This service:

• Caches positive and negative responses
• Respects DNS TTL values
• Implements DNS query optimization
• Provides the ipconfig /displaydns and ipconfig /flushdns commands

macOS DNS Caching:

macOS uses mDNSResponder for DNS resolution and caching. Cache management:

# View DNS cache (macOS 10.12+)
sudo dscacheutil -cachedump -entries Host

# Flush DNS cache
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

Linux DNS Caching:

Linux DNS caching depends on the resolver configuration:

1. systemd-resolved (Modern distributions):

   # View cache statistics
   resolvectl statistics
   
   # Flush DNS cache
   resolvectl flush-caches
   

2. dnsmasq (Often used on routers/embedded):

   # Flush by restarting service
   sudo systemctl restart dnsmasq
   

3. nscd (Name Service Cache Daemon):

   # Flush hosts cache
   sudo nscd -i hosts
   

4. No local caching — Some configurations forward directly to upstream; applications query upstream on every request.

Most local networks—home networks, small offices, Wi-Fi hotspots—include a local DNS resolver that serves all devices on the network. This is typically the router itself, which provides DHCP-assigned addresses with itself as the DNS server.

How Local Resolvers Work:

1. Devices receive router's IP as DNS server via DHCP
2. All DNS queries from local devices go to the router
3. Router checks its local cache; returns cached responses immediately
4. Cache misses forward to upstream resolver (ISP or public DNS)
5. Responses cached locally for all network devices to share

Benefits of Local Network Caching:

Home Router DNS Caching:

Consumer routers typically run lightweight DNS resolvers with modest cache sizes:

dnsmasq Configuration Example:

# /etc/dnsmasq.conf on router

# Set cache size (default is usually 150)
cache-size=1000

# Don't cache negative responses
no-negcache

# Log queries (for debugging)
log-queries

# Forward to specific upstream
server=8.8.8.8
server=1.1.1.1

Pi-hole and Local DNS Solutions:

Advanced users often deploy dedicated local DNS solutions:

• Pi-hole: DNS-level ad blocking plus caching; shows query statistics
• AdGuard Home: Similar ad-blocking with DoH/DoT support
• Unbound: Full recursive resolver with aggressive caching
• pfSense/OPNsense: Firewall appliances with integrated DNS

ISP recursive resolvers serve the largest populations—potentially millions of subscribers—making them the most impactful caching layer. A single cache hit at an ISP resolver can serve countless subsequent queries from all subscribers.

ISP Resolver Characteristics:

ISP Resolver Operations:

ISP resolvers implement sophisticated infrastructure for performance and reliability:

1. Geographic distribution — Anycast routes queries to nearest resolver cluster
2. Load balancing — Query distribution across multiple servers
3. Hierarchical architecture — Front-end caches, back-end recursive resolvers
4. Aggressive caching — May enforce minimum TTL floors for efficiency
5. DNSSEC validation — Validates signed records (increasingly common)

Public DNS Services:

Public DNS resolvers provide alternatives to ISP-provided DNS, often with privacy or performance benefits:

Why Cache Hit Rates Are Highest at This Level:

The power-law distribution of DNS queries explains high cache hit rates:

• ~1% of domains account for ~50% of queries (google.com, facebook.com, etc.)
• ~10% of domains account for ~90% of queries
• The remaining 90% of domains generate only 10% of queries

With millions of subscribers, even moderately popular domains get resolved frequently enough to remain cached. The top 10,000 domains are almost always cached at major ISP resolvers.

ISP Resolver Policies:

ISPs may implement policies affecting cache behavior:

• Minimum TTL floors — Refusing to honor very low TTLs (e.g., enforcing 30s minimum)
• NXDOMAIN rewriting — Redirecting non-existent domains to landing pages
• Query logging — Recording queries for various purposes
• Geo-steering impact — Affecting CDN server selection based on resolver location

Enterprise networks implement sophisticated DNS infrastructure that serves internal resources and external resolution, with caching as a critical component. Enterprise DNS differs from consumer DNS in several ways:

Enterprise DNS Functions:

1. Internal zone hosting — Resolving server.corp.example.com to internal IPs
2. Split-horizon DNS — Different responses for internal vs. external queries
3. Policy enforcement — Blocking categories of domains (compliance, security)
4. Integration with directory services — Active Directory DNS integration
5. External resolution caching — Caching public DNS for employee Internet access

Windows Active Directory DNS:

Microsoft environments typically use AD-integrated DNS:

# View DNS server cache statistics
Get-DnsServerStatistics -ComputerName dc01.corp.example.com

# Clear DNS server cache
Clear-DnsServerCache -ComputerName dc01.corp.example.com

# View cached records
Show-DnsServerCache -ComputerName dc01.corp.example.com

Enterprise DNS Architecture Patterns:

Enterprise DNS Security Layers:

Enterprises often add security layers to DNS:

• Infoblox, BlueCat, Efficient IP — Enterprise DNS management platforms
• Cisco Umbrella (OpenDNS) — Cloud security with DNS filtering
• Zscaler — Cloud security with DNS inspection
• DNS firewalling — Blocking queries to known malicious domains
• DNS logging and analytics — SIEM integration for threat detection

Understanding how cache levels interact helps troubleshoot resolution issues and predict propagation behavior. Several edge cases and interactions warrant special attention.

Cache Consistency Issues:

Different cache layers may hold different versions of records after a DNS change:

Scenario: DNS Change Propagation

1. Administrator changes A record from 1.2.3.4 → 5.6.7.8 (TTL=300)
2. User A's browser cache: Still has 1.2.3.4 (cached 2 mins ago, 3 mins remaining)
3. User A's OS cache: Same as browser (shared resolution)
4. Office router: Still has 1.2.3.4 (cached 4 mins ago, 1 min remaining)
5. ISP resolver: Already has 5.6.7.8 (queried after the change)

Result: User A continues reaching old IP even though ISP has new IP, because their local caches haven't expired.

Troubleshooting Cache Layer Issues:

When debugging DNS resolution problems, systematically check each cache level:

# Step 1: Check authoritative (ground truth)
dig @ns1.example.com www.example.com A

# Step 2: Check ISP/public resolver
dig @8.8.8.8 www.example.com A
dig @1.1.1.1 www.example.com A

# Step 3: Check local resolver
dig @192.168.1.1 www.example.com A

# Step 4: Check OS resolution
# Windows:
nslookup www.example.com
# Linux/macOS:
host www.example.com
getent hosts www.example.com

# Step 5: Check browser (manual - view cache page)

If results differ between levels:

• Higher levels showing old data → Lower levels need to expire and refresh
• Lower levels showing old data → Flush specific caches
• Intermittent results → May have multiple upstream resolvers with different cache state