DNSSEC Validation Report

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

DNSSEC Checks	Status
{{ c.label }}

Domain Name System security validation is a practical way to confirm whether a domain publishes signed records and that signatures align across the chain. When people talk about key status and trust they mean these checks in plain terms. The page labels the result as Configured or Partial or Incomplete or Missing so you can judge at a glance and decide what to address first.

Provide a domain and you receive an overall verdict plus a human readable breakdown of what passed and what failed. The report also lists the answers it saw and how long each lookup took so you can relate the result to expected change windows and caching effects, all without opening specialist tools.

For example you might check research.example after adding a new signing key at your registrar. The page could show Configured with both key roles present and future expiration times visible in the details. If you rerun soon after a change you may see a brief swing because different servers cache answers for different periods.

Start by checking the parent zone after you publish the linking record, then check the name itself. Take note of the time to live if you plan a key change and allow for caches to drain. If results look odd, try again from another network and include the quick status summary when reporting progress.

Technical Details:

Domain Name System Security Extensions (DNSSEC) add digital signatures to name data so resolvers can detect tampering. A zone publishes public keys in DNSKEY, links those keys to its parent using DS, and attaches signatures to record sets as RRSIG. Operators commonly use two roles: a key signing key (KSK) to sign the key set and a zone signing key (ZSK) to sign everyday answers.

This validator queries five record types over DNS over HTTPS and evaluates practical checks. It confirms that DNSKEY and DS exist, that at least one KSK (flag 257) and one ZSK (flag 256) are present, and that all DNSKEY entries use protocol 3. It also verifies that RRSIG(DNSKEY) is present and currently valid, compares algorithms, accepts DS digests of SHA‑256 or SHA‑384, notes NSEC or NSEC3PARAM, and records whether the resolver set the AD bit.

Interpret the overall label as a readiness signal. Configured means the zone publishes keys and parent linkage with distinct signing roles; Partial indicates progress but one core element is missing; Incomplete shows only a fragment. Review the per‑check results to spot mismatches such as algorithm differences or expired signatures, and compare lookup times and time to live with recent deployment changes.

Processing pipeline:

Sanitize the domain by removing scheme, path, and any trailing dot.
Validate the name with a strict pattern; allow localhost and Punycode prefixes.
Fetch DNSKEY DS RRSIG NSEC and NSEC3PARAM in parallel over DNS over HTTPS.
Parse answers and TTL values; record per‑query time rounded to milliseconds.
Build sets for algorithms digest types and key tags from record data.
Count keys by flag values 257 for KSK and 256 for ZSK.
Confirm every DNSKEY entry lists protocol value 3.
Extract RRSIG covering DNSKEY; check inception and expiration against current UTC time.
Compare the DS algorithm set against the DNSKEY algorithm set.
Mark digest types acceptable when codes 2 or 4 appear.
Note whether the resolver set the AD bit on DNSKEY and DS responses.
Aggregate pass and fail states; derive the overall label using explicit rules.

Symbols & Units:

Symbols and units used in outputs
Symbol	Meaning	Unit/Datatype	Source
`T`	Time to live from the first answer	seconds (integer)	Derived
`t_ms`	Per‑record lookup duration	milliseconds (integer)	Derived
`AD`	Authenticated Data flag on the reply	boolean	Derived
`alg`	Algorithm identifiers seen	set of integers	Derived
`digest`	DS digest type codes	set of integers	Derived
`tag`	Key tag identifiers	set of integers	Derived
`KSK`	Count of keys with flag 257	count	Derived
`ZSK`	Count of keys with flag 256	count	Derived

Status bands & interpretation:

Status logic and meaning
Status Band	Condition rule	Interpretation
Configured	DNSKEY present and DS present and KSK≥1 and ZSK≥1	Key material and parent linkage are in place.
Partial	DNSKEY and DS present, or DNSKEY with KSK or ZSK present	Setup underway; at least one essential piece still missing.
Incomplete	DNSKEY present or DS present, but not Partial	Only a fragment is published; continue configuration work.
Missing	Neither DNSKEY nor DS present	No signing material found at the name.

Constants & checks used:

Constants and acceptance rules
Constant	Value	Notes
Acceptable DNSKEY algorithms	8, 13, 14, 15, 16	Presence of any marks acceptable.
Modern signature algorithms	13, 14, 15, 16	Used to flag contemporary coverage on RRSIG(DNSKEY).
Acceptable DS digest types	2, 4	SHA‑256 or SHA‑384 accepted.
DNSKEY protocol value	3	All DNSKEY entries must list 3.

Units, precision & rounding policy:

TTL values are integers in seconds; decimal separator is a period.
Lookup duration is rounded to the nearest millisecond using standard half‑up rounding.
All numeric interpretation uses base 10.

Validation & bounds extracted from code:

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

I/O formats & encoding:

Inputs and outputs summary
Input	Accepted Families	Output	Encoding/Precision	Rounding
Domain name (FQDN or Punycode)	ASCII labels; Punycode prefixes (`xn--`) accepted	Record list, pass/fail checks, optional JSON and CSV	Text; integer TTL and ms timings	Lookup time to nearest 1 ms

Time & calendrics:

Signature inception and expiration timestamps are parsed as YYYYMMDDhhmmss and interpreted in UTC.

Networking & storage behavior:

Per‑record lookups are issued from the client to a DNS over HTTPS resolver with an accept: application/dns-json header.
No application server stores data; downloads are generated locally.

Performance & complexity:

Five lookups run in parallel; overall time scales with the slowest response.
Computation is linear in the number of returned answers; memory use is modest.

Diagnostics & determinism:

Identical inputs can produce different results as records change or signatures roll.

Security considerations:

Input is sanitized and pattern‑checked before querying.
The checks interpret metadata; they do not perform full cryptographic verification of signatures.

Worked example:

Scenario: dnssec‑demo.example publishes keys and a parent link. A lookup records T = 3 600 and a 28 ms query time. The signature window is active.

\begin{matrix} now & \geq & inception \\ now & \leq & expiration \end{matrix}

\begin{matrix} t {ms}_{} & = & round (t {end}_{} - t {start}_{}) \end{matrix}

Result: Configured, with KSK and ZSK present, DS linked, and RRSIG(DNSKEY) valid now.

Assumptions & limitations:

Results reflect one resolver’s view; answers can differ by location and policy. Heads‑up
Status logic relies on presence, flags, and windows rather than full chain validation. Heads‑up
Acceptable DNSKEY algorithms are 8, 13, 14, 15, 16; “modern” are 13–16.
Acceptable DS digest types are 2 and 4 only.
Only the DNSKEY signature window is assessed.
The AD flag depends on resolver behavior and may be suppressed.
Single‑label names are rejected except localhost; international names require Punycode.
Lookup timing is informational and not a performance benchmark.

Edge cases & error sources:

Network timeouts or SERVFAIL responses interrupt checks.
NXDOMAIN or empty answers produce “present” failures by design.
Clock skew can misclassify signature windows near boundaries.
Very low TTLs can cause apparent flapping across quick reruns.
Multiple RRSIGs may exist; only DNSKEY coverage is evaluated for validity now.
Algorithm or digest codes outside the accepted sets are flagged as failures.
Trailing dots are stripped; embedded schemes or paths are discarded before validation.
Punycode inputs are accepted as‑is; no runtime conversion from Unicode labels is performed.

Scientific and standards backing:

The DNSSEC core specification is defined across RFC 4033, RFC 4034, RFC 4035, with operational clarifications in RFC 6840.
DNS over HTTPS behavior is specified in RFC 8484.
Algorithm and digest code points are assigned through IANA registries.

Privacy & compliance:

Queries are issued from the client to a DNS over HTTPS resolver; no application server stores your inputs or results. Use with non‑sensitive domain names and follow your organization’s network policies.

Step‑by‑Step Guide:

Domain security validation returns a clear configuration label and a checklist you can act on.

Enter the Domain you want to assess.
Run the validation and wait for the summary label to appear.
Open the checks list to see which conditions passed or failed.
Compare lookup times and TTLs when investigating recent changes.
Repeat after publishing changes to confirm the expected improvement.

Example: zone.example returns Partial because DNSKEY and DS exist but only KSK is present. After adding a ZSK, rerun and confirm Configured.

You now know whether the signing setup is ready and what to adjust next.

Features:

One‑glance status label for quick triage.
Human‑readable checklist covering key material, linkage, algorithms, and digest types.
Record answers with TTL and per‑query timing.
Optional chart view for pass versus fail at a glance.
Copy or download structured results for audit notes.

FAQ:

Is my data stored?

No. Inputs are sent to a resolver for lookups and results are kept on the device for display and optional download.

Network queries are necessary to retrieve records.

How accurate is the status?

It reflects the resolver’s live answers and metadata. It does not perform full cryptographic validation of every signature in the chain.

Use it to guide fixes, then confirm with authoritative tooling if required.

What units are shown?

Time to live appears in seconds. Lookup duration appears in milliseconds. Status checks show pass or fail in plain text.

Can I use it offline?

No. It needs network access to request records from a resolver.

Does this cost anything?

No licensing terms are presented here. Use according to your organization’s policies.

Why does “Partial” appear?

Partial means progress is visible but at least one core element is missing such as a DS link or one of the key roles.

What does the AD flag mean?

It indicates that the resolver claims to have validated the data it returned. Policies vary, so treat it as advisory.

How do I publish a DS record?

Generate signing material, publish keys at the zone, then submit the DS to the parent through your registry or registrar workflow.

Exact steps vary by provider.

Troubleshooting:

“Lookup failed” — retry or check network filters and resolver reachability.
“Enter a valid domain” — remove schemes and paths; use a fully qualified name.
Unexpected “Missing” — ensure you queried the zone apex rather than a subdomain.
AD flag always off — the resolver may suppress it by policy.
DS mismatch — confirm algorithm numbers and key tags match current keys.
Expired signatures — wait for the rollover to complete and republish if needed.

If your registrar publishes DS but your zone has no keys, validation will fail for relying clients. Remove or fix DS before going live.

Advanced Tips:

Tip Run checks from different networks to spot cache or policy variation.
Tip Align algorithm choices with modern codes to simplify audits.
Tip Track TTLs during rollovers to predict when users will see changes.
Tip Keep key tags handy when comparing DS and signature metadata.
Tip Use the chart view to summarize progress for status reports.

Glossary:

DNSSEC: Security extensions that add signatures to DNS data.
DNSKEY: Record holding public keys for a zone.
DS: Record in the parent linking to a child’s key.
KSK: Key used to sign the DNSKEY set.
ZSK: Key used to sign everyday records.
RRSIG: Digital signature covering a record set.
NSEC: Record proving non‑existence of a name.
NSEC3PARAM: Parameters used for NSEC3 negative proofs.
TTL: Time a resolver may cache an answer.
AD flag: Indicator that a resolver validated an answer.