For a DNSSEC zone-signing key, how do pre-publish and double-signature rollovers differ, and when would you choose each?
answer
- two orderings, one safety goal
- key first, or signatures doubled
- response size against speed
- Ipub = Dprp + TTLkey
basics
~20 sPre-publish adds the new ZSK unused, waits out the DNSKEY TTL, switches signing, and removes the old key after its signatures expire. Double-signature signs everything with both keys at once, then drops the old one. Pre-publish keeps responses small; double-signature is simpler.
solid answer
~40 sBoth keep every cached signature matched to a cached key. **Pre-publish** adds the new zone-signing key to the `DNSKEY` RRset without using it, waits `Dprp + TTLkey` so every cached key set holds it, switches all signing to it, then keeps the old key for `Dsgn + Dprp + TTLsig` until the old signatures have left caches, and removes it. **Double-signature** adds the new key and immediately signs every RRset with both keys; after `Dsgn + Dprp + max(TTLkey, TTLsig)` the old key and its signatures go. RFC 7583 calls double-signature the conceptually simplest and fastest, but it doubles every `RRSIG` and so inflates zone and response size. Pre-publish keeps sizes minimal and leaves a published, unused key ready for an emergency, which is why RFC 7583 calls it the generally preferred ZSK method.
go deeper
Recall the two names and the one-line difference: pre-publish puts the new key out first and signs later; double-signature signs with both keys at once.
Walk through each method's steps and waits using propagation delay, the DNSKEY TTL and the signature TTL, and explain why every combination of cached data still validates.
Pick a method from the zone's facts, such as size, response budget, automation and the need for a standby key, and compute the real waits from its TTLs instead of quoting two TTLs.
Weigh operational simplicity against response size and emergency readiness across many zones, and set TTL and rollover-cadence policy so automation never has to cut a wait short.
## What both methods protect A **zone-signing key (ZSK)** signs the zone's ordinary RRsets; its public half sits in the zone's `DNSKEY` RRset. Validating resolvers cache the `DNSKEY` RRset and each `RRSIG` signature independently, so during a rollover any mix of old and new key sets and old and new signatures can meet in one cache. A ZSK rollover method is a schedule that keeps every such mix verifiable. Because the parent zone does not reference the ZSK, both methods are entirely under the zone operator's control (RFC 6781, Section 4.1.1). RFC 7583 defines the quantities the waits are built from: - `Dprp`, the **propagation delay**: time for a change to reach every authoritative server; - `TTLkey`, the TTL of the `DNSKEY` RRset; - `TTLsig`, the largest TTL of any signature made with the retiring key (an `RRSIG` carries the TTL of the RRset it covers); - `Dsgn`, the time needed to re-sign every RRset with the new key. ## Pre-publish, step by step 1. **Publish.** Add the new ZSK to the `DNSKEY` RRset, which the key-signing key re-signs. Nothing is signed with the new key yet. 2. **Wait `Ipub = Dprp + TTLkey`.** After this, every cached `DNSKEY` RRset holds both keys. 3. **Switch.** Replace the signatures with ones made by the new key. Whichever key made the signature a resolver sees, its cached key set holds that key. 4. **Wait `Iret = Dsgn + Dprp + TTLsig`.** The old signatures drain out of caches. 5. **Remove** the old key and re-sign the `DNSKEY` RRset. ## Double-signature, step by step 1. **Publish and sign.** Add the new ZSK and sign every RRset with both keys, keeping the old signatures. 2. **Wait `Iret = Dsgn + Dprp + max(TTLkey, TTLsig)`.** Any mix of old or new key set with old or new signatures contains at least one verifiable pair; the wait lets both old key sets and old signatures expire. 3. **Remove** the old key and every signature it made. ## Side by side | | Pre-publish | Double-signature | |---|---|---| | Zone changes | three: publish, switch, remove | two: publish and sign, remove | | Signatures per RRset during the roll | one | two | | Zone and response size | minimal | larger, every `RRSIG` doubled | | Waits | `Ipub`, then `Iret` | one `Iret` | | Spare key for emergencies | natural: the published, unused key | not practical | | RFC 7583's view | generally preferred for ZSKs | simplest and fastest | RFC 6781 notes that doubling the signatures "may be prohibitive if you have very big zones", while pre-publish exposes the new public key earlier than it is needed. ## Worked numbers for one zone Take `example.net` with a one-day `DNSKEY` TTL, ordinary records whose TTLs are at most one hour, one hour to reach every secondary, and one hour to re-sign the zone. - **Pre-publish:** `Ipub = 1 h + 24 h = 25 h` before switching. After the switch, `Iret = 1 h + 1 h + 1 h = 3 h` before removal. About 28 hours end to end. - **Double-signature:** `Iret = 1 h + 1 h + max(24 h, 1 h) = 26 h` before removal, with two signatures on every RRset for that whole time. The one-day key TTL dominates both. The short data TTLs make pre-publish's second wait small; the familiar summary "pre-publish takes about two TTLs" holds only when the data and key TTLs are similar. ## Choosing, and the emergency case - Choose **pre-publish** when response size matters (large keys, a tight UDP response budget, a big zone) and when you want a **standby key**. RFC 7583 (Section 4) says a standby ZSK only really makes sense with pre-publish: a key already in every cache can start signing at once after a compromise. - Choose **double-signature** for small zones and for automation that prefers fewer state changes. - A third variant, **double-RRSIG** (new signatures first, the key later), carries the costs of both and RFC 7583 does not consider it further. Neither method ever touches the parent's `DS` record; that is what separates a ZSK rollover from a key-signing key rollover.
- A DNSSEC zone-signing key is suspected compromised mid-life; why does the pre-publish method shorten the response?With pre-publish the successor key is already in every cached `DNSKEY` RRset, so the zone can switch signing to it at once instead of first waiting a DNSKEY TTL. The compromised key still cannot vanish immediately: RFC 6781 warns that removing it at once breaks signatures still in caches, so you weigh a short exposure window against bogus answers.
- Why does the double-signature retire wait use the larger of the DNSKEY TTL and the signature TTL?Both kinds of stale copy matter. A resolver may hold an old `DNSKEY` RRset without the new key, which needs the old signatures to stay, or old signatures, which need the old key to stay. Removal is safe only once both kinds have expired, so the wait covers whichever TTL is longer.
saying these in an interview costs you the question
- Double-signature means signing each RRset twice with the same key for redundancy.
- A zone-signing key rollover needs a new DS record at the parent.
- With pre-publish you can sign with the new key as soon as it is published.
- Double-signature is preferred because it keeps DNSSEC responses smaller.