DNS propagation checker

How this tool works

Enter a name, pick a record type, and the server sends the identical question to 14 public DNS resolvers at the same time, over DNS-over-HTTPS. Each resolver is given up to 6 seconds to answer. The page then lists every resolver with its status, the answer it returned, the TTL it reported and how many milliseconds it took.

The resolvers queried are Cloudflare, Google, Quad9, OpenDNS, AdGuard, CleanBrowsing, NextDNS, Mullvad, DNS.SB, Alibaba DNS, DNSPod (Tencent), Yandex, Control D and LibreDNS. Together they cover the resolver services most people and most devices actually use, which is what matters when you ask whether a change is live for your visitors.

Above the table the tool summarizes the run: how many resolvers answered, how many distinct answer sets were seen, and whether the answers are consistent. The result is marked consistent only when every resolver that answered returned exactly the same set of values and none reported that the name or record is missing.

Results are cached for 60 seconds per name and type, so repeating the check within a minute shows the same data. The tool is rate-limited per visitor to keep the resolvers' goodwill; it is meant for checking a change, not for monitoring.

The supported record types are A, AAAA, CNAME, MX, NS, TXT, SOA and CAA. For a single detailed answer with every record type at once, use the DNS lookup instead.

How to read the result

Each row shows one resolver. The status column is the first thing to look at:

A row with status ok but an address you did not expect is the one to investigate: that resolver is serving a cached copy from before your change, or your authoritative servers disagree with each other.

The TTL column shows how long that resolver will keep its current answer. A resolver showing the old address with a TTL of 2,400 seconds will keep showing it for another 40 minutes unless something clears its cache. The TTL also reveals whether the resolver fetched the record recently: a value close to the configured TTL means a fresh fetch, a low value means the entry is about to expire.

The milliseconds column is the round trip from our server to the resolver and back. It says nothing about how fast the resolver is for you; it mainly separates resolvers that answered quickly from ones that struggled.

Multiple values in one row are normal for names with several A records, several MX records or long TXT records. The consistency check compares the full set, so two resolvers returning the same addresses in a different order still count as consistent.

What to do next

The change is not showing anywhere yet

1. Query the authoritative name servers directly rather than a resolver. Run the NS type here to get their names, then on your computer use dig @ns1.yourprovider.com example.com A (macOS, Linux) or nslookup example.com ns1.yourprovider.com (Windows). If the authoritative server still returns the old value, the change was not saved or was saved in a different zone.
2. Check that you edited the zone that the domain actually delegates to. A domain registered at one company but hosted at another has its records at the hosting provider, not the registrar, and the WHOIS lookup shows which name servers are delegated.
3. If the authoritative answer is correct, the rest is waiting. Resolvers refresh when the old TTL runs out.

Some resolvers show the new value and others the old

This is normal propagation in progress. Nothing is broken. The old entries expire on their own schedule; you cannot push a new record to a resolver from outside. If a resolver still shows the old value well past the old TTL, verify that both of your authoritative servers hold the new zone by comparing their SOA serials.

Your own device still shows the old answer

1. Flush the local cache: ipconfig /flushdns on Windows, sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder on macOS, sudo resolvectl flush-caches on Linux with systemd-resolved.
2. Clear the browser's cache at chrome://net-internals/#dns in Chromium-based browsers, or restart the browser.
3. Reboot the router if it runs its own caching resolver, which most home routers do.
4. If the ISP resolver is the holdout, switch the device to a public resolver temporarily, or wait.

Before the next change

Lower the TTL of the records you plan to change to 300 seconds at least one full old-TTL period before the change. Make the change, confirm it here, then raise the TTL back to a sensible value such as 3,600 seconds. The TTL entry explains the trade-off between fast changes and resolver load.

Why resolvers disagree even without a recent change

Not every difference between rows is a propagation delay.

Several of the resolvers filter. AdGuard blocks advertising and tracking domains, CleanBrowsing's security filter and Quad9 block domains they classify as malicious, and the answer for a blocked name is typically NXDOMAIN or a null address. A domain that resolves at Cloudflare and Google but returns NXDOMAIN at those three is probably on a blocklist, not unpropagated.

Some services return different addresses on purpose. Content delivery networks and large platforms use the location of the resolver, or the client subnet it forwards, to pick a nearby server. In that case each resolver legitimately returns a different address and the result will never be consistent. The IP lookup tells you whether two different addresses belong to the same network, which is the usual sign of geo-aware DNS.

Negative answers are cached too. If you query a name before creating it, resolvers remember that it did not exist for the negative-cache time defined in the SOA record. Creating the record afterwards does not clear those negative entries. The practical rule: create the record first, then check.

Checking specific kinds of change

A new website or a server move. Query the A record (and AAAA if the server has IPv6) for the bare domain and separately for www, since the two are different names and are often changed in different places. Consistent new addresses at every resolver means visitors everywhere are reaching the new server.

A mail provider change. Query MX for the domain. Resolvers holding the old MX records will keep delivering to the old provider until they expire, so keep the old mailboxes alive for at least the old TTL plus a safety margin.

New name servers. Query NS. This is the slowest change to settle, because the delegation is cached at the parent zone with its own TTL, commonly a day or two, in addition to the caching of the NS records themselves.

Verification and authentication records. Query TXT at the exact name the provider gave you. A verification that fails right after you added the record is normally a resolver that cached a negative answer when the provider checked too early; wait and ask the provider to re-check rather than editing the record again.

Limits of this tool

• The resolvers are large anycast services. Each answers from whichever node is nearest to our server, so the table is not a map of 14 countries or regions. Only a few entries, such as the two Chinese resolvers, Yandex and LibreDNS, are tied to a specific region.
• Your ISP's resolver, your company's internal resolver and your router are not included. A consistent result here does not guarantee that every user in the world sees the new value.
• Filtering resolvers can return NXDOMAIN for domains on their blocklists, which looks like a missing record.
• The tool checks one name and one type per run. It does not walk CNAME chains, validate DNSSEC signatures or compare the delegation in the parent zone with the NS records in the zone itself.
• Results are cached for 60 seconds and the check is rate-limited, so it is unsuitable as a monitoring feed.
• Response times are measured from our server and do not reflect resolver performance from your location.