What is the difference between DS and DNSKEY?

The DNSKEY record holds the zone's public key and lives in the zone itself. The DS record is a fingerprint of that key and lives at the parent (e.g. at the top-level domain); it establishes the connection to the chain of trust.

What do KSK and ZSK mean?

Key Signing Key (KSK) signs the DNSKEY RRset and is anchored via the DS record at the parent. Zone Signing Key (ZSK) signs the zone's other records and typically rotates more often. Recognizable by the SEP flag in the DNSKEY record (set = KSK).

Why does the tool show 'not confirmed' instead of green even though DS and DNSKEY match?

The DNS resolver in use returns no AD flag, so it does not validate the chain itself (or is tampered with along the way). The recomputed DS digest is still a reliable, resolver-independent statement that the records match structurally, but it does not replace an actual signature check.

Why does my subdomain show 'not set up' even though the domain uses DNSSEC?

DS records only exist at actual delegation points, in practice almost always the registrable domain, not every subdomain individually. The tool automatically also checks the registrable domain when the entered subdomain has no DNSSEC records of its own.

How do I set up DNSSEC for my domain?

Your DNS provider usually handles this at the push of a button (sign the zone, publish DNSKEY and RRSIG). Afterwards, put the shown DS record at the domain's registrar so the parent marks the delegation as secure. The exact steps differ by provider.

What does DNSSEC have to do with email?

It is used directly by DANE (TLSA records for SMTP, see DANE Check): a TLSA record without DNSSEC could be removed or replaced unnoticed in transit. SPF, DKIM and DMARC themselves do not require DNSSEC, but generally benefit from the protection against forged DNS responses.

DNSSEC Check

Check a domain's DNSSEC chain of trust: DS, DNSKEY, RRSIG, algorithms.

DNSSEC cryptographically signs DNS responses, preventing them from being tampered with unnoticed in transit, for example through cache poisoning or a man-in-the-middle on the network path. The chain of trust starts at the root zone and runs through every delegation: the parent publishes a DS record pointing at the child zone's DNSKEY, and every signed RRset carries an accompanying RRSIG. For email, DNSSEC is the foundation for DANE (see DANE Check): without an intact chain a TLSA record is ineffective, because it could otherwise be removed or replaced unnoticed.

What this tool checks

It fetches the domain's DS record (answered at the delegation by the parent), the zone's own DNSKEY RRset, and the accompanying RRSIG. For each key it shows the algorithm (RSASHA256, ECDSAP256SHA256, ED25519 and others), the actual key length, and the role Key Signing Key or Zone Signing Key (via the SEP flag). For each DS record it evaluates the digest type (SHA-256 good, SHA-1 obsolete). Independent of the resolver, it also recomputes the DS digest from the existing DNSKEY and compares it (RFC 4034 section 5.1.4): that is a plain checksum, not a signature check, but a resolver-independent statement of fact about whether DS and DNSKEY actually match at all. It also evaluates the AD flag of the response, i.e. whether the resolver in use marks the chain as validated itself. If the upstream returns no AD (old resolvers, DNS interception on the local network), the tool reports that openly instead of wrongly claiming security. If the entered domain itself has no DNSSEC records of its own, the tool additionally checks the registrable domain, because DNSSEC is almost always set up there, not on every subdomain individually.

Reading the result

Green means: DS and DNSKEY are present, the computed digest matches the DS record, the RRSIG is valid, and, if the resolver in use can confirm it, the AD flag is set. No DS and no DNSKEY is not an error but the note that DNSSEC is not set up for this domain. It is an error, however, if only one side of the chain exists (DS without DNSKEY or vice versa) or if the recomputed digest does not match the DS record: in both cases validating resolvers reject the zone entirely (bogus), making the domain unreachable for them. This tool does not perform an actual signature check itself (whether the RRSIG actually matches the private key); that remains the job of the validating resolver.

Background

DNSSEC is defined in RFC 4033 through 4035, the DS digest calculation in RFC 4034 section 5.1.4, modern elliptic-curve algorithms in RFC 6605 (ECDSA) and RFC 8080 (EdDSA). The AD flag (Authenticated Data) of a DNS response is described in RFC 4035 section 3.2.3 and RFC 6840 section 5.7: it indicates that the queried recursive resolver validated the response itself via DNSSEC. An end-user resolver without DNSSEC support never returns this flag, regardless of whether the domain is actually signed.

Common problems and how to fix them

DS at the parent, but no DNSKEY in the zone. Usually an aborted migration or a DS record set too early. The zone must be signed first (publish DNSKEY and RRSIG) before the DS record is put at the registrar, otherwise the domain becomes completely unreachable for validating resolvers.
DNSKEY present, but no DS at the parent. The zone signs itself, but nobody trusts it because the chain does not continue from the parent. Put the matching DS record at the registrar or DNS provider.
DS digest does not match the DNSKEY. Usually after a key rollover where the old DS record was not replaced with the new one in time. Publish the current DS record for the new KSK.
RRSIG expired or expiring soon. Usually an issue with automatic re-signing at the DNS provider. Without intervention the zone becomes invalid for validating resolvers once it expires.
SHA-1 as the DS digest type. Considered obsolete. Switch to SHA-256 (digest type 2) at the next key rollover.

Common questions

What is the difference between DS and DNSKEY?: The DNSKEY record holds the zone's public key and lives in the zone itself. The DS record is a fingerprint of that key and lives at the parent (e.g. at the top-level domain); it establishes the connection to the chain of trust.
What do KSK and ZSK mean?: Key Signing Key (KSK) signs the DNSKEY RRset and is anchored via the DS record at the parent. Zone Signing Key (ZSK) signs the zone's other records and typically rotates more often. Recognizable by the SEP flag in the DNSKEY record (set = KSK).
Why does the tool show 'not confirmed' instead of green even though DS and DNSKEY match?: The DNS resolver in use returns no AD flag, so it does not validate the chain itself (or is tampered with along the way). The recomputed DS digest is still a reliable, resolver-independent statement that the records match structurally, but it does not replace an actual signature check.
Why does my subdomain show 'not set up' even though the domain uses DNSSEC?: DS records only exist at actual delegation points, in practice almost always the registrable domain, not every subdomain individually. The tool automatically also checks the registrable domain when the entered subdomain has no DNSSEC records of its own.
How do I set up DNSSEC for my domain?: Your DNS provider usually handles this at the push of a button (sign the zone, publish DNSKEY and RRSIG). Afterwards, put the shown DS record at the domain's registrar so the parent marks the delegation as secure. The exact steps differ by provider.
What does DNSSEC have to do with email?: It is used directly by DANE (TLSA records for SMTP, see DANE Check): a TLSA record without DNSSEC could be removed or replaced unnoticed in transit. SPF, DKIM and DMARC themselves do not require DNSSEC, but generally benefit from the protection against forged DNS responses.