DNS Propagation Checker

What usually brings someone to a tool like this is not "which addresses do twenty resolvers return", but "is my DNS change done, and if not, when will it be?". Those are different questions, and the first does not answer the second.

Divergent answers between resolvers have two distinct causes. The first is caching: a resolver stored the previous value before the change and keeps serving it until the TTL expires. That is propagation in progress, and the time left is a readable number. The second is geographic routing: the domain is served by a CDN or a load balancer that answers different addresses depending on the network the query comes from. In that case nothing is updating and there is nothing to wait for.

A measurable example on this very domain, with publication finished months ago: the authoritative nameservers answer 172.67.135.235 and 104.21.7.88, while 8.8.8.8 and 9.9.9.9 answer 188.114.96.7 and 188.114.97.7. Different addresses, same operator, anycast network. Read without context, that difference looks like a change that has not propagated yet.

The two cases can be told apart by observation. A cache serving a superseded value necessarily has an already-consumed TTL, because it was populated before the change and time passes; an answer just fetched from the origin arrives with a full TTL. So a different value with a full TTL indicates the origin answered that way just now, while a different value with an eroded TTL indicates a previous copy still in circulation, and the seconds left are the remaining TTL.

On top of that reading sits a direct check, when it can be obtained: query the authoritative nameserver with different EDNS Client Subnet values and see whether the answer changes. If it does, geographic routing is detected. If it does not, nothing is concluded, because several CDNs implement geography through nameserver anycast rather than ECS.

Every row in the result gets a class and the reason behind it. Each maps to an observed condition and to a different action.

Propagated. The value matches authoritative, or is one of the values in the published pool. Nothing else to do.

Updating. The value differs and the TTL is already eroded: the cache was populated before the change. The countdown shows how long is left. Third-party caches refresh when the TTL expires; the public flush forms Google and Cloudflare provide act only on their own resolvers.

Regional variant. The value differs but is current: the domain serves different answers to different networks. No waiting required.

Nameservers disagree. The zone's nameservers return different values with misaligned SOA serials. This is a synchronisation issue to fix at the DNS provider. While it lasts, every lookup's outcome depends on which nameserver is asked, which produces intermittent behaviour that is hard to diagnose downstream.

Not resolved everywhere. Some resolvers resolve the name and some return NXDOMAIN. On a recently created record this is almost always negative caching, which lasts as long as the SOA minimum field. If it persists, the zone delegation at the registry is not complete.

Invalid DNSSEC signature. A validating resolver rejects the answer on a signed zone. For users behind a validating resolver the domain is unreachable, so this ranks higher than slow propagation.

Server unreachable. Timeout or refusal. It concerns the resolver rather than the domain: across a wide sample, a few points not answering is ordinary, which is why the row stays grey rather than red.

Many tools in this category show a world map with coloured dots and claim to check from dozens of locations. It is worth understanding what that number means, because in most cases those locations are labels attached to the IP addresses of public resolvers.

The reason is anycast. Resolvers such as 1.1.1.1, 8.8.8.8 and 9.9.9.9 are not in one place: the same IP address is announced from hundreds of data centres, and the one closest to the asker replies. An Italian backend querying 9.9.9.9 is talking to Quad9's Italian PoP, not to Zurich. The check takes one command: dig CHAOS TXT id.server @1.1.1.1 returns fco01, meaning Rome, and dig CHAOS TXT id.server @9.9.9.9 returns res701.trn, meaning Turin.

The test that tells the two apart is physics. Light in fibre travels at roughly 200,000 km/s, so a round trip to a point D kilometres away cannot close in less than D/100 milliseconds. That is a hard limit: no routing, no optimisation and no cache can break it. If an address a database places 16,000 km away answers in 19 ms, the node that answered is not where the database says. This test runs against every address in the inventory, every day, from the same server that later runs the checks.

Hence the three labels next to every observation point, and the fact that there is no fourth one:

anycast means the address is global and the answer comes from the node nearest to us. Where the resolver exposes id.server or hostname.bind, the actual node that answered is shown, using the identifier it declares itself. Never a city picked by hand.

location consistent means the measured latency is compatible with the claimed distance: a closer node could not be that slow. Hovering the label shows the three numbers the conclusion rests on. The wording is deliberate: the test proves a location impossible, never a plausible one correct. A resolver at 286 ms is consistent with Sydney but could sit in Auckland; for this purpose what matters is that it is genuinely remote and genuinely distinct from the others, and that the test does guarantee.

location not verified means the test could not conclude, and in that case no location is shown at all.

There is no map, and that is not an omission. With geographic routing what you need to know is which value each area receives, not which points replied: the per-continent view carries that information without the cost of a mapping library and without implying a precision we do not have. A green dot on a map only ever says "it answered".

One last note. What decides whether a user sees the old value or the new one is less the country they are in than which resolver they use and when that resolver populated its cache. Two users on different continents both using 8.8.8.8 almost always get the answer of the regional PoP nearest to each. The remaining TTL describes that mechanism directly, which is why it is the column that stays visible on every row.

The measurements on this page are reproducible with dig from any machine.

Querying the domain's nameservers directly. The zone containing the name is found by walking up label by label, accepting only NS sets whose owner matches the candidate; the nameservers are resolved to addresses and each one is queried directly with the recursion bit cleared, asking for the requested record and for the zone SOA. Answers with the AA bit set form the reference. If the name is an alias, the CNAME chain is followed to the zone holding the final records, and the measurement happens there. Equivalent to: dig +norecurse @ns1.example.com example.com A.

Querying the observation points. An inventory of public recursive resolvers, queried in parallel over UDP/53 with a two second timeout. The inventory is revalidated daily: an address joins the active set only if it answers, exposes the recursion flag and does not filter, and it leaves after three consecutive failed validations. The location a database claims is then compared against the physical floor imposed by the speed of light in fibre (a round trip cannot be shorter than distance/100 in milliseconds): anything answering faster than its own floor is anycast, and is never shown with a city. Three DoH resolvers queried from the browser are added on top, measuring the network of whoever is looking. The TTL returned by a cached answer is the remaining TTL.

A note on non-recursive queries. Reading the remaining TTL with recursion disabled would avoid triggering a cache refresh, but it is not workable across resolvers: Cloudflare answers, Quad9 refuses and Google returns SERVFAIL. The remaining TTL is readable from an ordinary recursive query anyway, because a cache-served answer carries an already decremented TTL; on a cold cache the query causes a fetch from the origin and the TTL comes back full, and that is exactly the signal separating a previous copy from a freshly fetched answer.

Limits of a single vantage point. When the ECS probes detect that the zone answers differently to different networks, values outside the observed set are classified as geographic variants. That is the correct reading in most cases, since a CDN can serve many different addresses and a single location cannot enumerate them; it does have a downside, though: on a geographic domain, during a migration, a lagging resolver can be read as a variant. On domains of that kind the more reliable signal is querying the domain's nameservers directly.

What is not covered. There are no distributed probes, so no geography is claimed. There is no monitoring over time with notification. There is no immutable snapshot of a result: the share link repeats the check, which for moving data is more useful than a photograph. Any extension will be documented here.

This page answers one specific question: whether a DNS change is complete. Adjacent questions have their own tools in the same section.

The DoH query tester queries a single resolver and shows the raw answer: rcode, authority section, flags, CNAME chain and the domain's RDAP data. It suits understanding what a resolver replies rather than whether it is up to date.

The email DNS validator covers the mail vertical: MX, SPF with lookup counting, DKIM, DMARC and the typical deliverability mistakes. After publishing an authentication TXT, that one verifies its correctness and this one shows when it will be visible everywhere.

On the certificate side, the security headers analyzer and the SSL certificate decoder cover the checks that follow a migration, once DNS already points to the right place.