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: July 2026 · 8 checks documented
DNSSEC enabled (zone signed) #
DNSSEC cryptographically signs DNS responses, protecting against tampering/cache poisoning. Without DNSSEC, DNS-based security mechanisms (e.g. DANE) are ineffective.
Ratingpass if DNSKEY records are present; otherwise fail. 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 a DS record is present; otherwise fail (only relevant for a signed zone). 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 the entire signature chain checks out cryptographically. If it is missing despite a signature, the chain is incomplete or faulty (bogus).
Ratingpass with AD=1; warn without AD; SERVFAIL → fail (signatures invalid). Weight 3. For hostnames: if the zone validates but the host resolves via a CNAME into an unsigned zone (typical for CDNs), the finding is a warn – the final addresses are not end-to-end authenticated.
How to fix itEnsure a complete, valid chain: DS at the parent, valid RRSIGs, consistent algorithms. CNAME targets in foreign, unsigned zones (CDN) are usually outside your control and acceptable.
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.
Ratingpass with modern algorithms and adequate key sizes; warn with RSA/SHA-512 or RSA below 2048 bits; fail with deprecated/forbidden algorithms (RSA/SHA-1, RSASHA1-NSEC3-SHA1, DSA, RSA/MD5) or RSA below 1024 bits (practically breakable). Weight 2. Key-size limits apply to RSA only – ECDSA/Ed25519 keys have fixed, adequate sizes.
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+; warn with SHA-1. Weight 1.
How to fix itPublish DS records with digest type 2 (SHA-256).
RRSIG time remaining #
DNSSEC signatures (RRSIG) have an expiry date. When they expire, validating resolvers treat the entire zone as bogus – the domain becomes unresolvable. Providers that sign online use deliberately short validity windows (1–7 days) and re-sign continuously – 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 + Cap F. Weight 1.
How to fix itEnsure automatic re-signing of the zone (most DNS providers do this automatically).
Authenticated Denial (NSEC/NSEC3) #
NSEC/NSEC3 prove the non-existence of entries. NSEC allows "zone-walking" (full enumeration of the zone); NSEC3 makes that harder but, per RFC 9276, should run with 0 iterations and without opt-out.
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. Weight 0–1.
How to fix itUse NSEC3 with 0 iterations (RFC 9276); for sensitive zones, replace NSEC with NSEC3.
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. The special record CDS 0 0 0 0 requests DS REMOVAL, i.e. switching DNSSEC off.
Ratinggood when CDS 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); info when no CDS records are published. Weight 0 – never affects the grade.
How to fix itOptional: enable CDS/CDNSKEY publication at the DNS provider if your registry supports RFC 8078 scanning.