skip to content

Why does rolling a DNSSEC key-signing key involve the parent zone, and how do the double-KSK and double-DS methods order their steps?

level: middleimportance: should knowfreq 22%

answer

  1. trust enters through the parent
  2. the DS points down at the KSK
  3. key first, or DS first
  4. parent interactions against key-set size

basics

~20 s

The parent's DS record points at the key-signing key, so a new KSK is trusted only once a matching DS is published and cached. Double-KSK adds the new key first, then swaps the DS; double-DS adds the new DS first, then swaps the key.

solid answer

~50 s

Validators trust a zone's `DNSKEY` RRset because a `DS` record in the **parent** matches one of its keys, normally the key-signing key (KSK). Replacing the KSK therefore changes what the parent publishes, on the parent's schedule and under the parent's DS TTL. **Double-KSK** adds the new KSK and signs the `DNSKEY` RRset with both keys, waits for old key sets to leave caches, has the parent replace the old DS with the new one, waits the DS TTL, then removes the old KSK: one parent interaction, a larger key set. **Double-DS** has the parent add the new DS first, waits the DS TTL, swaps the KSK in the zone, waits the DNSKEY TTL, then has the parent remove the old DS: two interactions, a minimal key set. **Double-RRset** does both at once and is the fastest.

go deeper

for a junior

Recall that the parent's DS record points at the key-signing key, so changing that key means the parent has to publish a new DS.

for a middle

Lay out double-KSK and double-DS step by step, naming which TTL each wait covers and how many times you must deal with the parent.

for a senior

Choose a method from how the parent behaves, slow or manual DS changes and whether it checks the DS against your published key, and explain why algorithm rollovers need their own order.

for a principal

Treat parent interactions as the scarce resource across a portfolio of zones, and favour methods and automation that minimise them without ever leaving a DS pointing at nothing.

## Where a key-signing key's trust comes from A zone's **key-signing key (KSK)** signs the zone's `DNSKEY` RRset. A validator trusts that RRset because the **parent zone** publishes a `DS` record, a digest of the KSK, signed by the parent's own keys. The chain runs parent `DNSKEY` to `DS` to child `DNSKEY` (RFC 7344, Section 2.1). A second source of trust exists: a resolver may have the KSK configured directly as a **trust anchor**, and then RFC 5011 timing applies. That changes the problem compared with a zone-signing key rollover (RFC 7583, Section 2.2): - the KSK's signature travels together with the `DNSKEY` RRset, so a signature-without-key mismatch inside the zone is not the issue; - the issue is that every cached `DS` RRset must match some key in every cached `DNSKEY` RRset; - the `DS` lives in a zone you do not run, with a TTL you do not set, and changes after a **registration delay** you do not control. RFC 7583 adds that a slow parent only slows the rollover down; it does not break it, provided you wait for the DS to actually appear. ## Double-KSK RFC 6781 calls this the Double-Signature KSK rollover. 1. Add the new KSK to the `DNSKEY` RRset and sign the RRset with both KSKs. 2. Wait the child propagation delay plus the DNSKEY TTL, so every cached key set holds the new KSK. 3. Submit the new DS; the parent replaces the old DS with it. 4. Once the new DS appears, wait the parent propagation delay plus the DS TTL, so no cache still holds the old `DS` RRset. 5. Remove the old KSK. ## Double-DS 1. Submit the new DS; the parent publishes it **alongside** the old one. 2. Once it appears, wait the parent propagation delay plus the DS TTL, so every cached `DS` RRset holds both digests. 3. Replace the old KSK with the new one in the `DNSKEY` RRset and sign it with the new KSK. 4. Wait the child propagation delay plus the DNSKEY TTL, so old key sets leave caches. 5. Ask the parent to remove the old DS. Until step 3, the new DS points at a key that is not yet published. RFC 6781 (Section 4.3.3) calls a DS pointing at a nonexistent key **security lameness**: harmless while another DS still matches, fatal if all of them dangle. It also means the parent cannot check the new DS against a published key when it receives it. ## Double-RRset Add the new KSK (signing the key set with both) and submit the new DS at the same moment, wait until both old RRsets have expired from caches, then remove the old KSK and the old DS. The waits run in parallel, and RFC 7583's summary calls it the most efficient KSK method; it carries the costs of both others. | | Double-KSK | Double-DS | Double-RRset | |---|---|---|---| | First move | new KSK in the zone | new DS at the parent | both together | | Parent interactions | one: replace | two: add, then remove | two | | `DNSKEY` RRset size | larger during the roll | minimal | larger | | Parent can check the new DS against a published key | yes | no, the key is not out yet | yes, both appear together | | Waits | in sequence | in sequence | in parallel, fastest | ## Algorithm rollovers break the pattern RFC 4035 (Section 2.2) requires every RRset to carry a signature from each algorithm in the apex `DNSKEY` RRset, and the `DNSKEY` RRset to be signed by each algorithm that appears in the parent's `DS` RRset. Changing algorithm, say from RSASHA256 (8) to ECDSAP256SHA256 (13), therefore needs a strict order; RFC 6781 (Section 4.1.4) gives it for validators that read the rule strictly: 1. add signatures made with the new algorithm everywhere, and wait for caches to turn over; 2. add the new-algorithm keys; 3. swap the DS at the parent; 4. remove the old keys, and only then the old signatures. Double-DS cannot be used here: it would publish a DS for an algorithm the child's `DNSKEY` RRset is not yet signed with. ## Trust anchors If some resolvers hold your KSK as a configured trust anchor, RFC 5011 makes them wait an add hold-down of at least 30 days before accepting a new key and expects the old key to be published with its REVOKE bit before it disappears. RFC 7583 (Section 3.3.4) folds both into the waits, turning a KSK roll of days into one of weeks.

  • Why can the double-DS method not be used for a DNSSEC algorithm rollover?
    RFC 4035 requires the apex `DNSKEY` RRset to be signed by every algorithm that appears in the parent's `DS` RRset. Double-DS publishes the new DS first, so for a while the parent would list an algorithm the child's key set is not yet signed with. Validators applying the rule strictly would treat the zone as bogus, so RFC 6781 adds new-algorithm signatures and keys first and changes the DS last.
  • What changes if some resolvers have your DNSSEC key-signing key configured as a trust anchor?
    Those resolvers follow RFC 5011 rather than the DS: they accept a new key only after seeing it for an add hold-down of at least 30 days, and they drop the old one when it is published with the REVOKE bit set. RFC 7583 extends the publication wait to cover the hold-down and adds a revoke interval before removal, so the roll takes weeks rather than days.

saying these in an interview costs you the question

  • A key-signing key rollover can be finished entirely inside the child zone.
  • In a double-DS rollover the old DS can go as soon as the new key is in the zone.
  • Double-KSK needs two submissions to the parent, double-DS only one.
  • The child zone sets the DS TTL, so it can shorten it before a rollover.
  • An algorithm change can be done like any double-DS rollover.