DNSSEC Validation Report

Introduction:

DNS Security Extensions (DNSSEC) add cryptographic signatures to Domain Name System responses so resolvers can confirm that records come directly from an authoritative zone and have not been altered in transit. By binding public keys to zones, DNSSEC mitigates cache-poisoning attacks, prevents fraudulent redirections, and strengthens the integrity layer that underpins every internet service.

This tool queries a standards-compliant DNS-over-HTTPS resolver for the fully qualified domain you enter, retrieves the current DNSKEY and DS resource records, and applies straightforward rule checks to verify that key-signing (flag 257) and zone-signing (flag 256) keys are present. The resulting report highlights missing records, mismatched flags, and timing information in milliseconds.

Network engineers can run the checker before delegating a newly signed zone, while incident responders can isolate DNSSEC breakage when websites suddenly stop resolving for certain users. Changes to parent-zone DS records often require up to forty-eight hours to propagate through recursive resolver caches; consider repeat tests during that window for authoritative results.

Technical Details:

DNSSEC augments traditional DNS by publishing cryptographically signed resource record sets (RRsets). A zone owner generates a long-term Key-Signing Key (KSK, flag 257) that signs the DNSKEY RRset and a shorter-lived Zone-Signing Key (ZSK, flag 256) that signs all other RRsets. Parent zones publish the child’s KSK digest in a DS record, forming a verifiable chain of trust from the root through every delegation level. Resolvers validate each answer by walking this chain and confirming digital signatures.

Logical Sequence:

1. Resolve the fully qualified domain via DNS-over-HTTPS for the DNSKEY RRset.
2. Record the round-trip time and parse returned keys.
3. Resolve the same domain for the DS RRset published by its parent zone.
4. Test that at least one KSK (flag 257) and one ZSK (flag 256) appear in the DNSKEY dataset.
5. Declare overall pass when both record types exist and the flag criteria are satisfied.

Primary Parameters:

• Domain – fully qualified name to be validated.
• DNSKEY – base64-encoded public keys with associated flags.
• DS – hash digest of the domain’s KSK stored in the parent zone.
• TTL – time-to-live for each RR, expressed in seconds.
• RTT – resolver response time, expressed in milliseconds.

Assumptions & Limitations:

• Relies on a public resolver that supports DNS-over-HTTPS.
• Only verifies record presence, not full cryptographic validation.
• Does not test unsigned child zones beneath the queried domain.
• Time measurements can fluctuate because of network latency.

Edge Cases & Error Sources:

• Resolver blocked by a local firewall or captive portal.
• Stale records cached beyond their effective TTL.
• Mis-published DS pointing to an outdated KSK digest.
• Domains served by multiple CDNs with inconsistent signing status.

Scientific Validity & References:

Based on RFC 4033, RFC 4034, and RFC 4035, plus operational guidance from ICANN security workshops.

No personal data is processed; only publicly available DNS records are queried over an encrypted channel.

Step-by-Step Guide:

Follow these actions to generate a fresh DNSSEC status snapshot.

1. Enter the target domain in the input field.
2. Click Validate DNSSEC to launch the check.
3. Review the first table for raw DNSKEY and DS answers.
4. Confirm the second table shows five green checks.
5. If any check fails, update zone records and rerun the test after propagation.

FAQ:

Glossary:

DNSSEC

Extension that signs DNS data.

KSK

Key that signs the DNSKEY set.

ZSK

Key that signs regular RRsets.

DS Record

Digest of a child zone’s KSK.

TTL

Time a record stays valid in cache.