DNS TTL & Propagation Calculator

Frequently Asked Questions

What does DNS TTL control?

Time To Live is how long resolvers cache a record. Worst-case propagation after a change is roughly the old TTL - until every cache expires and re-queries.

How do I cut over with minimal downtime?

Lower the TTL well in advance (at least the old TTL before the change) so caches hold the new short value, make the change, then raise the TTL back afterward.

What is a good TTL value?

Stable records: 1–24 h (less query load, slower changes). Records you may fail over: 30–300 s. It is a tradeoff between agility and DNS traffic.

Why do some users see the old site after I change DNS?

Their resolver (or OS/browser) still has the record cached until its TTL expires; some ISPs also ignore low TTLs, extending propagation.

Provided by AllCalculators.io
Free online calculators for everyday. No registration required.

Estimates for informational purposes only.

Important Disclaimer: Estimates for informational purposes only.

This calculator provides estimates for informational purposes only. Results are based on assumptions and may not reflect actual outcomes. Consult qualified professionals in relevant fields before making important decisions based on these results.

JavaScript is required to use the interactive calculator above. The questions and answers below remain readable without JavaScript.

How This Calculator Works

A DNS record's TTL (Time To Live) tells resolvers how long they may cache the answer. The worst-case propagation window is one full TTL: imagine a resolver caches the old record one second before you change it - it can keep serving the stale value for the entire TTL afterward. This tool converts your TTL to seconds, then, given how long ago the change was made, computes the maximum remaining time any resolver could still serve the old record, and whether the change has certainly fully propagated.

Worked Example

TTL = 1 hour (3,600s). You changed the record 20 minutes (1,200s) ago. Worst-case window = 3,600s. Maximum remaining stale time = 3600 − 1200 = 2,400s = 40 minutes. Until that elapses, some users may still hit the old server. The safe migration play: lower the TTL to 300s at least one old-TTL period (1h) before the cutover, so by switch time every resolver re-fetches every 5 minutes - turning a 1-hour blind window into a 5-minute one.

Real-World Use

This drives every zero-downtime migration: server moves, mail (MX) cutovers, CDN switches, failover, and SSL/IP changes. The standard runbook is lower-TTL → wait the old TTL → make the change → wait the new low TTL → raise the TTL back. The tool tells you exactly how long each wait must be and when it is safe to assume the change is universal.

Common Mistakes

Lowering the TTL too late: the low value itself is cached at the OLD TTL - you must lower it a full old-TTL period before the change.

Trusting "DNS checker" green ticks: they sample some resolvers, not every cache on Earth - the worst case is still a full TTL.

Ignoring negative caching: NXDOMAIN/SOA minimum TTL can cache "does not exist" answers too.

Forgetting to raise the TTL back: leaving it at 300s permanently multiplies query load and resolver cost.

Low vs High TTL Tradeoffs

Low TTL (30–300s): fast failover and quick changes, but more queries, higher authoritative-server load and cost, and more exposure if DNS is briefly unreachable. High TTL (1–24h): resilient, cheap, fast for clients via cache hits, but slow to change and slow to fail over. Typical practice: high TTL for stable records, temporarily low during planned changes, and moderate (300–3600s) for records behind failover. This estimate ignores resolvers that violate TTL or serve-stale; treat the window as a floor, not a guarantee.

DNS TTL & Propagation Calculator

Frequently Asked Questions

Related Networking & IT Calculators