2026-09-14 · IPV4 Scanner
You changed an A record an hour ago. Your laptop still resolves to the old server. Someone in another office already sees the new one. And a colleague has helpfully suggested you give it 24 to 48 hours.
That last bit is where most of the wasted time comes from. DNS is far more predictable than its reputation suggests, and once you know which number actually controls the delay, you can work out how long a change will take before you make it.
The word does a lot of damage. It sounds like your DNS provider pushes the new record out across the internet while you wait for it to arrive everywhere. That isn't what happens. There's no broadcast and nothing in transit.
DNS works the other way round. Somebody visits your domain, their resolver (their ISP's, usually, or a public one like 8.8.8.8) asks your authoritative name servers for the record, gets an answer, and keeps a copy of it. Everyone else using that same resolver gets the copy. Your name servers don't hear from it again until that copy expires.
So your name servers were serving the new value about a second after you hit save. What you're waiting on is thousands of separate caches, run by people you'll never meet, each expiring on its own schedule.
Every record carries a TTL: a number of seconds telling resolvers how long they're allowed to reuse a cached answer before asking again. A TTL of 3600 means an hour.
Almost everyone gets the next part backwards the first time. The TTL governing your change isn't the one you just set. It's the one that was already sitting in that resolver's cache when you made the edit. If it picked up your record with a 24-hour TTL ten minutes before you changed it, it can keep handing out the old address for another 23 hours and 50 minutes. Your shiny new 300-second TTL doesn't reach it until it comes back to ask.
Which means lowering the TTL and making the change in the same sitting achieves almost nothing. A shame, because that's exactly what people do when they're in a hurry.
The trick is to be impatient a day early:
Done that way, a cutover people block out a weekend for is finished in about the time it takes to make coffee.
It isn't made up. It's real advice attached to the wrong operation.
Changing your name servers at the registrar is not the same as changing a record. Delegation lives up in the TLD's zone, and the registry sets those TTLs, not you. Move your domain to a new DNS provider and yes, it can genuinely take a day or more to settle, with no way to speed it along, because the TTL you'd want to lower was never yours to touch.
Editing an A, AAAA, CNAME, MX or TXT record inside a zone you already control is a different job entirely, governed by that record's own TTL and nothing else. People wait two days for changes that finished before lunch because nobody ever told them these were separate things.
Your own machine is caching. Your operating system keeps a DNS cache, and some browsers keep another one on top of it. You can easily be the last person anywhere still seeing the old site. On Windows, ipconfig /flushdns. On macOS, sudo dscacheutil -flushcache then sudo killall -HUP mDNSResponder. On Linux with systemd-resolved, resolvectl flush-caches.
Negative answers get cached too. Look up a hostname before you've created it and the "no such name" reply gets cached, for a length of time your zone's SOA record controls rather than the record you're about to add. Create it first, then check. This one costs people a surprising amount of time for how simple it is.
Resolvers don't have to respect your TTL. Plenty of them clamp anything longer than their own maximum. A two-week TTL is a request, not a contract.
Different answers in different countries is often correct. If you're behind a CDN, handing out the nearest edge server is the entire point of the thing. Four addresses from four countries isn't a half-finished rollout. It's the product doing its job.
Refreshing the site in your browser is the least reliable test available. It runs through every cache between you and the answer, two of which are on your own computer.
Ask the resolvers directly instead. Our DNS propagation checker queries ten major public resolvers side by side, and it will run the same lookup again from measurement probes on six continents, so you can see whether Asia and South America have caught up rather than just whether it works from your desk. It also separates a real lag from a CDN handing out regional addresses deliberately, which a plain "do they all match?" test gets wrong on most large sites.
If you'd rather see everything a domain publishes at once, the DNS lookup tool is the better place to start.
How long does DNS propagation actually take?
As long as the TTL that was cached before you made the change. Five minutes if it was 300 seconds, a full day if it was 86400. There's no global schedule and no queue you're waiting in.
Can I force other networks to update faster?
No, and nothing sold to you as a "propagation booster" can either. You can't clear a cache you don't control. The only real lever is lowering the TTL ahead of time. A few public resolvers offer a page where you can refresh one name in their own cache, which helps with that one resolver and no others.
Why do two people in the same building see different results?
They're on different resolvers. One's on the office connection, the other's on mobile data or a VPN, and those caches expire independently of each other.
It's well past my TTL and one resolver still disagrees. Now what?
Stop blaming caching and look at your own setup. The usual suspects are two authoritative name servers publishing different data, a stale record left behind at a provider you thought you'd stopped using, or an override at the CDN or registrar that you'd forgotten was there. Check that every name server listed for the domain gives the same answer.