DNS Propagation
Query the same DNS record from every prober region in parallel. Spot stale anycast nodes, propagation gaps, and out-of-sync geographies at a glance.
Loading prober map…
Only run these tools against systems you own or are authorized to test. Using them to scan or probe systems without permission violates our Terms.
Monitor this 24/7 — get alerts on the first failure.
What is DNS Propagation?
DNS propagation is the lag between updating a record at your authoritative nameserver and the rest of the world actually seeing the new value. The authoritative answer changes instantly. Every resolver everywhere — your ISP's, Cloudflare's, your customer's office Wi-Fi — keeps the old answer until its cached TTL expires. There's no broadcast, no push notification, no "DNS update" event. Just clocks running independently in tens of thousands of caches.
This tool runs the same lookup from every WatchFor prober region simultaneously and shows you a world map of what each region's resolver currently sees. Green for the new value, yellow for old/different, grey for no response yet. It's the closest thing to a real-time picture of how far your DNS change has spread — and a fast answer to the question every engineer asks five minutes after a DNS deploy: "is it actually live yet?"
How it works
A single query you submit fans out across the prober fleet in parallel:
- 1Fan out to every active region — We send the same
A/AAAA/CNAME/MX/TXT/NSquery from each prober pod (currently 14+ regions across North America, Europe, Asia, South America) at the same time. Each pod uses its local resolver by default — the closest geographic answer it would normally serve. - 2Per-region timeout of 6 seconds — Slow region =
timeoutstatus, not a wedged UI. The whole roundtrip completes under 8 seconds no matter how many regions hang. Probers that can't reach any resolver surface asunreachable. - 3Collect, compare, render — Each result comes back with the rdata that region saw, the resolver used, and the elapsed time. We diff against the first responder's answer so the map can colour-code matches vs. mismatches without you eyeballing 14 separate values.
- 4Optional resolver override — Force every region to use the same upstream resolver (e.g.
8.8.8.8) if you want to compare anycast cache state across geographies. Or use Random mode where each prober picks a different public resolver — maximises upstream diversity in one check.
When you'd use it
Did my DNS change deploy yet?
You updated the A record 4 minutes ago. Authoritative says new value, but you're not sure who else sees it. Map answers in under 8 seconds — green markers = caught up, yellow = still serving old. If most regions are still yellow, the answer is "wait another TTL period."
GeoDNS verification
Your CDN returns different IPs based on the geographic origin of the query. The propagation map shows you the IP each region actually got — useful for confirming that your São Paulo edge serves the South American pod's lookup, not the Frankfurt edge.
Anycast resolver health spotting
Public resolvers like 1.1.1.1 run as anycast — different nodes in different cities, each with independent caches. Sometimes one anycast node returns a stale answer because its cache hasn't refreshed. Run the propagation check with the Random resolver mode and you'll see which specific resolver node is out of sync.
TLS / TXT-based verification at scale
Domain validation records (_acme-challenge.example.com TXT, Google Search Console verification, GitHub Pages CNAME verification) need to be visible from wherever the verifier polls — usually a different region than your own. Confirm before you press "verify."
Pre-cutover sanity check
You're about to flip 100% of traffic from old origin to new. Before pressing the button, run a propagation check on the destination's A record. If 13 of 14 regions see the new value, you're good. If 3 are still on the old IP, hold the cutover for another TTL.
Reading the result
Status per region
responded = the resolver returned an answer (success field tells you whether it was a positive answer or NXDOMAIN). timeout = the resolver took longer than the per-region 6s budget. unreachable = couldn't even connect to the resolver (rare; usually means the resolver IP itself is misconfigured). error = upstream returned a SERVFAIL or similar.
rdata comparison
The map colours each marker by whether its rdata matches the "reference" answer (first region that responded successfully). Green = matches, yellow = different but still a valid answer, red = SERVFAIL/NXDOMAIN. A fully-green map means your change has reached every region in the fleet. A mix means propagation is in progress.
Per-region latency
Sub-100ms means the regional resolver had the answer cached. 100-500ms means cold cache, full recursive resolution. >1s means something is unhealthy on the upstream path — useful for spotting flaky authoritative servers or congested links between resolver and authority.
Resolver field
Each row shows which resolver IP that region actually used. Default mode = the prober's local resolver. Explicit mode = all regions used the resolver you specified. Random mode = each region was assigned a different public resolver, useful for catching one specific resolver's stale cache that wouldn't show otherwise.
Common pitfalls
"Some regions are still showing the old value — what's wrong?"
Almost always: TTL hasn't elapsed yet. Look at the TTL of the old answer in the affected region. If it's 47 seconds, that resolver will re-fetch in 47 seconds. There's no way to flush a third-party resolver's cache. Just wait, or lower your authoritative TTL before the next change so propagation completes faster.
Map shows green everywhere but my own laptop still sees the old IP
Your OS or browser has its own DNS cache, separate from any resolver. Flush it (sudo dscacheutil -flushcache on macOS, ipconfig /flushdns on Windows, resolvectl flush-caches on Linux). Or restart your browser. Or use a private window. The map is right; your local cache is stale.
Random resolver mode gives inconsistent results
That's the point of Random mode — every prober gets a different resolver, so you see what resolver A vs. resolver B vs. resolver C is currently caching. To see propagation across geography rather than across resolvers, use the default mode (each region uses its local resolver) or pin a specific resolver IP for all regions.
Tool says "no active public locations"
We're temporarily down to zero public prober regions — usually deploy-window or capacity rebalancing. Refresh in a minute, or use a single-region DNS lookup as a fallback.
Run DNS Propagation on every change, not just once.
Get alerts the moment something breaks — across HTTP, DNS, SSL, RDAP, ping, blacklist and more. Free forever for 10 monitors. No card.
Start freeFrequently asked questions
How fast does DNS propagate?
Can I force resolvers to flush my old DNS records?
rndc flush, Unbound unbound-control flush_zone). For third-party resolvers like Cloudflare or Google, the only path is TTL expiry. Set short TTLs before making the change to shorten the propagation window.Why do some regions show different IPs even after my DNS "finished" propagating?
dig with +trace against the same domain to confirm the authoritative behavior is intentional.How is this different from running dig from a server in each region?
dig invocations would output.