DNS Propagation Time Calculator
Work out the worst-case time a DNS change takes to reach every resolver, including the TTL you lowered beforehand.
Inputs
The lowered TTL only helps once the old TTL has fully expired everywhere.
NOTIFY plus IXFR to secondaries, or the provider's internal fan-out.
Some resolvers and stub caches enforce their own minimum TTL.
Worst-Case Propagation
420seconds
Worst Case as a Duration
7m
Typical Propagation
210seconds
TTL Actually in Caches Now
300seconds
Tail for Resolvers That Stretch TTLs
1,140seconds
Cutover Window to Plan
19.0minutes
Pre-Change Advice
The lowered TTL is already in caches — the change can proceed
Step by step
Values used
TTL currently published = 3,600 seconds; TTL you lowered it to = 300 seconds; Lead time since lowering the TTL = 2 hours; Zone sync to all authoritative servers = 60 seconds; Resolver refresh skew = 60 seconds; Resolvers that stretch short TTLs = 5 %
DNS Propagation Time
worst case = effective TTL + resolver refresh skew + zone sync time, where the effective TTL is the lowered value only once the previously published TTL has expired everywhere.
Worst-Case Propagation
= 420 seconds
Worst Case as a Duration
= 7
Typical Propagation
= 210 seconds
TTL Actually in Caches Now
= 300 seconds
Tail for Resolvers That Stretch TTLs
= 1,140 seconds
Cutover Window to Plan
= 19.0 minutes
How it works
Lowering a TTL does nothing until the previously published TTL has expired in every cache, so the change window is driven by the old value unless you lowered it far enough in advance. Once the short TTL is live, the worst case is that TTL plus refresh skew plus the time the edit takes to reach all authoritative servers. Cutovers fail when the change window is planned from the new TTL instead of the one still cached, leaving a fraction of users pointed at a decommissioned endpoint. Keeping the old target alive for the straggler tail is what makes a DNS migration safe.
Formula
DNS Propagation Time
worst case = effective TTL + resolver refresh skew + zone sync time, where the effective TTL is the lowered value only once the previously published TTL has expired everywhere.
- effective TTL
- The TTL actually sitting in resolver caches right now
- zone sync
- Time for the edit to reach every authoritative server
- straggler tail
- Extra time for resolvers that enforce their own minimum TTL
Frequently Asked Questions
How is DNS Propagation Time calculated?
worst case = effective TTL + resolver refresh skew + zone sync time, where the effective TTL is the lowered value only once the previously published TTL has expired everywhere. Lowering a TTL does nothing until the previously published TTL has expired in every cache, so the change window is driven by the old value unless you lowered it far enough in advance. Once the short TTL is live, the worst case is that TTL plus refresh skew plus the time the edit takes to reach all authoritative servers.
Why does DNS Propagation Time matter?
Cutovers fail when the change window is planned from the new TTL instead of the one still cached, leaving a fraction of users pointed at a decommissioned endpoint. Keeping the old target alive for the straggler tail is what makes a DNS migration safe.
What values do I need to enter?
This calculator takes 6 inputs: TTL currently published, TTL you lowered it to, Lead time since lowering the TTL, Zone sync to all authoritative servers, Resolver refresh skew, Resolvers that stretch short TTLs. The pre-filled defaults are a realistic starting point — replace them with figures from your own environment for a result you can act on.