Rolling the ZSK is local: nothing outside the zone refers to it, so no registrar is involved and no parent has to be updated. There are two ways to do it and they trade zone size against key-set size.
Pre-publish
1. Add the new ZSK to the DNSKEY RRset. Do not sign with it. Wait: the DNSKEY RRset TTL. 2. Switch signing to the new key. One signature per RRset, throughout. Wait: the longest TTL in the zone. 3. Remove the old ZSK from the DNSKEY RRset.
At step 2, a resolver may hold an RRset signed by the old key and a DNSKEY set containing both. Validation succeeds because the old key is still published. The zone never carries two signatures per RRset, so it stays small.
Double-signature
1. Add the new ZSK and sign every RRset with BOTH keys. Wait: the longest TTL in the zone. 2. Stop signing with the old key. Wait again. 3. Remove the old ZSK.
Every RRset carries two signatures for the duration. Validation is unambiguous at every moment, and the zone roughly doubles in size while it lasts.
Which
| Pre-publish | Double-signature | |
|---|---|---|
| Zone size during the roll | Unchanged | Nearly doubled |
| DNSKEY RRset size | Two keys, briefly | Two keys, briefly |
| Response size for a normal query | Unchanged | Larger — two RRSIGs per answer |
| Suits | Large zones, and the usual default | Small zones, or where signing is cheap and clarity matters |
Pre-publish is the standard choice and what most signers do automatically. Double-signature is easier to reason about, which makes it a reasonable pick for a zone small enough that the size does not matter.
With a CSK there is no ZSK roll
A combined signing key does both jobs, so every rotation is a KSK rotation with a DS update at the parent. That is the operational cost of the simpler key arrangement, and it is the reason large operators with frequent rotations still separate the two.