Query the same record at two independent public resolvers and compare the answers. If they agree, your change is live where it matters most; if they differ, one of them is usually still serving a cached copy — and the remaining TTL tells you how long that lasts.
Two resolvers, not twenty. Only Cloudflare (1.1.1.1) and Google (8.8.8.8) publish DoH endpoints a browser is allowed to read. Quad9 and AdGuard block cross-origin requests, so no honest browser-only tool can include them — and none of this runs from other countries. Everything here happens in your tab.
Enter a name and record type above to compare answers.
What this check can and cannot tell you
It compares two caches, not the world. Server-backed checkers query 20+ resolvers from 20+ countries. This page is limited to the two endpoints that permit browser requests. Two independent resolvers still catch the failure that matters most — one of them holding a stale answer.
Both resolvers are anycast. Your query lands on the node nearest to you, so a match proves those two networks agree as seen from your location. A resolver in another region may still hold a different cached copy.
Some records differ on purpose, permanently. Google's resolver forwards your approximate network location to the authoritative server (EDNS Client Subnet); Cloudflare's deliberately does not. Anything behind a CDN, or using latency-based or geographic routing, therefore hands the two resolvers different answers by design — and no amount of waiting makes them converge. A mismatch that outlives the longer TTL shown below is routing, not propagation.
Neither answer is authoritative. DoH gives you a recursive resolver's cached view, and neither endpoint exposes a cache-bypass flag. To confirm what your nameservers actually publish you need dig @ns1.yourprovider.net— a browser cannot open a raw DNS socket to an arbitrary server.
Response times are not a latency benchmark. The millisecond figure includes TLS setup and HTTP overhead, and a cache miss costs far more than a hit. Read it as a rough health signal, not a measurement.
Your own machine is a third cache. Your OS, your browser and your router may all still hold the old record even when both resolvers here agree.
Field notes
Nothing propagates. Caches expire.
The word "propagation" invents a process that does not exist, and it is the reason people wait passively for something that was already finished hours ago.
There is no wave to wait for
When you edit a zone, the change is live at your authoritative nameservers the moment they reload — usually seconds. Nothing is pushed anywhere. What you are actually waiting on is every recursive resolver that already asked, each holding your old answer until the TTL it was handed runs out. Those countdowns started at different moments, which is precisely why two resolvers can disagree for a while and both be behaving correctly.
So a mismatch here is not a fault to chase. The only question worth asking iswhich TTL is still running, and the answer is on the card that shows the old value.
Lower the TTL a day before you move
The professional technique is planned, not reactive. Roughly 24–48 hours before a migration, drop the TTL on the records you intend to change to300. Wait out the old TTL — if it was 86400, resolvers need a full day to pick up the new short one. Only then cut over: your worst-case exposure is now five minutes instead of a day.
Once the change is verified and stable, raise it back to 3600 or higher. Permanently low TTLs mean more lookups, more latency on cold hits, and a hard dependency on your DNS provider staying reachable. Low TTL is a manoeuvre, not a default.
Negative caching is the one that surprises you
Query a record before it exists and the resolver caches the absence. How long depends on the zone's SOA — the minimum field, capped by the SOA record's own TTL — and SOA minimums of 3600 are common while the record's TTL might be 300. Create the record, re-check, and it can stay missing for an hour even though publication was instant.
This is why "it works for my colleague but not for me" happens right after a launch: one of you tested early and poisoned your resolver's negative cache. The fix is patience or a different resolver — and the prevention is not querying a name until you have created it. Where this page returns NXDOMAIN it shows the negative TTL so you know the real wait.
Reading a disagreement
Answer order carries no meaning in DNS. A resolver that returns three A records will rotate them between queries on purpose, to spread load — this tool sorts both answer sets before comparing them, so rotation is never reported as a mismatch. Only thecontents of the sets are compared, and long TXT strings split across quoted segments are joined first, because consumers concatenate them anyway.
Two kinds of disagreement are not cache problems, and both are permanent. NS and SOA records that differ between resolvers usually mean the zone is hosted at two DNS providers at once, so each resolver reports whichever authoritative side answered it. Differing SOA serial numbers between providers are normal. Check whether the nameserver hostnames belong to two vendors before you start waiting for something to settle.
The other is the common one, and it catches people out: A and AAAA records that differ because the resolver differs. Google's 8.8.8.8 passes your approximate network location to the authoritative server as EDNS Client Subnet; Cloudflare's 1.1.1.1 refuses to, on privacy grounds. Any CDN or latency-routed record will answer those two queries differently and keep doing so forever, so a stable mismatch on a CDN-fronted name means your traffic is being steered, not that a cache is stale. The test is simple: note the longer TTL, wait it out, re-check. A cache converges; routing does not.
The genuinely interesting outcome is one resolver answering NXDOMAIN while the other resolves. That is mid-propagation in its clearest form: one cache learned "no such name" before you published, the other learned the record afterwards. If instead bothresolvers return SERVFAIL, stop thinking about caches — that points at a broken delegation or a DNSSEC validation failure, and no amount of waiting will fix it.
