This free test checks your domain's DNSSEC configuration across eight individual checks: Is the zone signed? Is the DS record anchored at the parent? Do validating resolvers accept the chain (AD flag)? How long are the signatures still valid, and do the key algorithms match current best practice? Check your domain →
DNSSEC signs DNS answers cryptographically: the zone publishes its keys as DNSKEY records and signs every record set (RRSIG). The whole thing is anchored through a DS record in the parent zone – creating an unbroken chain of trust from the DNS root, through the TLD, down to your domain. Without DNSSEC, DNS answers can be forged (cache poisoning), and mechanisms built on top of it such as DANE are rendered useless.
Many zones are signed, but the DS record is missing at the registrar. In that case the signatures do exist, but they hang in mid-air: validating resolvers treat the zone as if it were unsigned – the protection is zero, and nobody notices. The opposite case is more dangerous: if a DS record is set but the signatures have expired or no longer match after a key rollover, the zone is considered "bogus" – validating resolvers respond with SERVFAIL and the domain becomes unreachable for a large part of the internet. This test cleanly distinguishes the two cases: it checks DNSKEY, DS and resolver validation separately.
The test additionally evaluates the RSA key length (below 2048 bits: warning; below 1024 bits: practically breakable, error) and the digest algorithm of the DS record.
DENIC has signed the .de zone since 2011 – every .de holder can use DNSSEC, provided the registrar and DNS provider support it. This matters above all for email: DANE strictly requires DNSSEC, and the German BSI guideline TR-03108 ("Secure Email Transport") mandates DNSSEC and DANE for certified email service providers. So enabling DNSSEC lays the foundation for enforced, encrypted mail transport.
The most common reason: the DS record is missing at the parent (registrar/registry). The signatures do exist in that case, but they are not anchored in the chain of trust – validating resolvers treat the zone as if it were unsigned, so the protection has no effect.
ECDSA P-256 (algorithm 13) or Ed25519 (15) are recommended – both produce much smaller keys and signatures than RSA. RSA/SHA-256 (8) with at least 2048 bits is still fine. SHA-1-based algorithms (5 and 7) are forbidden for signing under RFC 9905.
Yes, on operational mistakes: if the RRSIG signatures expire or the DS record no longer matches after a key rollover, the zone is considered "bogus" and validating resolvers return SERVFAIL. Automatic re-signing at your DNS provider and CDS/CDNSKEY for automatic DS maintenance guard against this – this test shows the remaining lifetime of the signatures.
RFC 4033 (DNSSEC fundamentals) ↗ · RFC 9904 (algorithm recommendations) ↗ · RFC 9905 (SHA-1 forbidden for signing) ↗ · RFC 9276 (NSEC3 parameters) ↗