DNS propagation check: have resolvers caught up?
How does this check work, and what does the result tell you?
AdminKit's free DNS propagation check queries the same name and record types against four public recursive resolvers at once — Cloudflare, Google, Quad9 and OpenDNS — live, and reports whether they already agree or are still disagreeing after a recent change, rather than guessing from a single lookup or a TTL countdown alone.
Part of the DNS cluster — more tools, guides and terms on dns.
AI explanation Run a check below, then sign in to ask AI to explain the result in plain language.
What the result means
"Diverging" means at least one resolver returned a different answer than the others right now — expected for a few minutes after a change, worth a second look if it persists past the record's TTL.
Next step
Inspect the domain's raw DNS records directly, or check whether the zone is DNSSEC-signed and validates.
Keep this result
Copy a link to this check so you can share it or run it again later. Want a heads-up if something changes? That's early access, not a live feature yet — tell us and we'll set it up by hand.
How it works and limits
This tool sends a real DNS query through AdminKit’s live Check API (POST /v1/check/dns with options.propagation: true) to four named public recursive resolvers — Cloudflare, Google, Quad9 and OpenDNS — rather than asking only one
resolver and guessing about the rest. By default it checks A, AAAA, MX and NS, the record types most commonly
watched while a change rolls out (a host move, a mail cutover, or a delegation change), though you can narrow the
request to fewer types.
How it works
- Each resolver is queried independently for each requested record type, as defined in RFC 1035, and caches its own answer independently for the record’s TTL, per the resolver behavior RFC 1034 §5 describes.
- A record type is marked propagated when every resolver that answered returned the exact same value, and diverging when at least two resolvers disagree — a sign the change may still be mid-propagation, or that the zone is genuinely misconfigured.
- If a resolver times out or can’t resolve the name, that resolver’s own error is reported separately and the overall result degrades to a warning rather than failing outright — a single resolver’s bad moment is not treated as a propagation problem.
Limits
- This checks agreement across four named public resolvers, not literally every resolver on the internet — a different ISP or corporate resolver could still be caching a stale answer even when all four agree.
- “Propagated” describes resolver cache agreement at the moment you ran the check, not a guarantee tied to any specific TTL countdown; see DNS propagation and TTL explained for what actually controls the delay.
- A propagated result says the resolvers agree, not that the value is correct — pair this with the DNS lookup tool to inspect the actual records, or DNSSEC check to confirm an answer hasn’t been tampered with in transit.
- No query is logged; see /legal/privacy/.
See the glossary entry for DNS propagation / TTL for the underlying caching mechanics, and DNS resolver test if you want to inspect one specific resolver’s answer in more depth rather than compare four at once.
Frequently asked questions
What does a 'propagated' result actually mean?
It means every public resolver this tool queried returned the same value for that record type at the moment you ran the check — not a guarantee that every resolver on the internet already agrees. RFC 1035 defines the DNS record format being compared; RFC 8499 (DNS Terminology) defines TTL as the caching window that makes resolvers briefly diverge after a change.
Why would resolvers disagree right after I change a DNS record?
Each resolver independently caches a record for its published TTL and only re-queries the authoritative server once that TTL expires (RFC 1035 §3.2.1 defines the TTL field; RFC 1034 §5 describes resolver caching behavior) — so a resolver that cached the old answer minutes before your change can keep serving it until its own cache expires, even though every other resolver already sees the new value.
Which public resolvers does this check query?
Cloudflare (1.1.1.1), Google (8.8.8.8), Quad9 (9.9.9.9) and OpenDNS (208.67.222.222) — four independently operated public recursive resolvers, each queried directly rather than through whatever resolver your own device or network happens to use.
What happens if one of the four resolvers doesn't answer?
A timeout or lookup failure from a single resolver is reported as that resolver's own error and degrades the overall result to a warning, not a failure — one public resolver having a bad moment says nothing about whether your DNS change has actually propagated.
Does a fully 'propagated' result guarantee my DNS change is correct?
No — it only confirms the resolvers queried agree on the value, not that the value itself is correct. A typo in an A record that's identical across all four resolvers still shows as fully propagated; use the DNS lookup tool to inspect the actual record values, or the DNSSEC check if you need to confirm an answer hasn't been tampered with in transit.