DNSSEC Validator

DNSSEC (the DNS Security Extensions) adds data origin authentication and data integrity to 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 Trust Status verdicts

The Trust Status at the top of your report maps onto the validator states defined by the DNSSEC standards (RFC 4033 §5, RFC 4035 §4.3), plus one of our own for the case where the check could not reach a conclusion:

• 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. A zone signed only with a deprecated SHA-1 algorithm is reported here too, with a note saying so — see below.
• 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.
• Not determined — the check could not establish enough to judge: a query timed out, every resolver refused, or the zone signs with an algorithm this tool cannot verify. It says nothing about whether the zone is correct, and it is deliberately kept apart from “unsigned”: a lookup that failed is not evidence that a domain has no DNSSEC.
• Error — the lookup itself could not complete. This is a checking problem, not necessarily a DNSSEC problem.

Which zone the verdict is about

DNSSEC is a property of a zone, not of a hostname. A name like www.example.com usually has no DS or DNSKEY of its own — it is an ordinary name inside the example.com zone, whose apex holds both. So the tool first works out which zone actually signs the name you asked about, by reading the signer name from the signature over the answer, or the SOA the resolver returns, or by asking for SOA up the name. The report names that zone next to the name you typed. Occasionally a host is its own zone — www.cloudflare.com has its own DS — and then it is evaluated at its own apex.

Zones signed with SHA-1 (algorithms 5 and 7)

A few zones — defense.gov and nsa.gov among them — still sign with RSASHA1 (algorithm 5) or RSASHA1-NSEC3-SHA1 (algorithm 7). This tool verifies those signatures itself, because RFC 9905 keeps “Implement for DNSSEC Validation: MUST” for both, and it will tell you in the chain of trust that the signatures checked out.

It does not report such a zone as valid, and the reason is worth being precise about. RFC 9905 (November 2025) says operators of validating resolvers “MUST treat RSASHA1 and RSASHA1-NSEC3-SHA1 DS records as insecure”, and that where no DS of an accepted algorithm exists, “the DNS records below the delegation point MUST be treated as insecure”. Note that this is a rule about the delegation: the test is the set of DS records at the parent, not the algorithm of the answer’s own signature. A zone publishing one SHA-1 DS and one modern DS validates normally through the modern one, and the SHA-1 DS is simply ignored as a chain link. Only when every DS is algorithm 5 or 7 is the delegation insecure. The verdict is then Unsigned, with a warning naming the algorithm and the RFC — the zone is signed, it simply gets no protection in practice. The fix is a rollover to a current algorithm such as 13 (ECDSAP256SHA256).

A DS record’s digest type is a separate field and a separate question. Digest type 1 is also SHA-1, but RFC 9905 leaves it at “Use for DNSSEC Validation: RECOMMENDED” and “Implement for DNSSEC Validation: MUST”, and RFC 8624 §3.3 lists it as “DNSSEC Validation: MUST” with only generation forbidden. So a DS carrying a SHA-1 digest of a modern key is an ordinary, usable delegation and is treated as one here.

Be aware that deployed resolvers have not all caught up: as of this writing the major public resolvers still set the AD bit on algorithm-7 answers. That is a transitional state, not a reason to rely on those signatures.

Answers that are not a record set

Not every answer is a set of records to check a signature against, and the report distinguishes them, because the same missing RRSIG means different things in each case. A name may exist with no records of the type you asked for, or not exist at all; in both cases there is no record set for a signature to cover, and the proof of absence lives in NSEC or NSEC3 records instead. This tool does not verify those records itself, so where an answer is empty it reports what it did establish — that the zone is signed and its DS-to-DNSKEY chain holds — and shows the denial as the resolver’s claim, labelled as not independently verified here. An answer may also be an alias (a CNAME), in which case the signature that matters is the one over the alias itself; where the alias points into a zone with no DS, the report says so rather than calling the answer invalid.

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. Every signature this tool reports as verified was checked that way — each link validated from the root trust anchor down — rather than by trusting what a resolver said.

The Chain of Trust panel lists what was checked for the zone that signs your name, step by step: which zone that is, what kind of answer came back, the DS its parent publishes, the DNSKEY set the zone publishes, whether a DS digest matches one of those keys, whether the answer carries a signature and whether that signature verifies from the root. A step is marked as information where it is simply a statement of fact — an unsigned zone having no DNSKEY is how an unsigned zone is supposed to look, not a fault.

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 parent zone 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 Type names 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.

DNSKEY records 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 Expiration bound the window in which the signature is valid, and validation is a plain wall-clock comparison against them (RFC 4035 §5.3.1). Both ends are checked here: a signature whose expiration has passed is invalid, and so is one whose inception is still in the future — usually a signer with a wrong clock.

The report also warns when a signature is near the end of its life, and that warning is relative to the signature’s own validity window rather than a fixed number of days: it appears when less than a fifth of the signature’s lifetime remains, capped at a day. Signing practice varies enormously — some operators sign for thirty days, while Cloudflare re-signs continuously on a window of roughly two days — so a fixed threshold would warn permanently about zones that are behaving perfectly.

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.