DNS Propagation
Estimate how long a DNS change will take to fully propagate based on TTL and resolver caching.
About DNS Propagation
DNS propagation time is not a single fixed delay but the worst case across every caching layer between the authoritative nameserver and the end user: worst_case = max(record_TTL, NS_delegation_TTL, CDN_edge_cache_duration). A simple record value change (e.g. updating an A record) is bounded by that record's own TTL. Changing nameservers themselves is bounded by the much longer-lived NS delegation records held at the registry/registrar level, which often have TTLs of a day or more. CDNs add an entirely separate caching layer at their edge locations that isn't governed by DNS TTL at all, and can independently delay when users actually see a change even after DNS itself has updated everywhere.
Formula
Worst-case propagation time
worst_case = max(record_TTL, NS_delegation_TTL, CDN_cache_duration)
Worked example
With the default values below, DNS Propagation returns Worst-Case Propagation Time of 1 days. Change any input above and every figure here is recalculated in your browser.
Inputs used
- Current Record TTLminimum 0 seconds
- 3,600 seconds
- Registrar/NS-Record TTLminimum 0 seconds
- 86,400 seconds
- Uses a CDN
- No
- CDN Edge Cache Durationminimum 0 seconds
- 300 seconds
Results
- Worst-Case Propagation Time
- 1 days
- Typical Case (record update only)
- 1 hours
- Contributing Factors
- Record TTL: up to 1 hours | Nameserver delegation TTL (only relevant if changing NS records): up to 1 days
Step by step
- 1Values used
- 2Worst-case propagation time
- 3Worst-Case Propagation Time= 1 days
- 4Typical Case (record update only)= 1 hours
- 5Contributing Factors= Record TTL: up to 1 hours | Nameserver delegation TTL (only relevant if changing NS records): up to 1 days
Assumptions and limits
- The result is derived only from the 4 inputs listed above. Anything not among them is not part of the calculation.
- In particular, this calculator does not take inflation, tax, fees or charges or compounding frequency into account.
How these calculators are built and tested is described on the Methodology page. If a figure looks wrong, please report it.
Frequently Asked Questions
Why is changing nameservers slower to propagate than changing a single record?
Nameserver (NS) delegation records live at the parent zone/registry level and typically have longer TTLs (often 24-48 hours) than typical record TTLs, and many resolvers cache the delegation itself separately from individual records — so a nameserver change can take up to that longer delegation TTL to be seen everywhere.
Why doesn't lowering DNS TTL immediately fix CDN-related propagation delay?
CDN edge servers maintain their own independent cache of content and configuration, often with its own cache-control settings entirely separate from DNS TTL — even if every resolver worldwide instantly picked up a DNS change, the CDN's edge nodes might still serve stale cached content until their own cache expires or is explicitly purged.
Is 'DNS propagation' really about data spreading across the internet?
Not exactly — DNS records aren't pushed out to a global copy; instead, resolvers around the world simply hold cached copies from their last query and will keep serving that cached (possibly stale) answer until their own copy's TTL expires and they re-query the authoritative server. 'Propagation' is really 'waiting for caches to expire.'
What's the best practice before a major DNS change?
Lower the TTL on the record you plan to change well in advance (e.g. a day or more before, if the current TTL is high) so that by the time you make the actual change, most caches are already honoring the new, shorter TTL — minimizing worst-case propagation delay for the real change.