What the DNSSEC module validates on your chain of trust: signing, DS records, algorithm choices, signature lifetimes and authenticated denial – with scoring and fixes.
Check your domain →
Last updated: September 2026 · 8 checks documented
DNSSEC enabled (zone signed) #
DNSSEC attaches cryptographic signatures to the RRsets of a zone (RFC 4033 §3.1), so a validating resolver can detect tampered or poisoned DNS data. What is signed is the zone's data, not the response around it – the header, the RCODE, the AD bit and the transport are not covered, so the protection reaches exactly as far as a resolver that actually validates; a stub that simply believes the AD bit of its upstream resolver is trusting that resolver, not a signature (RFC 4033 §5). Without DNSSEC, DNS-based security mechanisms (e.g. DANE) are ineffective.
Ratingpass if DNSKEY records are present; fail if the zone publishes none. If our own DNSKEY lookup does not conclude (DNS/DoH error, SERVFAIL, REFUSED), the check is skipped as "not determinable" instead of declaring the zone unsigned. A zone without DNSKEY whose parent still publishes a DS record – or that validating resolvers reject – is reported as broken (bogus), not as unsigned. Weight 3. When a hostname (e.g. www.example.com) is scanned, the enclosing zone is evaluated – DNSKEY records only exist at the zone apex.
How to fix itEnable DNSSEC at the DNS provider/registrar (sign the zone + register the DS).
DS record at the parent zone #
The DS record anchors the zone’s signature in the global chain of trust. Without it, the signature is present but not verifiably anchored.
Ratingpass if the parent publishes a DS record. fail if the zone is signed and the parent publishes none, if DS records exist but none matches a published DNSKEY by key tag AND algorithm (a stale DS – unless a validating resolver already authenticates the zone, which means a cache lagging behind a key rollover rather than a stale record), or if a DS exists while the zone publishes no DNSKEY at all. The last two additionally cap the module at F, because validating resolvers then reject every record of the zone. Where the DS itself could not be retrieved, an AD=1 answer counts as pass: it proves a validated chain down to this zone. A corroborated SERVFAIL counts as pass too, but on weaker evidence – SERVFAIL is a single, undifferentiated signal (RFC 4033 §5) that does not say WHICH zone is bogus, so a break in the parent zone would be attributed to this one; the value beside the line therefore says the anchor was inferred, not read. skip if the zone is unsigned or if the DNSKEY/DS lookup gave no conclusive answer. Weight 2.
How to fix itRegister the DS record with the domain registrar (often automatic via an "enable DNSSEC" switch).
Validation by resolver (AD flag) #
A validating resolver sets the AD flag only if it has itself authenticated every RRset in the Answer and Authority sections (RFC 4035 §3.2.3), and resolvers should set it only when the query carried the DO or AD bit (RFC 6840 §5.8 – ours does). A missing AD flag therefore does not mean "bogus": it means the answer was not authenticated – an unsigned (insecure) branch, a resolver that does not validate, or a lookup that failed on our side, which this check reports separately as "not determinable". A genuinely broken chain looks different: the resolver answers SERVFAIL (RFC 4035 §5.5).
Ratingpass with AD=1; warn as long as there is neither an AD flag nor a SERVFAIL confirmed by a second lookup with validation switched off (not authenticated – and a SERVFAIL without that counter-check counts as transient, not as bogus); fail on the confirmed SERVFAIL, plus Cap F: on its own SERVFAIL is the generic server-failure code and proves nothing about signatures. skip if the zone is unsigned, if the DNSKEY/DS lookup gave no conclusive answer, or if our own validating lookup failed – an AD flag we never saw is not a statement about the chain. Weight 3. For hostnames: if the zone validates but the host resolves via a CNAME into a branch that is not authenticated (typical for CDNs), the finding is a warn with weight 1 – the final addresses are not end-to-end authenticated. If the zone itself validates but a validating resolver answers SERVFAIL for the host, it is a fail: behind validating resolvers that name does not resolve at all.
How to fix itEnsure a complete, valid chain: DS at the parent, valid RRSIGs, consistent algorithms. A CNAME target that is not covered by a validated signature chain (a CDN, typically) is usually outside your control and acceptable – the signed zone still protects the CNAME itself. A CNAME target whose own chain is signed but BROKEN is not acceptable: validating resolvers then answer SERVFAIL and the host is unreachable for their users. Fix the target's chain, or point the name at a target whose zone validates.
Key algorithms & strength #
Outdated algorithms (RSA/SHA-1, DSA) are considered weak. RFC 9905 forbids SHA-1-based DNSSEC signing entirely; RFC 9904 (obsoletes RFC 8624) rates RSA/SHA-512 (alg. 10) as NOT RECOMMENDED. Recommended are RSA/SHA-256 (8), ECDSA P-256 (13) or Ed25519 (15). For RSA the key length also counts: short keys can be factored – historically zones used 1024-bit zone-signing keys with frequent rollovers, today at least 2048 bits are expected. NIST SP 800-131A Rev. 2 disallows RSA below 2048 bits for signature generation and rates 1024–2047 bits as legacy-use for verification only – the same split our two thresholds follow (warn below 2048, fail below 1024).
Ratingpass with modern algorithms and adequate key sizes; warn with RSA/SHA-512 or RSA below 2048 bits; fail with algorithms the IANA registry marks MUST NOT for signing – RSA/MD5 (1), DSA (3), RSA/SHA-1 (5), DSA-NSEC3-SHA1 (6), RSASHA1-NSEC3-SHA1 (7) and ECC-GOST (12, via RFC 9906) – or RSA below 1024 bits (practically breakable). Weight 2. Key-size limits apply to RSA only – ECDSA/Ed25519 keys have fixed, adequate sizes. An algorithm number our table does not know does not prevent a pass: the finding names the gap on our side in its explanation instead of holding it against the zone.
How to fix itMigrate the zone to a modern algorithm – ECDSA P-256 (13) or Ed25519 (15), whose keys and signatures are much smaller – or use RSA ≥ 2048 bits (key rollover).
DS digest algorithm #
The DS record references the DNSKEY via a hash. SHA-1 as a digest type is outdated; SHA-256 (type 2) is recommended.
Ratingpass with SHA-256 or another digest the registry allows for delegations (SHA-384, GOST R 34.11-2012, SM3); warn with a digest the IANA registry marks MUST NOT for delegations, e.g. SHA-1 (type 1, RFC 9905) or GOST R 34.11-94 (type 3, RFC 9906). Exception: a SHA-1 DS published alongside a SHA-256 DS stays a pass – per RFC 4509 §3 validators ignore the SHA-1 record while a SHA-256 record is present, which is the ordinary state during a digest change. A digest type our table does not know does not prevent a pass; the gap is named in the explanation. Only evaluated when the parent publishes a DS record. Weight 1.
How to fix itPublish DS records with digest type 2 (SHA-256).
RRSIG time remaining #
DNSSEC signatures (RRSIG) have an expiry date. Past the expiry a validating resolver can no longer authenticate the affected RRsets (RFC 4035 §5.3.1) and answers SERVFAIL to its clients (§5.5 — RCODE 2 to the originating client; only a query carrying the CD bit still gets the full response, and CD is the validating client's own tool) – for a zone anchored by a DS at the parent that normally means the domain stops resolving for everyone behind a validating resolver. A signed zone WITHOUT a DS at the parent is an insecure delegation (RFC 4035 §5.2): its signatures are not checked, so an expiry there does not affect reachability. A signature whose validity has not started yet – a signer clock running ahead – has the same effect as an expired one. Providers that sign online use deliberately short validity windows and re-sign continuously, so a short remaining time is expected there.
Ratingpass > 7 days. For short-lived signatures (validity window ≤ 8 days, i.e. automatic re-signing) pass as long as more than a day remains. warn below that. Expired → fail while a DS at the parent anchors the zone; without a DS validating resolvers do not check the signatures at all, so it is only a warn, and if the DS lookup itself gave no answer the finding says so rather than guessing. A signature whose inception lies clearly in the future (more than 24 h ahead – signers backdate on purpose, RFC 6781 §4.4.2) is not yet valid and always fails, DS or not. Cap F applies to an expired or not-yet-valid signature only while the zone is anchored AND no validating resolver contradicts it with AD=1. Which signature is measured: an RRset may carry several RRSIGs – RFC 4035 §2.2 requires at least one per algorithm of the zone's DNSKEY RRset and explicitly permits more, and a double-signature ZSK rollover publishes two of the same algorithm (RFC 6781 §4.1.1.2) – so the one with the latest expiry decides; a leftover signing path is named, not counted as an expiry. Weight 1.
How to fix itEnsure automatic re-signing of the zone (most DNS providers do this automatically). If the signature is not valid yet, synchronise the signing system's clock (NTP) and re-sign. If an expired second signature is still published alongside a valid one, remove that leftover signing path once its rollover is complete.
Authenticated Denial (NSEC/NSEC3) #
NSEC/NSEC3 prove the non-existence of entries. With classic, pre-computed NSEC the zone contents can be enumerated by zone walking; online signers answering with minimally covering NSEC records (RFC 4470, "white lies") or compact denial of existence (RFC 9824) are not affected. NSEC3 hashes the names, but RFC 9276 §2.3 rates that protection as moderate at best – common prefixes fall to a dictionary and the collected hash chain can be cracked offline. §3.1 (BCP 236) puts NSEC ahead of NSEC3 where the operational or security features of NSEC3 are not needed. Where NSEC3 is used, RFC 9276 §3.1 requires an iteration count of 0 and asks operators not to use a salt; opt-out is NOT RECOMMENDED for small zones but MAY be used for very large, sparsely signed ones.
Ratingpass with NSEC3 without extra iterations and an empty salt; warn on extra iterations or a non-empty salt (opt-out is not observable from NSEC3PARAM); NSEC is info. When the NSEC3PARAM lookup fails – no answer at all, or a server-failure rcode – the row says "not determined" (skip) and is counted as not measured, so the weight it would have carried stays visible in the report instead of quietly disappearing from the denominator. Weight 0–1.
How to fix itIf the zone uses NSEC3, run it with an iteration count of 0 and without a salt (RFC 9276 §3.1). Do not switch from NSEC to NSEC3 as a matter of course: RFC 9276 §3.1 puts NSEC first where NSEC3's operational or security features are not needed, and §2.3 rates its enumeration protection as moderate at best. Where enumeration of the zone contents really matters, the effective answers are minimally covering NSEC records (RFC 4470) or compact denial of existence (RFC 9824) – both, like NSEC3, cost computation, so measure before switching.
Automated DS maintenance (CDS/CDNSKEY) #
CDS/CDNSKEY records (RFC 7344/8078) let the zone tell its parent which DS records it wants – registries/registrars that consume them update the DS automatically during key rollovers, removing the most error-prone manual DNSSEC step. This check reads BOTH RRsets of the zone: RFC 7344 §4 lets a child publish either type alone, and when both are published they must match in content. The special record CDS 0 0 0 0 (or CDNSKEY 0 3 0 0) requests DS REMOVAL, i.e. switching DNSSEC off. Automated DS maintenance during key rollovers is RFC 7344; RFC 8078 adds the initial enrolment and the delete signal, and for the FIRST DS the authenticated bootstrapping of RFC 9615 (which updates RFC 8078) is now the preferred route. The drill-down adds whether the parent publishes a DSYNC notification endpoint (RFC 9859) – i.e. whether it can be told about a new CDS/CDNSKEY RRset instead of having to poll for it.
Ratinggood when CDS or CDNSKEY records are published (whether they match the DS set, await the initial DS, or have a pending DS update); warn when the delete record is published (DNSSEC removal pending – usually unintended) or when CDS and CDNSKEY are both published but do not describe the same keys (RFC 7344 §4); info when neither is published; "not checked" (skip) when the module's time budget was used up by the mandatory lookups before this optional pair – nothing is then claimed about the zone, and because it is our own cap the skip carries no weight and no caveat. Weight 0 – never affects the grade.
How to fix itOptional: enable CDS/CDNSKEY publication at the DNS provider. RFC 7344 §4 says a child publishing either SHOULD publish both CDS and CDNSKEY, matching in content; which of the two your parent consumes is its choice (§6), and it may accept only one. If the registry consumes them (RFC 8078), the DS is then maintained automatically; for the first DS, the authenticated bootstrapping of RFC 9615 is the preferred route.