RESOLVER BEHAVIOUR DIAGNOSTICS

DNS Resolver Comparison

Put the same question to several public resolvers and read the differences: stale caches, DNS filtering, DNSSEC validation flags and response times.

No sign-up required. Public hosts and addresses only; results show what was observed, nothing is simulated.

What this comparison is for

Different recursive resolvers can give different answers to the same question, for reasons that are easy to confuse: one has an older cached copy, one blocks the domain, one validates DNSSEC and refuses a bad chain, one is steered to a nearby CDN node, and one is simply slow. This tool asks them all at once and sorts the differences by likely cause, to help you decide which problem you have.

It differs from the propagation checker in purpose. Propagation judges resolvers against an authoritative reference for one record type. The comparison looks at the resolvers themselves, for up to four record types in one run, such as A, AAAA, MX and TXT, and reports the majority view and the outliers.

What is queried

For each record type you list, the tool asks the system resolver of the scanner and ten public resolver addresses: Cloudflare (1.1.1.1 and 1.0.0.1), Google Public DNS (8.8.8.8 and 8.8.4.4), Quad9, Cisco OpenDNS, AdGuard DNS, Verisign Public DNS, Control D and CleanBrowsing. The default types are A and AAAA. Each row shows the answer, rcode, remaining TTL, AD flag, response time and a note about the resolver's policy, for example malware blocking or ad filtering.

How to read the result

All answering resolvers agree: a pass for that record type, with the common result shown.
Some resolvers differ: the tool reports the majority result and the outliers. Different address sets are normal for CDN and load-balanced names, where answers depend on the resolver, and also happen while a changed record is still cached.
Filtering signs: a resolver that returns NXDOMAIN or a sinkhole address (0.0.0.0 or ::) where others return real records is reported as possible DNS filtering. It is a hint, not proof, because an outage or stale cache can look similar.
AD flag differs: AD means that resolver validated DNSSEC for the answer. Only some public resolvers validate, so a mix is common; the DNSSEC checker examines the chain.
Failures at some resolvers: a SERVFAIL at some but not all resolvers can indicate a DNSSEC validation problem or a resolver-side policy. A timeout says nothing about the record.
Slow resolvers: those over one second are listed. The figure is one measurement, includes cache misses, and is not a benchmark.

Telling the usual causes apart

Everyone agrees on a wrong answer: the authoritative data is wrong. The comparison cannot find that; use the record lookups.
Two or three disagree and TTLs are counting down: caching. Wait for the remaining TTL.
One filtering resolver returns NXDOMAIN or a sinkhole: the domain is on a block list or category. Check the resolver operator's lookup page.
Validating resolvers fail, non-validating ones answer: typical of broken DNSSEC.
Different addresses that persist beyond the TTL: a CDN or geo-steered service.

How to act on a difference safely

Do not edit DNS in response to a difference without first deciding which of the above applies, since changing records to chase a stale cache or a filter resets nothing and may break what already works. If the cause is caching, wait and watch the TTL. If a filter blocks your domain, request a review through the operator and keep your records unchanged.

If DNSSEC is suspected, do not remove a DS record impulsively. Run the DNSSEC checker, and follow the order of operations it describes.

Choose the record types affected, up to four.
Run the comparison and note the majority answer and the outliers.
Match each outlier to caching, filtering, validation or steering.
For caching, wait the remaining TTL and re-run. For filtering, contact the resolver operator.
For SERVFAIL on validating resolvers, run the DNSSEC checker before touching any record.
Record the result before and after any change; to roll back, restore the earlier record.

Limits of the test

Resolver addresses are anycast and are queried once from this scanner, so the answer reflects whichever node responded, not every location the operator runs. Operators can change their filtering policy without notice. The tool does not know what your own ISP resolver or office resolver returns, and a result at one moment is not a history.

Frequently asked questions

How is this different from the propagation checker?

Propagation compares resolvers with the authoritative answer for one type. This tool compares resolvers with each other for up to four types and highlights filtering, AD flags and speed.

Why do resolvers return different IP addresses?

CDNs and load balancers answer according to resolver location, and caches can also hold older values. Check the TTL before assuming a fault.

What does a sinkhole address mean?

A filtering resolver may return 0.0.0.0 or :: for a domain it blocks, so clients cannot connect.

Is the speed column a benchmark?

No. It is one query from one place and includes cache misses. It only flags a resolver that was clearly slow.

Why only four record types?

To keep a run bounded; 11 resolvers times four types is already 44 queries. Run again for others.

Which resolver should I use?

The tool does not rank resolvers. Choice depends on privacy policy, filtering preferences and your network.

Scope of this tool

These are anycast public resolvers queried from this scanner. They are not geographic probes: a resolver answering from a different site, or a CDN steering answers by resolver, is not visible here. Propagation of a change is judged by agreement and TTL.

Written by DNS Tools editorial · Last updated 2026-10-09