DNSSEC Key Rollover: Rotating KSK and ZSK Without Breaking Validation

DNSSEC signs your zone so resolvers can prove the answers they get are genuine. Those signatures rely on cryptographic keys, and keys must be rotated: to limit exposure if one is ever compromised, to move to stronger algorithms, and simply as good hygiene. The catch is that a rollover done carelessly causes a validation outage. Resolvers that trusted your old key will return SERVFAIL, which looks to users exactly like the domain has vanished. This guide covers the two key roles, the standard rollover methods from RFC 6781, the DS timing with your parent zone, and the TTL math that keeps validation unbroken.

Two keys with two jobs

Most DNSSEC zones use a split-key setup. The Zone Signing Key (ZSK) signs the actual records in your zone, producing the RRSIG records resolvers check. The Key Signing Key (KSK) signs only the DNSKEY record set, which is the published bundle of your keys. The KSK is the one your parent zone vouches for through a DS (Delegation Signer) record.

This split exists so you can rotate the busy ZSK often and entirely on your own, without ever contacting the registrar or parent zone. The KSK changes rarely and its rollover does require updating the DS record upstream, which is slower and involves another party, so you keep it small and infrequent.

Rolling the ZSK: the pre-publish method

The recommended way to rotate a ZSK is the pre-publish method. You introduce the new key into the DNSKEY set well before you start signing with it, so by the time any record carries the new signature, every resolver already has the new key cached and can validate. The old signatures stay valid throughout, so nothing ever fails.

# 1. Generate the new ZSK and add it to the DNSKEY RRset
#    Both ZSKs are now published; still signing with the OLD key.
dnssec-keygen -a ECDSAP256SHA256 example.com

# 2. Wait at least the DNSKEY RRset TTL so every resolver
#    has the new key cached before it is used.

# 3. Re-sign the zone using the NEW ZSK.
#    RRSIGs now come from the new key; resolvers already trust it.

# 4. Wait the maximum RRSIG / record TTL so old signatures expire
#    from caches, then remove the old ZSK from the DNSKEY RRset.

The key discipline is the two waits. You never start using a key that resolvers have not yet cached, and you never remove a key while signatures it made might still be cached. Skip either wait and some resolver, somewhere, holds a signature it cannot match to a key, which is a validation failure.

Rolling the KSK: double-signature and the DS handoff

The KSK is trickier because the parent zone points at it through a DS record, and you do not control the parent directly. The common approach is the double-signature method, sometimes called double-KSK: you publish the new KSK alongside the old, sign the DNSKEY set with both, get the new DS record accepted at the parent, wait for the old DS to age out of caches, and only then retire the old key.

# 1. Add the new KSK; sign the DNSKEY RRset with BOTH KSKs.
# 2. Submit the NEW DS record to the parent (registrar/registry).
#    The parent now lists both the old and the new DS.
# 3. Wait the parent's DS TTL so resolvers see the new DS.
# 4. Remove the OLD DS at the parent.
# 5. Wait the DS TTL again, then drop the old KSK from DNSKEY.

An alternative is the double-DS method, where you publish the new DS first, wait, then swap the key. Either way, the rule that protects you is the same: the chain of trust from parent DS to your DNSKEY to your signatures must never have a gap. At every moment there must be at least one DS at the parent whose key is present and signing in your zone.

The TTL math that prevents a SERVFAIL outage

Every wait in a rollover exists to outlast a cache. A resolver may hold your DNSKEY set, your signatures, and your parent's DS record for as long as each one's TTL. If you remove something while a cached copy still references it, a validating resolver sees a broken chain and answers SERVFAIL.

• Before using a new key: wait at least the DNSKEY RRset TTL, so the key is cached everywhere first.
• Before removing an old key: wait at least the longest TTL of any record it signed, so no cached signature outlives its key.
• Before removing an old DS: wait at least the parent's DS TTL, so no resolver still expects the old chain.

A practical safety margin adds the propagation time of your authoritative servers to each TTL rather than cutting it exactly. Lowering the relevant TTLs a day or two before the rollover shrinks every wait and makes the whole operation faster to complete and faster to recover if something looks wrong.

Verifying the rollover at each step

Check your work as you go rather than at the end. List the published keys, confirm the DS at the parent matches a key you are publishing, and validate the whole chain.

# See the published keys
$ dig DNSKEY example.com +short

# See the DS records the parent is serving
$ dig DS example.com +short

# Validate the full chain from the root down
$ dig +dnssec +cd example.com
$ delv example.com         # reports "fully validated" when the chain is intact

If delv reports the zone as fully validated after each transition, the chain held. If any resolver starts returning SERVFAIL, stop and confirm that every DS at the parent corresponds to a KSK still signing your DNSKEY set, which is almost always where a broken rollover goes wrong.

Confirm the whole chain resolves everywhere

A rollover is only safe once the new keys and DS record have propagated to resolvers around the world and the old ones have aged out. Run your domain through the Valla DNS propagation checker to confirm the DNSKEY and DS records appear consistently across regions, and pair it with our guides on DNSSEC basics and DNS TTL strategy so every TTL and every signature lines up before you retire the old key.