First CH Apps / DNS Propagation Check
Enter a domain and a record type and we query five public DNS resolvers (Cloudflare, Google, OpenDNS and more) at once, then show whether they agree.
You see what each resolver serves from its cache right now. If they agree, these resolvers have converged; if they disagree, propagation is usually still in flight. When they all say the record does not exist, or all return SERVFAIL, a configuration problem is likely — confirm it by asking the authoritative name servers directly (steps below).
When a change “has not updated”, these are the usual suspects: (1) the record is not on the authoritative name servers (it was never saved, or a different zone or host name was edited); (2) it is there, but resolvers still hold the old value in cache; (3) you added the record only just now and resolvers cached the earlier “does not exist” (negative caching); (4) resolution itself fails because of a DNSSEC validation error or a wrong delegation (the name servers registered at the registrar); (5) the authoritative name servers are mid-sync or failed to sync. This page narrows down which is likely. Resolvers only show you the cached view, so confirm by asking the authoritative name servers directly with the steps below.
Everyone returns the same value → these resolvers have converged. Answers differ with TTL left → (2) is most likely and they converge once the TTL passes. Everyone says no record / NXDOMAIN → (1) is most likely, but right after adding the record (3) is possible (this page also shows how long the negative answer stays cached). Everyone returns SERVFAIL → suspect (4). Different SOA serials → a hint toward (5), but resolvers cache the SOA too, so that alone does not decide it.
(1) Run dig NS example.com +short to find the authoritative name servers. (2) Send dig +norec @ns1.example.net www.example.com A to each and see whether the new value comes back (on Windows: nslookup -type=A www.example.com ns1.example.net). (3) Run dig +norec @ns1.example.net example.com SOA +short against every name server and compare the serials. (4) For SERVFAIL, try dig +cd www.example.com A @8.8.8.8: if an answer comes back with validation disabled (+cd), suspect DNSSEC; if not, suspect the delegation or the name servers. If step (2) returns the new value, your configuration is right and the rest is caches turning over.
A resolver keeps an answer for the TTL in seconds. Change a record whose TTL is 86400 (24 hours) and some resolvers will serve the old value for a full day. The standard move is to lower the TTL to around 300 seconds the day before the switch, then raise it again afterwards. The TTL shown here is how much longer that particular resolver will hold its current cache. “Does not exist” answers are cached too, for the smaller of the zone SOA's last field (minimum) and the SOA's own TTL (RFC 2308).
On 2026-10-28 we queried freshly invented, non-existent names under our own domain first-ch.com (ConoHa DNS; the SOA minimum and TTL are both 3600 seconds) from this page, three times. The remaining negative TTL was 3600 seconds at Cloudflare, OpenDNS and DNS.SB, 3591–3593 at AdGuard, and 1800 every time at Google. The same “does not exist” from the same zone lingers up to twice as long depending on the resolver. That is why, right after adding a record, only some resolvers may still say it is missing; the “negative cache left” on each row is that wait.
The SOA serial is the zone's version number: it increases on the primary name server and is transferred to the secondaries. Resolvers cache the SOA as well, though, so if they cached it at different times the serials look split. We hit a real mismatch ourselves on ConoHa's DNS, where one name server kept an older serial and the answer depended on which server you reached. That kind of authoritative-side drift does not go away by waiting for the TTL, so query each name server's SOA directly; if they differ, check the provider's sync or re-save the record to trigger a transfer.
Then the cache is on your own machine. On macOS run sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder; on Windows ipconfig /flushdns. Browsers keep a separate cache (Chrome: chrome://net-internals/#dns), and a corporate resolver or your router may hold one too.
A frequent cause is editing the wrong host name. www.example.com and example.com are separate records; changing one leaves the other untouched. Query the CNAME type to see whether a CNAME sits behind the A record — when you query A, this page also lists any CNAME it went through.
Sent: only the domain name and the record type you choose. Our server (Cloudflare Workers) sends two queries to each of 5 public DNS-over-HTTPS resolvers (your record type plus SOA) — 10 queries in total. The “expected value” is only compared inside the request and is never sent anywhere.
Stored: nothing. The check lives entirely inside one request and writes neither the domain nor the result to any database (no KV, no D1). It leaves memory when the request ends.
Returned: the record values, remaining TTLs and SOA serials each resolver gave us, plus the comparison. We do not fetch ownership data (Whois) or any content from the site.
Note: only public DNS records can be looked up. localhost, internal domains (.internal, .local) and IP addresses are rejected. The resolvers are fixed and cannot be chosen by the visitor.
Kept on this device: to compare with earlier checks, the domain, type, expected value and a summary of each resolver's answer are kept in this browser's localStorage (the last 8 runs per setting, up to 20 settings). It is never sent to our server. Use “Clear history on this device” in the result to remove it.
POST /dns-propagation/api/check with JSON ({"domain": "example.com", "type": "A"}) or a form body and you get the same result as JSON (no auth, nothing stored).
