Domain Name System Security Extensions (DNSSEC) Validation

#	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

Signed domain name records are cryptographic proofs that answers come from the correct zone and have not been altered. This checker summarizes keys, signatures, and delegation links in a clear domain signature validation checklist so you can see what passes.

Enter a domain and run the lookup, then read the simple status at the top and the detailed checks below. You will see whether the parent publishes a link to your key, whether signatures are present, and whether the timing is within the active window.

A typical positive result shows a key at the zone, a matching reference at the parent, at least one key for signing and one for delegation, and valid signatures that span the current time. If one piece is missing the summary moves from configured to partial or incomplete so you know what to fix first.

Use consistent domains and repeat checks after changes to compare runs. Remember that valid structure does not prove the service is reachable or the key is well protected.

Technical Details:

Domain Name System Security Extensions (DNSSEC) add digital signatures to DNS records to create a trust path from a parent zone to a child zone. This report examines whether key material is present at the zone, whether the parent publishes a corresponding delegation reference, and whether signature windows currently cover the data.

The computation reads five record sets for the domain — DNSKEY, DS, RRSIG, NSEC, and NSEC3PARAM — via a resolver that returns structured answers, time‑to‑live values, and an authenticated‑data flag. From these, the tool derives a pass or fail outcome for each check and a concise overall status.

Results group naturally into bands: “Configured” when keys, delegation, and both key roles are present; “Partial” when essentials exist but one role is missing; “Incomplete” when only one side is visible; and “Missing” when neither appears. Values near a boundary, such as signatures close to expiration, deserve follow‑up even if they pass.

Comparisons are meaningful for the same domain at close times because caches, clock differences, and rollover stages can shift outcomes. The checks are structural and timing focused rather than full cryptographic verification of the chain to the root.

Processing pipeline

Normalize the domain by removing schemes, paths, and trailing dot.
Validate the name against length and label rules or allow localhost.
Query DNSKEY, DS, RRSIG, NSEC, and NSEC3PARAM over HTTPS in parallel.
Parse answers, TTLs, and the resolver’s authenticated‑data flag.
Count KSKs (flag 257) and ZSKs (flag 256) in DNSKEY.
Extract algorithms, digest types, and key tags from DNSKEY, DS, and RRSIG.
Evaluate checks and compute the overall status label.
Summarize timing and counts; present a pass versus fail chart.

valid = (t_{inc} \leq t_{now} \leq t_{\exp})

Symbols and units for timing and flags
Symbol	Meaning	Unit/Datatype	Source
tnow	Current time at evaluation	UTC Date	Derived
tinc	RRSIG inception timestamp	UTC Date	From RRSIG
texp	RRSIG expiration timestamp	UTC Date	From RRSIG
TTL	Record time to live	seconds	From answers
AD	Authenticated‑Data flag set by resolver	boolean	From answers

Worked example. Domain example.com returns one DNSKEY with flag 257 and one with flag 256; a DS is present; RRSIG(DNSKEY) inception is 2025‑10‑01 00:00:00Z and expiration is 2025‑10‑31 00:00:00Z; the current time sits between them; digest type is 2 and the DS algorithm matches a DNSKEY algorithm. Result: all critical checks pass and the overall status is Configured.

Interpretation bands and action cues
Band	Criteria summary	Action cue
Configured	DNSKEY and DS present; at least one KSK and one ZSK.	Monitor timing and plan routine rollovers.
Partial	DNSKEY and DS present, but a key role may be missing.	Add the missing role or complete propagation.
Incomplete	Only one of DNSKEY or DS present.	Publish the missing side to complete the link.
Missing	Neither DNSKEY nor DS detected.	Enable signing and publish delegation.

Validation & bounds extracted from code

Input field validation and constraints
Field	Type	Min	Max	Step/Pattern	Error Text	Placeholder
Domain	string (FQDN or localhost)	1	253	/^(?=.{1,253}$)(?!-)([A-Za-z0-9-]{1,63}(?<!-)\.)+[A-Za-z]{2,63}$/ or prefix `xn--`	Enter a valid domain like example.com	example.com

Constants & checks

Algorithms, digests, flags, and record families used
Constant	Value	Source	Notes
Record types queried	DNSKEY, DS, RRSIG, NSEC, NSEC3PARAM	Code	Requested in parallel.
Acceptable DNSKEY algorithms	8, 13, 14, 15, 16	Code	At least one must appear.
Modern RRSIG algorithms	13, 14, 15, 16	Code	Applies to signatures that cover DNSKEY.
Acceptable DS digest types	2 or 4	Code	SHA‑256 or SHA‑384.
KSK flag	257	DNSKEY	At least one required.
ZSK flag	256	DNSKEY	At least one required.
DNSKEY protocol	3	DNSKEY	All keys must declare protocol 3.

Units, precision & rounding

Query duration is rounded to the nearest millisecond.
TTL values are integers in seconds, displayed as returned.
RRSIG timestamps use a 14‑digit YYYYMMDDHHMMSS format and are parsed as UTC.

I/O formats & encoding

Inputs and outputs
Input	Accepted Families	Output	Encoding/Precision	Rounding
Domain name	FQDN, punycode prefix `xn--`, or localhost	Records, checks, summary	Text values; JSON and CSV available	Durations rounded to ms

Networking & storage behavior

Lookups are requested from your browser to a DNS‑over‑HTTPS resolver at cloudflare-dns.com. Results are rendered locally; the app does not persist your inputs or outputs.

Performance & complexity

Five network requests are made in parallel and processed in linear time with respect to the number of answers returned. Rendering and charting operate on small in‑memory arrays.

Diagnostics & determinism

Given identical inputs at the same moment, results are deterministic for that resolver. Differences may arise from caches, clock skew, or active key rollovers.

Security considerations

Input is sanitized to remove schemes, paths, and trailing dot.
Validation enforces label length, character set, and top‑level restrictions.
Punycode labels are accepted when prefixed appropriately.
No cryptographic verification of signatures is performed in the client.

Assumptions & limitations

Relies on one resolver’s view at query time.
Authenticated‑data flag may be unset by policy despite valid signatures.
Checks focus on DNSKEY and DS coherence, not full chain validation.
Signature validity uses timestamp windows, not cryptographic verification.
Algorithm and digest acceptability follow fixed lists in code.
Negative response coverage is inferred by NSEC or NSEC3PARAM presence.
Local clock skew can misclassify near‑boundary timestamps.
Delegation changes can lag due to caching and registry schedules.
Heads‑up Resolver outages or filtering can mimic domain misconfiguration.

Edge cases & error sources

Empty or whitespace‑only input after trimming.
Non‑ASCII characters not converted to punycode.
Leading or trailing hyphen in any label.
Labels exceeding 63 characters or name exceeding 253 characters.
Malformed RRSIG timestamps not matching 14‑digit format.
Resolver returns no answers for a queried type.
Unknown algorithms or digest types not in the accepted sets.
AD flag suppressed by resolver configuration.
Network timeouts or HTTP errors during lookups.
Stale caches producing conflicting TTLs across resolvers.

Privacy & compliance. Requests are issued from the browser to the resolver endpoint; the app does not transmit results to an application server or retain them beyond your session.

How‑to · Step‑by‑Step Guide

Domain signature validation produces a status and a checklist of key and delegation conditions.

Enter the domain name in the field.
Select Validate to start lookups.
Read the status badge and pass versus fail chart.
Open “Checks” to see which conditions passed.
Open “Records” to inspect answers, TTLs, and query times.
Copy or download results if you need to share them.

Example: After publishing a new DS, rerun validation until both DNSKEY and DS appear and signature timing is active.

Tip: Validate again from a second network to compare cache effects.

Pro tip: rotate keys during low‑traffic windows and watch signature windows before they hit expiry.

FAQ

Is my data stored?

No. Inputs and results are rendered locally. Queries are sent to a DNS‑over‑HTTPS resolver and are not retained by the app.

How accurate is the status?

It reflects your resolver’s view right now. Structural checks and timing windows are evaluated; full cryptographic validation of the chain is not performed.

What units do you show?

Durations are milliseconds, TTL is seconds, and signature times are UTC.

Can I use it offline?

No. It needs a network connection to query the resolver.

Does it cost anything?

No purchase is required to run checks or download the outputs.

How do I validate a DS record?

Confirm a DS exists, its algorithm matches a DNSKEY algorithm, the digest type is 2 or 4, and its key tag matches a DNSKEY signature’s key tag.

What does “borderline” result mean?

It often means signatures are near inception or expiration, or only one side of the delegation is visible. Re‑check after propagation.

Why is “Resolver set AD” failing?

Some resolvers clear the authenticated‑data flag by policy. A cleared flag does not always imply bad signatures.

Troubleshooting

“Enter a valid domain” — remove schemes or paths and check label rules.
No answers — verify the domain exists and query again after a short wait.
Only DNSKEY present — publish a DS at the parent and wait for propagation.
Only DS present — publish DNSKEY at the zone and enable signing.
RRSIG not valid now — check clock and rollover timing.
Unexpected algorithms — confirm signer supports accepted sets.
AD not set — try a different validating resolver.
Slow queries — check network path or resolver health.

Blocking issue: RRSIG shows expiration in the past. Renew signing keys and republish signatures before traffic relies on them.

Advanced Tips

Tip Verify new DS at multiple times to see cache roll‑off.
Tip Keep at least one overlapping signature window during rollovers.
Tip Track key tags before and after changes to confirm swaps.
Tip Prefer algorithms in the modern set when available.
Tip Lower TTLs ahead of planned changes to speed convergence.
Tip Recheck after registry updates to confirm the DS appears at the parent.

Glossary

DNSKEY: Public key record at the zone used to verify signatures.
DS: Delegation reference at the parent that points to a key.
KSK: Key Signing Key that signs the DNSKEY set.
ZSK: Zone Signing Key that signs other records in the zone.
RRSIG: Signature record that covers a specific RRset.
AD flag: Resolver marker indicating verified data.
TTL: Time a record may be cached before refresh.
NSEC/NSEC3PARAM: Records that support authenticated denial of existence.

Domain Name System Security Extensions (DNSSEC) Validation

DNSSEC Summary

Introduction:

Technical Details:

Processing pipeline

Validation & bounds extracted from code

Constants & checks

Units, precision & rounding

I/O formats & encoding

Networking & storage behavior

Performance & complexity

Diagnostics & determinism

Security considerations

Assumptions & limitations

Edge cases & error sources

How‑to · Step‑by‑Step Guide

FAQ

Troubleshooting

Advanced Tips

Glossary