DNS TTL Guide: Optimal Values for Every Record Type
What Is DNS TTL?
TTL (Time to Live) is a value in a DNS record that tells resolvers how long to cache the response before querying the authoritative nameserver again. Measured in seconds, TTL directly impacts how quickly DNS changes propagate across the internet, how much load your nameservers handle, and how resilient your infrastructure is to DNS outages.
How DNS Caching Works
When a user visits your website, their device queries a recursive resolver (typically provided by their ISP or a public service like 1.1.1.1 or 8.8.8.8). The resolver checks its cache first. If a valid cached response exists and the TTL has not expired, the cached response is returned immediately without contacting your nameservers.
The Caching Chain
- Browser cache: Modern browsers cache DNS responses for a short period (typically 60 seconds in Chrome), ignoring the actual TTL value.
- Operating system cache: The OS maintains its own DNS cache (systemd-resolved on Linux, mDNSResponder on macOS), respecting TTL values from the resolver.
- Recursive resolver cache: ISP or public resolvers cache responses for the full TTL duration. This is the most impactful cache layer.
- CDN edge cache: If using a CDN, edge nodes may cache DNS responses independently based on their own policies.
Recommended TTL Values by Record Type
| Record Type | Normal TTL | Pre-Migration TTL | Rationale |
|---|---|---|---|
| A / AAAA | 3600 (1 hour) | 300 (5 min) | Balance between caching efficiency and update speed |
| CNAME | 3600 (1 hour) | 300 (5 min) | Same as A records; CNAME resolution depends on target TTL too |
| MX | 3600-14400 | 600 (10 min) | Mail routing changes infrequently; higher TTL reduces query load |
| TXT | 3600 (1 hour) | 300 (5 min) | SPF, DKIM, and domain verification records benefit from moderate caching |
| NS | 86400 (24 hours) | 3600 (1 hour) | Nameserver changes are rare; high TTL is appropriate and expected |
| SOA | 86400 (24 hours) | 3600 (1 hour) | SOA refresh intervals govern zone transfer behavior |
| SRV | 300-3600 | 60-300 | Service discovery records may need faster updates for failover |
TTL and Propagation Time
A common misconception is that DNS propagation takes 24-48 hours. In reality, propagation time is bounded by the previous TTL value, not a fixed duration.
How Propagation Actually Works
Timeline of a DNS change with TTL=3600:
T+0: You update the DNS record
T+0: New visitors get the new IP immediately
T+1s: Visitors whose resolvers just cached get old IP
T+3600: ALL resolver caches have expired
T+3600: Every visitor now gets the new recordThe maximum propagation delay equals the TTL that was set before the change, not after. This is why lowering TTL before a migration is critical.
Migration Strategies
When planning server migrations, DNS cutover is often the most delicate step. A well-executed DNS migration strategy minimizes downtime and user impact.
Step-by-Step Migration Plan
- 48 hours before migration: Lower TTL on all affected records to 300 seconds (5 minutes). Wait for the old TTL to fully expire before proceeding.
- Pre-migration verification: Use multiple DNS Lookup tools to confirm the low TTL is being served globally. Check from different geographic regions.
- During migration: Update DNS records to point to the new server. With 300s TTL, full propagation occurs within 5 minutes.
- Post-migration monitoring: Monitor both old and new servers. Keep the old server running for at least 24 hours to serve any stale cached requests.
- After stabilization: Increase TTL back to normal values (3600s or higher) once you confirm the new server is stable.
Verification Commands
# Check current TTL from authoritative nameserver
dig +norecurse @ns1.example.com example.com A
# Check cached TTL from public resolvers
dig @8.8.8.8 example.com A
dig @1.1.1.1 example.com A
# Check remaining TTL (decrements over time)
dig example.com A +noall +answer
# Trace full resolution path
dig +trace example.com ACommon TTL Mistakes
- Setting TTL too low permanently: TTLs under 300 seconds increase query load on nameservers by 10-100x and add latency to every DNS resolution. Only use low TTLs temporarily.
- Forgetting to lower TTL before migration: If your TTL is 86400 seconds, changing the record still means some users see the old IP for up to 24 hours.
- Ignoring negative caching: DNS resolvers cache NXDOMAIN (domain not found) responses based on the SOA minimum TTL. Creating new records may not be visible immediately if the name was previously queried.
- Not accounting for minimum TTL enforcement: Some resolvers enforce a minimum TTL (often 30-300 seconds) regardless of what your DNS returns.
- Assuming instant propagation: Even with TTL=60, propagation is not instant due to browser caches, OS caches, and resolver minimum TTL enforcement.
TTL for High Availability
For services requiring high availability, DNS-based failover depends on low TTLs. If your TTL is 3600 seconds and your primary server fails, users continue hitting the dead server for up to an hour. Health-check-based DNS services like Route 53 or Cloudflare use TTLs of 60-300 seconds to enable rapid failover.
Conclusion
DNS TTL configuration is a balance between caching efficiency and operational agility. Use moderate TTLs (3600s) for stable records, lower them temporarily for migrations, and keep them low for records involved in failover. Always plan DNS changes at least 48 hours in advance, accounting for the current TTL expiration window.
Check your website right now
Check now →