DNS Propagation Calculator
Estimate worst-case DNS propagation time from TTL, resolver caching, and CDN factors.
Inputs
TTL of the parent NS delegation records, relevant when changing nameservers
CDNs often add their own edge-caching delay on top of DNS TTL
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
Values used
Current Record TTL = 3,600 seconds; Registrar/NS-Record TTL = 86,400 seconds; Uses a CDN = No; CDN Edge Cache Duration = 300 seconds
Worst-case propagation time
worst_case = max(record_TTL, NS_delegation_TTL, CDN_cache_duration)
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
How it works
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)
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.