DNS propagation checker?DNS propagation is the delay between changing a record at your authoritative nameservers and every recursive resolver dropping its cached copy. It is bounded by the record’s TTL, not by geographic distance.

What this checks

DNS propagation is not a single event; it is many independent caches expiring at their own pace. When you edit a record, the change lands immediately at your authoritative nameservers — the servers your domain delegates to — but recursive resolvers around the internet keep serving whatever they last cached until the record’s TTL (time-to-live) counts down to zero. This tool reads one record type for your domain from two kinds of source. First, a set of major public resolvers — Cloudflare (1.1.1.1), Google (8.8.8.8), Quad9 (9.9.9.9), and OpenDNS — which show what those widely used caches currently return. Second, the domain’s own authoritative nameservers, queried directly, which show the source-of-truth value with no cache in between. It then compares the two: when every resolver already matches the authoritative answer, the change has propagated to those caches; when a resolver still returns the old value, it is serving a stale copy that will refresh once its TTL expires. The DNS record types reference explains what each record does.

How to read the result

The verdict is a comparison, not a pass or fail. Consistent means every public resolver and the authoritative nameservers return the same value — the record has fully propagated to the caches checked. Propagating means some resolvers already match the authoritative value while others still serve the previous one; the mismatched resolvers are holding a cached copy that will refresh when its TTL elapses. Inconsistent means the authoritative nameservers disagree with each other, in a way that a simple cache lag does not explain — for example split-horizon DNS or a partially updated set of authoritative nameservers. The per-resolver rows show exactly what each source returned, so you can see which caches are behind. If the authoritative nameservers themselves disagree with each other, the change has not finished landing at the source yet, and waiting on resolver caches will not fix it — that is a problem to resolve at your DNS host.

Why this isn’t a geographic map?EDNS Client Subnet (RFC 7871) forwards a truncated slice of the client’s IP address to the authoritative server as a hint about where a request originates. It lets a resolver simulate what it would answer for a region — an approximation from a hint, not a probe run in that location, and only relevant for geo-aware records.

Some propagation tools draw a world map with a checkmark on each country. This tool deliberately does not, because that picture is usually misleading. The major public resolvers are anycast networks: a single address like 1.1.1.1 is answered by data centres on every continent, and which one replies depends on network routing, not on where you are. Querying Cloudflare tells you what Cloudflare’s cache holds; it does not tell you what someone in a specific city sees. So the honest framing is the one this tool uses — the results describe what major public resolvers and the authoritative nameservers return, not what a person in any given location would get.

There is one genuine geographic signal, and it is an approximation rather than a measurement. EDNS Client Subnet (ECS, RFC 7871) lets a resolver forward a truncated slice of the client’s IP address to the authoritative server as a hint about where a request originates. Resolvers that honour ECS — Google and OpenDNS among them — can be asked what they would answer for a client in a given region. That is a simulated hint sent from our server, not a probe running in that location, and it only changes the answer for records that are themselves geo-aware, such as GeoDNS or CDN routing. Cloudflare and Quad9 ignore client ECS entirely on privacy grounds, so for them the question does not apply. Treat the regional view as an indication of how a geo-aware record might resolve, never as proof of what a real user in that region receives.

What this does not prove

A consistent result covers the specific resolvers this tool queries; it is not a guarantee that every recursive resolver on the internet has refreshed, because caches you are not querying may still hold the old record until their own TTL expires. The check also says nothing about whether the record is correct — only whether the value has spread. A propagated record can still be a typo, point at the wrong host, or fail authentication; use the dedicated MX lookup or the relevant record checker to validate the content itself. Finally, the regional ECS view is an approximation via a client-subnet hint, not a measurement taken in that location, and it only moves for geo-aware records — so a uniform regional result does not prove your CDN or GeoDNS is configured the way you intend.