DNS Resolver Comparison Tool

The comparison sends the same DNS query — same name, same record type — to several public resolvers in parallel and lays their answers next to each other. Instead of trusting a single resolver, you see what Cloudflare, Google, Quad9, OpenDNS, and any custom resolver each return for the record, so you can tell at a glance whether the internet agrees on the answer.

Reach for the comparison right after you change a record and want to watch it propagate, when a site works for some users but not others, or when you suspect a resolver is handing back a stale or filtered answer. Comparing a public resolver against your ISP or internal resolver quickly separates a local caching problem from a genuine zone problem. For the caching mechanics behind uneven propagation, see DNS TTL explained.

When every resolver returns the same value, the record is consistent and propagation is complete. When answers differ, the resolvers are at different points in their cache cycle — the ones still showing the old value will update once their cached copy expires. An empty answer on one resolver but data on another usually means that resolver has not yet fetched the record, not that the record is missing.

One resolver returns SERVFAIL, the rest answer. A transient upstream failure or a DNSSEC validation issue isolated to that resolver. All resolvers return SERVFAIL. The authoritative servers are unreachable or the zone's DNSSEC signing is broken — fix it at the source. All resolvers return NXDOMAIN. The name genuinely does not exist; check for a typo or a missing record. To tell these failure modes apart, read NXDOMAIN vs SERVFAIL.

Each resolver caches a record for the length of its TTL, and every resolver started its countdown at a different moment, so after a change they expire and refetch at different times. That staggering is exactly why a fresh change looks inconsistent across resolvers for a while. Lowering the TTL a day before a planned change shrinks the window in which resolvers disagree.

These are the patterns you will see across resolvers and what each one usually means.

The most useful comparison is your own ISP resolver against a public one. When a site is down only for you, the public resolvers almost always agree with each other and disagree with your ISP — which points the finger at local caching or filtering, not the domain. Before a planned cutover, drop the TTL a day ahead so the window where these columns disagree stays short.