DNSSEC Validator

DNSSEC (the DNS Security Extensions) adds data origin authentication and data integrityto DNS answers by attaching cryptographically generated digital signatures to sets of records (RFC 4033 §3). When a validating resolver fetches a signed record it can prove two things: the answer really came from the authoritative zone, and it was not altered on the way. That is what stops DNS spoofing and cache-poisoning attacks, where an attacker injects forged answers to send users to the wrong server.

DNSSEC also provides authenticated denial of existence— cryptographic proof that a name or record type genuinely does not exist — using NSEC or NSEC3 records (RFC 4033 §3.2). NSEC records list the next existing name in the zone, which has the side effect of letting anyone “walk” the zone and enumerate every name; NSEC3 hashes the names (salted SHA-1 with configurable iterations) to make that enumeration expensive (RFC 5155 §1.1).

It is just as important to know what DNSSEC does not do. It is explicitly not designed to provide confidentiality(RFC 4033 §4): queries and responses still travel in plaintext, so DNSSEC does not hide which domains you look up. Query privacy is the job of DNS-over-HTTPS or DNS-over-TLS, a separate technology. DNSSEC also does not protect against denial-of-service attacks, and it secures individual record sets rather than zone transfers, which are guarded by mechanisms such as TSIG (RFC 4033 §4). If you are auditing a domain’s broader configuration rather than its signatures, our DNS validator checks for issues like missing glue records and lame delegation.

The four Trust Status verdicts

The Trust Status at the top of your report maps onto the four validator states defined by the DNSSEC standards (RFC 4033 §5, RFC 4035 §4.3):

• Valid (secure)— a complete chain of signed DNSKEY and DS records runs from the trust anchor down to the record set, and every signature checks out. This is the state you want.
• Unsigned (insecure)— there is signed proof that no DS record exists at the delegation, so the zone is legitimately not using DNSSEC. This is not an error; the domain works, but resolvers cannot detect tampering with its answers.
• Invalid (bogus)— the resolver believes it ought to be able to build a chain of trust but cannot, because a DS record exists yet the cryptography fails (an expired, missing, or mismatched signature). Validating resolvers typically return SERVFAIL, which can make the domain unreachable for the users behind them.
• Error— the lookup itself could not complete (for example a timeout or an unreachable nameserver), so no verdict could be reached. This is a checking problem, not necessarily a DNSSEC problem.

The chain of trust

DNSSEC validation follows an alternating sequence of DNSKEY and DS records, with each link vouching for the next (RFC 4033 §2). Validation starts at the trust anchor — in practice the root zone’s Key Signing Key — and walks down: the root DNSKEY set signs the DS record for a top-level domain, that DS matches the TLD’s DNSKEY, the TLD signs the DS for your domain, and so on to the record you asked about. The Chain of Trust panel lists each of these steps with its own status, so a single failing step tells you exactly where the chain broke rather than just that it did.

The root is anchored by a well-known key: the current active root KSK is KSK-2017 (key tag 20326), and a successor, KSK-2024 (key tag 38696), has been in the root zone since early 2025 and is planned to take over signing later. You do not need to configure any of this — it is the fixed top of every chain.

The DS, DNSKEY and RRSIG record tables

Below the chain, the tool lists the raw records it found. Here is how to read each field:

DS (Delegation Signer) records live in the parentzone and hold a digest of your zone’s KSK — they are the link the parent publishes to vouch for you (RFC 4035 §2.4). The Key Tag is a short fingerprint identifying which DNSKEY the DS refers to; the Algorithm number names the signing algorithm (for example 13 for ECDSAP256SHA256 or 8 for RSASHA256 per RFC 8624); and the Digest Typenames the hash used for the digest — type 2 (SHA-256) is mandatory, while type 1 (SHA-1) is validation-only and must not be used for new delegations.

DNSKEYrecords publish your zone’s public signing keys. The Flags field is the quickest tell: 257 marks a Key Signing Key (KSK), which signs only the DNSKEY set and is the key your parent’s DS references, while 256 marks a Zone Signing Key (ZSK), which signs everything else. The KSK/ZSK split is purely an operational convention rather than a protocol requirement (RFC 6781) — it lets you roll the ZSK frequently without touching the registrar and roll the KSK only rarely.

RRSIG (Resource Record Signature)records are the signatures themselves; at least one must cover each authoritative record set (RFC 4035 §2.2). Type Covered says which record set the signature protects, and the Key Tag points at the DNSKEY that produced it. The two timestamps matter most for debugging: the Inception and Expirationbound the window in which the signature is valid, and validation is a plain wall-clock comparison against them (RFC 4035 §5.3.1). If the expiration has passed, the signature is treated as invalid.

Most invalid (bogus) results trace back to a handful of recurring mistakes. Here is what each looks like and how a domain owner resolves it.

Expired RRSIG signatures

Signatures have an expiration timestamp, and the current time must be at or before it (RFC 4035 §5.3.1). When a signer’s automation stops running, the signatures simply age out and the zone goes bogus. Fix: re-sign the zone and put monitoring on RRSIG expiration so you are warned well before signatures lapse.

DS record at the parent does not match any DNSKEY

This is the classic “changed DNS provider and broke DNSSEC” case. The DS record lives at your registrar or parent zone and does not follow a nameserver change, so after a migration it still references the old provider’s key. Fix:remove the DS record before migrating, then republish a new one after the new DNSKEY is live — or adopt CDS/CDNSKEY automation so the parent updates the DS for you (RFC 7344).

Missing signature coverage

Each record set must carry an RRSIG for every algorithm present in the apex DNSKEY set (RFC 4035 §2.2). Partial signing — after a manual edit, say — leaves some sets unsigned and breaks validation. Fix: re-sign the whole zone so every set is covered; modern signers do this automatically.

Algorithm mismatch during a rollover

The apex DNSKEY set must be signed by each algorithm that appears in the parent’s DS set (RFC 4035 §2.2). Note the nuance: if a resolver supports none of the DS algorithms it should treat the zone as unsigned (insecure) rather than bogus (RFC 4035 §5.2). Fix: use a double-signature rollover (RFC 6781) and update the DS only after both algorithms are live in the zone.

Clock skew

Because inception and expiration are checked against the validator’s own clock (RFC 4035 §5.3.1), a resolver with the wrong time can see perfectly good signatures as expired or not-yet-valid. This is a resolver-side problem, and a checking tool distinguishes it by comparing the timestamps against true UTC rather than a local clock. Fix:correct the affected resolver’s clock (usually via NTP).

Broken denial-of-existence chains

After zone edits, an incomplete NSEC or NSEC3 chain (or a mismatched iteration count) can make legitimate “this name does not exist” answers fail validation (RFC 4035 §5.4, RFC 5155). Fix: regenerate the full NSEC/NSEC3 chain after any zone change, which modern signers handle for you. Once your DNSSEC is healthy, you can confirm the underlying records resolve as expected with our DNS flattener.