Understanding DNS TTL Values and Caching

DNS TTL (Time To Live) controls how long DNS records are cached by resolvers and clients. Setting appropriate TTL values is critical for balancing performance (longer caching = fewer queries) with agility (shorter caching = faster propagation of changes). This guide covers TTL best practices for different record types and scenarios.

How TTL Works

When a DNS resolver queries an authoritative server, the response includes a TTL value in seconds. The resolver caches the answer for that duration. During the cache period, subsequent queries are answered from cache without contacting the authoritative server.

# Check current TTL of a record
dig example.com A

;; ANSWER SECTION:
example.com.        300     IN      A       93.184.216.34
                     ^^^
                     TTL in seconds (300 = 5 minutes)

Recommended TTL Values

# Static records (rarely change)
# A/AAAA records for stable servers: 3600-86400 (1 hour to 1 day)
example.com.    86400    IN    A    203.0.113.1

# NS records: 86400-172800 (1-2 days)
example.com.    86400    IN    NS    ns1.example.com.

# MX records: 3600-86400 (1 hour to 1 day)
example.com.    3600     IN    MX    10    mail.example.com.

# TXT records (SPF, DKIM, DMARC): 3600 (1 hour)
example.com.    3600     IN    TXT    "v=spf1 mx -all"

# CNAME records: 3600-86400
www.example.com.    3600    IN    CNAME    example.com.

# Dynamic records (change frequently)
# Load balancer endpoints: 60-300 (1-5 minutes)
api.example.com.    60    IN    A    203.0.113.1

# Failover records: 30-60 (30 seconds to 1 minute)
ha.example.com.    30    IN    A    203.0.113.1

TTL Scenarios

Before a Planned Migration

# 48 hours before migration: lower TTL to 60 seconds
example.com.    60    IN    A    203.0.113.1    # Old IP

# At migration time: update the IP
example.com.    60    IN    A    198.51.100.1   # New IP
# Most clients will pick up the change within 60 seconds

# After migration is stable (24-48 hours): restore normal TTL
example.com.    3600    IN    A    198.51.100.1

High-Availability Failover

# Use low TTL for records that may need quick failover
primary.example.com.    30    IN    A    203.0.113.1
# If primary fails, update to backup IP within 30 seconds

# Alternative: use DNS health checks (Route 53, Cloudflare)
# These automatically remove unhealthy IPs from responses

CDN and GeoDNS

# CDNs typically use very low TTL (30-60 seconds)
# This allows dynamic routing based on location and server health
cdn.example.com.    30    IN    CNAME    d1234.cloudfront.net.

Negative TTL (NXDOMAIN Caching)

# The SOA record minimum TTL field controls negative caching
# (how long NXDOMAIN responses are cached)
example.com.    SOA    ns1.example.com. admin.example.com. (
    2025011501    ; Serial
    3600          ; Refresh
    600           ; Retry
    604800        ; Expire
    300           ; Minimum TTL (negative cache = 5 minutes)
)

TTL Pitfalls

• Some resolvers ignore low TTL — a few ISP resolvers enforce a minimum TTL of 30-60 seconds regardless of what you set
• Client-side caching — browsers, operating systems, and applications may cache DNS beyond the TTL
• TTL too low — increases query volume and load on authoritative servers
• TTL too high — makes changes slow to propagate; problematic during incidents

Checking Effective TTL

# Check remaining TTL at a caching resolver
dig @8.8.8.8 example.com A | grep -A1 "ANSWER"
# Run again immediately — the TTL will be lower (counting down)

# Check what TTL authoritative server returns
dig @ns1.example.com example.com A | grep -A1 "ANSWER"
# This always shows the configured TTL

# Flush DNS cache
# macOS: sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
# Windows: ipconfig /flushdns
# Chrome: chrome://net-internals/#dns → Clear host cache
# systemd-resolved: resolvectl flush-caches

Best Practices

• Use 3600 seconds (1 hour) as a sensible default TTL for most records
• Lower TTL to 60 seconds at least 48 hours before planned DNS changes
• Use 30-60 second TTL for records requiring quick failover
• Set negative TTL (SOA minimum) to 300-600 seconds to avoid long NXDOMAIN caching
• Raise TTL back to normal after migrations are complete to reduce query load
• Do not set TTL below 30 seconds — some resolvers will not honor it
• Factor in client-side caching when estimating DNS change propagation time