How to check DNS propagation (and how long it actually takes)
Just changed an A record and your friend in another country still sees the old site? That's DNS propagation. Here's how to verify when it's actually done — and how long it can take.
DNS propagation is the process of DNS resolvers around the world picking up a change you made to your domain's records. When you change an A record, your local DNS cache might update within seconds — but recursive resolvers on the other side of the planet have their own TTLs and cache windows. Until those expire and they re-query the authoritative nameserver, they'll keep handing out the old answer.
Why it's not instant
Three things contribute to propagation delay:
- TTL — the time a resolver is allowed to cache your old answer before re-querying. If your record's TTL is 86400 (24 hours), some resolvers will hold the old answer that long.
- Negative caching — if a record doesn't exist, resolvers cache the NXDOMAIN for a while too. This adds another delay on top of the TTL.
- Resolver refresh intervals — some resolvers (notably big ISP ones) actively hold past their TTL for performance reasons. The behavior varies by operator.
The official upper bound per RFC 1035 is 48 hours, but in practice most major resolvers refresh within minutes to a few hours. If your TTL was already low (300 seconds), propagation is usually complete within 5-15 minutes for any resolver that's paying attention.
How to check it
You can't just query one resolver — you'll see what your resolver's cache has, which may not match what your user's resolvers see. The right approach is to query several resolvers at once and compare the answers:
- Pick 5-10 well-known public resolvers that are geographically and operationally diverse.
- Query each one for the same record type on the same domain.
- Compare the answers. If they all return the same set of records, you've propagated.
Some resolvers are anycast (Cloudflare 1.1.1.1, Google 8.8.8.8, Quad9 9.9.9.9) — they'll route to the nearest instance and that instance's cache might not match what a regional resolver sees. That's why querying a mix of anycast and unicast resolvers gives a more honest picture.
Run the check from your browser — queries 8 resolvers in parallel and shows whether they agree:DNS Propagation Checker.
Speed it up before the change
If you know you're going to change a record soon, lower its TTL 24-48 hours in advance. Set A example.com 300 (or whatever your provider's lowest allowed is), wait for the previous TTL to fully expire, then make the change. After the change propagates, raise the TTL back to whatever you actually want (an hour is a common default).
If you're in a hurry (a migration went sideways and you need to roll back), there's no shortcut. Wait for the TTL to expire, or accept that some users will see the old answer until their resolver refreshes. This is one of those "the protocol works as designed, you just don't like it" situations.
Keep reading
- How to do a DNS lookup (and why you'd want to)DNS lookups are the first step in almost every network troubleshooting flow. Here's how they work, the record types that matter, and how to run them from your browser.
- How to read an open port (and when to actually worry)An 'open port' isn't a vulnerability by itself — it's information. Here's how to tell whether a port being open is fine, suspicious, or actively dangerous, and what to do about each case.
- WHOIS lookup explained: what's actually in a domain registration recordWHOIS is the public directory of who owns a domain. Here's what each field means, why some of them are redacted, and how to read a registration record.