DNSSEC Validator

DNSSEC Validation Brief

DNSKEY DS KSK ZSK Resolver: {{ resolverLabel }} AD on DNSKEY+DS: {{ resolverAdPassCount }}/{{ resolverComparisonRows.length }}

Passing checks {{ passCount }}/{{ checks.length }}

Record queries {{ records.length }}

Total query time {{ totalQueryMs }} ms

Domain:

Enter a bare domain such as example.com; schemes, paths, and a trailing dot are stripped.

Resolver:

Pick Cloudflare, Google Public DNS, or Quad9 for the primary DNSSEC lookup.

Compare AD across resolvers:

Turn on when investigating DNSSEC propagation or resolver validation disagreement.

#	Type	Answer(s)	TTL	Query ms	Copy
{{ i + 1 }}	{{ row.type }}	{{ row.answer }}	{{ row.ttl }}	{{ row.time }}

DNSSEC Checks	Status	Copy
{{ c.label }}	Pass Fail

Resolver	DNSKEY Status	DNSKEY AD	DNSKEY #	DNSKEY ms	DS Status	DS AD	DS #	DS ms	Notes	Copy
{{ row.resolverLabel }}	{{ row.dnskey_status }} ({{ row.dnskey_status_text }})	{{ row.dnskey_ad ? 'Yes' : 'No' }}	{{ row.dnskey_answers }}	{{ row.dnskey_time }}	{{ row.ds_status }} ({{ row.ds_status_text }})	{{ row.ds_ad ? 'Yes' : 'No' }}	{{ row.ds_answers }}	{{ row.ds_time }}	{{ row.note \|\| '—' }}

Run a DNSSEC lookup to generate the pass versus fail chart.

Embed:

Customize

Include current inputs

Size

Advanced

Width

Height

Aspect ratio

Max height

Collapsible embed

Allow fullscreen

Referrer policy

Sandbox tokens

Introduction:

DNSSEC Validator turns a domain's DNSSEC records into a readable validation report. It checks whether the domain publishes DNSKEY and DS records, whether expected signing roles are visible, whether signatures are current, and whether selected resolvers report authenticated data.

Use it before enabling DNSSEC, after a registrar or DNS provider change, during an outage review, or when you need a concise evidence export for a security or infrastructure ticket. The report focuses on visible DNSSEC evidence and resolver agreement, so it is practical for triage without pretending to replace a full authoritative trace.

DNSSEC evidence path from parent DS to DNSKEY, RRSIG, and resolver authenticated data signal

How to Use This Tool:

Enter the domain to validate. Paste a plain domain or a URL; the host name is normalized for the check.
Choose the resolver view to use for the primary report.
Turn on resolver comparison when you want to compare authenticated data signals across Cloudflare, Google Public DNS, and Quad9.
Read the summary status first, then inspect the DNSSEC records, validation checks, pass-rate chart, and JSON export.
Use the export in a change ticket when rotating keys, fixing DS mismatches, or proving that a DNSSEC issue has cleared.

Interpreting Results:

Configured means the expected parent and child signals are visible: DS, DNSKEY, and separate KSK/ZSK roles. Partial means some DNSSEC pieces exist but the report sees a missing role or link. Incomplete means only one side of the parent-child relationship is visible. Missing means no usable DNSSEC setup was observed.

Passing checks are strongest when DS records align with DNSKEY algorithms, signatures are within their validity window, modern algorithms are used, and the resolver reports authenticated data. A failed check should be read as a triage lead rather than a final root cause.

Resolver AD comparison helps identify inconsistent validation behavior. Agreement across resolvers is a useful confidence signal; disagreement usually means cache timing, publication differences, or validation failure needs deeper investigation.

Technical Details:

The report gathers DNSKEY, DS, RRSIG, NSEC, and NSEC3PARAM evidence for the normalized domain. It checks for a DNSKEY set, parent DS records, KSK and ZSK flags, protocol value 3, DNSKEY signatures, signature timing, accepted digest and signing algorithms, DS key-tag alignment with DNSKEY signatures, denial-record hints, and resolver authenticated-data signals.

Rule Core

Check	Pass Condition	Why It Matters
DNSKEY present	At least one DNSKEY record is returned.	The child zone publishes signing keys.
DS present	At least one parent DS record is returned.	The parent can delegate trust to the child.
KSK and ZSK roles	Flags 257 and 256 are visible where expected.	Key roles appear complete for normal operations.
RRSIG timing	Signature inception is in the past and expiration is in the future.	Expired or future signatures break validation.
Algorithm posture	Modern DNSSEC algorithms and accepted DS digest types are observed.	Weak or obsolete choices reduce trust and compatibility.
AD signal	The validating resolver reports authenticated data for key records.	Resolver validation agrees with the visible records.

Formula Core

The chart's pass rate is calculated from the validation checks shown in the report:

passRate = \frac{passing checks}{total checks} \times 100

A high pass rate does not prove that every ancestor in the chain is healthy. It shows that the domain-facing evidence and selected resolver view are internally consistent enough for triage or change validation.

Security and Privacy Notes:

The domain name and selected DNSSEC query types are sent to the chosen public DNS resolvers. For sensitive investigations, use a resolver path approved by your organization and avoid entering names that expose confidential projects.

For production DNSSEC changes, pair this report with registrar records, DNS provider audit logs, authoritative server output, and a planned rollback window.

Worked Examples:

Registrar DS mismatch: Check whether the parent DS key tag and digest posture still align after a key rollover.
Expired signature: Use the RRSIG timing check to confirm whether a signing job failed or a stale response is being served.
Resolver disagreement: Compare AD signals across resolvers before declaring a DNSSEC outage resolved.

FAQ:

Does this rebuild the entire chain from the root?: No. It checks visible record evidence and selected resolver validation signals. Use a dedicated trace when you need a full chain reconstruction.
Can a signed zone show as partial?: Yes. A zone can publish keys while the parent DS is missing, mismatched, or not yet visible to the resolver being checked.
Why are denial records included?: NSEC and NSEC3PARAM records help show whether authenticated denial support is visible for the zone.

Glossary:

DNSKEY: A public key record used by DNSSEC to validate signed DNS data.
DS: A parent-zone record that points to a child zone's key and establishes delegation of trust.
KSK: Key Signing Key, commonly used to sign the DNSKEY set.
ZSK: Zone Signing Key, commonly used to sign ordinary zone records.
RRSIG: A DNSSEC signature over a record set.