Calculate the impact of DNS TTL values on propagation time, resolver cache hit rates, and DNS query volume.
DNS TTL (Time to Live) controls how long resolvers cache a DNS response before querying the authoritative server again. Higher TTLs reduce DNS query volume and improve resolution speed from cache. Lower TTLs enable faster propagation of DNS changes but increase query load.
This calculator helps you understand the trade-offs of TTL values for your domains. It estimates cache hit rates, propagation times, and the query volume impact of different TTL settings. This is especially important when planning DNS migrations, failover configurations, or CDN integration.
Before a planned DNS change (migration, failover test), lower the TTL in advance by the current TTL duration. For example, if TTL is 3600 seconds (1 hour), lower it to 300 seconds at least 1 hour before the change. This ensures all cached entries expire before you make the change.
Quantifying this parameter enables systematic comparison across environments, deployments, and time periods, revealing optimization opportunities that improve both performance and cost-effectiveness.
DNS TTL values directly affect how quickly your domain changes take effect and how many queries hit your DNS servers. This calculator helps choose the right TTL for different scenarios. Precise quantification supports capacity planning and performance budgeting, ensuring infrastructure investments are right-sized for both current workloads and projected future growth.
Propagation Time ≈ TTL (worst case all resolvers have cached entries) Queries to Authority = resolvers / TTL (per second, per resolver refresh) Cache Hit Rate ≈ 1 − (resolvers / (resolvers + requests_per_sec × TTL))
Result: Propagation: ~5 min, ~1.67 auth queries/sec
At TTL 300 seconds, resolvers cache for 5 minutes. Each of 500 resolvers re-queries every 300 seconds: 500/300 = 1.67 queries/sec to the authoritative server. With 100 rps total, cache hit rate is very high since most requests are answered from resolver cache.
Static infrastructure (mail servers, name servers): TTL 3600–86400 seconds. These rarely change and benefit from aggressive caching. Web applications with potential failover: TTL 60–300 seconds. These need to change quickly during incidents.
The pre-migration TTL dance: (1) Lower TTL to 60–300 seconds, (2) Wait for the old TTL to expire, (3) Make the DNS change, (4) Verify propagation, (5) Raise TTL back to normal. Skipping step 2 means some resolvers still have the old record cached at the high TTL.
Cloud DNS services charge per million queries. At 1,000 resolvers with 60-second TTL, you generate 1,000/60 = 16.7 authoritative queries per second, or ~1.44 million per day. At 3600-second TTL, that drops to 24,000 per day — a 60x reduction.
For most records: 300–600 seconds (5–10 minutes) balances change speed with cache efficiency. For stable records: 3600 seconds (1 hour) or more. For records requiring instant failover: 30–60 seconds (high query cost).
Maximum propagation time equals the previous TTL value. If TTL was 3600 seconds, all resolvers will have updated within 1 hour. In practice, many resolvers update sooner as their cached entries expire at different times.
No. Some resolvers enforce minimum TTLs (e.g., 30 or 60 seconds). ISP resolvers may ignore low TTLs. Client operating systems cache DNS independently. Real-world propagation has a long tail even with low TTLs.
TTL under 60 seconds significantly increases query volume to authoritative servers and can increase latency for initial requests (cache misses). Some cloud DNS providers charge per query, making very low TTLs expensive.
TTL 0 means no caching, but many resolvers treat it as a minimum of 30–60 seconds. It dramatically increases authoritative query load. Use it only for testing or when instant record changes are critical and you can handle the query volume.
During a failover, DNS records change to point to backup infrastructure. The failover takes effect as resolver caches expire. With 300-second TTL, full failover takes up to 5 minutes. Health-check-based DNS (Route 53) can trigger changes faster.