First CH Apps / DNS Propagation Check
Enter a domain and a record type; our server asks several public DNS resolvers the same question at once and lines up their answers. It is the tool for answering “has the switch landed yet?” after a server migration or a domain change.
You see what each resolver serves right now. If they agree, propagation is done. If they disagree, it is still in flight. If they all agree that the record does not exist, this is not propagation but a configuration problem.
e.g. example.com (pasting a full URL or an email address works too — we read the domain part)
Enter the new value and we count how many resolvers already serve it (e.g. 192.0.2.10; separate several with spaces or commas)
(1) the record is simply not on the authoritative servers (it was never saved, or a different zone was edited); (2) it is there, but resolvers still hold the old value in cache; (3) the authoritative servers themselves disagree (primary vs secondary). This page separates them: (1) shows up as every resolver agreeing that there is no record, (2) as disagreeing answers with TTL still left, and (3) as mismatched SOA serials. Waiting fixes only (2).
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; it counts down and the resolver re-queries at zero.
The SOA serial is the zone's version number: it increases on the primary name server and is transferred to the secondaries. We hit this ourselves on ConoHa's DNS, where one name server kept an older serial and the answer depended on which server you reached. The stale copy is on the authoritative side, not in a cache, so no amount of waiting helps. Check the provider's zone transfer, or re-save the record to trigger one.
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.
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).