You've changed the A record, pointed the nameservers to the new server, but when you type the site address into your browser, the same old page comes up. Or worse: the new site opens for you and your customer still sees the old version. This is the moment when most people say "we have to wait 24 to 48 hours." That number is almost always wrong, and waiting instead of troubleshooting is just a waste of time.
DNS propagation is an instantaneous event, not a time window. The moment the record is registered on your authoritative server, propagation is done. What takes time is the expiration of cached copies in resolvers and intermediary machines. So the right question isn't "how long does it take," but "what is still holding onto the old version."
Why "24 to 48 hours" is almost always wrong
That number comes from an era when the default TTL for records was 86400 seconds, exactly one day, and some providers recommended double that to make sure all caches had expired. Today the default TTL in most panels is between 300 and 3600 seconds. That means the worst theoretical case is one hour. In practice, what you see usually resolves within 5 to 30 minutes.
The 48-hour number was a safety margin, not a technical fact. If someone tells you this today, they're dodging your real question.
What exactly does TTL control
TTL tells the resolver how many seconds it can keep this answer in memory. The point many people don't know: TTL only applies from the moment the resolver cached that record, not from the moment you change it. If the resolver cached your record 5 minutes ago with a TTL of 3600, it will keep serving the old version for another 55 minutes, even if you just lowered the TTL to 60 seconds.
So lowering the TTL after the change is useless. It must be done before the change.
The right method: lower the TTL before the migration
If you know you want to switch servers tomorrow at noon, lower the TTL of your A, AAAA, and CNAME records to 300 seconds today. Wait a day for the previous caches with the old TTL to expire. Then make the change. Now your propagation window is about five minutes, not a day.
The order of operations is like this:
- 24 hours before: set the TTL to 300 and wait for the old cache to expire.
- Change the A record to the new server's IP.
- Use
digfrom several different points to verify the new answer is returned. - After it stabilizes, return the TTL to its normal value.
To check, ask an authoritative resolver, not your local cache:
dig +short A example.com @1.1.1.1
dig +short A example.com @8.8.8.8
dig +trace example.comIf the answers from 1.1.1.1 and 8.8.8.8 are the same and show the new IP, propagation at the public level is done. If one of them still returns the old IP, that resolver still has a cache and its remaining TTL must run out.
Why some users still see the old site
There are three layers of caching and most troubleshooting only looks at the first layer:
- ISP resolver cache: some local ISPs ignore TTL and hold the old answer for hours. This is outside your control.
- Operating system cache: on Windows it's cleared with
ipconfig /flushdnsand on Linux withsystemd-resolve --flush-caches. - Browser cache: it's independent of DNS and isn't cleared by changing the record.
Here's where people go wrong: the user sees the new IP in dig, concludes DNS is fixed, and then ignores the customer's complaint. Meanwhile the customer is behind an ISP with a stubborn resolver. The practical solution is to keep both servers up for a while so traffic comes through both paths.
Zero-downtime migration: the point that's rarely mentioned
If you have an e-commerce site, the DNS propagation window isn't just a technical matter. A user who's in the middle of checkout and suddenly gets routed to another server loses their shopping cart. The solution is to prepare the database on the new server before changing the record, and after the change keep both servers in sync for a while. For this, migrating WordPress without a plugin is a safer path than relying on migration plugins mid-task.
The cost of this method: you have to pay for two servers simultaneously for a few hours and do manual synchronization. If it's a personal site or a small blog, this is overkill and you can accept the risk. For a store, no.
CNAME and MX records behave differently
A records propagate quickly because they're just an IP. CNAME is a chain and each link has its own TTL; if your CNAME points to another domain that also has a CNAME, the total delay increases. MX records for email usually have a higher TTL and changing them can send emails to the old server for several hours. If you're moving email at the same time as the site, do these two separately and with a gap between them.
Comparing options: lowering TTL or waiting
| Approach | Propagation window | Cost | Suited for |
|---|---|---|---|
| Lowering TTL in advance | About 5 minutes | Slightly more load on resolvers | Active and e-commerce sites |
| Changing with default TTL | 30 to 60 minutes | Risk of seeing the old version | Low-traffic sites |
| Waiting 24 to 48 hours | Same window, for no reason | Lost time | No one |
My choice is the first method. The only condition that makes the second method acceptable is that your site has negligible traffic and a short outage doesn't matter to you.
Tools that speed things up
To check propagation from multiple geographic points, use DNS propagation checker services, but keep in mind these tools also only ask their own resolvers, not the whole world. If you want to make sure the new server actually responds correctly, test it with curl and a Host header before changing the record:
curl -I -H "Host: example.com" http://192.0.2.10/If it returns a 200 response, the new server is ready and you can safely change the record. This one small step eliminates half the headaches after migration.
If you work with WordPress, after migration be sure to clear the object cache and page cache, otherwise DNS may be correct but the site still shows a cached version. For a quick status check from the terminal, essential WP-CLI commands has a few ready-made commands for clearing cache and checking database status.
Frequently asked questions
How long does DNS propagation really take?
In practice between 5 and 60 minutes, depending on the record's TTL and the ISP resolver's behavior. If you lowered the TTL to 300 seconds in advance, it usually finishes in under 10 minutes. The 24 to 48 hour number belongs to an era when the default TTL was one day.
Why do I see the new site but my customer sees the old one?
Because the DNS cache on the user's side or their ISP hasn't expired yet. This situation continues until the remaining TTL runs out and can't be accelerated from your side. The only practical solution is to keep the old server up during this window so old users also get the correct answer.
Does lowering TTL after changing the record help?
No. TTL applies from the moment the resolver cached the record, not from the moment you change it. If the resolver cached the old version with a TTL of 3600, lowering the TTL to 60 seconds has no effect on that cache. Lowering the TTL must be done at least a day before the change.
How do I know DNS propagation is done?
By asking several public resolvers directly. If dig +short A example.com @1.1.1.1 and the same command with @8.8.8.8 both return the new IP, propagation at the public level is done. For more certainty, test the new server with curl -I -H "Host: example.com" to make sure it returns the correct HTTP response.
In summary: lower the TTL before migration, test the new server before changing the record, and after the change keep both servers up for a while. If you work on infrastructure where you do these migrations frequently, Linux hosting with full control over DNS and TTL makes this cycle more predictable.
Comments 0
No comments yet — be the first!