DNSSEC Validator

Introduction:

DNS can return an address and still fail the trust test. That is the uncomfortable part of DNS Security Extensions, usually shortened to DNSSEC. A validating resolver does not only ask whether a record exists; it also asks whether the answer can be tied back through signed evidence to a trusted delegation. When that evidence is missing, expired, mismatched, or hidden by resolver behavior, users may see a plain DNS failure even though the authoritative zone still contains ordinary records.

DNSSEC adds signatures and delegation records to the Domain Name System. The parent zone publishes a DS record that points toward the child zone's signing key. The child zone publishes DNSKEY records and RRSIG signatures over DNS data. Negative answers can be protected by NSEC or NSEC3 evidence so a forged "name does not exist" response is harder to accept. A recursive resolver that validates the answer may set the AD signal, meaning Authenticated Data, when its view of the answer checks out.

Delegation

The parent-side DS record links the domain to a key published in the child zone.

Zone keys

DNSKEY records identify the public keys used for DNSSEC validation, commonly including key-signing and zone-signing roles.

Signatures

RRSIG records prove that an RRset was signed and that the signature is inside its valid time window.

Resolver proof

The AD signal shows that a validating resolver accepted the answer it returned, not that every resolver will agree immediately.

Operational problems usually appear at the joins. A registrar can keep an old DS record after a DNS provider move. A signing system can publish a new DNSKEY before the parent delegation is updated. RRSIG dates can expire when automated signing stops. During a key rollover, one resolver may still cache the old evidence while another has already fetched the new records. The result is often a confusing split: one monitoring probe shows SERVFAIL, another resolver looks healthy, and the zone owner has to decide whether the fault is at the registrar, the authoritative servers, the signing schedule, or the recursive resolver path.

DNSSEC validation reports are best read as triage evidence. They can show which public records are visible, whether signature timing looks current, whether algorithm and digest choices look acceptable for the checker's rule set, and whether selected resolvers return authenticated data. They cannot replace registrar access, authoritative trace output, resolver logs, or a controlled rollover plan when the next change could affect production name resolution.

The most common mistake is to treat a single green or red signal as the whole answer. DNSSEC is a chain, and chains fail at the weakest visible link. A healthy DS with stale child signatures, a signed child zone with no parent DS, or mixed resolver AD results all call for different operational fixes.

How to Use This Tool:

Use the checker to compare DNSSEC record evidence with the selected resolver's validation signal. Keep the same resolver during a change window unless the purpose is to look for resolver disagreement.

1. Enter the target in Domain. Pasted HTTP or HTTPS URLs are reduced to the host name, and a trailing dot is removed. If the page asks for a valid domain such as example.com, remove paths, spaces, ports, fragments, and unsupported characters.
2. Open Advanced when you need to choose the primary resolver. The available choices are Cloudflare, Google Public DNS, and Quad9.
3. Enable Compare AD across resolvers when propagation, resolver caching, or validation policy might explain a disputed result. Leave it off for a focused single-resolver check.
4. Run the validation and wait for the summary to change from Checking to a status such as Configured, Partial, Incomplete, or Missing.
5. Open DNSSEC Records to inspect DNSKEY, DS, RRSIG, NSEC, and NSEC3PARAM answers with TTL and query timing. Use Validation Checks to see the pass and fail labels behind the summary.
6. If resolver comparison is enabled, open Resolver AD to see DNSKEY and DS status for each resolver. The DNSSEC Pass Rate Chart and JSON output are useful when you need a compact report for a ticket, change note, or incident timeline.

Interpreting Results:

Configured means the main DNSKEY, DS, KSK, and ZSK checks all pass in the selected resolver view. That is the strongest status, but it is still a visible-evidence result rather than a full root-to-domain cryptographic trace. Use it as a good sign, then check failed secondary rules, TTLs, and resolver agreement before closing a production change.

Partial means DNSSEC evidence exists but the checker cannot see the full expected key relationship. This can happen when DNSKEY and DS are both visible but some role or companion signal is missing, or when DNSKEY exists with only one of the expected key-role flags. Incomplete points to a more one-sided state, such as parent DS evidence without usable child keys or child keys without a visible parent DS. Missing means neither DNSKEY nor DS evidence was observed.

The pass count and pass-rate chart are not a weighted security grade. A domain with many passing checks can still be operationally broken if the failed item is a DS mismatch, an expired DNSKEY signature, or a missing AD signal on the resolver path that affected users rely on. Treat individual failed labels as the work queue, then use the percentage to compare repeated runs of the same domain and resolver.

Resolver agreement raises confidence. If Cloudflare, Google Public DNS, and Quad9 all return AD for DNSKEY and DS, the public recursive view is likely stable. If one resolver differs, wait for relevant TTLs, compare against authoritative output, and avoid changing registrar DS records until the stale or inconsistent path is understood.

Technical Details:

DNSSEC validation combines record structure, signature timing, key linkage, algorithm posture, and resolver behavior. A parent DS record carries a key tag, algorithm, digest type, and digest. A child DNSKEY record carries flags, protocol value, algorithm, and public key data. RRSIG records name the type covered, the signing algorithm, the original TTL, inception and expiration timestamps, and the key tag used to sign the RRset.

The report checks visible resolver responses rather than rebuilding every cryptographic proof from the root trust anchor. That scope is useful for operations triage because many incidents are caused by missing delegation records, stale signing windows, or resolver disagreement. It also means the report should not be read as a substitute for a full validating trace when a domain is under active incident review.

Rule Core

Status Logic

Pass Rate Formula

The pass-rate chart gives each validation check equal weight. It helps compare repeated runs, but it intentionally does not rank a DS failure, an expired signature, and a missing denial-record hint by operational severity.

For example, 12 passing checks out of 15 gives an 80% pass rate. The failed-check labels still matter more than the percentage when deciding whether to change registrar DS records, restart signing, or wait for cached data to age out.

Privacy and Accuracy Notes:

The normalized domain name and selected DNS record types are sent from the browser to the chosen public DNS resolver using DNS-over-HTTPS. The page does not need a zone file, registrar login, or DNS provider credential. The resolver can still see the queried name and may handle logs under its own policy.

The checker uses public resolver answers and a fixed rule set. It does not prove private split-horizon DNS, internal resolver policy, every authoritative name server, or every root-to-leaf validation step. Results can also change during TTL expiry, key rollover, resolver cache refresh, or incident mitigation.

Avoid checking confidential internal project names against public resolvers unless your environment allows that exposure. For production DNSSEC changes, pair the report with registrar settings, authoritative name server output, a full validating trace, and a rollback plan.

Worked Examples:

• Registrar DS not visible: A newly signed domain shows DNSKEY record present as Pass but DS record present as Fail. The child zone is publishing keys, but the parent delegation has not exposed matching DS evidence to the selected resolver.
• Rollover evidence mismatch: During a provider move, DNSKEY and DS may both appear while DS key tag matches RRSIG(DNSKEY) key tag fails. That points to parent and child evidence that may belong to different key generations.
• Expired signing window: If RRSIG for DNSKEY present passes but RRSIG for DNSKEY valid now fails, check the signing scheduler and authoritative servers before changing DS records.
• Resolver disagreement: A monitoring system reports SERVFAIL while another path resolves normally. Enable Compare AD across resolvers; if only one resolver lacks AD for DNSKEY and DS, wait for TTLs and compare against authoritative output before declaring the incident fixed.

FAQ:

Glossary:

DNSSEC

DNS Security Extensions, the DNS standards that add signed authentication evidence to DNS answers.

DNSKEY

A public key record used to validate DNSSEC signatures for a zone.

DS

Delegation Signer, a parent-zone record that links a delegation to a child-zone key.

KSK

Key Signing Key, commonly indicated by DNSKEY flag 257 in the checker rule set.

ZSK

Zone Signing Key, commonly indicated by DNSKEY flag 256 in the checker rule set.

RRSIG

A DNSSEC signature record with a covered type, algorithm, key tag, inception time, and expiration time.

NSEC or NSEC3PARAM

Records that support authenticated denial-of-existence evidence, including hashed denial setups for NSEC3.

AD

Authenticated Data, the resolver response signal that validation succeeded for the returned data.