dnswatchdog.iodocs

Propagation Checker

Check how a DNS change has propagated worldwide — compare the authoritative answer against 16 public resolvers across the globe and watch each one converge in real time.

Open Propagation Checker

What it does

When you change a DNS record, resolvers around the world keep serving the old value until their cached copy expires. The Propagation Checker shows you exactly where a change has and has not landed yet.

You enter a record name and type. DNS Watchdog first reads the authoritative answer directly from the zone's own nameservers, then queries 16 public recursive resolvers around the world at once and compares each one against the authoritative value. The results render as a world map — one beacon per resolver, coloured by status — with a matching server list.

Unlike the BIMI Validator and Email Deliverability tools, the Propagation Checker works on any public record, not only domains in your inventory. It stores nothing — each check is live.

Running a check

Enter a fully-qualified record name (for example www.example.com) and choose a record type. The supported types are:

A, AAAA, CNAME, MX, TXT, NS, SOA, CAA, SRV

The name must be a valid domain of at least two labels plus the root (a bare single label such as localhost is rejected) and at most 253 characters. A trailing dot is optional.

While any resolver is still serving a stale answer, the check re-polls automatically every 30 seconds and updates the map in place. Polling stops once every resolver has either synced or been marked unreachable, so you can leave the page open and watch a change roll out.

Statuses

Each resolver is graded independently:

StatusColourMeaning
SyncedGreenThe resolver returns the same value as the authoritative nameserver
PendingAmberThe resolver has not yet caught up — it still serves the old value, or nothing yet
UnreachableGreyThe resolver did not answer within the timeout after retrying

An unreachable resolver does not fail the check — public resolvers occasionally rate-limit or drop foreign queries, and the remaining resolvers still report normally. The summary counts synced, pending and unreachable resolvers so you can see overall progress at a glance.

For a resolver that is still pending, the per-resolver TTL is the countdown to synchronisation: it is how long that resolver will keep serving its cached copy before it must fetch the new value. The map surfaces this as a live countdown.

How answers are graded

The checker normalises both answers before comparing — it collects the records of the requested type from the full response (following CNAME chains where present), lower-cases domain names, and compares TXT payloads byte-for-byte. Two cases are handled deliberately and are worth understanding:

  • Deleted records. If you have deleted a record, the authoritative answer is empty. A resolver that still serves the old value is correctly shown as pending, and it flips to synced once its cache clears — deletion propagation is a first-class case, not an error.
  • A and AAAA records that differ but are both present are graded as synced, not pending. Content delivery networks and geo-aware DNS (CloudFront, Vercel, Cloudflare and similar) hand out different edge IP addresses depending on where the query originates, so a resolver returning a different but valid address is serving a legitimate regional edge rather than a stale cache. The interface flags these as a different edge rather than a mismatch. All other record types are expected to match exactly, so a difference there is treated as pending.

The vantage points

The 18 resolvers are spread across North America, South America, Europe, Africa, Asia and Australia so you get a genuinely global picture. They were chosen for reliability — public resolvers that timed out or rate-limited cross-border queries during testing were excluded.

ProviderResolver IPLocation
Google Public DNS8.8.8.8Mountain View, US
Cloudflare DNS1.1.1.1San Francisco, US
Vercara UltraDNS Public64.6.64.6Sterling, US
OpenDNS (Cisco)208.67.222.222San Francisco, US
CIRA Canadian Shield149.112.121.10Ottawa, CA
UOL DNS200.221.11.100São Paulo, BR
Quad99.9.9.9Zurich, CH
CleanBrowsing185.228.168.9Frankfurt, DE
CZ.NIC ODVR193.17.47.1Prague, CZ
Hurricane Electric (London)216.66.80.26London, GB
AdGuard DNS94.140.14.14Nicosia, CY
Liquid Intelligent Technologies5.11.11.5Johannesburg, ZA
Yandex DNS77.88.8.8Moscow, RU
114DNS114.114.114.114Nanjing, CN
AliDNS223.5.5.5Hangzhou, CN
NTT129.250.35.250Tokyo, JP
DNS.SB (xTom)185.222.222.222Tokyo, JP
Telstra139.130.4.4Sydney, AU

Locations are the operator's nominal site. Because most of these resolvers are anycast, the node that actually answered your query may be closer to you than the city shown.

Interpreting a check

  • All green — the change has propagated everywhere the checker can see. Note that individual client resolvers not in this list may still be caching the old value until their own TTL expires.
  • Mostly green, a few amber — propagation is in progress; the amber resolvers' TTL countdown tells you roughly how long until they catch up.
  • A grey resolver — that resolver did not answer this round; it is not evidence of a propagation problem.
  • Authoritative lookup failed — if DNS Watchdog cannot find or reach the zone's authoritative nameservers for the name you entered, the check reports an error. Confirm the name is correct and the zone's delegation is healthy (see Broken Delegation).

On this page