DNS Propagation Checker: Compare Google, Cloudflare and Server-Side DNS Answers

What is DNS propagation

DNS propagation is the time window during which a recent change to a domain’s DNS record becomes visible to recursive resolvers around the world. When the authoritative nameserver publishes a new IP address, MX server or TXT record, that change does not instantly reach every browser or every mail server. Each recursive resolver caches the previous answer for the duration of its time-to-live (TTL). Until the cached entry expires, that resolver keeps serving the old value. Propagation is therefore not a single moment but a gradual sweep, controlled by per-record TTL, by the resolver implementation, and by network conditions between the resolver and the authoritative server.

This DNS propagation checker queries three independent vantage points in parallel and compares the answers. Two are the largest public DNS-over-HTTPS resolvers, Google Public DNS and Cloudflare 1.1.1.1, queried directly from your browser. The third is the PeopleAreGeek server resolver, which gives you a European (OVH) perspective without leaving the page. If every resolver returns the same data with consistent TTL countdowns, the change has propagated cleanly. If one still serves the previous record, or the TTL values diverge, the change is still in progress.

How a DNS propagation checker works

The page builds one request per resolver, sends them in parallel, and joins the responses into a single comparison view. For Google and Cloudflare the request is a DNS-over-HTTPS (DoH) call to their public JSON endpoint. For the PeopleAreGeek vantage point, the page calls the site REST API which executes a normal recursive lookup on the OVH-hosted server. The three answers come back with the same shape: record list, TTL and status code (NOERROR, NXDOMAIN, SERVFAIL). By sampling several resolvers at once you get a reasonable picture of how the wider internet currently resolves the name, without having to install dig or SSH into different servers.

1. Validate the input by trimming the domain, removing any scheme or path, and normalising the record type.
2. Send DoH requests to Google Public DNS and Cloudflare 1.1.1.1, plus a server-side recursive query through the PeopleAreGeek REST API.
3. Parse the responses: extract the answer records, the TTL, the response status, and the CNAME chain that was followed.
4. Group the unique answers across resolvers to see which records each resolver currently returns and which it does not.
5. Score consistency: when every resolver returns the same record set, the change is propagated; when a minority still shows the old value, propagation is still under way; when one or more resolvers fail or return empty, there is likely a configuration problem upstream.

Common use cases for a DNS propagation checker

• After a record edit on your registrar. You changed an A record from one IP to another and you want to know how many resolvers already see the new value before announcing the migration to users.
• During a hosting migration. When pointing a domain to a new server, both the old and the new value can be returned for hours. The comparison view shows how much of the global pool has switched over and helps you decide when to retire the legacy host.
• When troubleshooting a “different on my machine” report. A teammate sees the new site, another still hits the old one. The chances are that their resolver is serving a stale cache. A quick check from this page surfaces exactly which public resolver is lagging.
• Email delivery investigations. A new MX, SPF or DMARC record is only effective once it reaches the receiving mail server’s resolver. Comparing the TXT and MX answer across resolvers helps confirm that bounce or quarantine issues are not caused by stale DNS.
• SSL certificate validation. DNS-01 challenges for Let’s Encrypt or similar ACME flows require a fresh TXT record. If validation fails, comparing what each resolver returns helps determine whether the record is published correctly or still propagating.
• Subdomain takeover audits. When a CNAME points to a third-party service, comparing the CNAME chain on several resolvers can catch dangling delegations that have already been removed from the authoritative server but are still cached elsewhere.
• Security investigation of suspicious domains. A clearly inconsistent set of answers across resolvers can be a sign of fast-flux DNS or geographically targeted hijack. It is one signal among many but it is quick to capture.

Limitations and privacy notes

This tool gives a representative picture of how three independent vantage points see a domain right now, but it does not cover every resolver in the world. Most consumer ISPs run their own internal resolvers; corporate networks sometimes operate split-horizon DNS that returns internal IPs for the same name. If a user reports a problem from such a network, the tool can confirm that the public side looks fine, but the final step usually requires a query from inside the user’s network. The TTL countdown shown for each resolver is the value the resolver is currently returning, which is not necessarily the value that was originally set on the authoritative server: caching and forwarding can lower it. Some other large public resolvers (Quad9, OpenDNS, AdGuard, NextDNS) do not currently allow direct browser queries because their DoH endpoints do not return the CORS headers that browsers require; a future version of this tool will reach them through a server-side proxy.

For privacy, the domain you query travels to the DoH endpoints of Google and Cloudflare, plus the PeopleAreGeek server for the third vantage point. Google and Cloudflare publish their own privacy policies for resolver queries. The PeopleAreGeek server resolver does not log the domain you query. The result is computed entirely in your browser and is cleared as soon as you close or refresh the page.

Frequently asked questions

Related tools and resources

DNS propagation rarely sits alone. The tools below help confirm the record at the authoritative source, review delegation, inspect TLS readiness on the new IP, and audit the wider domain health.