DNS Propagation Explained: How Long It Takes and How to Check
Understand what DNS propagation is, why DNS changes take time to spread globally, how TTL affects propagation speed, and how to check propagation status.
Last updated: 2026-02-18
What DNS Propagation Is
When you change a DNS record, the change does not take effect instantly across the internet. DNS propagation is the time it takes for updated DNS records to spread through the global network of DNS resolvers and caches.
DNS is a distributed system. There is no single database that every computer queries. Instead, there are thousands of recursive DNS resolvers operated by ISPs, companies, and public providers like Google (8.8.8.8) and Cloudflare (1.1.1.1). Each resolver caches DNS records to reduce query load and speed up lookups. When you change a record at your DNS provider, these caches do not update simultaneously. They update individually as their cached copies expire.
This is why you can change an A record and immediately see the new IP address from one location while someone in another country still sees the old one. Both responses are technically correct — one resolver has the updated record, the other is still serving a valid cached copy.
How DNS Caching and TTL Work
Every DNS record has a TTL (Time to Live) value, measured in seconds. The TTL tells DNS resolvers how long they are allowed to cache that record before they must query the authoritative nameserver again.
When a resolver looks up your domain for the first time, it contacts your authoritative nameserver, gets the record, and stores it in cache. It also starts a countdown timer based on the TTL. Until that timer expires, the resolver serves the cached copy to anyone who asks. Once the TTL expires, the next query triggers a fresh lookup from the authoritative nameserver.
| TTL Value | Cache Duration | Use Case | Propagation Speed |
|---|---|---|---|
| 60 seconds | 1 minute | During planned migrations | Very fast (minutes) |
| 300 seconds | 5 minutes | Frequently changing records | Fast (under 30 minutes) |
| 3600 seconds | 1 hour | Standard for most records | Moderate (1-2 hours) |
| 14400 seconds | 4 hours | Stable records | Slow (4-8 hours) |
| 86400 seconds | 24 hours | Rarely changing records | Very slow (24-48 hours) |
The TTL is the single biggest factor in propagation speed. A record with a 60-second TTL propagates in minutes. A record with an 86400-second (24-hour) TTL can take up to 48 hours because some resolvers cache slightly beyond the specified TTL.
Why Propagation Takes Up to 48 Hours
The "up to 48 hours" guidance exists because of several compounding factors.
Hierarchical caching. DNS resolution involves multiple layers: your local machine's DNS cache, your router's cache, your ISP's recursive resolver, and potentially intermediate caching servers. Each layer may cache independently, and each has its own expiry timing.
ISP resolver behavior. Some ISP resolvers do not strictly honor TTL values. They may cache records for longer than specified to reduce their query load, especially for popular domains. While this violates the DNS specification, it happens in practice.
Negative caching. If a resolver queries for a record that does not exist and gets an NXDOMAIN response, it caches that negative result too. Negative cache entries have their own TTL (defined in the SOA record's minimum TTL field). If you create a new record for a subdomain that previously did not exist, resolvers that cached the NXDOMAIN response will not see the new record until their negative cache expires.
Client-side caching. Operating systems and browsers maintain their own DNS caches with their own expiry rules. Even after all resolvers have the updated record, a user's machine may still serve a stale cached copy.
The 48-hour figure is a worst case. Most DNS changes propagate within 1-4 hours for records with standard TTL values. Changes to records with low TTLs (60-300 seconds) propagate in minutes.
How to Check DNS Propagation
Using Command-Line Tools
The dig command (Linux/macOS) and nslookup (Windows) let you query specific DNS resolvers to see what record they are returning.
Query Google's resolver:
dig @8.8.8.8 example.com A
Query Cloudflare's resolver:
dig @1.1.1.1 example.com A
If both return the new IP address, propagation is complete for those resolvers. If they differ, propagation is still in progress.
On Windows, use nslookup:
nslookup example.com 8.8.8.8
Using Online Propagation Checkers
Online tools query dozens of DNS resolvers worldwide and show you the result from each location. This gives you a global view of propagation status without manually querying individual resolvers.
These tools typically show a map or table with each resolver's response, making it easy to spot which regions have the updated record and which are still serving the old one.
Multi-Location Monitoring
Automated DNS monitoring tools check your records from multiple geographic locations on a continuous schedule. Unlike point-in-time propagation checkers, monitoring catches propagation inconsistencies as they happen and alerts you if a record returns different values from different locations.
Monitor DNS Propagation Automatically
Site Watcher checks DNS records from multiple locations and alerts you when records change or return inconsistent results. Also monitors uptime, SSL, domain expiry, and vendor dependencies. Free for 3 targets.
How to Speed Up DNS Propagation
You cannot force every resolver on the internet to drop their cache. But you can minimize propagation time with preparation.
Lower the TTL 24-48 Hours Before the Change
If your record currently has a TTL of 86400 (24 hours), resolvers that cached it today will hold it for up to 24 hours. Lower the TTL to 60-300 seconds at least 24-48 hours before your planned change. This ensures that by the time you make the actual change, all resolvers have the new low TTL and will expire their cache quickly.
Make the DNS Change
Once the low TTL has propagated (wait the duration of the old TTL), make your actual record change. Resolvers will now expire their cache within the new low TTL window — typically 1-5 minutes.
Verify Propagation
Use command-line tools or online propagation checkers to confirm the new record is returning correctly from resolvers worldwide. Check at least 3-5 major resolvers in different regions.
Raise the TTL Back Up
After confirming full propagation and verifying everything works correctly, raise the TTL back to a normal value (3600-86400 seconds). Low TTLs increase query load on your authoritative nameservers and slightly increase DNS lookup latency for your users.
Lowering the TTL and making the change at the same time does not help. Resolvers that already cached the record with the old high TTL will continue to serve it until the old TTL expires. The TTL reduction must propagate first.
Common DNS Propagation Issues
Stale Cache After Migration
You migrate your website to a new server, update the A record, and the site works from your machine but not from your phone. Your machine happened to query after the cache expired, getting the new record. Your phone's ISP resolver still has the old record cached. Wait for the TTL to expire, or flush the DNS cache on your phone by toggling airplane mode.
Negative Caching Blocking New Subdomains
You create a new subdomain (staging.example.com) and add an A record, but it does not resolve. If a resolver previously received an NXDOMAIN response for that subdomain, it cached the negative result. The negative cache TTL (from the SOA record) must expire before the resolver will query for the new record.
ISP Resolvers Ignoring TTL
Some ISP resolvers enforce a minimum cache time regardless of the record's TTL. Even with a 60-second TTL, these resolvers might cache for 5-30 minutes. This is non-compliant behavior, but you cannot control it. The only workaround is patience or using a different resolver.
Local DNS Cache
Your operating system caches DNS independently. On Windows, flush with ipconfig /flushdns. On macOS, use sudo dscacheutil -flushcache && sudo killall -HUP mDNSResponder. On Linux, it depends on the resolver: sudo systemd-resolve --flush-caches for systemd-resolved. Browsers also maintain their own DNS cache — restart the browser or visit chrome://net-internals/#dns in Chrome to flush it.
DNS Propagation and Monitoring
DNS monitoring and propagation are closely related. When you make an intentional DNS change, monitoring detects the change during propagation. Good monitoring tools let you acknowledge planned changes so they do not trigger false alerts.
More importantly, monitoring verifies that propagation completed successfully. After making a change, monitoring from multiple locations confirms that the new record is returning correctly everywhere. If a record has propagated to most resolvers but one region is still serving the old value, monitoring catches the inconsistency.
Monitoring also catches unintentional changes. If someone modifies a DNS record without authorization, monitoring detects the change as it propagates — often before users notice anything wrong.
DNS propagation is not something you can control. It is something you can prepare for, monitor, and verify. The difference between a smooth DNS migration and a multi-hour outage is preparation.
DNS Monitoring From Multiple Locations
Site Watcher monitors DNS records from multiple vantage points, verifies propagation, and alerts you when records change. Combined with uptime, SSL, domain expiry, and vendor monitoring. $39/mo unlimited. Free for 3 targets.