How DNSSEC Works — KSK, ZSK, DS, DNSKEY, RRSIG, NSEC Explained

DNSSEC authenticates DNS data through a hierarchy of cryptographic signatures that chain from a record in your zone all the way back to a trust anchor hard-coded in every validating resolver. This guide walks through the moving parts — DNSKEY, DS, RRSIG, NSEC/NSEC3, and the KSK/ZSK roles — at a level that lets you reason about real-world deployments without being a cryptographer.

For the operational rollover procedures (pre-publish ZSK, double-signature KSK, algorithm rollover), continue to DNSSEC Key Management. For the high-level introduction without the mechanics, the What is DNSSEC? page is a better starting point.

The Records Involved

DNSSEC introduces four record types into a signed zone, plus DS records published at the parent:

Signing Keys: KSK, ZSK, CSK

DNSSEC has historically used a two-key split: a KSK for high-value, low-frequency operations and a ZSK for high-frequency, lower-ceremony operations. The motivation is purely operational — cryptographically, both keys do the same thing (sign data with a private key, verify with a public key).

Zone-Signing Key (ZSK)

The ZSK signs everything in your zone except the DNSKEY record set. When a resolver asks for the A records of example.com, the answer comes back with a corresponding RRSIG record signed by the ZSK. Every signed record set has its own RRSIG.

ZSKs are typically:

• Smaller (1024-bit RSA was common in early deployments; ECDSA P-256 / 256-bit keys are the modern norm)
• Rotated relatively often (every 1–3 months historically; some operators now skip scheduled rotations with strong key storage)
• Easier to rotate because the parent zone's DS record doesn't need to change

Key-Signing Key (KSK)

The KSK signs only the DNSKEY record set. That set contains the public part of every active signing key in the zone. By signing the DNSKEY set with the KSK, you bind every other key in the zone (specifically, every active ZSK) to a key whose hash is published at the parent.

KSKs are typically:

• Larger (2048-bit RSA, ECDSA P-256, or Ed25519 are all common)
• Rotated rarely (once every 1–5 years, or only on suspected compromise)
• More expensive to rotate because the DS record at the parent must be updated, which involves the registrar and TLD timing

Combined Signing Key (CSK)

A CSK plays both roles in a single key. The same key signs DNSKEY (KSK role) and other record sets (ZSK role). Modern deployments increasingly use CSK with ECDSA P-256 or Ed25519, because:

• Signatures are small enough that the per-query cost is negligible
• Operational complexity is lower (one key to manage, one rollover to coordinate)
• HSM-backed key storage reduces the security argument for separating KSK and ZSK

DNScale defaults to CSK with ECDSA P-256 for new zones, which is the standard for most modern managed providers.

DNSKEY: Publishing Public Keys in the Zone

Every active signing key has its public part published as a DNSKEY record at the zone apex:

example.com.   3600   IN   DNSKEY   257 3 13 oJMR...                        ; KSK
example.com.   3600   IN   DNSKEY   256 3 13 mZXp...                        ; ZSK

Decoding the fields:

• Flags (257 or 256): bit 7 (SEP — Secure Entry Point) is set on the KSK, giving 257. The ZSK has 256. Both formats also share bit 8 (Zone Key) which is always set in DNSKEY.
• Protocol (3): always 3 in valid DNSSEC.
• Algorithm (13 here): 13 = ECDSA P-256, 8 = RSA SHA-256, 15 = Ed25519. See IANA DNSSEC algorithms for the full list.
• Public key (base64-encoded): the actual key material.

A validating resolver fetches the DNSKEY set when validating any record from your zone, and uses the appropriate key (KSK for the DNSKEY RRSIG itself, ZSK for everything else).

RRSIG: The Signatures

Every signed record set in your zone is accompanied by one or more RRSIG records — one per active signing key for that role. An RRSIG looks like this:

example.com.   3600   IN   A      192.0.2.1
example.com.   3600   IN   RRSIG  A 13 2 3600 20260601000000 20260501000000 12345 example.com. 4kQp...

The RRSIG fields:

• Type covered (A): the type of record set being signed.
• Algorithm (13): must match the DNSKEY algorithm.
• Labels (2): the number of labels in the original signed name.
• Original TTL (3600): the TTL the record set had when it was signed.
• Signature expiration (20260601000000) and inception (20260501000000): UTC timestamps. The signature is only valid in this window.
• Key tag (12345): a short identifier for which DNSKEY in the zone produced this signature. Matches the key tag of the corresponding DNSKEY record.
• Signer name (example.com.): the zone whose key signed this.
• Signature (base64-encoded): the actual cryptographic signature.

Signature expiration windows are why DNSSEC is operationally non-trivial. If your authoritative server stops re-signing the zone — even briefly — signatures will start expiring, validating resolvers will start returning SERVFAIL, and your domain effectively goes dark. Managed DNS providers re-sign automatically; self-hosted DNSSEC requires a working signer pipeline.

DS Records: The Link to the Parent

The DS (Delegation Signer) record is the hinge that connects your zone into the global chain of trust. It lives in the parent zone (.com, .eu, .de, etc.) and contains a hash of your KSK. You don't add it to your own zone — you publish it at your registrar, who passes it to the TLD registry.

A DS record looks like this in the parent zone:

example.com.   86400   IN   DS   12345 13 2 7c89...

Fields:

• Key tag (12345): identifier for which KSK this DS hashes (matches the DNSKEY key tag).
• Algorithm (13): must match the DNSKEY algorithm.
• Digest type (2): SHA-256 (2) or SHA-384 (4) — SHA-1 (1) is deprecated.
• Digest (hex-encoded): the actual hash.

When a validating resolver wants to authenticate your zone, it fetches the DS record from the parent (e.g., from the .com nameservers), then fetches your DNSKEY set, computes the hash of the matching KSK, and checks that it equals the digest in the DS. If they match, the resolver trusts your zone's DNSKEY set, and by extension the RRSIGs signed with those keys.

This is the only automated link from outside your zone into your zone's keying material. Get the DS wrong and DNSSEC validation fails — or worse, your domain becomes unresolvable for validating clients.

NSEC and NSEC3: Authenticated Denial of Existence

A subtle but important problem: DNSSEC can't just sign the records that exist. It also needs to prove, when a resolver asks for nonexistent.example.com, that the name really doesn't exist rather than the answer being silently dropped or forged.

The mechanism is NSEC (RFC 4034) or NSEC3 (RFC 5155).

NSEC

NSEC records are sorted alphabetically and chain through the names that exist in the zone. For example:

alpha.example.com.    NSEC  gamma.example.com.   A NSEC RRSIG
gamma.example.com.    NSEC  zulu.example.com.    A NSEC RRSIG
zulu.example.com.     NSEC  alpha.example.com.   A NSEC RRSIG     ; wraps to start

A resolver asking for beta.example.com gets back the signed NSEC for alpha.example.com, which proves there's nothing between alpha and gamma — therefore beta doesn't exist. The signature on the NSEC record authenticates the negative answer.

The drawback: NSEC records publicly enumerate every name in the zone. Anyone walking the NSEC chain can build a complete list of every record name. This is "zone walking" and is sometimes considered a privacy leak.

NSEC3

NSEC3 records the same chain but uses hashed names instead of plain ones, plus an iteration count and salt:

< hash of alpha >.example.com.    NSEC3 1 0 10 abcd123...    < hash of gamma > A RRSIG NSEC3

Resolvers can verify denial of existence as before (compute the hash of the queried name, find which NSEC3 record covers it), but an attacker can't trivially walk the zone — they have to crack each hash. NSEC3 also supports opt-out, which lets registries skip signing unsigned delegations to avoid having to NSEC3-sign every nonexistent subzone.

Modern recommendation: NSEC3 with iterations=0 and a fixed salt (or no salt). High iteration counts add CPU cost without meaningful privacy benefit because attackers with GPUs can crack any non-zero count. The "white lies" approach (RFC 4470) is another way to reduce zone-walking risk while keeping NSEC's simplicity.

The Validation Flow — Step by Step

What actually happens when a validating resolver receives a DNSSEC-signed answer? Walking through dig +dnssec example.com @1.1.1.1:

1. Resolver receives the A record + RRSIG from your authoritative server.
2. Resolver fetches your zone's DNSKEY set + RRSIG. Now it has both the data and the keys (in public form) needed to verify everything.
3. Resolver verifies the data RRSIG against the ZSK in the DNSKEY set. If the signature is invalid, validation fails immediately.
4. Resolver verifies the DNSKEY RRSIG against the KSK in the DNSKEY set. The KSK has signed the DNSKEY record set, including the ZSK. This step locks the ZSK to the KSK.
5. Resolver fetches the DS record from the parent zone (e.g., from the .com nameservers). The DS contains a hash of the KSK.
6. Resolver computes the hash of the KSK and compares it to the DS. If they match, the parent has confirmed which KSK is authoritative for your zone.
7. Resolver repeats the chain at the parent. The DS record itself is signed by the parent zone's ZSK; the parent's DNSKEY set is signed by the parent's KSK; the parent's KSK is hashed in the grandparent zone's DS, and so on, up to the root.
8. At the root, the resolver compares the root KSK hash to the trust anchor it has hard-coded (or auto-updated via RFC 5011). The current root KSK is published at https://data.iana.org/root-anchors/.

If every signature verifies and the root chains back to the trust anchor, the resolver returns the answer with the AD (Authenticated Data) flag set. Any failure along the way and the resolver returns SERVFAIL — better to break than to serve a potentially-tampered answer.

What Can Go Wrong

The first two — stale DS and expired signatures — cause the vast majority of real-world DNSSEC outages. Managed providers handle re-signing automatically; the DS record at the registrar is the human-touchable failure point.

Putting It Together — A Mental Model

DNSSEC's apparent complexity is mostly bookkeeping. The actual cryptographic question is simple: did this answer come from someone who controls the zone's private key? The chain of trust is a series of public-key bindings, each one a normal "key A signs key B" or "key A signs data D" step:

• The root KSK signs the root DNSKEY set (which includes the root ZSK).
• The root ZSK signs the DS records of TLDs.
• A TLD's KSK signs the TLD's DNSKEY set (which includes the TLD's ZSK).
• The TLD's ZSK signs the DS records of registered zones.
• Your zone's KSK signs your DNSKEY set (which includes your ZSK).
• Your ZSK signs every record set in your zone — including the NSEC/NSEC3 records that handle denial of existence.

Every link is just a signature; the magic is that the resolver only needs the root key to verify them all.

References

• RFC 4033 — DNS Security Introduction and Requirements
• RFC 4034 — Resource Records for the DNS Security Extensions (DNSKEY, DS, NSEC, RRSIG)
• RFC 4035 — Protocol Modifications for the DNS Security Extensions
• RFC 5155 — DNSSEC Hashed Authenticated Denial of Existence (NSEC3)
• RFC 6781 — DNSSEC Operational Practices, Version 2
• RFC 7344 / 8078 — Automating DNSSEC Delegation Trust Maintenance (CDS / CDNSKEY)
• RFC 8624 — Algorithm Implementation Requirements and Usage Guidance for DNSSEC
• RFC 8901 — Multi-Signer DNSSEC Models
• IANA DNSSEC Algorithm Numbers
• IANA Root Trust Anchors

Related Reading

• What is DNSSEC? — top-of-funnel introduction
• DNSSEC Key Management — operational rollover procedures
• DNSSEC Setup Guide for DNScale — product walkthrough
• DNSSEC vs DNS over HTTPS — integrity vs privacy
• DNS Cache Poisoning — the attack DNSSEC defeats
• NIS2 and DNS Compliance — DNSSEC as a regulatory control