DNS Records & Concepts
What is DNS propagation?
DNS propagation is the process by which changes to DNS records spread across the global network of DNS resolvers, caches, and nameservers after being made on an authoritative nameserver. When a DNS record is updated, changing an A record to point to a new server, adding a CNAME record to connect a domain to redirect infrastructure, or updating an MX record to change email routing, that change does not take effect everywhere simultaneously. It spreads gradually as cached copies of the old record expire and resolvers fetch fresh data from the authoritative nameserver.
The word propagation captures this gradual spreading, DNS changes ripple outward from the authoritative nameserver through the global resolver network over time rather than flipping instantly everywhere at once. During the propagation window different visitors experience different DNS results depending on which resolver they use and whether that resolver has a cached copy of the old record or has already fetched the updated version.
DNS propagation is one of the most commonly misunderstood aspects of domain management. It is not a technical problem to be solved, it is an inherent characteristic of how the DNS caching system works. The caching that causes propagation delays is also what makes DNS fast and scalable at global scale. Understanding propagation, what drives it, how long it takes, and how to manage it, is essential for anyone making DNS changes as part of redirect management, domain migrations, or domain setup.
Why DNS propagation happens
DNS propagation exists because of caching, one of the fundamental mechanisms that makes the DNS system work at internet scale.
Without caching every DNS lookup would require a full query chain, from the resolver to the root nameservers to the TLD nameservers to the authoritative nameserver, for every single request. For a website receiving millions of visitors this would generate an enormous number of DNS queries hitting authoritative nameservers directly. The nameservers could not handle this load. DNS would be impossibly slow.
Caching solves this by allowing resolvers to store DNS responses locally for a period of time and serve them to subsequent requesters without querying the authoritative nameserver again. A resolver that looks up example.com stores the result, the IP address and record type, along with an expiry time. Any visitor using that resolver within the expiry period receives the cached result instantly without any additional DNS queries.
The expiry time for cached records is determined by the DNS TTL: Time To Live, a value set on each DNS record that specifies how many seconds resolvers should cache it. A TTL of 3600 means resolvers cache the record for one hour. After one hour the cached copy expires and the resolver must query the authoritative nameserver again for a fresh copy.
When a DNS record is changed on the authoritative nameserver the old value continues to be served by any resolver that has cached it until the cached copy expires. Only after expiry, when the resolver queries the authoritative nameserver again, does it receive and begin serving the new value. The time it takes for all resolvers worldwide to expire their cached copies and fetch the updated record is what we call DNS propagation.
What determines propagation speed
Several factors determine how quickly a DNS change propagates across the global resolver network.
DNS TTL: the most direct control over propagation speed. A record with TTL 300, five minutes, is cached for a maximum of five minutes before resolvers recheck. A record with TTL 86400, 24 hours, may be cached for up to 24 hours before resolvers fetch an update. The TTL is the single most important factor in propagation speed. Lowering the TTL before making a planned DNS change dramatically reduces the propagation window.
When the record was last cached: even with a TTL of 3600 a resolver that cached the old record one second before the DNS change was made will serve the old value for nearly the full hour. A resolver that cached the record 59 minutes before the change will serve the old value for only one more minute before fetching the update. The actual propagation time for any individual resolver depends on when it last cached the record relative to when the change was made.
Resolver behaviour: different DNS resolvers handle TTL compliance differently. Most resolvers respect TTL values as specified. Some, particularly public resolvers under heavy load, may cache records for slightly longer or shorter than the specified TTL. Google’s 8.8.8.8 and Cloudflare’s 1.1.1.1 are generally TTL-compliant. Corporate DNS servers and ISP resolvers vary more.
Negative caching: when a resolver queries for a record that does not exist the authoritative nameserver returns a negative response, NXDOMAIN. Resolvers cache negative responses for the duration specified in the SOA record’s minimum TTL field. A newly created record may not be visible to resolvers that cached a negative response for the domain until their negative cache expires.
Nameserver changes: changing nameservers involves propagation at a higher level of the DNS hierarchy, the TLD nameservers must propagate the updated delegation information. TLD nameservers cache NS records with TTLs set by the TLD registry, typically 172800 seconds, 48 hours for .com, .net, and most common TLDs. Nameserver changes can take significantly longer to propagate than individual record changes.
Propagation timelines
Understanding typical propagation timelines helps set realistic expectations for how long DNS changes take to take effect globally.
Individual record changes with low TTL: a record with TTL 300 or less propagates to most resolvers within 5 to 10 minutes after the change. Resolvers that cached the old record very recently may take up to 5 minutes longer. Full propagation, reaching virtually all resolvers worldwide, typically completes within 15 to 30 minutes for low-TTL records.
Individual record changes with standard TTL: a record with TTL 3600, the most common default, propagates over a window of up to one hour. Some resolvers receive the update within minutes if they query the authoritative nameserver shortly after the change. Others continue serving the old value for up to the full hour. Full propagation completes within one to two hours for most standard-TTL records.
Individual record changes with high TTL: a record with TTL 86400, 24 hours, may take up to 24 hours to fully propagate. Resolvers that cached the old value shortly before the change may serve it for nearly the full 24 hours. This is why high TTLs should be lowered before planned DNS changes.
Nameserver changes: changing nameservers involves TLD-level propagation with TTLs typically set to 172800 seconds, 48 hours. The actual propagation window is often shorter, many resolvers check more frequently, but planning for up to 48 hours of split-brain behaviour during nameserver changes is prudent.
Real-world observation: in practice propagation often completes faster than the maximum TTL suggests because resolvers do not all query exactly at the TTL expiry moment. Many resolvers perform background refresh before TTL expiry, query more frequently than the TTL strictly requires, or have shorter effective cache times due to cache pressure from high-traffic environments. However planning for the maximum TTL duration ensures no surprises.
Managing propagation during redirect management
DNS propagation has specific implications for redirect management setups that require careful planning.
Lowering TTL before DNS changes: the most effective way to reduce the propagation window for planned DNS changes. Lower the TTL on the records being changed at least 24 to 48 hours before the planned change. The TTL change itself takes up to the current TTL to propagate, so lowering from 86400 to 300 requires at least 24 hours for the lower TTL to reach all resolvers before the actual DNS change is made.
After the planned change is made and stable the TTL can be raised back to a normal value. A temporary low TTL during migration has minimal performance impact, the increased resolver query frequency is a small cost compared to the benefit of rapid propagation.
Dual-serving during propagation: when migrating from old hosting to new redirect infrastructure the old server should continue serving correctly for the duration of the propagation window. Some visitors continue reaching the old server while others reach the new redirect infrastructure. The old server must remain functional throughout.
If the old server is decommissioned before propagation completes visitors still being routed there by resolvers with cached old records receive errors. Never decommission old infrastructure until propagation is confirmed complete.
Split-brain during propagation: the period during propagation when some visitors see old DNS values and others see new ones is called split-brain. During split-brain a visitor using a resolver with the old cached value reaches the old server. A visitor using a resolver that has already updated reaches the new redirect infrastructure. Both experiences occur simultaneously for different visitors.
For simple domain migrations where the old site remains functional during propagation split-brain is acceptable, some visitors get the old site, others get redirected correctly, everyone can access the content. For migrations where the old URL structure is being retired the split-brain window means some visitors still reach old URLs that will eventually 404. Minimising this window through TTL management is important.
SSL certificate provisioning timing: when connecting a domain to redirect management infrastructure that automatically provisions SSL certificates via DNS validation the certificate provisioning requires DNS changes to have propagated before validation can succeed. The certificate authority checks for specific DNS records, typically TXT records or CNAME records: and the check fails if propagation is not complete. Allowing sufficient propagation time before expecting SSL provisioning to complete prevents frustrating delays.
Checking propagation status
Several tools and approaches help verify whether DNS changes have propagated to resolvers worldwide.
Online propagation checkers: web-based tools like whatsmydns.net, dnschecker.org, and similar services query DNS records from multiple geographic locations simultaneously and show which locations are returning the old value and which are returning the new one. These tools provide a real-time map of propagation status across the globe.
dig command with specific resolvers: querying specific resolvers directly shows what those resolvers are currently returning:
Comparing results across multiple resolvers indicates whether propagation is complete, if all return the same new value propagation has reached those resolvers. Differences indicate propagation is still in progress.
Querying the authoritative nameserver directly: querying the authoritative nameserver bypasses all caching and shows the current definitive value:
This confirms the change is correctly configured on the authoritative nameserver, useful for distinguishing between a DNS configuration error and normal propagation delay.
Local DNS cache flushing: when testing DNS changes from a local machine the operating system and browser have their own DNS caches that may be serving old values. Flushing the local DNS cache ensures the test uses fresh resolver results rather than locally cached ones.
On macOS: sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder On Windows: ipconfig /flushdns On Linux: sudo systemd-resolve --flush-caches or sudo service nscd restart
Common propagation misconceptions
Propagation takes exactly 48 hours: the persistent myth that DNS propagation always takes 48 hours. This is based on a rough maximum for nameserver changes with high TTLs. For individual record changes with standard or low TTLs propagation typically completes within one to two hours. For records with TTL 300 it may complete in minutes. The 48-hour figure is a worst case not a constant.
The change is instant on my machine but slow globally: flushing the local DNS cache or using a resolver that quickly picked up the change creates the impression that propagation is complete when it is not. Testing from multiple geographic locations and resolvers provides an accurate picture.
Propagation can be forced to complete faster: there is no mechanism to push DNS changes to all resolvers simultaneously. Propagation speed is governed by TTL values set before the change and by resolver behaviour, both outside direct control once the change is made. The only way to speed up propagation is to have lowered the TTL before making the change.
A new DNS provider can propagate faster: changing to a better DNS provider does not speed up propagation of record changes. The propagation delay is a function of TTL values and resolver caching behaviour, not of which DNS provider hosts the authoritative zone.
Propagation is complete when it works on my device: confirming a DNS change works from a single device or location only confirms that device’s resolver has updated. Resolvers in other regions or on other ISPs may still be serving the old value for up to the full TTL duration.