DNS Cache

What is DNS Cache?

DNS caching is the temporary storage of DNS query results by resolvers, operating systems, browsers, and applications. When a DNS lookup is performed, the result is cached for a period defined by the record's TTL (Time To Live), allowing subsequent requests for the same domain to be answered instantly without querying authoritative servers.

Why DNS Caching Matters

Without caching, every single web request would require a full DNS lookup—adding latency and generating massive DNS traffic. DNS caching provides:

• Faster Response Times: Cached answers return in microseconds vs milliseconds for full lookups
• Reduced Network Traffic: Fewer queries to authoritative servers
• Improved Resilience: Local cache provides answers even if DNS servers are temporarily unreachable
• Lower Server Load: Authoritative servers handle fewer queries

How DNS Caching Works

The Caching Hierarchy

DNS caching occurs at multiple levels:

Browser Cache (seconds to minutes)
    ↓
OS Cache (seconds to minutes)
    ↓
Local Resolver Cache (minutes to hours)
    ↓
ISP Resolver Cache (minutes to hours)
    ↓
Authoritative Name Server (source of truth)

Cache Lookup Process

1. User requests example.com

2. Browser checks its cache

3. If miss, OS checks its cache

4. If miss, resolver checks its cache

5. If miss, recursive query to authoritative servers

6. Result cached at each level based on TTL

7. Response returned to user

TTL-Based Expiration

Each DNS record includes a TTL value:

example.com.    300    IN    A    203.0.113.50
                ^^^
                TTL in seconds (5 minutes)

Caches store this record for 300 seconds, then discard it. The next query triggers a fresh lookup.

DNS Cache Layers

Browser Cache

Modern browsers cache DNS results independently:

Typical browser cache TTL: 60 seconds (regardless of DNS TTL)

Operating System Cache

# View cache
ipconfig /displaydns

# Flush cache
ipconfig /flushdns

# Flush cache (macOS 10.15+)
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

# Flush systemd-resolved cache
sudo systemd-resolve --flush-caches

# Check statistics
sudo systemd-resolve --statistics

Resolver Cache

Recursive DNS resolvers (ISP DNS, 8.8.8.8, 1.1.1.1) maintain large caches serving millions of users:

Cache Behavior Examples

Normal Operation

Query 1: example.com
→ Full lookup: 50ms
→ Cached for 300s (TTL)

Query 2: example.com (1 minute later)
→ Cache hit: 1ms

Query 3: example.com (10 minutes later)
→ Cache expired, full lookup: 50ms
→ Re-cached for 300s

DNS Record Update

Original: example.com → 203.0.113.50 (TTL: 300s)
Time: 10:00 - DNS updated to 203.0.113.51

Client queries at 10:02
→ Still cached: 203.0.113.50 (expires 10:05)

Client queries at 10:06
→ Cache expired, new lookup: 203.0.113.51
→ Cached until 10:11

TTL Strategy and Caching

Choosing TTL Values

Pre-Migration TTL Reduction

Best practice when planning DNS changes:

Day -7: example.com TTL 3600s (1 hour)
Day -2: Reduce to 300s (5 minutes)
Day 0:  Make DNS change
        → Max 5 minute cache retention
Day +1: Restore TTL to 3600s

Cache Poisoning and Security

DNS Cache Poisoning Attack

Attackers attempt to inject false DNS records into caches:

1. Attacker floods resolver with fake responses

2. If one matches a pending query, it's cached

3. Users receive malicious IP for legitimate domain

4. Cached poison served to many users

Security Mitigations

example.com.    IN    A      203.0.113.50
                IN    RRSIG  A 8 2 300 ...

Checking DNS Cache

View Cache Contents

ipconfig /displaydns | more

sudo killall -INFO mDNSResponder
# Check Console.app for logs

sudo systemd-resolve --statistics

Test Cache Behavior

# First query (cache miss)
time dig example.com

# Immediate repeat (cache hit)
time dig example.com

# Compare times

Cache-Related Issues

Stale Cache After DNS Change

1. Wait for TTL to expire

2. Reduce TTL before future changes

3. Ask users to flush local cache

Overly Aggressive Caching

Some ISPs ignore TTL and cache longer:

• Use lower TTLs (ISPs usually respect 300s minimum)
• Consider anycast DNS for critical services
• Document known problematic ISPs

Negative Caching

Failed lookups (NXDOMAIN) are also cached:

Query: newsubdomain.example.com
Response: NXDOMAIN (does not exist)
Cached: 3600s (SOA minimum TTL)

Result: New subdomain won't resolve for 1 hour

Flushing DNS Cache

When to Flush

• Testing DNS changes immediately
• Troubleshooting resolution issues
• After DNS provider migration
• Suspected cache poisoning

How to Flush

ipconfig /flushdns

sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

sudo systemd-resolve --flush-caches

Navigate to: chrome://net-internals/#dns
Click: "Clear host cache"

Toggle network.dnsCacheExpiration in about:config
Or restart browser

Best Practices

1. Set appropriate TTLs: Balance performance and change velocity

2. Reduce TTL before changes: Lower TTL 24-48 hours before DNS updates

3. Monitor propagation: Use tools to check global DNS resolution

4. Document cache behavior: Understand your infrastructure's caching layers

5. Use DNSSEC: Protect against cache poisoning

6. Test thoroughly: Verify DNS changes work as expected before declaring success

7. Educate users: Provide clear instructions for cache flushing when needed

Advanced Caching Concepts

Prefetching

Browsers and resolvers may prefetch DNS for links on a page:

<!-- Hint to browser -->
<link rel="dns-prefetch" href="//cdn.example.com">

Cache Warming

Load balancers and CDNs may pre-populate caches for critical records.

Anycast and Caching

Anycast DNS routes queries to nearest server, creating geographically distributed caches for optimal performance.

DNS caching is fundamental to internet performance—understanding and properly configuring TTLs ensures your DNS changes propagate efficiently while maintaining fast resolution times.