BRev DNS propagation checker
A DNS propagation checker: four public resolver caches with live TTL countdowns, a 12-city location-hint view, and a watch mode that logs every answer change.
What “DNS propagation” actually isTTL expiry, not a pushRead
A DNS change is never pushed to the world's resolvers. Each resolver simply keeps the answer it last fetched until that answer's TTL (time to live) runs out, then asks the authoritative servers again. A DNS propagation checker like this one watches that process: it asks several independent caches the same question and shows you which have re-fetched your new record and which still hold the old one.
Why caches disagree for a while
Different resolvers filled their caches at different moments, so after a change they naturally disagree until every cache's TTL has expired. That window is bounded by the old record's TTL — a 24-hour TTL means up to 24 hours of mixed answers, no matter how fast your DNS host is. Anycast resolvers (Cloudflare, Google, AliDNS) are really many caches worldwide sharing one address, which is why even one “resolver” can flip back and forth briefly.
The migration playbook
A day or more before a planned change, lower the record's TTL (say to 300s) and wait for the old TTL to expire so the low value is what everyone caches. Make the change — the world now converges within minutes. Verify here, then raise the TTL back. During the switch, turn on watch mode above and leave the tab open: every answer flip is logged with a timestamp.
Negative caching — NXDOMAIN has a TTL too
If a name was queried before it existed, resolvers cache the “does not exist” answer (NXDOMAIN) for the time given by the zone's SOA minimum field. So a brand-new record can look “stuck” even though you just created it — that's negative caching expiring, not a failed change.
Need the full record detail — SOA serials, DNSSEC, CAA, reverse lookups? Use the DNS lookup tool for single-resolver inspection with zone-file and dig exports.
A DNS change is never pushed out to the world's resolvers. Each resolver keeps the answer it last fetched until that answer's TTL (time to live) runs out, then asks the authoritative servers again, so for a while after a change different resolvers give different answers. That gap is what people call propagation, and this checker measures it from your browser. It sends the same query over DNS-over-HTTPS to four public resolvers, Cloudflare (1.1.1.1), Cloudflare Security (1.1.1.2), Google (8.8.8.8) and AliDNS (223.5.5.5), compares their answer sets and tags any that differ. Next to each answer is the TTL that resolver returned, counting down to the moment it re-asks. A second table queries Google Public DNS with EDNS Client Subnet hints for 12 cities, from Dubai to São Paulo, to show GeoDNS and CDN steering. Watch mode repeats all 16 queries every 30 or 60 seconds and logs each answer that changes.
What you can do
- Four public resolvers queried at once over DNS-over-HTTPS: Cloudflare (1.1.1.1), Cloudflare Security (1.1.1.2), Google (8.8.8.8) and AliDNS (223.5.5.5)
- A “re-asks in” countdown on every cached answer: the TTL that resolver returned, ticking down to its next fetch from the authoritative servers
- A World regions table: Google Public DNS asked with an EDNS Client Subnet hint from a local ISP in each of 12 cities, including Dubai, London, New York, Tokyo, Mumbai and Johannesburg
- Six record types: A, AAAA, CNAME, MX, TXT and NS
- Majority-vote verdicts with a “differs” tag on outlying rows; a resolver that cannot be reached is reported as a failure, never counted as a disagreement
- Watch mode: a full re-check every 30 or 60 seconds, paused while the tab is off screen, with a timestamped log of the latest 50 answer changes
- Share copies a link that reopens the same domain and record type; Copy full report puts every answer, TTL and verdict on your clipboard as plain text
How to use dns propagation checker
- Enter a domain in “example.com — or paste a full URL”Type a name such as example.com, or paste a whole link; the tool keeps only the host name and converts an international domain to its punycode form. Try an example fills in google.com, whose answers genuinely vary by location.
- Choose “A”, “AAAA”, “CNAME”, “MX”, “TXT” or “NS”A is selected at the start. With a domain already in the box, pressing another type runs the check again straight away.
- Press “Check propagation”All 16 queries go out together. Read the verdict at the top of Resolver caches, then the “differs” tags and the “re-asks in” countdown on each row.
- Compare the “World regions” tableOne answer in every row means no location-based steering. Different answers by city usually mean GeoDNS or a CDN is choosing a server for each network, or a change is still spreading.
- Turn on “Watch mode” with “Every 30s” or “Every 60s”Leave the tab open during a migration and every answer change is logged with the time the tool saw it. Press Stop to end polling.
FAQ
How long does DNS propagation take?
As long as the old record's TTL, counted from the moment each resolver last fetched it. A record that had a 24-hour TTL can give mixed answers for up to 24 hours however fast your DNS host applies the change, while one with a 300-second TTL settles within minutes. The countdown in the Resolver caches table shows how long each cache has left before it asks again.
Why is my DNS change not showing yet?
Usually a cache still holds the old answer and its TTL has not run out; the countdown shows when each resolver will re-ask. If the name was looked up before it existed, resolvers cache that “does not exist” (NXDOMAIN) answer for the time in the zone's SOA minimum field, so a brand-new record can look stuck. If all four resolvers here return the new answer and your own device does not, the old copy is held by a resolver this page does not query, such as your router's or your ISP's.
What does it mean when one resolver shows a different answer?
When most resolvers agree, the others are tagged “differs” and the verdict counts how many caches still hold an older or different answer. AliDNS, whose anycast sits mostly in China and Asia, is the cache most likely to lag a fresh change. If only Cloudflare Security differs, the domain may be on its malware blocklist rather than mid-change. Domains behind CDNs or rotating load balancers can give each resolver a different answer on purpose, which shows as a split with no majority.
Does this check DNS from servers in each country?
No, and the page says so. The World regions table asks Google Public DNS 12 times, each with an EDNS Client Subnet hint: a /24 address block from a local ISP, such as Etisalat for Dubai or SoftBank for Tokyo. An authoritative server that steers by location can use that hint to pick its answer, so you see GeoDNS and CDN steering, but the queries do not run in those cities and some servers ignore the hint.
How can I make a DNS change take effect faster?
Plan around the TTL. A day or more before the change, lower the record's TTL, to 300 seconds for example, and wait for the old TTL to expire so the short value is what resolvers hold. Then make the change, which should reach every cache within minutes, confirm it here, and raise the TTL again.
What does watch mode do?
It re-runs all four resolver queries and all 12 region queries every 30 or 60 seconds until you press Stop, and logs an entry whenever a row's answer set differs from its previous successful answer. Polling pauses while the tab is not on screen and re-checks when you return; a change found across a pause is labelled “changed while polling was paused”. The log keeps the latest 50 changes, and a domain that rotates its answers will add entries even when you changed nothing.
Who can see the domains I check?
The queries go from your browser straight to Cloudflare, Google and AliDNS (run by Alibaba) over HTTPS, and each of them sees the name you look up; BRev has no server in that path. After a check, the domain and record type are written into the page address (?d= and &t=) so the Share link works, and the last domain you typed is kept in this browser's local storage so it survives a reload. Like every page on the site, this page also loads Google Analytics.