DNSSEC check
Is the zone signed, does the chain of trust validate, and are the algorithms current?
Working on it…
Running the checks. Results appear here in a moment.
What this tool checks
DNSSEC (RFC 4033, 4034 and 4035) signs DNS answers so resolvers can prove they came from the zone's owner unaltered. It is a chain of trust: the zone signs its records with keys published as DNSKEY records, and the parent zone (such as .com) publishes a DS record, a hash of your key, sent there by your registrar.
The tool reads the DS records from the parent zone's servers and the DNSKEY records from the zone's own nameservers, using our own resolver, and checks that a DS key tag matches one of the zone's keys. Whether the chain actually validates comes from Google's validating resolver: the tool asks it for the SOA record and reads the AD flag. If that lookup gives SERVFAIL, it asks again with validation off: answering only then is the mark of a broken ("bogus") setup. It also flags outdated algorithms and digest types.
What it can't see:
- Individual signatures. It relies on Google's verdict for the SOA record and does not verify each RRSIG, expiry date or NSEC/NSEC3 record itself.
- Names below the zone. A host such as
www.example.comhas no DS or DNSKEY of its own. If its answers validate, the tool names the signed zone it belongs to; enter the zone (example.com) to see its keys and algorithms. - Other resolvers. The validation verdict comes from Google only; caches can differ for a while after a key change.
Reading the results
The main finding is one of these:
| Finding | Meaning |
|---|---|
| Signed and validating | DS at the parent, keys in the zone, and the resolver validated the answer. The chain of trust is intact. |
| DNSSEC is not enabled | No DS and no DNSKEY. The domain resolves normally, just without DNSSEC protection. |
| DNSKEYs but no DS record | The zone is signed, but the parent doesn't point to it, so nobody validates it. |
| A DS record exists but answers are not validated | The parent has a DS, but the answer didn't come back validated. Check the DS matches a key in the zone. |
| DNSSEC validation fails | Bogus. The zone only answers with validation switched off. Everyone behind a validating resolver gets SERVFAIL. |
DS records at the parent zone lists each DS with its key tag, algorithm and digest type. Keys in the zone (DNSKEY) lists each key's flags and algorithm: flags 257 is shown as a KSK (key-signing key, the one the DS points to), 256 as a ZSK (zone-signing key).
Extra warnings appear for deprecated algorithms (RSAMD5, DSA, RSASHA1, RSASHA1-NSEC3-SHA1, DSA-NSEC3-SHA1, ECC-GOST; see RFC 8624) and for DS records that only use a SHA-1 digest.
Common problems and fixes
DNSSEC validation fails (bogus)
This is urgent: the domain is unreachable for most of the internet. It usually follows a move of DNS hosts, when the old DS stays at the registrar but the new host signs with different keys, or not at all. Either update the DS at your registrar to match the key your DNS host shows, or remove the DS to switch DNSSEC off. When moving hosts, remove the DS first, wait for its TTL to pass, move, then re-enable DNSSEC.
Signed but no DS at the parent
The zone has keys, but signing protects nobody until the parent points to them. Copy the DS record your DNS host shows into your registrar's DNSSEC settings. It looks like this:
example.com. 3600 IN DS 12345 13 2 <SHA-256 digest from your DNS host>
The four fields are key tag, algorithm (13 is ECDSAP256SHA256), digest type (2 is SHA-256) and the digest.
Deprecated algorithm
RSASHA1 (5) and RSASHA1-NSEC3-SHA1 (7) are still common on older setups. Roll over to ECDSAP256SHA256 (13) or ED25519 (15) using your DNS host's rollover process, so validation never breaks.
DS digest uses SHA-1 only
Publish a SHA-256 (digest type 2) DS record for the same key at your registrar, then remove the SHA-1 one.
See raw records with DNS lookup, and whether a SERVFAIL shows worldwide with the DNS propagation check.
FAQ
What does DNSSEC bogus mean?
The zone is signed and the parent has a DS, but validation fails, usually because the DS doesn't match the current key. Validating resolvers answer SERVFAIL, so the domain is unreachable for their users. Unsigned is safer than bogus.
Do I need DNSSEC?
It is not required for a website or mail to work. It protects against forged answers and cache poisoning, and DANE depends on it. Many DNS hosts enable it with one click; you then add the DS at your registrar.
What is the difference between a KSK and a ZSK?
The key-signing key (flags 257) signs the zone's set of DNSKEY records, and the DS at the parent is a hash of it. The zone-signing key (flags 256) signs everything else. Some setups use a single key for both roles.
Why does my domain show DNSKEYs but no DS?
The zone was signed at your DNS host but the DS was never added at the registrar. Until it is, resolvers treat the zone as unsigned.
How do I turn off DNSSEC safely?
Remove the DS at the registrar first and keep the zone signed until the DS TTL has passed (often a day or two). Only then stop signing. The other order makes the domain bogus meanwhile.