DNS Cache Management: Operational Excellence

Effective DNS cache management is the operational discipline that ensures DNS caching achieves its intended benefits—reduced latency, lower query volumes, and improved resilience—while minimizing the drawbacks of stale data, security vulnerabilities, and resource exhaustion.

DNS cache management encompasses:

• Cache sizing and capacity planning — Ensuring caches have adequate capacity for workload
• TTL policy decisions — Balancing freshness against efficiency for different record types
• Cache flushing and invalidation — Clearing stale or incorrect data when needed
• Monitoring and observability — Understanding cache health and performance
• Change management integration — Coordinating DNS changes with cache behavior
• Troubleshooting procedures — Diagnosing and resolving cache-related issues

This page covers the operational practices that network administrators use to manage DNS caches across enterprise, ISP, and service provider environments.

DNS cache capacity directly impacts performance and hit rates. Undersized caches evict entries prematurely, reducing hit rates and increasing upstream query load. Oversized caches waste memory with minimal marginal benefit.

Cache Size Determinants:

1. Client population — More clients generate more unique queries requiring cache entries
2. Query diversity — Organizations accessing many unique domains need larger caches
3. TTL distribution — Lower average TTLs mean entries expire faster, affecting working set size
4. Peak query rate — High query rates during business hours drive cache requirements
5. Memory availability — Physical memory constraints limit practical cache size

Sizing Guidelines:

BIND Cache Configuration:

# named.conf options for cache management
options {
    # Maximum cache size (memory limit)
    max-cache-size 256M;   # Limit cache to 256 MB
    
    # Alternative: percentage of physical memory
    max-cache-size 50%;    # Use up to 50% of system memory
    
    # Maximum cache TTL (cap very high TTLs)
    max-cache-ttl 86400;   # 24 hours maximum
    
    # Maximum negative cache TTL
    max-ncache-ttl 3600;   # 1 hour for NXDOMAIN caching
    
    # Minimum cache TTL (floor for very low TTLs)
    min-cache-ttl 60;      # Don't cache less than 60 seconds
};

Unbound Cache Configuration:

# unbound.conf cache settings
server:
    # Cache memory size
    msg-cache-size: 128m
    rrset-cache-size: 256m
    
    # Number of cache slabs (performance tuning)
    msg-cache-slabs: 4
    rrset-cache-slabs: 4
    
    # Cache TTL limits
    cache-min-ttl: 60
    cache-max-ttl: 86400
    cache-max-negative-ttl: 3600
    
    # Prefetch expiring entries
    prefetch: yes
    prefetch-key: yes

Organizations should develop explicit TTL policies rather than accepting default values. Well-designed TTL policies balance operational needs (failover speed, change agility) against infrastructure efficiency (cache hit rates, upstream load).

TTL Policy Framework:

Documenting TTL Policies:

Enterprise DNS documentation should include:

1. Standard TTL values by record type
2. Exceptions process for non-standard TTL requests
3. Pre-change procedures (TTL lowering before changes)
4. Post-change procedures (TTL restoration after verification)
5. Emergency procedures for rapid changes

Example Zone File with Policy-Driven TTLs:

$TTL 3600                           ; Default 1-hour TTL for most records

; SOA with 5-minute negative cache TTL
@       IN SOA  ns1.example.com. admin.example.com. (
                2024011701 7200 3600 1209600 300 )

; NS records: 24-hour TTL (stable infrastructure)
@       86400   IN NS   ns1.example.com.
@       86400   IN NS   ns2.example.com.

; MX records: 1-hour TTL (default)
@               IN MX   10 mail1.example.com.
@               IN MX   20 mail2.example.com.

; Primary website: 1-hour TTL (default)
www             IN A    93.184.216.34

; API with active health checks: 2-minute TTL
api     120     IN A    10.0.1.100
api     120     IN A    10.0.1.101

; CDN edge: 1-minute TTL (geographic steering)
cdn     60      IN CNAME example.com.cdn.cloudflare.net.

Cache flushing removes entries from DNS caches before TTL expiry. Flushing is required when:

• DNS records change and immediate propagation is needed
• Poisoned or incorrect entries must be cleared
• Troubleshooting requires fresh resolution
• Testing requires predictable cache state

Flushing Scope Considerations:

Platform-Specific Flushing Commands:

Flushing Public Resolvers:

Public DNS providers don't allow external cache flushing, but some offer cache status checking:

Google Public DNS:

• Visit: https://dns.google/cache
• Enter domain to view cached records
• No direct flush capability; wait for TTL

Cloudflare DNS:

• Visit: https://1.1.1.1/purge-cache/
• Enter domain to request cache purge
• May take a few minutes to propagate

Automated Flushing Scripts:

#!/bin/bash
# Flush DNS across infrastructure after change

DOMAIN="$1"

if [ -z "$DOMAIN" ]; then
    echo "Usage: $0 <domain>"
    exit 1
fi

echo "Flushing DNS caches for: $DOMAIN"

# Flush internal resolvers (BIND servers)
for server in dns1.corp.example.com dns2.corp.example.com; do
    echo "Flushing $server..."
    ssh $server "rndc flushtree $DOMAIN" 2>/dev/null || echo "  Failed: $server"
done

# Notify team
echo "Cache flush complete. TTL-based propagation continues."
echo "Verify: dig @8.8.8.8 $DOMAIN"

Effective cache management requires visibility into cache behavior. Monitoring DNS cache metrics enables capacity planning, performance optimization, and anomaly detection.

Key Metrics to Monitor:

Extracting BIND Statistics:

# Generate statistics dump
rndc stats

# Parse cache statistics from named.stats
grep -A5 'Cache Statistics' /var/named/data/named.stats

# Sample output:
# ++ Cache Statistics ++
#     cache hits = 1523847
#     cache misses = 234521
#     cache hit rate 86.67%
#     CacheSize 45123

# Enable query logging (verbose, use sparingly)
rndc querylog on

Extracting Unbound Statistics:

# Get current statistics
unbound-control stats

# Key metrics in output:
# total.num.queries=1284753
# total.num.cachehits=1089428
# total.num.cachemiss=195325
# total.num.recursivereplies=195325
# mem.cache.rrset=98745632
# msg.cache.count=45231

# Calculate hit rate:
# hit_rate = cachehits / queries = 1089428/1284753 = 84.8%

Integration with Monitoring Systems:

Modern DNS servers export metrics in formats compatible with monitoring systems:

• Prometheus — BIND exporter, Unbound exporter available
• Grafana — Dashboard templates for DNS metrics
• Datadog/New Relic — DNS integration plugins
• SNMP — Traditional monitoring via SNMP MIBs

DNS changes must account for cache behavior. Poor change management leads to extended outages as stale caches direct traffic incorrectly. Integrating DNS cache considerations into change management prevents these issues.

DNS Change Lifecycle:

Change Management Checklist:

Pre-Change (48-72 hours before):

• Document current DNS records (dig/nslookup output)
• Note current TTL values for all affected records
• Calculate maximum current cache duration (current TTL)
• Lower TTL to desired change-time value (e.g., 300 seconds)
• Verify TTL change has propagated (check from multiple resolvers)
• Schedule change after previous TTL has fully expired

During Change:

• Execute DNS record modifications
• Verify changes on authoritative servers immediately
• Check propagation from multiple geographic locations
• Monitor application health dashboards
• Document any anomalies for post-mortem

Post-Change (after verification):

• Continue monitoring for TTL duration after change
• Restore higher TTL values once stable (if desired)
• Document actual propagation timeline
• Update runbook with lessons learned

Rollback Considerations:

If a DNS change causes problems:

1. Immediate rollback — Restore previous records; new low TTL ensures fast propagation
2. Cache flush internal — Flush internal resolver caches to accelerate internal recovery
3. External caches — Cannot flush; must wait for TTL expiry at ISP resolvers
4. Communication — Notify affected users that recovery depends on external cache expiry

Beyond basic configuration, advanced techniques can further optimize DNS cache performance for demanding environments.

Prefetching (Cache Warming):

Prefetching proactively refreshes cache entries before they expire, eliminating the latency spike that occurs when a popular entry expires and must be re-resolved:

# Unbound prefetch configuration
server:
    # Enable prefetching of expiring entries
    prefetch: yes
    
    # When TTL is x% expired, prefetch
    # (default is when 10% of TTL remains)
    prefetch-key: yes

How Prefetching Works:

1. Entry cached with TTL=3600 seconds
2. At T=3240 (90% of TTL elapsed, 10% remaining)
3. Next query for that entry triggers background refresh
4. Client gets immediate cached response
5. Cache entry updated with fresh data before expiry

Serve-Stale (RFC 8767):

Serve-stale allows resolvers to return expired cache entries when authoritative servers are unreachable, improving availability:

# BIND serve-stale configuration
options {
    stale-answer-enable yes;
    stale-answer-ttl 30;           # Return stale with 30s TTL
    max-stale-ttl 86400;           # Serve stale up to 24 hours old
    stale-answer-client-timeout 1800;  # Wait 1.8s before serving stale
    stale-refresh-time 30;         # Retry authoritative every 30s
};

Cache Partitioning for Security:

Enterprise environments may benefit from separate caches for different purposes:

Separation prevents cache poisoning in one zone from affecting others and allows zone-specific policies (e.g., IoT resolver might have stricter filtering).

Performance Tuning:

# Unbound performance tuning for high-volume resolver
server:
    # Thread and socket settings
    num-threads: 4                 # Match CPU cores
    so-reuseport: yes              # Better multi-thread performance
    
    # Buffer sizes
    so-rcvbuf: 4m
    so-sndbuf: 4m
    
    # Cache slab count (power of 2, >= num-threads)
    msg-cache-slabs: 4
    rrset-cache-slabs: 4
    infra-cache-slabs: 4
    key-cache-slabs: 4
    
    # Outgoing query optimization
    outgoing-range: 8192           # Concurrent outgoing queries
    num-queries-per-thread: 4096

DNS cache issues manifest as resolution failures, stale data, or inconsistent behavior. Systematic troubleshooting isolates problems to specific cache layers.

Common Cache-Related Problems:

Systematic Troubleshooting Workflow:

# Step 1: Verify authoritative response (ground truth)
dig @ns1.example.com problematic.example.com A +short

# Step 2: Check each cache layer
# ISP/Public resolver
dig @8.8.8.8 problematic.example.com A +short
dig @1.1.1.1 problematic.example.com A +short

# Internal resolver (replace with your resolver IP)
dig @192.168.1.1 problematic.example.com A +short

# Local OS resolution
nslookup problematic.example.com

# Step 3: Compare TTL values at each layer
dig @ns1.example.com problematic.example.com A +noall +answer
dig @8.8.8.8 problematic.example.com A +noall +answer
# Authoritative shows original TTL; caches show remaining TTL

# Step 4: If stale, identify which layer is stale
# The layer with incorrect data AND high remaining TTL is the culprit

# Step 5: Flush specific layer if needed
# (Use appropriate flush command for identified layer)

The 'Negative Cache' Trap:

A common issue: creating a new subdomain that was previously queried. If new.example.com was queried before the record existed, resolvers cache NXDOMAIN. After creating the record, resolvers continue returning NXDOMAIN until negative cache expires.

Diagnosis:

# Query with +nsid to see if response is from cache
dig @8.8.8.8 new.example.com A

# If NXDOMAIN returned, check authoritative
dig @ns1.example.com new.example.com A

# If authoritative has the record but public doesn't → negative cache
# Solution: wait for SOA MINIMUM TTL to expire