Skip to content
ProbeDNS

DNS Compare

This tool asks four major public resolvers — Google 8.8.8.8, Cloudflare 1.1.1.1, Quad9 9.9.9.9, and OpenDNS 208.67.222.222 — the same DNS question at the same moment, and shows exactly what each returned. Disagreement is reported as-is, because during a change there genuinely is no single correct answer.

Why four resolvers can give four answers

A recursive resolver answers from its cache when it has a valid entry and only asks your authoritative servers when it does not. Each resolver caches independently, on its own schedule, from its own location. Four resolvers therefore represent four separate snapshots of your zone, taken at four different times.

There are three distinct reasons the answers can differ, and telling them apart is the whole point of this tool:

  1. Caching. You changed a record; some resolvers still hold the previous value until its TTL expires. Time fixes this — nothing else does.
  2. Geographic or load-based steering. The authoritative server deliberately answers differently depending on where the query came from. CDNs do this constantly, which is why google.com legitimately returns different addresses to each of these four resolvers. This is not a fault and will never converge.
  3. A genuinely inconsistent zone. Your authoritative nameservers do not all hold the same data — a failed zone transfer, a half-finished migration, or a lame delegation. This is the case worth panicking about, because it is invisible from any single vantage point.
A quick discriminator: if the differing answers all belong to the same provider's address ranges, it is steering. If one resolver returns your *old* server and the others return the new one, it is caching. If one returns NXDOMAIN while others answer, suspect the delegation.

How the comparison is made

Each resolver is queried through its own resolver instance bound to a single upstream IP address, so no answer can leak in from the host's own configured DNS. Every record set is normalised — sorted, lower-cased, and rendered in the same textual form — before comparison, so that a difference in record *order* (which resolvers rotate deliberately) is never reported as a difference in record *content*.

Read the full explanation of dns compare results ↓

Only resolvers that returned a definite answer count towards the verdict: records, an authoritative empty answer, or NXDOMAIN. A timeout or a refused query is shown in the table but excluded from the consistency check, because a dropped packet is evidence about the network, not about your zone.

StatusMeaning
n recordsNOERROR with an answer. The records are listed in full.
no recordsThe name exists but publishes nothing of this type (NODATA).
NXDOMAINThis resolver was told the name does not exist.
timeoutNo reply within the query timeout. Excluded from the verdict.
refusedThe resolver declined to answer — usually a network-level block between this server and that IP.

Response times include the round trip from this server to each resolver, so they say more about network distance than about resolver speed. Do not read them as a benchmark of which public DNS is fastest for you — that depends entirely on your own location.

What to do with a mismatch

  1. Check the TTL of the record with the full DNS lookup. If the TTL is 3600 and you changed the record 20 minutes ago, a mismatch is expected and requires nothing but patience.
  2. Query your authoritative servers directly. Find them with an NS lookup, then ask each one — that removes caching from the picture entirely and tells you what is actually published.
  3. Compare SOA serials across all your nameservers with the SOA lookup. Different serials mean the zone did not replicate, which is the one failure mode that produces genuinely inconsistent authoritative answers.
  4. If a single resolver returns SERVFAIL while the others answer, run the DNSSEC checker. Validating resolvers SERVFAIL on a broken chain while non-validating ones answer normally, producing exactly this split.
  5. For a wider view than four resolvers, run the DNS propagation checker across all 85 resolvers — four data points can miss a regional problem.

The same comparison from the command line

# The four resolvers this tool uses
for r in 8.8.8.8 1.1.1.1 9.9.9.9 208.67.222.222; do
  printf '%-16s ' "$r"
  dig +short @"$r" example.com A | sort | tr '\n' ' '
  echo
done

8.8.8.8          104.20.23.154 172.66.147.243
1.1.1.1          104.20.23.154 172.66.147.243
9.9.9.9          104.20.23.154 172.66.147.243
208.67.222.222   104.20.23.154 172.66.147.243

# Remove caching from the equation — ask the authoritative servers
for ns in $(dig +short example.com NS); do
  printf '%-28s ' "$ns"; dig +short @"$ns" example.com A | tr '\n' ' '; echo
done
Real output. Identical sets across all four resolvers means the record has settled everywhere.

The sort matters. Without it, the same three addresses returned in three different rotations look like three different answers, and you will chase a problem that does not exist. This tool sorts for the same reason.

One case where disagreement is never benign: if a resolver returns an address in a network you do not recognise, and the others do not, investigate immediately. Check the owner with an ASN lookup. Cache poisoning is rare, but a hijacked or misconfigured DNS account is not.

Frequently asked questions

Why do resolvers return different IP addresses for the same domain?
Usually because the authoritative server is steering traffic by location — CDNs answer with the edge nearest the querying resolver, so different resolvers get different addresses permanently and correctly. The other explanation is caching: one resolver still holds a pre-change value until its TTL expires. The TTL and the address ownership together tell you which you are looking at.
Does "resolvers disagree" mean my DNS is broken?
No. For CDN-hosted and geo-steered names, disagreement is the designed behaviour and will never resolve. It is only a problem when a static record differs, which means either a change is still propagating or your authoritative nameservers are out of sync with each other.
How long should I wait for all four to agree?
Up to the TTL of the previous record, counted from when each resolver last cached it. With a 3600-second TTL, allow a full hour after the change before treating disagreement as a fault. Anything still differing well past the TTL points at the authoritative side, not at caching.
Why does one resolver return SERVFAIL while the others answer?
Almost always DNSSEC. Google, Cloudflare, and Quad9 validate signatures; a zone with a broken chain of trust returns SERVFAIL from them and answers normally from non-validating resolvers. Run the DNSSEC checker — it distinguishes a validation failure from an unreachable nameserver by repeating the query with checking disabled.
Can I use this to test my DNS provider's failover?
Partly. It shows what each resolver currently holds, so after a failover event you can watch the new answer replace the old one across the four. It cannot force a cache to expire, so a record with a long TTL will appear to fail over slowly no matter how quickly your provider acted.
Which public resolver is fastest?
The times shown here are measured from this server, so they reflect its network distance to each resolver and nothing about yours. To find the fastest for you, run the same query from your own machine against each address and compare — and note that the second query will be fast for all of them because it is served from cache.
Why is my answer missing from one resolver entirely?
A timeout or refusal usually means a network problem between this server and that resolver, or rate limiting at their end — not a problem with your domain. Those results are shown but excluded from the agreement verdict for exactly that reason. If one resolver times out repeatedly across several different domains, the fault is on the path, not in your zone.

Related guides

Why Is My DNS Not Propagating?

A checklist for records that refuse to update: caching, wrong zone, and stale nameservers.