What is the difference between a KSK and a ZSK?

Both are DNSKEY records. The Key Signing Key (KSK) signs only the DNSKEY record set and is the key the parent's DS record points to. The Zone Signing Key (ZSK) signs all other record sets in the zone. Splitting roles lets you roll the ZSK frequently without re-coordinating with the parent.

How does the chain of trust work?

Each zone publishes DNSKEY records and an RRSIG over every record set. The parent zone publishes a DS record that is a hash of the child's KSK. A validating resolver walks down from the trust anchor at the root, checking each DS matches the child's DNSKEY and each RRSIG verifies, establishing an unbroken chain.

Why are there two records for denial of existence?

NSEC and NSEC3 both prove that a name or record type does not exist, in a signed way. NSEC lists the next name in canonical order, which allows zone walking (enumerating all names). NSEC3 hashes the names to prevent easy enumeration and adds an opt-out option for large delegation-heavy zones.

What are CDS and CDNSKEY for?

CDS (Child DS) and CDNSKEY (Child DNSKEY) are published by the child zone to signal the DS record it wants the parent to publish. They automate DS updates during key rollovers (RFC 7344/8078), so the parent can pick them up without a manual out-of-band exchange.

What does NSEC3PARAM do?

NSEC3PARAM appears at the zone apex and stores the hash algorithm, flags, iteration count and salt used to generate the zone's NSEC3 records. Authoritative servers use it when synthesising NSEC3 responses so every NSEC3 record in the zone uses consistent parameters.

DNSSEC Record Types Reference

Email me this result

Get this tool's output sent to your inbox, plus one useful tool a week. No spam, unsubscribe any time.

Securing DNS with DNSSEC records

DNSSEC adds cryptographic signatures to DNS so resolvers can verify that answers are authentic and unmodified. It does this with a small family of resource record types that hold keys, signatures and authenticated denial-of-existence proofs. This reference explains each record’s role in signing a zone and in the chain of trust.

How it works

A signed zone publishes its public keys as DNSKEY records and a signature (RRSIG) over every record set. The parent zone vouches for the child by publishing a DS record — a hash of the child’s Key Signing Key:

example.com.   DNSKEY  257 3 13 ( ... )   ; KSK — signs the DNSKEY set
example.com.   DNSKEY  256 3 13 ( ... )   ; ZSK — signs everything else
example.com.   RRSIG   A 13 2 3600 ( ... ); signature over the A RRset
com.           DS      12345 13 2 ( hash ); parent points at child KSK

A validating resolver starts at the root trust anchor and walks down: each DS must match the child’s DNSKEY, and each RRSIG must verify against the corresponding key. For names that do not exist, NSEC or NSEC3 provides a signed proof of non-existence.

Tips and notes

Roll the ZSK often; roll the KSK rarely (it requires a parent DS update).
NSEC3 prevents zone walking; NSEC is simpler but enumerable.
CDS/CDNSKEY let the child automate DS updates during rollovers.
A broken signature or missing DS yields SERVFAIL from validating resolvers.