---
title: Free DNS Propagation Checker
description: Check how a DNS record looks from every WatchFor prober region at once, and get an A+ to F DNS health grade: nameservers, delegation, DNSSEC, CAA and propagation, with the fix for every problem. No signup.
canonical: https://watchfor.io/dns-propagation-checker
---

# Free DNS Propagation Checker

## 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.

[How to use this tool](/blog/how-to-check-dns-propagation)

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](/legal/terms).

## The DNS health grade scale

Every check of a domain also grades its zone : the delegation, every nameserver asked directly, the SOA, DNSSEC and CAA — read from your nearest probe location — plus how consistently the record answers from every location on the map. If we could not reach the nameservers from our side, there is no grade.

A+ Excellent

At least two nameservers on separate networks, every one answering authoritatively with the same serial, the parent zone and the zone agree, DNSSEC validates, CAA is published and every location sees a consistent answer.

A Good

Healthy, one step short of A+: usually no DNSSEC or no CAA record, all nameservers on one provider's network, an unusual negative-caching TTL, or a record still propagating.

B Needs attention

A real weakness: nameservers out of sync, the parent and the zone list different nameservers, all nameservers in one /24, a nameserver that does not answer, or several locations that cannot resolve the record.

C Weak

A lame nameserver — listed, but refusing or not answering authoritatively for the zone — or only one nameserver.

F Failing

The domain does not resolve, or DNSSEC is broken so validating resolvers (Google, Cloudflare, Quad9 and most ISPs) refuse to answer.

## Every rule, in full

The grade starts at A+ and each problem can only lower the ceiling, so the grade is always explained by the worst finding in the report. Rules version dns-2026.10b .

Grade at most When

F The domain does not resolve and no nameserver answers authoritatively

F DNSSEC is bogus: a DS record at the parent, but signatures that do not validate (resolvers return SERVFAIL)

C A lame nameserver: listed, but it refuses, fails or answers without authority for the zone

C Only one nameserver

B A nameserver that does not answer from our location while the others do

B SOA serial differs between nameservers of the same network (several DNS providers numbering the zone independently are reported, not graded)

B The parent zone and the zone itself list different nameservers

B Every IPv4 nameserver address sits in one /24

B Propagation: 2 or more locations (or 20 %) cannot resolve the record while most can

A Every nameserver on one network (ASN). Anycast providers often do this, so it only costs A+

A DNSSEC not enabled (no DS at the parent), or keys published without a DS

A No CAA record limits which CAs may issue certificates

A Negative-caching TTL (SOA minimum) outside 300 s – 1 day

A Propagation: locations disagree on an NS, MX, TXT or CNAME answer (still propagating)

— SOA refresh / retry / expire outside the RFC 1912 ranges (they only matter to secondaries that pull the zone by transfer)

— NS TTL under 5 minutes or over 2 days; one location that cannot resolve; A / AAAA answers that differ by region (normal for CDNs and GeoDNS)

[How WatchFor grades everything the same way](/grades#dns-health)

Monitor this 24/7 — get alerted when a failure is confirmed.

[Start free](/auth/sign-up)

## 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 and a table of what each region's resolver currently sees: the records each one returned, side by side. Green means a region answered with records, amber that it answered with none, grey that it didn't answer in time. 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?"

Every check of a domain also earns a DNS health grade , A+ to F, on the same WatchFor Grade scale as our SSL/TLS and mail grades. From your nearest probe location we read the delegation at the registry, ask every nameserver directly whether it serves the zone and which version, and check the SOA, DNSSEC and CAA; the map adds what no single-location checker can see — whether the record answers consistently around the world. The grade starts at A+, each problem can only lower it, and every reason is listed with its fix. The [DNS Health Checker](/dns-health-checker) runs the same check and opens on the grade.

## How it works

A single query you submit fans out across the prober fleet in parallel:

- 1 Fan out to every active region — We send the same A / AAAA / CNAME / MX / TXT / NS query from every active WatchFor probe location at the same time (20 locations worldwide when this was written). Each pod uses its local resolver by default — the closest geographic answer it would normally serve.
- 2 Per-region timeout of 6 seconds — Slow region = timeout status, 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 as unreachable .
- 3 Collect, compare, render — Each result comes back with the rdata that region saw, the resolver used, and the elapsed time. The colours show whether each region answered; the values themselves are listed per region, so a stale one stands out when you read down the column.
- 4 Optional 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.
- 5 Grade the zone — In parallel, one probe at your nearest location reads the parent zone's delegation (NS + glue), asks each nameserver for the SOA and NS set without recursion, checks DNSSEC through a validating resolver (DS, DNSKEY, and whether signatures validate) and reads CAA. Those facts plus the propagation answers go through the published rules (rules version dns-2026.10b ) — the result is the letter at the top of the report.

## 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. The map answers in under 8 seconds; read the value each region returned. If most regions still show the old one, 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 every region sees the new value, you're good. If 3 are still on the old IP, hold the cutover for another TTL.

## Reading the result

### The DNS health grade

A+ = at least two nameservers on separate networks, all authoritative and in sync, the registry and the zone agree, DNSSEC validates, CAA is published and every location agrees. A = healthy but one step short — usually no DNSSEC or CAA, or all nameservers on one provider's network. B = a real weakness such as serials out of sync within one provider, a registry/zone NS mismatch, all nameservers in one /24, a silent nameserver or several regions that cannot resolve the record. C = a lame nameserver or only one nameserver. F = the domain does not resolve, or DNSSEC is broken. No letter means we could not measure from our side — never a verdict on your domain.

### Status per region

responded = the resolver returned an answer, positive or not. timeout = the resolver took longer than the per-region 6s budget. unreachable = the probe couldn't reach the resolver (rare; usually means the resolver IP itself is wrong). error = the lookup failed — SERVFAIL, or a name that returned nothing (the status column says which).

### Marker colours

The map colours each marker by whether the region answered, not by what it answered. Green = records came back, amber = an answer with no records or a status other than NOERROR , red = the lookup failed, grey = timeout or unreachable. Green everywhere means every region resolved the name; whether they all see the new value is in the value column, row by row. Several different values can be normal for GeoDNS and CDN-fronted names.

### 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. Check the record's TTL at the authoritative server ( dig <name> @<nameserver> +noall +answer ): a resolver that cached the old answer keeps it for up to that long. 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.

### Every region shows the new IP but my own laptop still sees the old one

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 alerted when an outage is confirmed — across HTTP, DNS, SSL, RDAP, ping, blacklist and more. Free forever for 15 monitors. No card.

[Start free](/auth/sign-up)

## Frequently asked questions

What does the DNS health grade check? Nameserver count and network diversity (ASN and /24), whether each nameserver answers authoritatively, SOA serial sync between nameservers, the delegation at the parent registry versus the NS records inside the zone, SOA timers, DNSSEC (signed, validates, or broken), CAA, NS TTL, and — from every probe location — whether the record you looked up resolves consistently. The full rule table, with the highest grade each problem allows, is on this page.

How is the DNS health grade calculated? Every domain starts at A+. Each finding caps the grade at the highest letter it allows — a lame nameserver at C, out-of-sync serials within one provider at B, no DNSSEC at A — and the worst finding wins; nothing adds points back. So the letter is always explained by the first reason in the list. Its rules version ( dns-2026.10b ) is shown with every result.

Why does my domain on a big DNS provider get A, not A+? The usual reasons are DNSSEC not enabled, no CAA record, or every nameserver on one provider network. Large anycast providers are very resilient, so a single network only costs the step from A+ to A — but the provider is still one point of failure. Each of these shows up as a note with the exact fix.

Why is there no grade for my domain? Because we could not measure it honestly: the zone checks did not run from our location, every nameserver timed out from our side while the domain still resolves (a network path problem, not your DNS), or the domain is not delegated at all. We never turn our own network trouble into a bad grade for you — run the check again in a minute.

How fast does DNS propagate? It's not about speed — it's about TTL. A record with TTL 60s will propagate worldwide in roughly 60s after the authoritative change (each resolver re-fetches on its own schedule). TTL 86400 (24h) will take up to 24h for the last cached copy to expire. There is no "global push" — propagation is just TTL-driven eviction at every individual resolver.

Can I force resolvers to flush my old DNS records? No, not the ones you don't operate. You can flush your own resolver (BIND 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? GeoDNS, anycast load balancing, or split-horizon configuration. If your authoritative nameserver is configured to return different rdata depending on the resolver's IP, the propagation check shows you exactly that. Use 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? Functionally identical, just parallelised and visualised. We run the same UDP/TCP query from real probers in real geographic locations. The map is a renderer for what 20 separate dig invocations would output.

Does the random resolver mode use my queries to poison caches? No — DNS queries are read-only. You're asking each resolver what it currently has cached for your domain. There's no mechanism to write into a public resolver's cache through normal queries.

What's the maximum number of regions you check from? However many probe locations are currently active and public — 20 worldwide when this was written. Enterprise plans can add private locations that run inside your own network.

Why is my TXT record showing in some regions but not others? Either the authoritative servers haven't fully replicated the new record (multi-server zones with eventual consistency), or some regions' resolvers are still serving an old NXDOMAIN cache. SERVFAIL = upstream broken. NXDOMAIN with TTL > 0 = the resolver is caching the absence of the record ("negative caching") and won't re-fetch until that TTL expires.

Can I monitor a record continuously instead of one-shot? Yes — that's what the paid plans do. Set up a DNS monitor at WatchFor and it checks the record on a schedule from the locations you pick, and alerts when the lookup fails or the answer stops matching the values you expect. The one-shot tool here is for debugging; continuous monitoring is the productised version.

## Related dns tools

- [DNS LookupResolve A, AAAA, MX, TXT, NS, SOA, CNAME, PTR, CAA, SRV records for any domain.](/dns-checker)
- [Whois LookupModern RDAP-based domain registration lookup: registrar, expiry, nameservers, status flags.](/whois-lookup)
- [DNS Health CheckerGrade a domain's DNS A+ to F: how many nameservers it has and on which networks, lame delegation, whether the registry and the zone agree, SOA serials, DNSSEC and CAA, with the fix for every problem. Then see what every probe location answers, on a map.](/dns-health-checker)
- [A Record LookupFind the IPv4 address a domain resolves to — every A record, from the resolver of your choice. Spot a stale IP after a migration, a missing record behind a 'site can't be reached', or a round-robin set that is one address short.](/a-record-lookup)

---

Canonical page: https://watchfor.io/dns-propagation-checker · Site guide: https://watchfor.io/llms.txt