Why would resolvers disagree on an answer?

Three common causes. (1) Propagation: you changed DNS and some resolvers still have the old record cached until TTL expires. (2) GeoDNS: the authoritative server returns different answers depending on where the query comes from — resolvers in different regions see different IPs legitimately. (3) Bugs or outages at a specific resolver. The consistency verdict tells you there's divergence; the per-resolver answer tells you which flavour you're seeing.

How is this different from a 'DNS propagation checker'?

Traditional propagation checkers query the authoritative server from multiple geographic locations to see whether the change has been rolled out. Resolver Compare queries what end users actually see — the public recursive resolvers they use daily (Cloudflare 1.1.1.1, Google 8.8.8.8, etc.). The end-user view is what matters because resolvers cache; propagation is only one cause of divergence.

Why Cloudflare, Google, AdGuard, NextDNS specifically?

All four offer JSON-format DNS-over-HTTPS, which is what PingThat queries against. Between them they cover the bulk of public recursive DNS traffic. Quad9 and OpenDNS also offer DoH but not in compatible JSON form, so they're excluded for now. The four represent a geographically diverse and technically diverse sample — divergence between them tends to be meaningful.

What's a good latency number?

Under 150 ms (green) means the resolver is nearby and responsive. 150–400 ms (yellow) suggests a longer route or a less optimised POP. Over 400 ms (red) is unusual — it indicates either a transit problem from PingThat's edge to that resolver, or the resolver itself is slow on this specific query. Retry; if it persists, the resolver may be rate-limiting or have an issue.

DNS Resolver Comparison Online Free

About this tool

Enter a domain to query it from multiple public DNS resolvers in parallel. You see which resolvers agree on the answer, how long each took, and any divergence that hints at propagation in progress, GeoDNS, or resolver caching issues. A practical replacement for ping-from-N-locations when you care about DNS, not RTT.

How to compare DNS resolvers

Enter a domain and record type to query.
The tool sends the query to multiple public resolvers (Cloudflare 1.1.1.1, Google 8.8.8.8, Quad9 9.9.9.9) in parallel.
Review the responses side by side — differences flag propagation delays, censorship or poisoning.
Pick the resolver that best matches your trust model (privacy, speed, filtering).

Common use cases

Confirming a DNS change propagated by comparing resolver answers after editing records.
Diagnosing censorship suspicions when a domain resolves on Cloudflare but fails on your ISP resolver.
Benchmarking resolver speed from your location to pick the fastest for daily use.
Spotting DNS poisoning where one resolver returns an IP that differs from the others.

Frequently asked questions

Why do resolvers sometimes disagree?

Caching timing, different anycast points of presence, and geographic variance in CDN-backed records all produce legitimate differences. Persistent disagreement for non-CDN records is a red flag.

Which resolver is fastest?

Depends on your location. Cloudflare (1.1.1.1) is consistently fast globally; Quad9 prioritises security filtering; Google is widely available. Run the comparison from your own network to decide.

Are these resolvers private?

Cloudflare and Quad9 publish strong privacy policies. Google logs more data. All public resolvers beat the typical ISP resolver in privacy, but none are truly anonymous without Tor.

Is my query logged?

The upstream resolvers may log per their policies. This tool adds no logging of its own.

Why resolver comparison matters

DNS does not propagate instantly. During a migration or a config change, resolvers cache the old record until their TTL expires. If Cloudflare 1.1.1.1 returns the new IP but Google 8.8.8.8 still returns the old one, your users on Google will still hit the old server. This tool surfaces that state so you can wait out the TTL or flush caches deliberately.

Parallel queries against 4 major public resolvers
Consistency verdict across resolvers
Per-resolver latency (colour-coded)
Supports A, AAAA, MX, NS, TXT, CNAME
Divergent-answers detection during propagation

Free. No signup. Browser tools (subnet, JWT, password strength) run locally; lookup tools query public APIs (Cloudflare DoH, RDAP, certificate logs). Full per-tool breakdown at /methodology/.

Sources (2)

Mockapetris, P. (1987). Domain Names — Implementation and Specification. RFC 1035, IETF.
Hoffman, P., & McManus, P. (2018). DNS Queries over HTTPS (DoH). RFC 8484, IETF.

These are the IETF RFCs, NIST publications, and W3C standards the tool implements or queries. Locate them on the IETF Datatracker (datatracker.ietf.org) or the official standards body.

Related guides

DNS Propagation — Why "Wait 48 Hours" Is Mostly WrongDNS changes do not propagate — caches expire. Here is how TTL, negative caching, and public resolvers actually work during a migration.

By Marco B. · Last verified June 2026 — runs in your browser