skip to content

A DNSSEC zone has a one-day DNSKEY TTL and its parent serves the DS with a two-day TTL; how long must each wait in a double-DS key-signing key rollover last?

level: seniorimportance: should knowfreq 12%

answer

  1. two caches, two TTLs
  2. DS first, then the key
  3. IpubP = DprpP + TTLds
  4. Iret = DprpC + TTLkey

basics

~20 s

After the new DS appears at the parent, wait the parent's propagation delay plus two days before swapping the key-signing key; after the swap, wait the child's propagation delay plus one day before removing the old DS. The parent's registration delay comes on top.

solid answer

~40 s

Double-DS has two waits, each set by a different cache. Once the new `DS` appears in the parent zone, wait `IpubP = DprpP + TTLds`; with one hour of parent propagation that is 49 hours, after which every cached `DS` RRset holds both digests. Then swap the KSK in the `DNSKEY` RRset and wait `Iret = DprpC + TTLkey`, 25 hours with one hour of child propagation, until no cache holds the old key set; only then ask the parent to remove the old DS. Before all of it comes the registration delay, the time the parent takes to publish what you submit. If that is six hours, the safe minimum is 80 hours, the same total as double-KSK, while double-RRset overlaps the waits and needs about 55.

go deeper

for a junior

Recall that each wait is a propagation delay plus the TTL of the record that changed: the DS TTL for the parent's record, the DNSKEY TTL for the child's.

for a middle

Compute the two double-DS waits from the symbols, parent propagation plus DS TTL and then child propagation plus DNSKEY TTL, and say what a resolver holds if you cut each one short.

for a senior

Count from the DS actually appearing, budget the parent's registration delay, compare double-KSK and double-RRset on the same numbers, and know which TTLs are not yours to change.

for a principal

Set rollover cadence knowing that KSK rolls take days and depend on the parent, and decide whether the faster double-RRset is worth two parent interactions per roll across many zones.

## The inputs RFC 7583 names every quantity in a rollover timeline. For this zone: | Symbol | Meaning | Value used here | |---|---|---| | `TTLkey` | TTL of the child's `DNSKEY` RRset | 24 h | | `TTLds` | TTL the parent gives the `DS` RRset | 48 h | | `DprpC` | time for a child-zone change to reach all its authoritative servers | 1 h, assumed | | `DprpP` | the same for the parent zone | 1 h, assumed | | `Dreg` | registration delay: from submitting a DS to its appearing in the parent zone | 6 h, assumed | The zone is `example.net`, and its key-signing key (KSK) is matched by a `DS` record in its parent. The propagation and registration values are assumptions for the arithmetic; measure your own. RFC 7583 notes that `Dreg` is not a fixed time in practice: its end is signalled by the DS appearing in the parent zone. ## Double-DS, phase by phase 1. **Submit** the new DS at t = 0. It appears in the parent at t = `Dreg` = 6 h. 2. **Wait `IpubP = DprpP + TTLds` = 1 + 48 = 49 h.** Until then, a resolver may still hold the old `DS` RRset without the new digest. The earliest safe swap is 6 + 49 = **55 h**. 3. **Swap the KSK** in the `DNSKEY` RRset and sign the RRset with the new key. Every cached `DS` RRset now holds both digests, so either key set validates. 4. **Wait `Iret = DprpC + TTLkey` = 1 + 24 = 25 h.** Until then, a resolver may still hold the old key set, which only the old DS matches. The earliest safe removal of the old DS is 55 + 25 = **80 h**. 5. **Submit the removal.** Its own registration delay only postpones clean-up; it does not affect safety. ## The same zone with double-KSK 1. Publish the new KSK and sign the `DNSKEY` RRset with both keys. Wait `IpubC = DprpC + TTLkey` = 25 h. 2. Submit the DS replacement at 25 h; it appears 6 h later, at 31 h. 3. Wait `Iret = DprpP + TTLds` = 49 h, then remove the old KSK at 31 + 49 = **80 h**. The same total with a different shape: one parent interaction, and a larger key set for the whole roll. ## Double-RRset Publish the new KSK and submit the new DS together. RFC 7583 gives the wait as `Ipub = max(Dreg + IpubP, IpubC)` = max(6 + 49, 25) = **55 h**: the child's 25-hour wait passes while the parent is still publishing the DS and its TTL runs. | Method | Earliest safe completion | Parent interactions | |---|---|---| | Double-DS | 80 h | 2 | | Double-KSK | 80 h | 1 | | Double-RRset | 55 h | 2 | ## What breaks if a wait is cut short - **Swapping the KSK before `IpubP` ends:** a resolver holding the old `DS` RRset, with only the old digest, fetches the new `DNSKEY` RRset, with only the new KSK. No DS matches any key, and the zone is bogus for that resolver until its cached DS RRset expires, up to two more days. - **Removing the old DS before `Iret` ends:** a resolver holding the old `DNSKEY` RRset fetches a `DS` RRset that no longer matches it. Bogus again, this time until its cached key set expires. - A mistake costs **at least as long as the TTL you skipped**, because the repair has to travel through the same caches. ## What you cannot shorten - `TTLds` is the **parent's** choice. You can ask for a different value; you cannot set it. - Lowering `TTLkey` helps only after the old, longer TTL has itself expired from caches. RFC 7583 assumes constant TTLs and warns that changing them near a rollover changes the timings. - If some resolvers hold your KSK as a configured trust anchor, RFC 5011 imposes an add hold-down of at least 30 days, and RFC 7583 stretches the publication wait to cover it. - `Dreg` is organisational, not technical. Count `IpubP` from the moment the new DS **appears in the parent zone**, never from the moment you submitted it or from the deadline the parent promised.

  • Why does a double-RRset DNSSEC rollover finish sooner than double-DS for this zone?
    Its two waits run in parallel. The new key and the new DS are introduced together, so the 25-hour DNSKEY wait passes while the parent is still publishing the DS and the 48-hour DS TTL runs. RFC 7583 takes the larger of the two paths, 6 + 49 = 55 hours here, instead of their sum.
  • The parent promises to publish your new DS within 24 hours; when does the 49-hour DS wait start?
    When the new DS actually appears in the parent zone, not at submission and not at the promised deadline. RFC 7583 treats the end of the registration delay as signalled by the DS appearing, and the propagation term covers its spread to every parent server. Query the parent's servers for the record and start counting from there.

saying these in an interview costs you the question

  • Every DNSSEC rollover wait is one DNSKEY TTL, whichever record changed.
  • The double-DS wait starts when you submit the DS to the parent.
  • The child zone can shorten the DS TTL to speed up a rollover.
  • Cutting a rollover wait short causes errors for only a few minutes.