How Does DNS Caching Work and What is the Role of TTL

DNS Caching is a key mechanism for improving DNS resolution efficiency. By storing DNS query results at multiple levels, it reduces repeated queries to authoritative DNS servers, thereby speeding up resolution and reducing server load.

DNS Caching Hierarchy

DNS caching works at multiple levels:

1. Browser Cache

• Location: Inside the browser
• Characteristics: Closest to users, fastest response
• Control: Users can clear via browser data cleanup
• Typical TTL: Minutes to hours

2. Operating System Cache

• Location: OS DNS client service
• Windows: DNS Client service
• Linux: nscd (Name Service Cache Daemon) or systemd-resolved
• View Commands:

bash
# Windows
ipconfig /displaydns

# Linux
systemd-resolve --statistics

3. Local DNS Server Cache

• Location: ISP or enterprise internal DNS servers
• Function: Shared cache for multiple users, higher hit rate
• Software: BIND, dnsmasq, Unbound, etc.

4. Recursive DNS Server Cache

• Location: Public DNS services (like 8.8.8.8, 114.114.114.114)
• Characteristics: Large user base, high cache hit rate

TTL (Time To Live) Details

What is TTL

TTL is an important field in DNS records that indicates the maximum time (in seconds) the record can be cached. When TTL expires, the cache must be cleared and DNS query must be performed again.

How TTL Works

shell
Authoritative server sets TTL = 3600 seconds (1 hour)
         ↓
Local DNS server retrieves and caches the record
         ↓
Within 1 hour, all queries return from cache
         ↓
After 1 hour, cache expires, re-query authoritative server

Typical TTL Values

Record Type	Typical TTL	Use Case
A/AAAA Records	300-3600 seconds	Frequently changing servers
CNAME Records	3600-86400 seconds	Relatively stable aliases
MX Records	3600-86400 seconds	Mail servers
NS Records	86400-172800 seconds	Name servers, rarely change
TXT Records	300-3600 seconds	SPF, DKIM verification records

TTL Best Practices

Stable Services

• Use longer TTL (24-48 hours)
• Reduce DNS query traffic
• Improve resolution speed

Frequently Changing Services

• Use shorter TTL (5-15 minutes)
• Facilitate quick server switching
• Suitable for blue-green deployment, failover

Pre-Change Preparation

shell
24 hours before change: Lower TTL to 300 seconds
Execute the change operation
24 hours after change: Restore TTL to original value

Cache Flushing and Clearing

Client-Side Flushing

bash
# Windows clear DNS cache
ipconfig /flushdns

# macOS clear DNS cache
sudo killall -HUP mDNSResponder

# Linux (systemd-resolved)
sudo systemd-resolve --flush-caches

Server-Side Flushing

• Restart DNS service
• Use rndc flush (BIND)
• Wait for TTL natural expiration

Problems Caused by Caching

1. Cache Inconsistency

• Different cache levels may have different TTLs
• Users may access different versions of services

2. Change Delay

• DNS changes need to wait for all caches to expire
• Global propagation may take TTL × 2 time

3. Cache Poisoning Attacks

• Attackers forge DNS responses to pollute cache
• Solution: DNSSEC digital signatures

Cache Optimization Strategies

1. Set TTL Reasonably

dns
; High-availability service - Short TTL
www.example.com.    300    IN    A    192.0.2.1

; Stable service - Long TTL
static.example.com. 86400  IN    A    192.0.2.2

2. Use CDN

• CDN edge nodes cache DNS results
• Intelligent scheduling of users to nearest nodes

3. DNS Prefetch and Preconnect

html
<!-- HTML DNS prefetch -->
<link rel="dns-prefetch" href="//cdn.example.com">
<link rel="preconnect" href="//api.example.com">

Summary

Aspect	Description
Cache Levels	Browser → OS → Local DNS → Recursive DNS
TTL Function	Controls cache validity, balances performance and consistency
Optimization	Set reasonable TTL values based on service characteristics
Considerations	Lower TTL before changes, avoid cache inconsistency

​