What this DNSSEC checker tests
DNSSEC adds digital signatures to DNS, so resolvers can prove an answer really came from the domain's owner and wasn't forged or altered on the way. This DNSSEC checker tests the whole chain of trust:
- Validation status from three public validating resolvers (Cloudflare, Google and Quad9): does each one confirm the answers are authentic (the "AD" flag)?
- Broken DNSSEC detection: if validation fails but the same query works with checking disabled, the domain has a DNSSEC error that makes it unreachable for many users.
- DS records published by the parent registry, and a cryptographic digest check that each one really matches a key in your zone.
- DNSKEY records: key-signing (KSK) and zone-signing (ZSK) keys and their algorithms, with deprecated algorithms flagged.
- Signature validity: when the current signatures were created and when they expire.
How the DNSSEC chain of trust works
DNSSEC works like a chain of signatures from the DNS root down to your domain:
- Your DNS provider signs your records with a zone-signing key (ZSK), creating RRSIG records.
- The ZSK is itself signed by a key-signing key (KSK). Both are published as DNSKEY records.
- A fingerprint of the KSK, the DS record, is placed in the parent zone (for example .com) by your registrar.
- The parent zone is signed in the same way, all the way up to the root, whose key resolvers already trust.
A validating resolver follows this chain. If every link checks out, the answer is marked authentic. If any link is broken, for example a DS record that doesn't match your current KSK, the resolver refuses to answer (SERVFAIL) to protect users from possibly forged data.
Common DNSSEC problems and how to fix them
| Result | Cause | Fix |
|---|---|---|
| Signed, but not secured at the registrar | Zone is signed but no DS record exists | Copy the DS record from your DNS provider into your registrar's DNSSEC settings. |
| DS record without keys | DNSSEC was switched off at the DNS provider, or you moved provider, but the DS remains | Remove the DS record at your registrar, or re-enable signing. |
| Digest mismatch / broken | Keys changed (often after switching DNS providers) without updating the DS | Replace the DS at the registrar with the new one, or remove it urgently. |
| Expired signatures | The provider stopped re-signing the zone | Contact your DNS provider. Expired signatures make the domain fail validation. |
Moving DNS providers? Remove the DS record at your registrar first, wait for its TTL (often 1–2 days), switch providers, then enable DNSSEC again with the new provider's DS record. This is the most common cause of DNSSEC outages.
Recommended algorithms
Algorithm 13 (ECDSA P-256 with SHA-256) is the most widely recommended today: small, fast signatures with broad support. Algorithm 8 (RSA/SHA-256) is still common and fine. Ed25519 (15) is excellent where your provider supports it. Older SHA-1-based algorithms (5 and 7) are deprecated and should be replaced.
Related tools and guides
Frequently asked questions
Do I need DNSSEC?
It's optional, but it protects your visitors against DNS spoofing and cache-poisoning attacks, and some standards (such as DANE for email) need it. Many DNS providers make it a one-click setting. The key is to keep it working once it's on.
Will DNSSEC slow down my website?
Not noticeably. Answers are slightly larger and resolvers cache validated results like any other DNS data.
Why do some resolvers show "AD: No" for a signed domain?
Only validating resolvers set the AD flag. If none of the three validate, check the DS and DNSKEY sections for a broken link. Unsigned domains always show "No".
Where do I add the DS record?
At the registrar where you bought the domain, usually under "DNSSEC" in the domain's settings. Your DNS provider gives you the values to enter.