2026-03-21 · CalcBee Team · 7 min read

DNS TTL Strategy: How to Choose the Right Time-to-Live Values

DNS Time-to-Live is one of those settings that most teams configure once and never think about again — until a migration fails because stale DNS records point traffic to a decommissioned server for hours. TTL controls how long resolvers cache your DNS records, and getting it wrong creates a painful tradeoff: set it too high and changes propagate slowly; set it too low and every request hits your authoritative nameservers, increasing latency and cost.

This guide explains the math and strategy behind TTL selection for different record types, operational scenarios, and reliability requirements.

How DNS TTL Works

When a recursive resolver (like Google's 8.8.8.8 or Cloudflare's 1.1.1.1) looks up your domain, it caches the result for the duration specified by the TTL field in the DNS response. During that window, all subsequent queries for the same record are answered from cache without contacting your authoritative nameserver.

The TTL value is specified in seconds:

After the TTL expires, the resolver discards the cached entry and makes a fresh query to your authoritative nameserver on the next request. This is the "propagation" that everyone worries about during DNS changes — it is really just waiting for worldwide caches to expire.

Important caveat: Not all resolvers honor TTL perfectly. Some impose a minimum TTL (common minimums: 30 seconds to 5 minutes). Some impose a maximum (rarely caching beyond 24 hours regardless of the stated TTL). And some corporate resolvers and ISPs apply their own caching policies. There is no guarantee that every resolver on the internet will see your change within exactly one TTL period.

The DNS TTL impact calculator models how TTL values affect propagation time, cache hit rates, and authoritative query volume for your domain.

Choosing TTL by Record Type

Different record types serve different purposes and warrant different TTL values.

A/AAAA records (IP addresses): These point your domain to a server IP. If the IP changes rarely (static hosting, dedicated servers), a TTL of 3600 to 86400 seconds is appropriate. If the IP can change for failover or load balancing, use 60 to 300 seconds.

CNAME records: These alias one domain to another. Since the target hostname has its own TTL, the CNAME TTL controls how long the alias relationship itself is cached. A TTL of 3600 seconds is standard. Lower values are useful when you might need to redirect traffic quickly.

MX records (mail servers): Email can tolerate delayed propagation better than web traffic — sending servers will retry for hours or days. A TTL of 3600 to 14400 seconds is standard for MX records.

TXT records (SPF, DKIM, verification): These change infrequently and can tolerate high TTLs (3600 to 86400 seconds). Lower TTLs are useful when you are actively configuring email authentication and need to verify changes quickly.

NS records: These delegate authority for a zone and should have high TTLs (86400 to 604800 seconds). NS record changes are rare and have long propagation times regardless.

TTL Math for Migrations

The most critical TTL decision happens before a migration — when you lower the TTL in advance so caches expire quickly once you flip the DNS record.

The pre-migration TTL reduction:

1. At time T-48h: Lower TTL from 86400 to 300 (from 24 hours to 5 minutes)
2. Wait at least the old TTL period (24 hours) for all caches to refresh with the new low TTL
3. At time T-0h: Make the DNS change (point to new IP/host)
4. Within 5 minutes (the new TTL), most resolvers pick up the change
5. After confirming success, raise TTL back to the operational value

Why waiting for the old TTL matters: If your TTL was 86400 seconds and a resolver cached the record 1 second before you lowered the TTL, that resolver will hold the old record (with the old high TTL) for almost 24 hours. It will not see the lowered TTL until its cache expires. This is why you must lower the TTL and wait for the old TTL duration before making any change.

> Minimum preparation time = Old TTL + Safety buffer

For a 24-hour TTL: lower the TTL at least 24–48 hours before the migration. For a 1-hour TTL: at least 1–2 hours before.

Migration timeline example:

TTL and Failover Speed

For services using DNS-based failover (Route 53 health checks, Cloudflare load balancing, NS1 Filter Chain), TTL directly determines how quickly traffic shifts away from a failed endpoint.

Failover time = TTL + Health check interval + Propagation delay

With a 300-second TTL and a 30-second health check interval:

• Health check detects failure: ~30 seconds
• DNS record updated: ~5 seconds
• Resolvers serve stale cache: up to 300 seconds
• Worst-case failover: ~335 seconds (5.5 minutes)

Reducing TTL to 60 seconds:

• Health check: ~30 seconds
• DNS update: ~5 seconds
• Cache expiry: up to 60 seconds
• Worst-case failover: ~95 seconds (1.5 minutes)

The tradeoff for lower TTLs is increased query volume to your authoritative nameservers. Each cache expiry generates a new query, so reducing TTL from 3600 to 60 increases query volume by 60×. For a domain receiving millions of queries per day, this significantly increases DNS hosting costs and adds latency for uncached queries.

The MTU size calculator can help you verify that your DNS responses fit within a single UDP packet (512 bytes, or 4096 with EDNS0) — oversized responses fall back to TCP, adding latency to every uncached lookup.

Monitoring DNS and TTL Impact

TTL decisions should be data-driven. Monitor these metrics to validate your TTL strategy:

Authoritative query volume: Track queries per second to your nameservers. A spike after lowering TTL is expected. If the volume is too high, your DNS provider may throttle or charge overages.

Resolution latency: Measure DNS lookup time from multiple geographic locations. Low TTLs increase the frequency of uncached lookups, which are slower than cached ones. If 95th-percentile DNS latency exceeds 100 milliseconds, investigate the cause.

Cache hit ratio: Some DNS providers report the percentage of queries served from cache. A high TTL yields high cache ratios (95%+); a very low TTL might drop to 60–70%.

Propagation completeness: After a DNS change, use tools like whatsmydns.net to verify that resolvers worldwide have picked up the new record. Expect 95% propagation within one TTL period and 99%+ within two TTL periods.

Common TTL Mistakes

Never changing the TTL before a migration. This is the number-one cause of prolonged DNS propagation during cutovers. If your TTL is 86400 and you change the IP without lowering it first, some users may not see the change for up to 24 hours.

Setting TTL to zero. A TTL of zero means "do not cache," which forces a DNS lookup on every single request. This creates extreme load on your authoritative nameservers and adds DNS latency to every page load. Some resolvers interpret TTL=0 as "cache for my minimum" (often 30 seconds), so you do not even get the instant-propagation benefit.

Using the same TTL for everything. Your CDN CNAME, your MX records, and your API A records have different stability profiles and failover requirements. Differentiate your TTLs accordingly.

Forgetting about downstream caches. Applications, libraries, and operating systems may cache DNS independently of the resolver TTL. Java's default DNS cache TTL was historically infinite (until JDK 9 changed it to 30 seconds). Go's resolver caches for the TTL period. Browsers typically cache for 60 seconds regardless of TTL. These application-level caches add lag beyond what DNS TTL alone controls.

A thoughtful TTL strategy is a small investment that pays dividends during every infrastructure change, failover event, and traffic migration. Set your TTLs intentionally, lower them before changes, monitor the impact, and raise them back afterward. Your on-call engineers will thank you.

Category: Tech

Tags: DNS, TTL, Networking, Infrastructure, DNS management, Site reliability, Performance optimization