DNS Propagation Explained: Why Your Changes Take So Long
You just updated your DNS. The hosting company says it's done. But the site is still pointing at the old server twelve hours later. Here's exactly what's happening — and what you can actually do about it.
Every developer has been here. You've finished migrating a site to a new host. You've updated the A record. The registrar dashboard shows the new IP. You reload your browser — same old site. You wait two hours. Still the old one. A colleague in another city can already see the new one. What is actually happening?
DNS propagation isn't magic and it isn't random. It's a predictable caching mechanism — one you can influence significantly if you understand how it works.
How the DNS System Works
When you type a domain into your browser, your computer doesn't know the IP. It asks a resolver — typically your ISP's DNS server or a public resolver like Cloudflare's 1.1.1.1. That resolver might already have the answer cached. If not, it works up the hierarchy: root nameservers → TLD nameservers (.com, .net, etc.) → your domain's authoritative nameservers. Once it gets the answer, it caches it for everyone until the TTL expires.
What TTL Actually Controls
TTL (Time to Live) is set by you in your DNS zone, and it tells resolvers how long to cache a record before fetching fresh data. A TTL of 86400 = 24 hours. A TTL of 300 = 5 minutes.
The critical detail people miss: the TTL that matters is the one that was set before your change. If your A record had a 24-hour TTL when you changed it, resolvers that fetched it anytime in the past 24 hours can hold the old answer for up to another 24 hours. The new TTL only governs fresh fetches from that point forward.
The Correct Migration Sequence
- 48 hours before: Reduce all relevant TTLs to 300 seconds and leave them there.
- Day of migration: Confirm the new server is fully set up and tested via its IP directly.
- During the change window: Update the record. With a 300s TTL, global propagation completes in 10–30 minutes.
- Monitor: Use a propagation checker to watch the change spread from multiple global vantage points.
- 24 hours later: Raise TTL back to 3600 or 86400 for better caching performance.
🌍 DNS Propagation Checker
Watch your DNS changes spread globally in real time during cutover.
Why Different People See Different Things
During propagation, someone in Singapore might see your new server while someone in Berlin still sees the old one. This is exactly how the system works. Different resolvers expire their cached records at different times depending on when they last fetched them. It's not a bug — it's a distributed caching layer doing its job.
Flushing your local DNS cache can help you see the updated records sooner. On macOS: sudo dscacheutil -flushcache. On Windows: ipconfig /flushdns. On Linux: sudo systemd-resolve --flush-caches.
Nameserver Changes vs Record Changes
Changing a single DNS record only requires the resolvers that cached that record to update. Changing nameservers involves TLD registries updating their delegation records — inherently slower. The .com TLD updates nameserver delegations within a few hours, but individual resolvers still need to expire their cached NS records before querying the new ones.
When DNS Isn't the Problem
If DNS has propagated but your site still shows old content, look elsewhere first. Browser cache is the most common culprit — test in an incognito window. CDN cache is next — purge it. Application cache follows. And if the new SSL certificate isn't valid for your domain, browsers will block the page regardless of what DNS says.
🔍 DNS Lookup Tool
Check current TTL values and record states from multiple resolvers.