Resolver Policy Difference Comparator

Resolver policy differences appear when the same DNS name returns one answer through an open resolver and a different answer through a security, malware-filtering, or family-filtering resolver. That split can look like propagation drift, CDN steering, a broken record, or a block page unless the resolver roles are compared side by side.

This comparator sends the same DNS question to a selected resolver pack and groups the replies by status, answer fingerprint, TTL range, validation flags, and zero-sink patterns. The goal is to tell whether the evidence looks like policy shaping or ordinary resolver variation.

DNS results are live network observations. A single run can be affected by cache age, resolver geography, DNSSEC validation state, HTTP transport errors, and filtering products that choose not to answer every category the same way. Use the output as evidence for triage, then confirm with authoritative DNS, endpoint policy, or resolver vendor logs.

Technical Details:

The tool supports A, AAAA, CNAME, MX, NS, and TXT questions. It queries open baselines and filtered profiles from providers such as Cloudflare, Google Public DNS, Quad9, and OpenDNS. Some DNS-over-HTTPS endpoints can be queried directly, while wire-format endpoints that require cross-origin help are routed through a shared proxy.

Each resolver row records transport success, DNS status, answer values, TTL bounds, AD validation flag, latency, section counts, and a normalized answer fingerprint. Outcome clusters then group equivalent replies so a majority answer, filtered outlier, or open-resolver disagreement is easier to see.

The radar score summarizes response split, status shift, TTL drift, validation drift, and filter confidence. It is a compact triage view, not a standards result. The resolver ledger remains the source of the actual answers.

Everyday Use & Decision Guide:

Use the policy pack when you want broad evidence across open, threat-filtered, and family-filtered profiles. Use the threat-filter pack when malware blocking is the question. Use the family split when the expected difference is adult-content or household filtering. Use provider ladders when you want same-provider open and filtered tiers next to each other.

• Run A and AAAA first for web destinations that may be blocked by address replacement.
• Run CNAME or TXT when the policy question concerns aliases, verification records, or service metadata.
• Increase retry attempts only when transport errors are making the ledger sparse.
• Use shorter timeouts for quick checks and longer timeouts when cross-origin proxy paths are involved.

A strong policy signal usually has open resolvers agreeing on one usable answer while filtered resolvers return a zero sink, empty answer, blocked comment, or different status. When open resolvers disagree, move to propagation, CDN, or authoritative DNS troubleshooting before blaming filtering.

Step-by-Step Guide:

1. Enter a domain or host-like target and choose the DNS record type.
2. Select the resolver pack that matches the policy question.
3. Open Advanced only if validation mode, retries, or timeout need adjustment.
4. Run the comparison and read the evidence brief before inspecting individual resolver rows.
5. Use clusters and provider ladders to decide whether differences follow resolver role, provider, or random cache state.

Interpreting Results:

Likely policy split means the filtered profiles diverged while open controls stayed aligned. Mixed resolver drift means the run found differences but attribution is weaker. No material split means the selected pack behaved as one shared answer set during the run.

Latency rows are measurement clues, not performance benchmarks. Public resolver RTT from a browser can vary with route, proxy use, cache, and local network conditions.

For a blocking investigation, keep the resolver response ledger with timestamps and then test from the affected network. Resolver policy can differ between consumer endpoints, enterprise policy accounts, and local network forwarding rules.

Worked Examples:

Malware sinkhole check. An A lookup returns the same address from Cloudflare 1.1.1.1 and Google Public DNS, while Cloudflare Security and Quad9 return 0.0.0.0 or no usable answer. That pattern is strong evidence of threat-filter policy.

Propagation false positive. Open resolvers return different A records with different TTLs, and filtered resolvers split in more than one direction. This is more consistent with cache age, CDN steering, or propagation than a clean policy decision.

Family filter review. Open controls agree on a normal web host, while the family-filter profile diverges and the threat-filter profile does not. The likely cause is category policy rather than malware reputation.

FAQ:

Does a zero address always mean blocking? No. It is strong evidence only when open controls resolve normally and the resolver is known to use filtered responses.

Why can public resolvers disagree without filtering? Cache timing, CDN geography, DNSSEC validation behavior, negative caching, and stale records can all produce different answers.

What data is sent during a run? The target name and selected record type are sent to the chosen public resolver endpoints. Some resolver paths use a proxy so the browser can reach wire-format DNS-over-HTTPS services.

Glossary:

DNS-over-HTTPS

DNS queries carried over HTTPS rather than classic UDP or TCP port 53.

Zero sink

A blocking-style answer that points to 0.0.0.0, ::, or another non-route destination.

AD flag

The authenticated-data flag reported by a validating DNS resolver.

Outcome cluster

A group of resolver replies with the same status and normalized answer set.

References:

• Google Public DNS JSON DNS-over-HTTPS API
• Cloudflare public resolver behavior
• Cloudflare resolver endpoint and filtering profiles