A complete guide to how the DNS Propagation Tool works, why only 6 of its 31 listed resolvers are queryable from a browser, and how to use it to verify DNS changes.
Launch the DNS Propagation Tool →The DNS Propagation Tool checks how a domain name resolves across a curated list of 31 well-known public DNS resolvers around the world, which is the standard way IT professionals verify whether a recent DNS change (like updating an A record after moving a website to a new server) has finished "propagating" — spreading out and being recognized consistently across the many independent DNS servers that make up the internet's domain name system.
Of those 31 resolvers, 6 are actually queryable directly from your browser: Cloudflare's two resolvers, Google Public DNS's two resolvers, and Quad9's two resolvers. The remaining 25 are included as accurate, correctly labeled reference entries, showing their real IP address, geographic location, and operating ISP, but are marked as not queryable from a browser, with the underlying reason explained directly on the page rather than hidden or glossed over.
This split exists for a very specific technical reason explored in depth below, and understanding it is actually one of the more broadly useful pieces of networking knowledge this entire site can teach, because it applies to any browser-based tool that tries to talk directly to a remote server.
The core issue is a browser security mechanism called CORS (Cross-Origin Resource Sharing). When a web page running on one domain tries to make a request to a different domain using JavaScript's fetch() function, the browser does not simply let the response through by default. Instead, it checks whether the server being contacted explicitly included a special Access-Control-Allow-Origin header in its response, granting permission for a webpage running elsewhere to read that response. If that header is missing, the browser silently blocks JavaScript from reading the response content, even though the actual network request succeeded and the server actually sent data back.
This exists to prevent a specific class of security problem: without it, any website you visit could make background requests to other sites you're logged into (like your bank or email) using your browser's existing session, and read the responses to steal data. CORS puts the decision in the hands of the server being contacted — it has to opt in to being readable by other websites' JavaScript.
DNS-over-HTTPS (DoH), the modern standard that lets DNS queries be sent over regular HTTPS instead of old-style unencrypted UDP packets, happens to be built on this same HTTP foundation. That means every DoH resolver technically could choose to send the CORS header that would allow browser-based tools like this one to read its responses — but very few of them actually do, because supporting browser-based CORS access was only ever an optional part of the DoH specification's original design intent, documented by organizations like ISC (the maintainers of BIND, one of the internet's most widely used DNS server implementations), and most providers simply never implemented it.
This tool's resolver list was built by directly testing each candidate resolver's real-world CORS behavior rather than assuming based on documentation. Cloudflare, Google, and Quad9 were confirmed, through live browser console testing, to send the correct CORS headers. By contrast, AdGuard, OpenDNS, and NextDNS were specifically tested and confirmed to return a valid HTTP 200 response with correct DNS data — the query itself works perfectly fine — but none of the three include the CORS header needed for a browser page to read that response, so they are correctly marked as not queryable, with that exact explanation shown on the page itself rather than a generic error.
Cloudflare and Google both offer a convenient JSON-based DoH API, meaning a browser can request DNS data and receive back an easy-to-parse JSON object. Quad9, however, only supports the original binary wire-format defined in RFC 8484 (the official DNS-over-HTTPS standard), not a JSON convenience layer. To make Quad9 work in this tool, a custom encoder and decoder for that binary format had to be written from scratch in JavaScript.
DNS wire-format is a precise binary structure: a 12-byte header containing a transaction ID, flags, and record counts, followed by the question section (the domain name being queried, encoded as a sequence of length-prefixed labels rather than a plain string, plus a 2-byte query type and 2-byte query class), and finally the answer section in the response, which follows a similar length-prefixed structure. Getting any of these byte offsets or lengths wrong produces a query that either gets rejected by the server or, worse, appears to work but silently returns incorrect data.
Because a subtle mistake in this kind of binary encoding and decoding logic can be essentially invisible until it causes a wrong answer somewhere down the line, the wire-format codec was verified with a full round-trip test before being included in the shipped tool: a known domain name was encoded into the binary query format, that encoded query was then decoded back into its component parts, and the decoded result was checked against the original input to confirm the encode and decode logic were correct and consistent with each other. Only after that verification passed was the Quad9 integration considered safe to ship.
This is the same category of risk as any cryptographic or algorithmic code: it's easy to write code that looks correct and runs without throwing an error, while still silently producing wrong results. Testing against a known-correct round trip before shipping is the standard way to catch that class of bug before real users ever see it.
Two additional candidates, Mullvad DNS (base.dns.mullvad.net, also wire-format only, like Quad9) and dns0.eu, were specifically investigated as possible additions to the working resolver list, since both are reputable, privacy-focused DNS providers. Neither ended up being added, for reasons consistent with the broader pattern described above: live testing is required before any resolver can be marked as working, and most DoH providers skip CORS support entirely since it was never a mandatory part of the specification.
This reflects a deliberate working principle behind this tool and this site more broadly: a resolver is only ever marked as queryable after a real, live test confirms it, never based on assumption, documentation claims, or how the provider markets itself. The expectation going in, based on the pattern already observed across a dozen other providers, was that most additional candidates would also fail the CORS check, since this is a systemic gap across the DoH ecosystem rather than a quirk specific to any one provider.
example.com.After updating a website's A record to point to a new server, you might see Cloudflare's two resolvers and Google's two resolvers already returning the new IP address, while Quad9 still briefly shows the old one. This is completely normal during the propagation window and typically resolves within the domain's configured TTL (time-to-live) value, often anywhere from a few minutes to 24-48 hours depending on how the DNS record was configured before the change.
DNS records are cached at many layers between the authoritative server for a domain and any individual user's device: by ISPs, by corporate networks, by individual DNS resolvers, and sometimes by the browser or operating system itself. When you update a DNS record, that change does not take effect everywhere instantly — each cache holds onto its old answer until its TTL expires, at which point it asks the authoritative server again and picks up the new value.
This creates a genuinely confusing situation for anyone who has just made a DNS change: the website might work correctly from one network and show the old server from another, entirely because of which DNS resolvers happen to be in the path and whether their cached copies have expired yet. A propagation checker like this tool lets you see, from a single page, whether a representative sample of major public resolvers around the world have already picked up the new value, which is a much more useful signal than just checking from your own single internet connection.
This is especially relevant after common changes like moving a website to new hosting, setting up a new subdomain, changing mail server (MX) records, or correcting a DNS misconfiguration — in every one of these cases, confirming propagation status helps distinguish "the change hasn't finished spreading yet, just wait" from "something is actually configured incorrectly and needs to be fixed."
Each DNS query made by this tool goes directly from your browser to the specific DNS resolver being tested (Cloudflare, Google, or Quad9), using the same DNS-over-HTTPS protocol increasingly built into modern browsers themselves. NexTechTools does not operate any server in this flow and does not log, store, or see the domain names you check or the results returned.
Because DNS queries are inherently visible to whichever resolver answers them, the resolvers themselves (Cloudflare, Google, Quad9) do see the domain name being queried, exactly as they would for any other DNS query sent to them from any device. Each of those providers maintains their own separate privacy policy governing how they handle query data, independent of NexTechTools.
Browser security policy (CORS) blocks JavaScript from reading responses from the 25 resolvers that don't explicitly grant that permission, even though those resolvers work perfectly fine for normal DNS resolution outside a browser context. This is explained in detail in the Why Only 6 of 31 Resolvers Actually Work section above.
No. All 25 non-queryable resolvers are real, functioning DNS servers with correctly listed IP addresses and operators. They simply cannot be reached from browser-based JavaScript due to CORS, the same restriction that affects countless other browser-based tools across the internet, not a flaw in the resolvers themselves.
Cloudflare and Google both offer a JSON-based DoH API that's simple for a browser to parse. Quad9 only supports the binary wire-format defined in the official DoH standard, which required building a custom encoder and decoder specifically for this tool, as described in The Quad9 Challenge section above.
This depends entirely on the TTL (time-to-live) value configured on the DNS record before it was changed. A record with a 300-second TTL will typically propagate within minutes, while one with a 24-hour TTL set before the change can take up to a full day to fully clear from caches across the internet.