When you update a DNS record — whether changing an A record to point to a new server, modifying your MX records for a new mail provider, or publishing a new TXT record for email authentication — that change does not appear instantly for every user on the internet. This delay, commonly called DNS propagation, describes the period during which different resolvers around the world return different answers for the same query. Understanding why this happens is essential for planning infrastructure changes without unexpected downtime or user confusion during the transition window.
DNS propagation is not a single process controlled by one system. It is the aggregate result of thousands of independent caching resolvers each deciding when to refresh their cached copy of your zone data. The internet has no central authority that pushes DNS updates to every resolver simultaneously. Instead, resolvers check authoritative nameservers only when their cached records expire. This distributed caching model is what makes DNS fast and globally scalable, but it is also why changes take time to reach every corner of the internet.
- DNS changes are not pushed to resolvers — resolvers pull updates only when cached records expire
- Different resolvers worldwide cache records for different lengths of time independently
- During propagation, some users see old values while others see updated ones simultaneously
- The propagation window is determined by the TTL value in effect before the change was made
- Critical infrastructure changes require advance TTL reduction to minimize the propagation window
Every DNS record carries a Time to Live value, expressed in seconds, that instructs resolvers how long to cache that record before fetching a fresh copy from the authoritative nameserver. A TTL of 300 means the record is cached for five minutes. A TTL of 3600 means one hour. A TTL of 86400 means 24 hours. When a recursive resolver receives a DNS response, it stores the answer locally and decrements the TTL counter with each passing second. When the TTL reaches zero, the resolver discards the cached entry and fetches a fresh copy the next time a client requests that record from the authoritative source.
The TTL value you set in your DNS zone file is your primary lever for controlling propagation speed. If your A record has a TTL of 86400 and you change the IP address, every resolver that cached the old record will continue serving the old IP for up to 24 hours after your change. Conversely, a TTL of 300 means resolvers refresh every five minutes. The tradeoff is query volume: lower TTL values cause more frequent queries to your authoritative nameservers, increasing load and potentially increasing latency for users served by cold caches.
300seconds (5 minutes) — low TTL suitable for records you plan to change soon3600seconds (1 hour) — moderate TTL for most active production records86400seconds (24 hours) — high TTL for stable records like MX and NS that rarely change- The TTL at the moment of a change determines how long the old value persists in resolver caches
- After a change completes, raise the TTL back to reduce unnecessary authoritative nameserver queries
The 24-48 hour figure commonly cited for DNS propagation reflects the worst-case scenario where a record carried a 24-hour TTL before the change was made. Every resolver that cached the record just before your change will hold the old value for the full remaining TTL duration. Since resolvers worldwide cached the record at different moments, their expiry times are staggered across the entire TTL window. A resolver that cached the record 23 hours and 59 minutes before your change expires and refreshes almost immediately, while one that cached it one minute before will hold the old value for nearly the full 24 hours.
The hierarchical structure of DNS compounds this effect. Large ISPs operate their own resolvers serving millions of customers from a single cache entry. Enterprise networks run internal resolvers. Mobile carriers operate their own caching infrastructure. Each resolver maintains its cache independently. When you publish a change, the new answer does not flow outward from your zone — instead, each resolver fetches the new answer on its own schedule when its cached TTL expires. The result is a rolling propagation front sweeping across the global resolver population over the entire TTL window.
- Resolvers cached the old record at different times, so expiry times are staggered across the TTL window
- ISP resolvers may serve millions of customers from a single cached entry
- Some resolvers apply their own minimum or maximum cache durations, ignoring published TTL values
- NS record changes take longer because the parent zone delegation must also be updated
- The actual propagation window equals the TTL that was in effect at the moment of the change
Several tools make it easy to verify whether your DNS change has reached resolvers in different geographic regions. The website dnschecker.org queries your domain from servers in dozens of countries simultaneously and shows a world map with green or red indicators for each location. The similar tool whatsmydns.net provides resolver results organized by region and displays the actual value returned by each resolver, making it straightforward to compare old and new values during the propagation window and confirm which regions have received the updated record.
For detailed investigation from the command line, the dig utility is the standard tool on Linux and macOS. The command dig @8.8.8.8 example.com A queries Google's public resolver specifically for the A record, letting you compare results across multiple resolvers by changing the @ target. The +trace flag shows the full delegation path from the root zone to your authoritative server. On Windows, nslookup example.com 8.8.8.8 provides equivalent functionality for checking what a specific resolver is currently returning.
- dnschecker.org — visual world map showing propagation status across dozens of global locations
- whatsmydns.net — displays actual record values returned by regional resolvers for direct comparison
dig @1.1.1.1 example.com A— query Cloudflare's resolver for the current A recorddig @8.8.8.8 example.com MX +short— compact MX record check via Google DNSnslookup -type=TXT example.com 8.8.8.8— Windows TXT record lookup against Google DNS
The single most effective tactic for minimizing propagation time is to lower your TTL well in advance of a planned change. If your current A record has a TTL of 86400 and you want to minimize propagation time during a server migration, lower the TTL to 300 at least 24 hours before the migration. This ensures that by the time you make the actual change, no resolver holds a cached copy with more than five minutes remaining. After migration, once you confirm the new record is resolving correctly globally, raise the TTL back to its normal high value to reduce resolver query load.
The timing window is critical. You must lower the TTL at least as long before the change as the current TTL value. If the current TTL is 86400, lower it 24 hours in advance. If it is 3600, lowering it one hour before is sufficient. After lowering the TTL, verify with dig against multiple public resolvers that they are now caching the new low TTL before proceeding with the actual record change. Skipping this verification step is the most common cause of unnecessarily slow propagation during planned migrations and cutover windows.
- Lower TTL to
300at least 24-48 hours before any planned DNS change - Wait for the full original TTL duration to pass before making the actual record change
- Verify resolvers cache the low TTL using
dig @8.8.8.8 example.com Abefore proceeding - Monitor with dnschecker.org after the change to confirm global propagation is complete
- Raise TTL back to
3600or higher once the change has propagated successfully everywhere
Even after global resolver propagation completes, individual users may still see the old record due to local DNS caches at multiple layers. Web browsers maintain their own DNS cache independent of the operating system. Google Chrome's DNS cache can be inspected and cleared by navigating to chrome://net-internals/#dns and clicking the Clear host cache button. Firefox caches DNS queries internally as well; restarting the browser process clears this layer. These browser-level caches are separate from the system resolver cache and can persist even after the operating system cache has been flushed.
The operating system itself maintains a DNS resolver cache that persists across browser sessions. On Windows, the command ipconfig /flushdns run in an elevated Command Prompt clears the system DNS cache and typically returns a success confirmation message. On macOS, running sudo dscacheutil -flushcache from a Terminal window clears the system DNS cache. On Linux systems using systemd-resolved, the command sudo systemd-resolve --flush-caches clears the resolver cache, verifiable with systemd-resolve --statistics.
- Chrome browser cache: navigate to
chrome://net-internals/#dnsand click Clear host cache - Windows OS cache:
ipconfig /flushdnsin an elevated Command Prompt window - macOS cache:
sudo dscacheutil -flushcachein a Terminal window - Linux systemd-resolved:
sudo systemd-resolve --flush-caches - Enterprise environments may have internal resolvers requiring separate administrator-level flush procedures