{{ summaryTitle }}
{{ summaryValue }}

{{ summaryLine }}

{{ badge.label }} {{ badge.value }}
{{ detail.label }} {{ detail.value }}
Parent DS Zone DNSKEY RRSIG Validator
Use one public domain such as example.com. The resolver receives the queried name.

{{ feedback }}

Resolver caches and validation policy can differ during DNSSEC changes.
The neutral default is Off. Turning it on affects the next explicit run only.
{{ compareResolversEnabled ? 'On' : 'Off' }}
LayerCheckStatusEvidenceNext stepCopy
{{ row.layer }}{{ row.label }}{{ row.pass ? 'Pass' : 'Fail' }}{{ row.evidence }}{{ row.nextStep }}
TypeRoleKey tagAlgorithmTTLRecord dataCopy
{{ row.type }}{{ row.role }}{{ row.keyTag }}{{ row.algorithm }}{{ row.ttl }}{{ row.data }}
ResolverDNSKEY statusDNSKEY ADDS statusDS ADQuery timeObservationCopy
{{ row.resolver }}{{ row.dnskeyStatus }}{{ row.dnskeyAd }}{{ row.dsStatus }}{{ row.dsAd }}{{ row.queryMs }}{{ row.note }}

The chart renderer is unavailable. The same pass/fail rows remain available in Validation Checks.

DNS Delegation Trace Analyzer Trace a public hostname through DNS delegation and aliases, compare resolver views, and inspect DNSSEC or negative-cache clues.
SMIMEA / OPENPGPKEY Lookup Look up SMIMEA or OPENPGPKEY records for a mailbox and derive its RFC owner name with DNSSEC and resolver evidence plus cache and payload details.
TLS-RPT Record Validator Validate a TLS-RPT policy from live DNS or pasted text, check report destinations and RFC rules, then build a reviewable TXT record.
dnsmasq DHCP Config Generator Generate a dnsmasq IPv4 DHCP scope with CIDR and pool checks plus reservations, client options and optional PXE lines for a review-ready config.

DNS Security Extensions (DNSSEC) add origin authentication and integrity checks to DNS. A validating resolver follows a chain of signed data from a trusted parent toward the requested zone. When that chain breaks, ordinary records may still exist on authoritative servers while validating clients receive SERVFAIL.

The handoff between parent and child is the most consequential boundary. The parent publishes a Delegation Signer (DS) record derived from a child DNSKEY. The child publishes the DNSKEY and signatures over its record sets. A stale parent DS after a key rollover can therefore make a correctly served child zone appear bogus to validators.

EvidenceRole in the trust path
DSParent-side reference containing a key tag, algorithm, digest type, and digest for the child key.
DNSKEYChild-zone public key record containing flags, protocol value, algorithm, and key material.
RRSIGSignature metadata with the covered type, algorithm, validity window, signer, and key tag.
Authenticated Data (AD)A recursive resolver's statement that it authenticated the response under its validation policy.

Operational checks often start with presence, timing, and linkage. The DS and DNSKEY should identify compatible algorithms and key tags, the DNSKEY record should use protocol value 3, and at least one current RRSIG should cover the DNSKEY set. Algorithm recommendations also change over time, so registry status should be reviewed before a rollover rather than copied from an old runbook.

Resolver evidence is valuable but bounded. An AD flag is not an independent cryptographic trace, and a high pass percentage does not turn several simplified checks into a security grade. Registrar state, authoritative answers from every server, DS digest recomputation, and a controlled rollover plan remain necessary for high-risk changes.

How to Use This Tool:

Run the report against the public domain and validating resolver used by the affected clients, then widen the view only when cache or policy differences matter.

  1. Enter one public domain without a path, query string, or private split-horizon name.
  2. Choose Cloudflare DNS, Google Public DNS, or Quad9 as the primary resolver view.
  3. Enable Compare AD across resolvers when a rollout, incident, or cache transition could produce different validator observations.
  4. Run the validation and start with the first failed check in Validation Checks. Use its layer and next step to identify the registrar, authoritative DNS provider, signer, or resolver owner.
  5. Confirm sensitive changes with authoritative queries and cryptographic DS or signature validation before editing registrar or signing data.

Interpreting Results:

Configured requires visible DNSKEY and DS records plus a DNSKEY carrying both the Zone Key and Secure Entry Point bits. Partial, Incomplete, and Missing describe progressively less of that publication baseline; they do not summarize every signature, algorithm, or resolver check.

The pass rate is a separate count of 15 equal-weight checks. A single failed DS linkage or expired DNSKEY signature may matter more than several passing presence checks. Resolver disagreement should be investigated after relevant TTLs have elapsed, and a missing AD bit should be compared with a known validating path before the zone is changed.

Technical Details:

DNSKEY, DS, and RRSIG data are parsed from the selected recursive resolver's DNSSEC-enabled responses. DNSKEY key tags are computed from the flags, protocol, algorithm, and decoded public-key octets, then compared with DS and RRSIG key tags. Signature inception and expiration timestamps are compared with the observation time.

NSEC and NSEC3PARAM rows are retained as informational evidence when returned. Apex queries do not provide a complete proof of authenticated denial, and the model does not recompute a DS digest or verify signature mathematics.

Formula Core

The displayed pass rate gives every check the same weight and keeps full precision until presentation.

P = p15 × 100 %

P is the pass rate and p is the number of passing checks. The percentage is a triage summary only; no weighting is added for the security consequence of an individual failure.

Rule Core

LayerCheckPass condition
DelegationDNSKEY presentAt least one usable DNSKEY record is returned.
DelegationDS presentAt least one usable DS record is returned.
Zone keysSEP hintAt least one DNSKEY has both Zone Key and Secure Entry Point bits, conventionally flag 257.
Zone keysZone keyAt least one DNSKEY has the Zone Key bit, conventionally flag 256 or 257.
Zone keysProtocolEvery returned DNSKEY uses protocol value 3.
SignaturesDNSKEY RRSIG presentAt least one RRSIG covers the DNSKEY set.
SignaturesDNSKEY RRSIG currentAt least one DNSKEY-covering signature includes the observation time.
SignaturesRRSIG algorithm matchAt least one DNSKEY signature uses an algorithm present in the DNSKEY set.
Key linkageDS algorithm matchAt least one DS algorithm appears in the DNSKEY set.
Key linkageDS digestAt least one DS uses digest type 2 (SHA-256) or 4 (SHA-384).
Key linkageDNSKEY algorithmAt least one DNSKEY uses the report's accepted set: 8, 13, 14, 15, or 16.
Key linkageDS key tagAt least one DS key tag equals a key tag computed from a returned DNSKEY.
Key linkageRRSIG key tagAt least one DNSKEY signature names a returned DNSKEY key tag.
ResolverDNSKEY ADThe primary resolver sets AD on the DNSKEY response.
ResolverDS ADThe primary resolver sets AD on the DS response.

The configuration label follows a smaller publication rule. DNSKEY + DS + SEP + Zone Key gives Configured. DNSKEY with DS, or DNSKEY with a Zone Key, gives Partial. Only one of DNSKEY or DS gives Incomplete; neither gives Missing.

Privacy and Accuracy Notes:

The chosen public resolver receives the queried domain. Cross-resolver comparison sends it to all three supported providers, so do not submit confidential internal names.

Every run is a transient recursive-resolver observation subject to caching, policy, network failure, and the seven-second request timeout. Use authoritative traces, registrar evidence, and independent cryptographic checks before a rollover or incident repair.

References: