Resolver Policy Difference Comparator

Introduction:

A domain can look reachable through one recursive DNS resolver and blocked, rewritten, or temporarily broken through another. The difference may come from normal DNS behavior, such as cache age or CDN steering, but it can also come from resolver policy. Security resolvers may suppress names connected with malware or phishing. Family-filtering resolvers may rewrite names that match adult-content categories. DNSSEC-aware resolvers may also disagree when validation flags change the response path.

Resolver policy comparison is most useful when the same hostname and record type are tested through more than one kind of resolver at about the same time. Open resolvers give a baseline for what a normal recursive lookup sees. Filtered resolvers show whether a provider's security or family policy changes that baseline. If the open baseline is already split, the evidence is weaker because the difference may reflect where the resolver sits on the internet, which cached answer it has, or how the domain's authoritative DNS and CDN are steering traffic.

Open control

A public resolver profile used as a baseline because it is not selected for threat or family filtering in the comparison.

Filtered tier

A resolver profile that may apply malware, phishing, adult-content, or family-safety policy before returning an answer.

Zero-sink

An address such as 0.0.0.0 or :: that prevents a normal client connection to the original destination.

Validation drift

A difference tied to DNSSEC-related status or flags rather than a clear content-filtering answer change.

DNS-over-HTTPS is only the transport for this kind of check. It carries DNS questions over HTTPS, which protects the query from simple network interception between the client and the resolver, but the selected resolver still receives the hostname and record type. The useful evidence comes from comparing the DNS responses: status code, answer values, time-to-live values, DNSSEC signals, provider comments when exposed, and transport failures.

For incident notes, false-positive reports, or troubleshooting, the important record is not just the final label. Keep the hostname, record type, resolver family, validation mode, timestamp, and row-level evidence together. A later run may differ after a resolver refreshes cache, a provider changes categorization, or the domain owner updates records.

A DNS policy split is also narrower than a web-access diagnosis. DNS can explain why a client reaches a different address or no address, but browser controls, endpoint security, firewalls, TLS inspection, HTTP status codes, and application behavior can still decide what the user actually sees.

How to Use This Tool:

Use one focused question per run. Start with the hostname and record type that match the symptom, then widen the resolver pack or validation mode only when the first result needs more context.

1. Enter a domain, fully qualified hostname, or URL. The hostname is normalized before lookup, and invalid names are rejected before any resolver requests are sent.
2. Choose the record type. Use A for IPv4 website symptoms, AAAA for IPv6, CNAME for alias changes, MX for mail routing, NS for delegation checks, and TXT for verification or policy text records.
3. Select the resolver pack. Policy ladder compares open, threat-filtered, and family-filtered profiles; Threat-filter ladder narrows the check toward malware blocking; Family-filter split focuses on family filtering; Provider ladders emphasizes same-provider open-versus-filter evidence.
4. Leave validation mode at Resolver default unless DNSSEC is part of the symptom. DNSSEC visible asks for DNSSEC material, while bypass validation asks for a response even when resolver-side validation would otherwise matter.
5. Use Advanced only when transport coverage is poor. Retry attempts can fill in timed-out rows, and the timeout range keeps one slow resolver from holding up the whole comparison.
6. Run the comparison, then read the Policy Evidence Brief before the ledgers. Use the Resolver Response Ledger for row-level status, answers, TTLs, AD flags, timing, comments, and errors.

Exports are useful when another operator needs to repeat or challenge the reading. CSV and DOCX exports preserve the table evidence, while JSON keeps the structured verdict, rows, clusters, provider ladders, recommendations, and radar metrics together.

Interpreting Results:

Read the result in order: open-control consensus, filtered divergence, then same-provider ladder evidence. A filtered resolver that returns a zero-sink address while open controls agree on a normal answer is strong evidence of resolver policy. A filtered difference beside a weak or split open baseline is less certain because normal DNS variation is already visible.

The radar view compresses five comparison signals into a fast visual shape: response split, status shift, TTL drift, validation drift, and filter confidence. It is a summary of the same resolver rows, not a separate measurement. Use it to spot which profile family is unusual, then inspect the ledger row that created the shape.

A no-difference result is still useful. It means the selected resolver pack did not show a visible DNS policy split for that hostname, record type, and moment. It does not prove the domain is safe, correctly categorized everywhere, or reachable from every network.

Technical Details:

DNS-over-HTTPS carries a normal DNS question inside an HTTPS exchange. The response still has ordinary DNS concepts: a response status code, answer records, time-to-live values, authority and additional sections, and DNSSEC-related flags when the resolver exposes them. Comparing policy behavior therefore starts with normalizing those DNS response parts into values that can be grouped across providers.

Outcome grouping uses the DNS status code plus a normalized answer fingerprint. Address records are sorted with address-aware ordering, name records have trailing dots removed where appropriate, TXT chunks are joined into readable strings, and duplicate effective answers are collapsed. This makes the comparison less sensitive to display order while still preserving row-level evidence for inspection.

DNSSEC modes change request flags rather than the hostname or record type. The default mode reflects normal resolver behavior. DNSSEC visible requests DNSSEC-related material where supported. Bypass validation asks the resolver to return data even when upstream validation might otherwise affect the answer. A difference that appears only when these modes change should be treated as validation behavior before it is treated as category filtering.

The supported record types cover common access, routing, and verification checks: A, AAAA, CNAME, MX, NS, and TXT. The same policy question can produce different evidence by record type. A domain might have filtered A records while TXT or MX records remain unchanged, so compare the record type that matches the real symptom.

Privacy and Accuracy:

The selected public resolvers receive the queried hostname, record type, and DNSSEC-related request flags needed for the lookup. Some resolver paths can be queried directly from the browser. When a provider blocks direct browser access, the same lookup details may pass through a server-assisted relay so the comparison can return a row instead of a silent browser failure.

Do not treat the page as a private local-only DNS lab. DNS-over-HTTPS encrypts traffic in transit to the resolver path, but public resolver providers can still observe the DNS question according to their own service policies. Avoid entering private internal hostnames unless you are comfortable sending them to the selected public resolver services.

Accuracy depends on timing, resolver reachability, provider policy freshness, cache state, anycast location, and the target domain's authoritative DNS. Repeat important checks, keep exports with timestamps, and confirm from the affected network before publishing a block claim or requesting a categorization change.

Worked Examples:

Threat-filter split. An A-record run for a suspicious hostname returns ordinary addresses from open controls, while a threat-filtered profile returns 0.0.0.0. The policy brief reports filtered divergence and a zero-sink row, so the next check is provider categorization rather than changing the domain's public records.

Family-filter split. A family-filter pack shows open controls and threat-filtered rows aligned, but a family tier returns a different answer. That pattern points toward content-category policy instead of general malware blocking.

CDN-like open split. Open controls return different address sets and TTL ranges before filtered tiers are considered. The result moves toward cache or CDN drift, which means authoritative DNS, CDN steering, and a repeat run are better follow-ups than a filtering escalation.

DNSSEC-focused symptom. The answer values stay aligned across profiles, but AD flags differ and the verdict reports validation-policy drift. A validation-focused rerun helps separate DNSSEC handling from category blocking.

Too little evidence. A short timeout leaves only one completed row. The result is limited evidence, so increasing timeout or narrowing the resolver pack is more useful than interpreting the single row as a policy decision.

FAQ:

Advanced Tips:

• Use Policy ladder for the first pass, then switch to Provider ladders when same-provider open-versus-filter evidence matters more than broad resolver coverage.
• Keep Target name, Record type, and Validation mode unchanged across repeat runs so cache movement, policy changes, and resolver failures are easier to separate.
• Start with A or AAAA when the symptom is web reachability. Use MX, NS, CNAME, or TXT only when the real operational question is mail routing, delegation, aliasing, or verification text.
• Read Provider Ladder Ledger before escalating a block claim. Same-provider differences are usually stronger than comparing a security resolver from one provider with an open resolver from another.
• Increase Request timeout or add one Retry attempt only when transport failures hide the answer pattern. A narrower resolver pack is often clearer than a very slow broad run.
• Avoid private internal hostnames unless disclosure is acceptable. The selected public resolvers receive the queried name and record type, and relayed rows still require the lookup details to leave the browser.

Glossary:

DNS-over-HTTPS

DNS queries and responses carried over HTTPS while preserving DNS response concepts such as status code, answer section, TTL, and flags.

Recursive resolver

A DNS service that accepts a client query, finds or caches the answer, and returns the result to the client.

Open control

A resolver profile used as a baseline because it is not selected for a security or family-filtering role.

Filtered tier

A resolver profile that may apply threat, malware, phishing, adult-content, or family policy before answering.

Answer fingerprint

A normalized grouping key based on the response status and effective answer values.

Zero-sink answer

An address such as 0.0.0.0 or :: that usually prevents a client from reaching the original destination.

TTL

Time to live, the number of seconds a DNS answer may remain cached before it should be refreshed.

AD flag

The authenticated-data flag a resolver may set when reporting DNSSEC-validated data.

CD flag

The checking-disabled flag a client may set when it wants a resolver response even when validation would otherwise affect the answer.

References:

• RFC 8484: DNS Queries over HTTPS, RFC Editor.
• RFC 1035: Domain Names - Implementation and Specification, RFC Editor.
• RFC 4035: Protocol Modifications for the DNS Security Extensions, RFC Editor.
• JSON API for DNS over HTTPS, Google Public DNS.
• Set up Cloudflare 1.1.1.1 resolver, Cloudflare Docs.
• Quad9 services, Quad9.
• Understand OpenDNS FamilyShield, Cisco.
• How to check DNS resolution in Linux, Simplified Guide.
• How to query DNS records in Windows, Simplified Guide.