DNS Propagation Checker: Why DNS Changes Take Time
You have just changed your domain's nameservers, updated an A record, or pointed a subdomain to a new server. You can see the change immediately—but your client, your boss, or users across the globe still see the old version. Welcome to DNS propagation, one of the most misunderstood aspects of internet infrastructure. This technical deep dive explains exactly what happens during propagation, why it takes time, and how to troubleshoot delays using our free DNS propagation checker.
The DNS Hierarchy: Four Layers of Resolution
To understand propagation, you must first understand how DNS resolution works. The system is organized in a hierarchical chain of servers, each with a specific role.
Root Nameservers
The top of the DNS hierarchy. There are 13 root server networks (labeled A through M), operated by organizations like ICANN, Verisign, and NASA. Root servers do not know your domain's IP address—they only know which TLD server to ask next. When you query example.com, the root server responds: "Ask the .com TLD server."
TLD Nameservers
Each top-level domain (.com, .org, .net, .io, etc.) has its own set of authoritative servers. The .com TLD servers, operated by Verisign, know which authoritative nameserver handles your domain. When queried, they respond: "Ask ns1.yourdnsprovider.com for example.com."
Authoritative Nameservers
This is where your actual DNS records live. When you update your A record, CNAME, MX record, or any other DNS entry, you are making changes at the authoritative nameserver. These servers provide the definitive answer: "example.com points to 203.0.113.50."
Recursive Resolvers (Caching)
Your ISP, Google (8.8.8.8), Cloudflare (1.1.1.1), and corporate networks operate recursive resolvers. These are the servers that actually answer your computer's DNS queries. Critically, they cache the answers they receive from authoritative servers. This caching is what causes propagation delays.
Key Concept: DNS propagation is not a single event. It is the gradual process of thousands of independent caching resolvers around the world updating their stored copies of your DNS records.
TTL: The Clock That Controls Propagation Speed
TTL (Time to Live) is the single most important factor in how long DNS propagation takes. Every DNS record includes a TTL value, measured in seconds, that tells caching resolvers how long they are allowed to store the record before checking for an update.
| TTL Value | Duration | Propagation Impact |
|---|---|---|
| 60 | 1 minute | Changes propagate almost instantly, but creates high query volume |
| 300 | 5 minutes | Fast propagation, moderate server load |
| 3600 | 1 hour | Standard for most records; propagation takes 1-4 hours |
| 14400 | 4 hours | Common for MX records; propagation takes 4-12 hours |
| 86400 | 24 hours | Maximum propagation delay; minimal server load |
The TTL Timing Trap
Here is a critical detail that catches many people off guard: the TTL that matters is the one set before you make the change, not the one you set after.
Consider this scenario:
Monday 9:00 AM — Your A record has TTL = 86400 (24 hours) Monday 10:00 AM — A resolver queries your record, caches it with 24h TTL Monday 2:00 PM — You change the A record AND set TTL to 300 The resolver that cached at 10:00 AM will NOT check for updates until Tuesday 10:00 AM (24 hours after it cached). Your new TTL of 300 only affects resolvers that query AFTER 2:00 PM.
This is why the standard advice is: lower your TTL 24-48 hours before making DNS changes. This ensures that all resolvers have cached a short TTL, so when you make the actual change, propagation completes quickly.
The Propagation Process: What Actually Happens
When you update a DNS record at your authoritative nameserver, nothing actively pushes that change to caching resolvers. There is no propagation "signal" or notification system. Instead, propagation happens passively through cache expiration.
Step-by-Step Propagation
1. The change is made at the authoritative server. From this moment, any new query to the authoritative server returns the updated record. But resolvers that have cached the old record will not know about the change until their cached TTL expires.
2. Different resolvers expire at different times. Resolver A may have cached the record 5 minutes before your change (with a 1-hour TTL), so it updates in 55 minutes. Resolver B cached 30 minutes before your change, so it updates in 30 minutes. Resolver C cached 59 minutes before your change, so it updates in 1 minute.
3. Each resolver independently queries the authoritative server after expiration. When a resolver's cached TTL expires and a user queries the domain, the resolver fetches the fresh record from the authoritative server and caches the new value (with the new TTL).
4. Full propagation occurs when all active resolvers have refreshed. In practice, this means waiting at least as long as the old TTL value. For a 3600-second TTL, full propagation takes about 1 hour. For an 86400-second TTL, it takes up to 24 hours.
Important: DNS changes at the root and TLD level (like changing nameservers) propagate through a separate chain of caches. Root and TLD servers have their own TTL values (often 48 hours), which is why nameserver changes can take up to 48 hours to propagate fully.
Why Some Users See Changes Faster Than Others
Propagation is not uniform across the globe. Several factors create variation:
- Resolver diversity: Different users use different resolvers (ISP, Google, Cloudflare, corporate). Each has independent cache timing.
- Geographic distribution: Some resolvers serve millions of users in specific regions. A resolver in Tokyo may update before one in São Paulo simply because it cached the record more recently.
- Browser DNS caching: Chrome, Firefox, and Edge all maintain their own DNS caches separate from the OS resolver. Chrome's DNS cache respects TTL but may extend it by up to 5 minutes.
- Operating system caching: Windows, macOS, and Linux all cache DNS locally. The OS cache must also expire before a new query reaches the resolver.
- CDN and reverse proxy caching: If your site uses Cloudflare, AWS CloudFront, or similar CDNs, they may cache DNS responses at their edge nodes.
Troubleshooting Delayed DNS Propagation
When DNS changes seem stuck, follow this systematic troubleshooting process:
1. Verify the authoritative record is correct
Query the authoritative nameserver directly, bypassing all caches:
dig @ns1.yourdnsprovider.com example.com A
If the authoritative server returns the old value, the change was not applied correctly. Check your DNS provider's dashboard.
2. Check what different resolvers see
Use our DNS propagation checker to query your domain from multiple global resolvers simultaneously. This reveals whether propagation is partial or complete.
3. Flush local caches
Clear your operating system and browser DNS caches to ensure you are not seeing a stale local result:
# Windows ipconfig /flushdns # macOS sudo dscacheutil -flushcache sudo killall -HUP mDNSResponder # Linux sudo systemd-resolve --flush-caches
4. Check for DNSSEC validation failures
If your domain uses DNSSEC, a misconfigured DS record or key rotation can cause resolvers to reject the updated response. Verify DNSSEC chain validity.
5. Investigate negative caching
Some resolvers cache NXDOMAIN (non-existent domain) or SERVFAIL responses. If your DNS was briefly misconfigured during the update, negative caching may cause delays even after the fix. Negative cache TTLs are typically 300-900 seconds.
6. Consider firewall or routing issues
If a specific region cannot resolve your domain while others can, the issue may not be propagation at all. Check if port 53 (DNS) is accessible from the affected network, and verify that your authoritative nameservers are reachable globally.
Best Practices for DNS Changes
- Plan ahead: Lower TTL to 300 seconds at least 24 hours before scheduled changes.
- Verify before and after: Use a propagation checker to confirm the change is visible globally.
- Restore TTL after propagation: Once propagation is complete, increase TTL back to normal (3600 or higher) to reduce server load.
- Make changes during low-traffic periods: Propagation during off-peak hours minimizes the number of users affected by inconsistent results.
- Keep TTLs reasonable: A TTL of 3600 (1 hour) is a good balance for most records. Only use very high TTLs (86400+) for records that rarely change.
Check DNS Propagation Globally
Query your domain from multiple DNS servers worldwide. See propagation status in real time.
Check Propagation →Frequently Asked Questions
DNS propagation typically takes 24 to 48 hours globally, though most users see changes within 1 to 4 hours. The actual time depends on the TTL (Time to Live) value previously set on the DNS record. If the old TTL was 3600 seconds (1 hour), propagation completes within about an hour after the TTL expires.
TTL (Time to Live) is a value in seconds that tells DNS resolvers how long to cache a record before checking for updates. A TTL of 3600 means resolvers will serve the cached answer for 1 hour before querying the authoritative server again. Lower TTLs mean faster propagation but more DNS queries. Higher TTLs reduce server load but slow down updates.
This happens because different DNS resolvers cache records independently. Your computer or ISP's resolver may have already flushed its cache (or you flushed it manually), while other resolvers are still serving the old cached record until their TTL expires. This is normal during propagation.
On Windows: open Command Prompt and run 'ipconfig /flushdns'. On macOS: run 'sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder' in Terminal. On Linux: run 'sudo systemd-resolve --flush-caches' or restart the nscd service.
DNS resolution is the process of looking up a domain name to find its IP address—it happens every time you visit a website. DNS propagation is the process of distributing updated DNS records across the global network of resolvers after a change is made at the authoritative nameserver.