What Is TTL?
TTL (Time-To-Live) is a value in seconds that tells DNS resolvers how long to cache a record before checking for updates. When you look up example.com, the resolver caches the result for the TTL duration. During this time, all queries return the cached value without contacting the authoritative nameserver.
How TTL Works in Practice
# Check the TTL of a record
dig example.com A
# In the answer section:
# example.com. 300 IN A 93.184.216.34
# ^^^ TTL in seconds (300 = 5 minutes)
The resolver caches this for 300 seconds. After that, the next query fetches a fresh answer from the authoritative nameserver.
Recommended TTL Values
| Record Type | TTL | Reasoning |
|---|---|---|
| A / AAAA (stable) | 3600 (1 hour) | Rarely changes, reduces DNS load |
| A / AAAA (dynamic) | 300 (5 min) | Need quick failover |
| CNAME | 3600 (1 hour) | Usually stable |
| MX | 3600 (1 hour) | Mail routing rarely changes |
| TXT (SPF/DKIM) | 3600 (1 hour) | Rarely modified |
| NS | 86400 (24 hours) | Delegation records change very rarely |
The Migration Pattern
When planning a DNS change (e.g., server migration), follow this TTL strategy:
Before the Change (48 hours)
- Lower the TTL to 300 seconds (5 minutes)
- Wait for the old TTL to expire (e.g., if old TTL was 3600, wait at least 1 hour)
Make the Change
- Update the DNS record to point to the new server
- Changes will propagate within the new TTL (5 minutes)
After the Change (48 hours)
- Verify everything works
- Raise the TTL back to the normal value (e.g., 3600)
# Day 1: Lower TTL
# example.com 300 IN A OLD_IP
# Day 2: After old TTL expires, change IP
# example.com 300 IN A NEW_IP
# Day 3: Raise TTL back
# example.com 3600 IN A NEW_IP
Common Misconceptions
'DNS propagation takes 24-48 hours'
This is a myth. DNS doesn't 'propagate' — it's cached. Once the TTL expires, resolvers fetch the new value. If your TTL is 300 seconds, the change is visible within 5 minutes.
The 24-48 hour myth comes from:
- High default TTLs (some registrars set 86400)
- Some resolvers ignoring TTL or adding minimum TTL floors
- NS record changes at the registry level (which do take time)
'Lower TTL is always better'
Low TTLs increase DNS query volume, which:
- Adds latency to every request (DNS lookup before HTTP)
- Increases load on authoritative nameservers
- May cost more (some DNS providers charge per query)
Use low TTLs only when you need quick changes. For stable records, higher TTLs (1-4 hours) improve performance.
Checking TTL Across Resolvers
Different resolvers may have different cached TTLs:
# Google DNS
dig @8.8.8.8 example.com A +noall +answer
# Cloudflare DNS
dig @1.1.1.1 example.com A +noall +answer
# OpenDNS
dig @208.67.222.222 example.com A +noall +answer
The TTL value in the response decreases as the cache ages. A freshly cached record shows the full TTL; a stale one shows the remaining seconds until expiry.