DNS Propagation Checker
After a DNS change, see whether public resolvers have caught up with what your authoritative servers publish, and read the TTL that decides how long old answers can linger.
Run DNS propagation
No sign-up required. Public hosts and addresses only; results show what was observed, nothing is simulated.
What DNS propagation really is
DNS changes do not spread outward like a broadcast. When you edit a record, the authoritative servers start giving the new answer at once, or after they have loaded the update. Every recursive resolver that has already cached the old answer keeps returning it until the record's TTL runs out, and then fetches the new one. 'Propagation' is therefore the gradual expiry of old cached copies, and its length is set mostly by the TTL that was on the record before you changed it.
This tool measures that directly. It finds the zone's authoritative servers, asks them for the record to get the reference answer, and then asks ten named public resolvers the same question. Each resolver is judged against the reference.
Which resolvers are asked
The ten are public resolver addresses: Cloudflare (1.1.1.1 and 1.0.0.1), Google Public DNS (8.8.8.8 and 8.8.4.4), Quad9, Cisco OpenDNS, AdGuard DNS, Verisign Public DNS, Control D and CleanBrowsing. Several of those filter content, which the table notes so you can tell filtering apart from a stale cache.
They are anycast addresses queried from this scanner. The result tells you nothing about geography: a resolver address that answers from many sites is asked once, from one place, and what a visitor in another country sees is not visible here.
How to read the result
- All resolvers agree with the authoritative answer: a pass. The ten public resolvers are in step with the zone.
- Some agree, some failed: informational, with the failures listed by state. A timeout or SERVFAIL gives no information about the record, so the picture is incomplete rather than wrong.
- Some resolvers differ: informational. The most likely cause is a cached old value, and the tool shows the remaining TTL so you know how long it can last. It can also be resolver-specific steering by a CDN.
- A filtering resolver returns NXDOMAIN or a sinkhole address: reported as possible filtering, not delay. Quad9, AdGuard and CleanBrowsing block categories of domains.
- Authoritative servers disagree with each other: there is no single current answer, so resolvers cannot be judged as current or stale. This points at a zone transfer or provider problem, not at propagation.
- No definite authoritative answer: the reference is unknown and the page says so.
- Record TTL: shown as the longest time a resolver that cached the previous value may keep it.
Common reasons a change seems not to propagate
- The edit was never published: the change is in a draft or at the wrong provider. Authoritative servers still serve the old value, so every resolver agrees on the old answer.
- Delegation points elsewhere: you edited a zone that is not the one the registrar delegates to. The NS tool shows this.
- Long TTL on the old record: a 24-hour TTL means up to a day of mixed answers.
- Cached negative answer: a name that did not exist is cached as NXDOMAIN for the negative TTL in the SOA.
- Local caches: operating system, browser and router caches are outside this test and add their own delay.
- CDN or geo-DNS: answers differ by resolver on purpose.
How to make a change with less waiting
Plan ahead rather than hope. A day or more before the change, reduce the TTL of the record to a few minutes, because only caches filled after that point benefit. Make the change after the old TTL has passed, check the result, and restore a longer TTL later.
Keep the old destination working until the checks show agreement and the old TTL has expired. That way users on stale caches and users on fresh ones both succeed, and a rollback is simply putting the old value back.
- Note the current record and its TTL.
- Lower the TTL and wait for the old TTL to pass.
- Make the change at the authoritative provider.
- Run this check until the resolvers agree with the authoritative answer.
- Keep the old destination available through one full old TTL.
- Raise the TTL again. To roll back, restore the old value; the same waiting rules apply.
What this test cannot tell you
Agreement among ten public resolvers does not mean every resolver, ISP or office network has updated. The test makes one query per resolver at one moment from one scanner, and it cannot see local caches or resolvers inside private networks. It checks a single record type per run. Use the DNS resolver comparison for several types at once.
Frequently asked questions
How long does DNS propagation take?
It depends mainly on the TTL the old record had. Resolvers that cached it keep it for up to that long. Newly uncached resolvers see the change immediately.
Does this tool show propagation by country?
No. It asks ten named public resolvers from one location. It does not model geography.
Why do two resolvers show different IP addresses and both look right?
Some services return different addresses by resolver location or by load. Compare with the authoritative answer rather than with each other.
Why does one resolver return NXDOMAIN?
It may be a stale negative answer, or a filtering resolver blocking the domain. The table notes which resolvers filter.
Can I speed up propagation?
You cannot force third-party caches to clear, though some public resolvers offer a manual cache flush form. Lowering the TTL ahead of the change is the dependable method.
What if the authoritative servers disagree?
Fix that first. Resolvers will receive different answers depending on which server they ask.
Scope of this tool
- These are anycast public resolvers queried from this scanner. They are not geographic probes: a resolver answering from a different site, or a CDN steering answers by resolver, is not visible here. Propagation of a change is judged by agreement and TTL.
Written by DNS Tools editorial · Last updated 2026-10-09