You changed a DNS record — is the internet seeing the new value yet? This tool asks the same
question to several independent resolver networks at once (Google, Cloudflare,
DNS.SB, AliDNS, and our own Cloudflare Worker) and compares the answers. When they all agree,
your change has propagated; while they're mixed, you can see exactly which networks still hold
the old value and how long their caches can last.
"Propagation" is really just cache expiry: nothing is pushed to resolvers —
each one keeps your old record until its TTL runs out, then fetches the new one. The queries
run straight from your browser over DNS-over-HTTPS, so results are instant and
re-checkable with one click. For inspecting a single resolver's full answer in depth — SOA
serials, CAA, SRV, structured MX fields — use our
DNS Lookup instead; and if you're unsure which record type you
changed, see DNS record types explained.
What DNS propagation actually is
When you edit a DNS record, you're editing the zone on your authoritative name
servers. Nobody notifies the world's resolvers about it. Instead, every resolver that ever
looked up your domain holds a cached copy stamped with a TTL — a maximum age in seconds — and
simply keeps serving that copy until it expires. What we call "propagation" is thousands of
independent caches timing out at different moments and re-fetching. That's why the transition
is messy by design: for one TTL-length window, part of the internet sees the new value and part
sees the old one, and both are behaving correctly.
This checker makes that window visible. Each resolver network below runs its own cache, so
comparing them side by side shows the propagation front mid-flight: which networks have
converged on your new record, which are still serving the old one, and — via the TTL column —
the worst-case wait until each straggler must refresh.
An honest note on "checking from 50 locations"
Propagation checkers love world maps with green checkmarks on Sydney and São Paulo. The
uncomfortable detail: the big public resolvers are anycast — 8.8.8.8 is one
address answered by data centers all over the planet, and each query lands at the one nearest
the asker. A map pin mostly tells you which of Google's caches happens to sit near that probe
server, not what "Australia" sees. We'd rather be straight with you: this tool compares
independent resolver networks, which is the comparison that actually predicts
what your visitors get — nearly everyone resolves through these networks or an ISP resolver
obeying the same TTLs. In exchange you get checks that run from your own browser with zero
server round-trip, zero ads, and a one-click re-check while you watch a migration converge.
A migration checklist that avoids the wait
- One TTL before the change: lower the record's TTL to 300 seconds. (If the
old TTL was 86400, do this a day ahead — resolvers must first expire the old, long TTL.)
- Make the change at your DNS provider, and keep the old server running.
- Verify here: run a check, wait for the green "propagated" banner — with a
300-second TTL you're typically converged in minutes.
- Keep the old destination alive for at least one original-TTL period for
stragglers with long-lived caches (and mobile OS caches that ignore short TTLs).
- Raise the TTL back (3600–86400) to cut query load and add resilience.
Changing name servers rather than a record? Expect the slow path: NS and registry
glue records commonly carry 24–48 hour TTLs, so keep the zone identical on both old and new
providers during the handover.
Related tools
- DNS Lookup — deep-inspect a single resolver's records for
one domain: SOA, CAA, SRV, PTR, structured MX and TXT breakdowns.
- WHOIS Lookup — check the registrar-side story: name
servers on file, domain status, and expiry dates.
- What Is My IP — confirm what address your own connection
resolves and presents to the world.
Frequently asked questions
How long does DNS propagation take?
Exactly as long as your record's TTL (Time To Live), plus a few minutes of slack — not a fixed number of hours. Every resolver that cached your old record before the change will keep serving it until its copy expires, and the TTL is the maximum age of that copy. If your A record had a TTL of 3600, the whole internet converges within about an hour of the change reaching your authoritative name servers. The professional trick for planned migrations: lower the TTL to 300 seconds (5 minutes) at least one full old-TTL period before the switch, make the change, verify with a propagation check, then raise the TTL back once everything agrees.
Why do different resolvers show different answers?
Because each resolver network caches independently. A resolver that answered a query for your domain five minutes before your change will serve its cached copy until the TTL expires; a resolver that never cached it will fetch the new value immediately. Cache timing differs per network — and within one anycast network, per data center — so during the TTL window it's completely normal to see Google serving the new address while another resolver still returns the old one. Disagreement isn't an error; it's a snapshot of caches mid-expiry. If the answers still disagree long after the TTL has passed, check that all your authoritative name servers are actually serving the new zone (mismatched serials between primary and secondary name servers are a classic cause).
Is "wait 24–48 hours for DNS propagation" true?
Mostly folklore. The 48-hour figure dates from an era of day-long default TTLs and slow registry updates for name-server (NS/glue) changes. For an ordinary record change — updating an A, CNAME, MX, or TXT record at your existing DNS provider — propagation takes one TTL, which is typically 5 minutes to a few hours. The genuine slow case is changing which name servers a domain uses: NS records and registry glue often carry TTLs of 24–48 hours, and there resolvers really can hold the old delegation for up to two days. If a provider quotes "48 hours" for a simple A-record change, they're reciting the folklore, not describing your record.
Does this tool check DNS from different countries?
Honestly: no, and neither do most tools that claim to. Every browser-reachable public resolver (Google, Cloudflare, DNS.SB, AliDNS) is anycast — one IP address served by many data centers, and your query lands at the one nearest you. So this tool compares independent resolver networks, each with its own cache, rather than literal geographies. That's the comparison that matters for "has my change propagated?", because your visitors overwhelmingly use exactly these big resolver networks or their ISP's (which obeys the same TTLs). The trade-off for map-pin tools' geographic theater is ads and a server round-trip; this one queries straight from your browser and updates the moment you re-check.
What does the TTL column tell me?
The maximum remaining wait for that resolver. A cached DNS answer includes a countdown: the TTL shown is how many seconds the resolver may keep serving its current answer before it must re-fetch from your authoritative name servers. If a resolver is still showing your old IP with a TTL of 9 minutes, it is guaranteed to pick up the new value within 9 minutes — that's your worst-case wait, and a good time to hit Re-check. A full, freshly-fetched TTL alongside the new value means that resolver has already converged.
What do NXDOMAIN and SERVFAIL mean in the results?
They're DNS response codes (rcodes) rather than answers. NXDOMAIN means the resolver says the name doesn't exist at all — expected for a brand-new subdomain that hasn't reached every network yet (negative answers are cached too, per the zone's SOA minimum TTL, so a resolver that recently saw "no such name" may keep saying it for a while). SERVFAIL means the resolver couldn't complete the lookup — often a DNSSEC validation failure or unreachable authoritative servers. Seeing NXDOMAIN from some resolvers and real answers from others is the classic signature of a new record mid-propagation.