DNS Propagation Checker

“Propagation” is industry jargon rather than a term the DNS RFCs use, and the picture it paints — a change spreading outward across the internet — is misleading. Nothing is ever pushed to the world’s resolvers. What really happens after you edit a record is two independent processes, and only one of them is the one you are waiting for.

The first is zone distribution. Your authoritative primary tells its secondaries that the zone changed, using a NOTIFY message (RFC 1996); each secondary compares the SOA serial (RFC 1035 §3.3.13) and pulls the new data with a full zone transfer, AXFR (RFC 5936), or an incremental one, IXFR (RFC 1995). This stage is typically a matter of seconds to minutes and is almost never the cause of a change that seems stuck.

The second is cache expiry, and this is what your users experience. Every recursive resolver that already looked up your name is holding an answer it is entitled to keep until that answer’s TTL runs out (RFC 1035 §3.2.1). No one tells those resolvers anything has changed. Each one simply counts down on its own clock and re-queries when it reaches zero. They started their countdowns at different moments, and that staggering is the entire phenomenon.

For a resolver that honours TTLs, then, the maximum wait after a record change is one TTL from the moment the authoritative data is correct. There is no global progress bar, because there is no global anything — just independent caches ageing out.

This checker queries a fixed set of public recursive resolvers directly on port 53, in parallel, for six record types at once: A, AAAA, MX, TXT, NS and CNAME. The resolvers are grouped into four regions — Global, North America, Europe and Asia Pacific — and the region selector above the form decides which groups are queried; Global alone is the default. Every query asks for recursion, so what comes back is whatever that resolver currently has cached or is willing to fetch — that resolver’s current view, from this probe’s location, rather than your zone’s own answer.

Each question goes out over UDP first. If the answer is too large for the datagram the resolver sends back a stub with the truncation bit set, and the same question is then retried over TCP to that same resolver (RFC 7766); the TCP answer is the one you see, and the latency shown covers both legs. A resolver whose TCP retry also fails is not shown with the partial answer UDP managed to carry — a fragment of an answer set would read as a disagreement about your zone when nothing of the sort happened — so it is listed under “Did not answer” with the reason instead.

Consensus and consistency

For each record type, the tool groups the resolvers by the whole answer they returned and takes the largest group as the consensus: one answer a resolver actually gave, never a merge of two rival answers. The consistency percentage is the size of that group divided by the resolvers that answered. A resolver that timed out or errored gave no answer, so it is left out of that division entirely and listed separately under “Did not answer”; each record type states how many of the resolvers queried answered it. An answer of “no such record” is still an answer and forms its own group, so a record type every resolver agrees is absent scores 100%.

When two answers are returned by the same number of resolvers, neither has a majority: the record type is marked Split, no majority, both answers are shown with their counts, and the percentage is the real share of the leading group — 50% for an even two-way split, not 0%. Which group is labelled the leading one is decided by the answer text so the same results always display the same way; in a split, the other group is not simply wrong. If no resolver answered at all, the record type says so rather than showing a percentage. The Overall Consistency figure at the top is the plain mean of the per-type percentages, skipping any type that nothing answered for.

Anomalies

An anomaly is a resolver that answered successfully but whose set of records differs from the consensus. Only resolvers outside the largest group are flagged: a resolver that timed out or errored is not an anomaly — it disagreed about nothing — and appears in the “Did not answer” list for that record type instead, where you can see the reason. During a genuine change, anomalies are exactly what you expect, and the list should shrink as TTLs expire. If it does not shrink, the disagreement is telling you something else — see the next section. Each anomaly shows the expected and actual records side by side, and the per-region breakdown tells you whether a disagreement is geographic or scattered.

Latency

The millisecond figure on each resolver card is the round trip from this server to that resolver, not a measure of how fast your domain resolves for end users. Treat it as a health signal for the probe: a timeout tells you the resolver did not answer within the window, which is a reachability fact rather than a verdict about your zone.

The old TTL is still running

This is the ordinary case, and the subtlety catches people out: lowering a TTL now does nothing for caches that already hold the record at the old value. They keep it for the remainder of the old TTL and only learn the shorter one when they next re-query. That is why the TTL reduction has to happen before the change, by at least the duration of the old TTL. Resolver ceilings also apply: BIND caps cached answers at one week by default (max-cache-ttl 604800s) and Unbound at one day (cache-max-ttl 86400s), so an absurdly long TTL is clamped, not honoured.

Negative caching pinned a “does not exist”

Resolvers cache absence as well as presence (RFC 2308). An NXDOMAIN is cached against the name, a NODATA answer against the name and record type (§5). The lifetime is not simply the SOA MINIMUM field: it is the lesser of that field and the TTL of the SOA record itself (§3), so shortening one without the other changes nothing. The practical trap: if you queried a hostname before you created it — testing, say — you may have taught the resolver that it does not exist, and your brand new record stays invisible until that entry expires. RFC 2308 observes that one to three hours works well and that more than a day is problematic, so check both values on the zone’s SOA before blaming the record.

You changed nameservers, not records

Delegation changes are slower, and not because of anything you control. Measured in September 2026, the .com and .net registry servers publish delegation NS records with a TTL of 172800 seconds — 48 hours. The domain owner cannot shorten it, so anything holding your old delegation may keep using it for two days. Related trap: if a nameserver’s hostname lives inside the zone it serves, the parent must publish A or AAAA glue for it, or resolvers face a circular lookup (RFC 1034 §4.2.1). A delegation that is broken rather than merely slow will never settle on its own; our DNS validator checks delegation and glue specifically.

The answer was never meant to be the same everywhere

Public resolvers are anycast: a single IP address is answered by many points of presence, each holding its own cache with its own TTL countdown, so two probes to the same address can hit caches of different ages and both be current. On top of that, a resolver may pass a truncated form of the client’s subnet to the authoritative server using EDNS Client Subnet (RFC 7871) so a CDN can tailor its reply — Google Public DNS documents doing this. Where a CDN is involved, different regions returning different addresses is the system working correctly. If the names in question are CNAMEs into a provider, following the chain to its terminal addresses with our DNS flattener makes it obvious which layer is varying.

Check the authoritative answer first

Before waiting on anything, find out whether there is anything to wait for. Query an authoritative server directly with recursion disabled: dig +norecurse @ns1.example.com example.com A. That bypasses every cache and shows what your zone genuinely serves right now. If the authoritative answer is correct and the resolvers here disagree, you are looking at caching lag and time will fix it. If the authoritative answer is wrong, it is a misconfiguration, and no amount of waiting will change it.

Lower the TTL before the migration, not during it

Plan the cutover backwards. Drop the TTL on the records you are about to change at least one old-TTL period ahead of time so that every cache has re-queried and picked up the short value; a 300 second TTL for the migration window is a common convention rather than a standard. Make the change, confirm it here, and restore the normal TTL afterwards.

Purge the public caches you can

A few operators let you flush a name from their own resolvers: Google Public DNS at dns.google/cache, Cloudflare at one.one.one.one/purge-cache/, and OpenDNS at cachecheck.opendns.com. These are useful for confirming a fix quickly, but they reach only those resolvers — every ISP, corporate and on-device cache is untouched and still counting down. Treat purging as a verification shortcut, never as a way to shorten the wait for real users.

Know when an old answer is deliberate

One edge case is worth recognising. RFC 8767 describes “serve-stale”: a resolver MAY answer from expired data when it cannot reach the authoritative servers, handing out the stale record with a non-zero TTL — 30 seconds is the RECOMMENDED value — and a suggested staleness ceiling of seven days. The RFC frames this as a fallback for unreachable authoritatives rather than routine behaviour, so if you are seeing stale answers, first confirm your nameservers are actually reachable.