DNSSEC Key Rollovers (ZSK and KSK)

ZSK, KSK and the chain of trust

Most signed zones use two kinds of key. The key-signing key, or KSK, signs only the DNSKEY record set. The zone-signing key, or ZSK, signs everything else. The parent zone publishes a DS record containing a hash of the KSK, which links your zone into the chain that runs up to the root. A combined signing key, or CSK, does both jobs in one key and is common with modern elliptic-curve algorithms.

The split exists so that the key you change most often, the ZSK, never requires a change at the parent. Only a KSK rollover touches the DS record, and that is the step that needs coordination with your registrar or registry.

$ dig +short DNSKEY example.com
257 3 13 EiMPGdn052xY3MrYdQKBK4Lieclg8lbwK3/qsVXBEAByrq3FHDmd1fMLSQNsyAfLp4hYUAywzFRIIg68HN2DJA==
256 3 13 HObHih1ug+ea2I1F3eVWjFb/ziLnOgt7p5dml7y133C4JtCJEn3iNjPDkF9QygyM6+PA6dUnMmb2VLAX8AKH3w==

$ dig +short DS example.com @a.gtld-servers.net
12345 13 2 8E7C2BA8A5F995FEB4EA11EBCACD32AA4B0FA107073EBE20F47974004FDFF622

In the DS output, 12345 is the key tag of the KSK, 13 is the algorithm (ECDSA P-256 with SHA-256), and 2 is the digest type (SHA-256). During a KSK rollover you check that a DS matches a key with flags 257 in the DNSKEY set. A matching key tag is only a first hint: tags are short and can collide, so the algorithm must match too, the digest must be the hash of that exact key, and the key must actually sign the DNSKEY set with a signature that is currently valid.

Why and when to roll keys

Keys are rolled for four practical reasons. A key may be compromised or suspected of compromise. You may be changing algorithm, for example from RSA to ECDSA. You may be moving the zone to a new DNS operator that signs with its own keys. Or your policy may call for periodic replacement so that the process stays exercised. RFC 6781 discusses the trade-offs and does not mandate a fixed lifetime.

In practice, many signing platforms roll the ZSK automatically and leave the KSK alone for long periods. That is a reasonable choice as long as a KSK rollover has been rehearsed. The worst time to discover your registrar's DS update process is during an emergency.

Rolling a ZSK

The two standard methods are pre-publish and double-signature. Pre-publish keeps responses small and is the most common choice.

Double-signature adds the new key and signs every record set with both keys at once, waits, then removes the old key and its signatures. It needs only one waiting period, but every signed response is larger while both signatures exist, which matters for zones already close to UDP size limits.

Rolling a KSK

A KSK rollover has to account for the DS record at the parent, whose TTL is set by the parent zone, not by you. RFC 6781 describes two main methods.

• Double-KSK. Add the new KSK to the DNSKEY set and sign the set with both KSKs. Wait for the DNSKEY TTL. Replace the old DS at the parent with the new one. Wait for the parent's DS TTL. Remove the old KSK.
• Double-DS. Add a DS for the new KSK at the parent alongside the old one. Wait for the DS TTL. Swap the old KSK for the new one in the DNSKEY set. Wait for the DNSKEY TTL. Remove the old DS.

Double-KSK is the usual choice because it keeps the parent interaction to a single swap. Either way, the rule is not that every DS must match a key. A DS set may briefly hold a DS for a key that is not published yet, or one that has just been retired, and that is exactly how Double-DS works. What must hold is that for every combination of DS set and DNSKEY set a resolver could have cached, at least one DS points to a published key, with a supported algorithm and digest, that signs the DNSKEY set with a valid signature. RFC 4035, section 5.2, describes how a resolver checks that link. Breaking it produces the classic "DS present but no matching key" failure covered in Debugging DNSSEC validation errors.

The DNS root itself has done this. The root KSK was rolled on October 11, 2018, and validating resolvers learned the new trust anchor through the automated update mechanism in RFC 5011 or through software updates.

Automating DS updates with CDS and CDNSKEY

RFC 7344 lets the child zone publish the DS it wants as a CDS record, or the key it wants as a CDNSKEY record. A parent that supports the mechanism polls for these records, validates them with the existing chain of trust, and updates the DS set to match. RFC 8078 extends this with guidance on initial enablement and a special value that asks the parent to remove the DS records entirely, which is how a zone can go insecure in a controlled way.

$ dig +short CDS example.com
54321 13 2 4B9D2F8E1C3A5B7D9E0F1A2B3C4D5E6F708192A3B4C5D6E7F8091A2B3C4D5E6F

Support is uneven. Some registries and registrars scan for CDS and CDNSKEY automatically, others accept them only through a registrar workflow, and many still require a manual DS update. Check with yours before you rely on it. Signers such as BIND and Knot DNS can publish CDS and CDNSKEY records as part of an automated key policy.

Algorithm rollovers and operator changes

Changing algorithm is stricter than changing a key. A zone has to carry signatures from every algorithm that appears in its DNSKEY set, so the conservative order is to add signatures made with the new algorithm across the whole zone first, then add the new keys, then change the DS, and remove the old algorithm in the reverse order. RFC 6781 walks through this sequence.

Moving a signed zone between DNS operators is a special case, because each operator usually signs with its own keys. RFC 8901 describes multi-signer models for this. In one, the operators share a common KSK and each imports the other's ZSK into the DNSKEY set. In the other, each operator keeps its own KSK, both KSKs get a DS at the parent, and the ZSKs are cross-published. Some operators also support importing your existing keys, or exporting theirs, so the new operator can keep signing with the same keys through the handover. Going insecure briefly, by removing the DS, moving and re-signing, is the fallback when neither side supports any of these. Plan this together with the steps in Moving DNS Providers Without Downtime, and remember that TTL behavior, explained in DNS TTLs and Caching Explained, drives every wait.

Monitoring a rollover with DNS Panopticon

At each phase, check what the world sees, not what your signer reports. delv validates an answer the way a resolver would, and dig with +dnssec shows which key tags signed the DNSKEY set.

$ delv example.com A
; fully validated
example.com.		300	IN	A	192.0.2.10
example.com.		300	IN	RRSIG	A 13 2 300 20261029000000 20261015000000 40001 example.com. ...

Domain Visualizer asks public resolvers over DNS over HTTPS for the domain's DS and DNSKEY records and checks whether the resolver set the AD (Authenticated Data) flag. It reports DNSSEC as absent, valid, DS without DNSKEY, DNSKEY without DS, or not confirmed. That is a quick before-and-after record for each phase, but it does not inspect individual key tags, signature validity windows or cached DS sets at other resolvers, so use delv or DNSViz for those. If you manage the zone from an export, Zone Analyzer lets you filter on DNSKEY and CDS rows to confirm what the file contains before you load it.