DNS propagation checker
Query the same DNS record across several public resolvers at once and compare their answers. If they agree, the change is in sync; if they differ, it's still propagating. Runs in your browser over encrypted DNS-over-HTTPS — nothing stored.
Queries the same A record across 5 public DNS-over-HTTPS resolvers and compares their answers. If they differ, a recent change is still propagating. This checks resolvers from your one location — it is not a global multi-city probe.
Each query runs in your browser over encrypted DNS-over-HTTPS, straight to each public resolver. We don't proxy or log the domains you check. Answers reflect what these resolvers return from your location right now — not a global vantage.
What DNS propagation actually is
DNS propagation
DNS propagation is the time it takes for a DNS change to be reflected everywhere, as each resolver's cached copy of the old record expires and is refreshed. It isn't a wave spreading across the globe — it's independent caches timing out at their own pace.
How the checker works
You enter a domain and pick a record type — A, AAAA, CNAME, MX, TXT, or NS. Your browser then sends the same query, in parallel, to every public DNS-over-HTTPS resolver we can read (Cloudflare, Google, AliDNS, and others). Each resolver replies with whatever it currently has cached, and we show one card per resolver with its exact answer, its status code, or an honest error if it couldn't be reached.
We then compare the answers. If every resolver that responded returned the same set of values, you'll see a green In sync pill. If they returned different answers, you'll see an amber Not in sync yet pill — which is exactly what you expect part-way through a change. A resolver that times out or refuses the query is marked unreachable and left out of the comparison, rather than being counted as agreement or disagreement.
Why TTL causes the delay
Every DNS record carries a TTL (time to live) — a number of seconds a resolver is allowed to keep the answer cached before it must ask again. TTL is the single biggest factor in how long a change takes to settle. If your A record had a TTL of 3600, a resolver that cached it one second before your change will keep serving the old value for almost a full hour. A resolver that happened to cache it right after your change already has the new value. That timing difference — not distance — is why two resolvers disagree.
This is also why lowering the TTL ahead of a planned change speeds things up: shorter cache lifetimes mean the old value expires from caches sooner. Raise the TTL back up afterward so resolvers can cache efficiently again.
When to use this vs. the DNS lookup tool
Reach for the DNS lookup tool when you want to inspect a domain in detail — every record type, each record's name, value, and TTL, from one resolver of your choice. Reach for this propagation checker when you've just made a change and want to answer one question quickly: have the resolvers caught up yet? It trades depth for a side-by-side agreement view across several resolvers.
If answers are still mixed, wait for roughly the record's old TTL to elapse and check again. To confirm a domain's records are cryptographically signed rather than just consistent, use the DNSSEC checker.
DNS propagation — frequently asked questions
What is DNS propagation?
DNS propagation is the delay between changing a DNS record and every resolver on the internet serving the new value. It isn't really a signal spreading outward — it's cached copies of the old record expiring at different times. Until each resolver's cached copy hits its TTL and is refreshed, that resolver keeps handing out the old answer.
How long does DNS propagation take?
It depends almost entirely on the record's TTL (time to live) and when each resolver last cached it. A record with a 300-second TTL can be fully consistent within minutes; one with a 24- or 48-hour TTL can take that long for the last caches to expire. Registrar or nameserver changes can add more time on top. There is no fixed "48 hours" rule — it's just cache expiry.
Why do different resolvers show different results?
Each resolver caches records independently. Right after a change, some resolvers have already refreshed to the new value while others are still serving the old one from cache until its TTL expires. Different resolvers also refresh at different moments and may sit behind different upstream caches, so seeing a mix of old and new answers mid-change is completely normal.
Is this a global propagation check across many cities?
No — and we won't pretend otherwise. This tool compares several public resolvers as reached from your single location and current network. It is not a worldwide, multi-city geographic probe. A large resolver like Cloudflare or Google is also anycast, so the node answering you may hold a different cached value than the node answering someone on another continent. Treat this as a fast, honest multi-resolver spot check, not a global map.
How is this different from the DNS lookup tool?
The DNS lookup tool queries one resolver and shows the full record detail — type, name, TTL, and value — for many record types. This propagation checker queries one record type across several resolvers at once and focuses on one question: do they agree yet? Use lookup to inspect records; use this to watch a change roll out.
Does lowering the TTL make propagation faster?
Lowering the TTL before you make a change means resolvers cache the record for less time, so they pick up the new value sooner. The catch is that resolvers must first fetch the record while the low TTL is published for it to help — so lower the TTL a day or two ahead of a planned change, then raise it again afterward for efficiency.