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.

What is the DNSSEC Record Types Reference?

Reference for DNSSEC resource record types — RRSIG, DNSKEY, DS, NSEC, NSEC3, NSEC3PARAM, CDS and CDNSKEY — with each record's purpose in zone signing and chain-of-trust validation. It runs free in your browser on Gera Tools, with nothing uploaded.

DNSSEC Record Types Reference

Name: DNSSEC Record Types Reference
Creator: Gera Tools
License: https://creativecommons.org/licenses/by/4.0/

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.

The record types explained

DNSKEY holds a zone’s public key. The flags field distinguishes two roles: flag value 257 marks a Key Signing Key (KSK), which signs only the DNSKEY record set and is the key the parent’s DS points to; flag value 256 marks a Zone Signing Key (ZSK), which signs all other record sets. Splitting the roles means you can roll the ZSK frequently without re-coordinating with the parent registry.

RRSIG is a signature over one record set (RRset) — for example, all A records at the same name. It names the signing key’s key tag, the algorithm, the original TTL, and validity dates. A resolver verifies the signature against the matching DNSKEY before trusting the RRset.

DS (Delegation Signer) lives in the parent zone and contains a hash of the child’s KSK. The com. zone holds a DS pointing to example.com.’s KSK; . (root) holds a DS for com. The chain of DS records forms the trust path from the root trust anchor down to any signed zone.

NSEC (Next Secure) proves a name does not exist by listing the next name in canonical order and the record types that do exist at the current name. A resolver seeing no A record for ghost.example.com can be shown a signed NSEC from foo.example.com. to zoo.example.com. proving nothing between them exists. The downside is zone walking: an adversary can enumerate all names by following NSEC chains.

NSEC3 replaces the plaintext names with hashed values, preventing zone walking while still providing authenticated denial. An NSEC3PARAM record at the zone apex records the hash algorithm, iteration count, and salt so that all NSEC3 records in the zone use consistent parameters.

CDS and CDNSKEY allow the child zone to signal a desired DS update to the parent without out-of-band communication. Defined in RFC 7344 and RFC 8078, they let domain registrars and DNS hosting providers automate key rollovers by reading these child-published records.

Common operational problems

Symptom	Likely cause
SERVFAIL from resolvers	Expired RRSIG — signatures have a validity period
DS mismatch	KSK was rolled without updating DS at the parent
Legitimate queries failing	NSEC3 or NSEC chain broken after adding a new name
Zone walking concerns	Using NSEC instead of NSEC3 on a zone you want private

Key operational rules: roll the ZSK often; roll the KSK rarely (every 1–2 years, because it requires a parent DS update); monitor RRSIG expiry dates and automate re-signing.