You change an MX record, or repoint an A record to a new server, and then comes the anxious part: some people see the new value, some still hit the old one, and there’s no obvious way to tell how far along the change is. That in-between window is what everyone means by “DNS propagation” — and this tool exists to make it visible by asking several independent resolvers the same question at the same moment.
Why DNS changes aren’t instant
DNS is built to be cached, aggressively, because caching is what keeps the system fast and the authoritative servers from melting under load. When a resolver looks up a record, it holds onto the answer for a length of time set by that record’s TTL (time to live), measured in seconds. Until that timer expires, the resolver keeps serving the cached value — even after you’ve updated the record at the source. So “propagation” isn’t really data spreading across the world; it’s a bunch of independent caches expiring at their own pace and re-fetching.
The practical upshot: if a record had a TTL of 3600, a resolver that cached the old value can keep serving it for up to an hour after your change. Lowering the TTL before a planned change (say to 300 seconds) shrinks that window; raising it back afterwards restores efficiency.
Authoritative vs. recursive — who holds the truth
Two kinds of servers are involved, and confusing them is the root of most propagation confusion:
- Authoritative servers hold the real, source-of-truth zone for your domain (your DNS host or registrar). Change a record here and it’s updated immediately at the source.
- Recursive resolvers are the caching middlemen your devices actually query —
8.8.8.8,1.1.1.1, your ISP’s resolver. They fetch from the authoritative servers and cache the result per its TTL.
Your change is live on the authoritative side the instant you save it. What you’re waiting on is every recursive resolver’s cached copy to expire. That’s why the answer looks different depending on who you ask.
What this tool compares
We query the domain’s A record from several well-known public resolvers at once — Cloudflare, Google, Quad9, OpenDNS, Level3, DNS.WATCH. If they all return the same value, the change has reached those caches and you can be reasonably confident it’s widely visible. If they disagree, either the change is still working through their TTLs (wait and re-check), or you’re running split-horizon or GeoDNS, where different resolvers are supposed to get different answers by design.
One honest caveat: this compares distinct resolver caches, not true geographic vantage points. Two of these resolvers may share infrastructure, and none of them represents “what a user in Tokyo sees” precisely. It’s a strong, fast signal of propagation across major public resolvers — not a global census.
A sane way to roll out DNS changes
- Lower the TTL on the record a day or two before the change, so caches hold the old value for only a short time.
- Make the change at your authoritative DNS host.
- Watch it converge here until the resolvers agree on the new value.
- Raise the TTL back up once you’re confident, and if it was a mail-related change, confirm the destination with the MX lookup and SMTP test.
Frequently asked questions
- How long does DNS propagation take?
- It’s governed by the record’s TTL. A 3600-second TTL can take up to an hour to update everywhere; a 300-second TTL, about five minutes. Lower the TTL before a planned change to shorten the wait.
- Why do different resolvers show different results?
- Each resolver caches independently, so their copies expire at different times mid-change. Persistent differences usually mean split-horizon or GeoDNS serving different answers on purpose.
- What’s the difference between authoritative and recursive DNS?
- Authoritative servers hold the source-of-truth zone and update instantly. Recursive resolvers are the caches your devices query and hold answers per the TTL. Propagation is those caches expiring.
- Can I speed up propagation?
- You can’t force public resolvers to drop cached entries, but lowering the TTL before a change limits how long stale values linger. You can only flush your own resolver’s cache, not theirs.