RFC 7583
DNSSEC Key Rollover Timing Considerations
RFC 7583: DNSSEC Key Rollover Timing Considerations 🔐
- Authors: S. Morris (ISC), J. Ihren (Netnod), J. Dickinson (Sinodun), W. Mekking (Dyn)
- Category: Informational (not Internet Standards Track, just published for info 📚)
- Date: October 2015
- ISSN: 2070-1721
- Obsoletes / Updates: the title block doesn't list anything here, so nothing is marked as obsoleted or updated 🙈
Abstract ✨
okay so this doc is all about the timing stuff when you roll a key in a DNSSEC-secured zone 🔑 it lays out timelines for the key rollover and spells out how all the different parameters that affect the process are connected. it's giving "read this before you touch anything" energy 💅
Status of This Memo 🎀
ngl this part is the official-paperwork bit, but it matters so here we go 💜
This document is not an Internet Standards Track specification; it is published for informational purposes.
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7583.
Copyright Notice 🌈
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. please review these documents carefully, bestie, because they spell out your rights and restrictions for this document 🫶 Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
Table of Contents 🧚
1. Introduction ....................................................3
1.1. Key Rolling Considerations .................................3
1.2. Types of Keys ..............................................4
1.3. Terminology ................................................4
1.4. Limitation of Scope ........................................5
2. Rollover Methods ................................................5
2.1. ZSK Rollovers ..............................................5
2.2. KSK Rollovers ..............................................7
3. Key Rollover Timelines ..........................................8
3.1. Key States .................................................8
3.2. ZSK Rollover Timelines ....................................10
3.2.1. Pre-Publication Method .............................10
3.2.2. Double-Signature Method ............................12
3.3. KSK Rollover Timelines ....................................14
3.3.1. Double-KSK Method ..................................14
3.3.2. Double-DS Method ...................................17
3.3.3. Double-RRset Method ................................20
3.3.4. Interaction with Configured Trust Anchors ..........22
3.3.5. Introduction of First Keys .........................24
4. Standby Keys ...................................................24
5. Algorithm Considerations .......................................25
6. Summary ........................................................26
7. Security Considerations ........................................26
8. Normative References ...........................................26
Appendix A. List of Symbols ......................................28
Acknowledgements ..................................................31
Authors' Addresses ................................................311. Introduction 🦋
1.1. Key Rolling Considerations 🔥
okay so when a zone is secured with DNSSEC, the zone manager has to be ready to swap out ("roll") the keys used in signing 🔄 the rolling might happen because one or more of the existing keys got compromised, or because a management policy wants periodic key replacement for security or operational reasons. to actually do a key rollover, the keys need to be introduced into and removed from the zone at the right moments. things that must be taken into account are:
DNSKEYrecords and their associated info (like theDSrecords orRRSIGrecords made with the key) aren't just sitting at the authoritative nameserver, they're also cached by resolvers 🗃️ the data on these systems can be interlinked, e.g., a validating resolver may try to validate a signature retrieved from a cache with a key obtained separately.- zone "bootstrapping" events, where a zone gets signed for the very first time, can be super common in setups serving a large number of zones 🌱 procedures should be able to cope with introducing keys into the zone for the first time as well as "steady-state", where the records are being replaced as part of normal zone maintenance.
- to allow for an emergency re-signing of the zone as soon as possible after a key compromise has been detected, standby keys (additional keys over and above those used to sign the zone) need to be present 🚨
- a query for the
DNSKEYRRset returns allDNSKEYrecords in the zone 📦 since there's limited space in the UDP packet (even with EDNS0 support), key records that are no longer needed must be periodically removed. (For the same reason, the number of standby keys in the zone should be restricted to the minimum required to support the key management policy.)
management policy, like how long a key is used for, also needs to be considered 🕰️ however, the whole point of key management logic isn't to make sure a rollover finishes at a certain time. it's to make sure no changes are made to the state of keys published in the zone until it's "safe" to do so ("safe" here means that at no time during the rollover process does any part of the zone ever go bogus 🙅♀️). in other words, although key management logic enforces policy, it may not enforce it strictly. 💅
a high-level overview of key rollover can be found in [RFC6781]. this document is different: it focuses on the low-level timing detail of two classes of operations described there, the rollover of Zone Signing Keys (ZSKs), and the rollover of Key Signing Keys (KSKs) 🎯
note that introducing keys into a zone is a different process from rolling a key. see Section 3.3.5 for more information 👀
1.2. Types of Keys 🌸
ok so DNSSEC validation treats all keys equally, but [RFC4033] recognizes the broad classification of ZSKs and KSKs 🫧 a ZSK is used to authenticate information within the zone, and a KSK is used to authenticate the zone's DNSKEY RRset. the main implication of this distinction is about keeping information consistent during a rollover ✨
during operation, a validating resolver has to use separate pieces of information to do an authentication. at the time of authentication, each piece might be in its cache or might need to be retrieved from an authoritative server 🧩 the rollover process needs to happen in such a way that the information stays consistent at all times during the rollover. with a ZSK, the information is the RRSIG (plus associated RRset) and the DNSKEY, and both are obtained from the same zone. with a KSK, the information is the DNSKEY and DS RRset, with the latter obtained from a different zone 😳
yes there are similarities in the algorithms to roll ZSKs and KSKs, but there are also a number of differences 💖 for this reason, the two types of rollovers are described separately.
1.3. Terminology 📖
the terminology used in this document is as defined in [RFC4033] and [RFC5011].
a number of symbols are used to identify times, intervals, etc. they're all listed in Appendix A 🧁
1.4. Limitation of Scope 🙈
this document represents current thinking at the time of publication 🕰️ however, the subject matter is evolving and it's not possible for the document to be comprehensive. in particular, it does not cover:
- rolling a key that is used as both a ZSK and KSK.
- algorithm rollovers. only the rolling of keys of the same algorithm is described here: not transitions between algorithms.
- changing TTLs.
algorithm rollover is excluded because there needs to be an RRSIG for at least one DNSKEY of each algorithm in the DNSKEY RRset [RFC4035]. that adds extra constraints on rollovers that aren't considered here 🧐 those considerations don't apply where other properties of the key, like key length, change during the rollover, because the DNSSEC protocol doesn't impose any restrictions in those cases.
also excluded is the effect of changing the Time to Live (TTL) of records in a zone 💜 TTLs can be changed at any time, but doing so around the time of a key rollover may have an impact on event timings. in the timelines below, it's assumed that TTLs are constant. ⏱️
2. Rollover Methods 👑
part 1 ends right here bestie, more is coming 🫶🎀
2.1. ZSK Rollovers ✨
Okay bestie, for ZSKs the big question for the zone operator/signer is making sure that any caching validator holding a particular signature also has access to the matching valid ZSK 🔑💖
There are three ways to roll a ZSK 🦋
- Pre-Publication: described in [RFC6781]. The new key gets added to the DNSKEY RRset, and then the RRset gets re-signed 🌸 That state has to hang around long enough for every cached DNSKEY RRset to contain both keys. Once that's true, signatures made with the old key can be swapped out for ones made with the new key. During the re-signing (which may or may not be atomic, depending on how the zone is managed), it literally doesn't matter which key made the RRSIG a resolver grabbed, because the cached DNSKEY RRsets will have both the old and new keys 💅
Once the zone only has signatures from the new key, there's a stretch of time where the RRSIG records made with the old key expire from caches. After that, no signatures anywhere were made with the old key, so it can be removed from the DNSKEY RRset 🧚
- Double-Signature: also mentioned in [RFC6781]. This one adds the new key to the zone and uses it to create extra RRSIG records, while the old key and the existing RRSIG records stay put 🎀 While the zone is being signed (again, the signing might not be atomic), validating resolvers can always validate RRSIGs. Basically, any mix of old and new DNSKEY RRset and RRSIGs lets at least one signature get validated 🫶
After signing is done and enough time has passed that every validator holding the DNSKEY and signatures in cache has both the old and new info, the old key and signatures can be removed from the zone. Same deal as before: any combo of DNSKEY RRset and RRSIGs still lets at least one signature be validated during this period ✨
- Double-RRSIG: okay, so the term "Double-Signature" above is kinda a misnomer 🙈 That method is double signature, but it's also double key! The true Double-Signature method (called Double-RRSIG here) adds new signatures to the zone while keeping the old ones, but it does not introduce the new key 🍓
Once signing is finished and enough time has passed for every cache that might hold an RR and its associated RRSIG to have both signatures, the key gets changed. After a further interval where the old DNSKEY RRset expires from caches, the old signatures are removed from the zone 🌈
Of the three, Double-Signature is conceptually the simplest 💜 You introduce the new key and new signatures, then roughly one TTL later you remove the old key and old signatures. It's also the fastest, but the downside is that it increases the size of the zone and the size of responses 📈
Pre-Publication is more complicated: introduce the new key, roughly one TTL later sign the records, and then roughly one TTL after that remove the old key. The upside? It keeps the zone and response sizes to a minimum 🌸
Double-RRSIG is basically the reverse of Pre-Publication: introduce the new signatures, roughly one TTL later change the key, and roughly one TTL after that remove the old signatures. Here's the tea, though 🫖 It has the Pre-Publication disadvantage in terms of how long the rollover takes, and the Double-Signature disadvantage in terms of zone and response sizes, and it gets none of the advantages of either one 💀 For these reasons it's unlikely to be used in any real-world situation, so this document won't consider it any further 😭
2.2. KSK Rollovers 👑
For KSKs, there should be no problem with a caching validator not having access to a signature made with a valid KSK 🫶 The KSK is only used for one signature (the one over the DNSKEY RRset), and the key and the signature travel together. So the real issue here is making sure the KSK is trusted 💖
Trust in the KSK comes from either a signed and validated DS record in the parent zone, or an explicitly configured trust anchor. If it's the DS record, the rollover algorithm will need to involve the parent zone in adding and removing DS records, so the timings aren't entirely in the zone manager's hands 🙃 If it's a trust anchor instead, [RFC5011] timings will be needed to roll the keys 🔐 (Even when authentication is via a DS record, the zone manager may choose to include [RFC5011] timings in the key rolling process, so they can handle the possibility that the key has also been explicitly configured as a trust anchor 🧚)
Here's something important ⭐ Needing to interact with the parent doesn't stop you from developing key rollover logic. The whole goal of the rollover logic is working out when a state change is "safe," and the only effect of depending on the parent is that you might have to wait for the parent to respond on top of whatever delay the rollover logic already needs. Sure, that adds delays, but even with a parent that isn't super responsive, the only result is a slowdown in the rollover state transitions. That might cause a policy violation, but it won't cause any operational problems 🌸
Like the ZSK case, there are three methods for rolling a KSK 🦋
- Double-KSK: the new KSK gets added to the DNSKEY RRset, which is then signed with both the old and new key. After waiting for the old RRset to expire from caches, the DS record in the parent zone is changed. After waiting a further interval for that change to show up in caches, the old key is removed from the RRset 🍓
- Double-DS: the new DS record is published. After waiting for that change to propagate into caches, the KSK is changed. After a further interval during which the old DNSKEY RRset expires from caches, the old DS record is removed 🌈
- Double-RRset: the new KSK is added to the DNSKEY RRset, which is then signed with both the old and new key, and the new DS record is added to the parent zone. After waiting a suitable interval for the old DS and DNSKEY RRsets to expire from caches, the old DNSKEY and DS records are removed 💅
Basically, Double-KSK means the new KSK is introduced first and used to sign the DNSKEY RRset. Then the DS record gets changed, and finally the old KSK is removed 🎀 It limits interactions with the parent to a minimum, but while the rollover is happening, the size of the DNSKEY RRset goes up 📈
With Double-DS, the order is flipped: introduce the new DS, change the DNSKEY, then remove the old DS 🧚 The DNSKEY RRset size stays at a minimum, but you need two interactions with the parent 🙈
And finally, Double-RRset is the fastest way to roll the KSK, but it has the drawbacks of both of the other methods: a larger DNSKEY RRset and two interactions with the parent 😭💅
3. Key Rollover Timelines ⏰
3.1. Key States 🔑
DNSSEC validation needs both the DNSKEY and the information created from it (called "associated data" in this section) 💖 When it comes to validating an RR, the data associated with the key is the corresponding RRSIG. When you need to validate a chain of trust, the associated data is the DS record 🫶
During the rolling process, keys move through different states 🦋 Here are the defined states:
- Generated: keys can be created right before first use, but some implementations may find it convenient to create a pool of keys in one operation and draw from it as needed. (Note: such a pre-generated pool must be secured against surreptitious use 🔒) In the timelines below, before the first event, the keys are considered created but not yet used. They're said to be in the "Generated" state ✨
- Published: a key enters the published state when either it or its associated data first appears in the appropriate zone 🌸
- Ready: the DNSKEY or its associated data has been published for long enough to guarantee that copies of the key(s) it's replacing (or associated data related to that key) have expired from caches 🧚
- Active: the data is starting to be used for validation 🔥 For a ZSK, that means the key is now being used to sign RRsets, and both the key and the RRSIGs it created appear in the zone. For a KSK, it means it's possible to use it to validate a DNSKEY RRset, because both the DNSKEY and DS records are present in their respective zones. Heads up though: once this state is entered, validating resolvers might not be able to use the data for validation in every case. The zone signing may not be finished, or the data might not have reached the resolver yet because of propagation delays and/or caching issues. If that's the case, the resolver has to rely on the predecessor data instead 🌈
- Retired: the data has stopped being used for validation 🌙 For a ZSK, that means the key is no longer used to sign RRsets. For a KSK, it means the successor DNSKEY and DS records are in place. In both cases, the key (and its associated data) can be removed as soon as it's safe to do so, i.e., when all validating resolvers are able to use the new key and associated data to validate the zone. Until that happens, though, the current key and associated data must remain in their respective zones 🫶
- Dead: the key and its associated data are still present in their respective zones, but there's no longer any information anywhere that requires their presence for validation. So they can be removed at any time 👻
- Removed: both the DNSKEY and its associated data have been removed from their respective zones 👋
- Revoked: the DNSKEY is published for a period with the "revoke" bit set. This is a way of telling validating resolvers that have it configured as a trust anchor (as used in [RFC5011]) that it's about to be removed from the zone 🚨 This state is used when [RFC5011] considerations are in effect (see Section 3.3.4) 💅
3.2. ZSK Rollover Timelines 🎀
The following sections describe rolling a ZSK 💜 They show the events in the lifetime of a key (called "key N") and cover its replacement by its successor (key N+1) ✨
3.2.1. Pre-Publication Method ✨
okay so in the pre-publication method, the new key gets added to the DNSKEY RRset first 📝 💖 Then you wait long enough for every cached copy of that RRset to include both keys. Only then do you sign the zone with the new key and remove the old signatures. Last step: once every signature made with the old key has expired from caches, the old key can go 👋 super organized, no notes 💅
This diagram shows the timeline of a Pre-Publication rollover 🦋 Time runs left to right, the vertical lines are events, and the important times and intervals are labelled.
|1| |2| |3| |4| |5| |6| |7| |8|
| | | | | | | |
Key N |<-Ipub->|<--->|<-------Lzsk------>|<-Iret->|<--->|
| | | | | | | |
Key N+1 | | | |<-Ipub->|<-->|<---Lzsk---- - -
| | | | | | | |
Key N Tpub Trdy Tact Tret Tdea Trem
Key N+1 Tpub Trdy Tact
---- Time ---->
Figure 1: Timeline for a Pre-Publication ZSK RolloverEvent 1: Key N's DNSKEY record gets put into the zone, meaning it's added to the DNSKEY RRset. That RRset then gets re-signed with the currently active KSKs. The moment this happens is the publication time (Tpub), and the key is now "published." Key N isn't signing anything yet, though 🙈
Event 2: before the key can actually be used, it has to stay published long enough to guarantee that any cached copy of the zone's DNSKEY RRset includes it. That wait is the publication interval (Ipub). For the second or later keys in the zone, it's:
Ipub = Dprp + TTLkeyDprp is the propagation delay, which is the time it takes for a change made at the master to copy out to all the nameservers. TTLkey is the TTL for the DNSKEY records in the zone. Put together, the sum is the longest time existing DNSKEY records could hang around in caches, no matter which nameserver they came from 🧚
(The case of introducing the first ZSK into the zone is discussed in Section 3.3.5.)
After a wait of Ipub, the key is "ready" and could be used to sign records. The moment that happens is key N's ready time (Trdy):
Trdy(N) = Tpub(N) + IpubEvent 3: at some later point, the key starts signing RRsets. That's the activation time (Tact), and from then on key N is "active" 👑
Tact(N) >= Trdy(N)Event 4: at some point you have to think about its successor, key N+1. Same as when the current active key went in, the successor needs to be published at least Ipub before it gets activated. The publication time of key N+1 depends on key N's activation time:
Tpub(N+1) <= Tact(N) + Lzsk - IpubLzsk is how long a ZSK gets used, which is the ZSK lifetime. Heads up: the diagrams show the actual key lifetime, which can be a little different from the intended lifetime the key management policy sets 🌸
Event 5: while key N is still active, its successor becomes ready. From that point on, key N+1 could be used to sign the zone 🔥
Event 6: once key N has been in use for a stretch equal to the ZSK lifetime, it's retired. That means it will never be used to generate new signatures again. Key N+1 gets activated and starts signing the zone. This is key N's retire time (Tret):
Tret(N) = Tact(N) + LzskIt's also the activation time of the successor key N+1. Also, operational considerations might make key N stay in use for a longer (or shorter) time than the key management policy's lifetime 🍓
Event 7: the retired key has to stay in the zone for as long as any RRSIG records made with it are still published in the zone or sitting in caches. (A validating resolver might still have an old RRSIG in its cache even after the old DNSKEY RRset has expired, when it's asked to hand both to a client. In that case, the DNSKEY RRset would have to be looked up again 💀) So once the key stops signing records, it should be kept in the zone for at least the retire interval (Iret):
Iret = Dsgn + Dprp + TTLsigDsgn is the delay needed to make sure all existing RRsets have been re-signed with the new key. Dprp is the propagation delay, needed to guarantee the updated zone info has reached all slave servers. TTLsig is the maximum TTL of all the RRSIG records in the zone that were created with the retiring key.
The moment all RRSIG records made with this key have expired from resolver caches is the dead time (Tdea):
Tdea(N) = Tret(N) + Iret...and at that point the key is "dead" 🦋
Event 8: any time after the key is dead, it can be removed from the zone's DNSKEY RRset. The RRset then has to be re-signed with the current KSK. This moment is the removal time (Trem):
Trem(N) >= Tdea(N)...and at that point the key is "removed" 🎀
3.2.2. Double-Signature Method
okay this one is giving "no time to wait around" energy 🫶 A new key gets introduced and starts signing the zone, but the old key and its signatures stick around. Once every cached DNSKEY and/or RRSIG has copies of the new DNSKEY and the RRSIGs made with it, the old DNSKEY and RRSIGs can be taken out of the zone 🌈
Here's the timeline for a Double-Signature rollover. It follows the same convention as Section 3.2.1.
|1| |2| |3| |4|
| | | |
Key N |<-------Lzsk----------->|<--->|
| | | |
| |<--Iret-->| |
| | | |
Key N+1 | |<----Lzsk------- - -
| | | |
Key N Tact Tdea Trem
Key N+1 Tact
---- Time ---->
Figure 2: Timeline for a Double-Signature ZSK RolloverEvent 1: key N gets added to the DNSKEY RRset and then starts signing the zone. Existing signatures in the zone are left alone and not removed. The key is published and active, and this is key N's activation time (Tact). From then on, key N is "active" ✨
Event 2: as the current key (key N) gets close to the end of its actual lifetime (Lzsk), the successor (key N+1) comes in. It's added to the zone and starts signing RRsets. Neither the current key nor the signatures made with it get removed, so the successor is active too 💜
Tact(N+1) = Tact(N) + Lzsk - IretEvent 3: before key N can be pulled from the zone, every RRset that needs signing has to have been signed by the successor (key N+1). Also, any old RRsets that don't include the new key or new RRSIGs have to have expired from caches. Note that the signatures don't get replaced: each RRset ends up signed by both the old and the new key 🧁
This takes Iret, the retire interval, which is given by:
Iret = Dsgn + Dprp + max(TTLkey, TTLsig)Same as before, Dsgn is the delay needed to make sure all existing RRsets have been signed with the new key, and Dprp is the propagation delay, needed to guarantee the updated zone info has reached all slave servers. The last term (the maximum of TTLkey and TTLsig) is how long to wait for key and signature data tied to key N to expire from caches. TTLkey is the TTL of the DNSKEY RRset, and TTLsig is the maximum TTL of all the RRSIG records in the zone created with the ZSK. These two can be different: the TTL of an RRSIG equals the TTL of the RRs in the matching RRset [RFC4034], but the DNSKEY RRset only needs to be signed with the KSK 🤓
At the end of this interval, key N is "dead." That happens at the dead time (Tdea), so:
Tdea(N) = Tact(N+1) + IretEvent 4: at some later time, key N and the signatures made with it can be removed from the zone. This is the removal time (Trem):
Trem(N) >= Tdea(N)3.3. KSK Rollover Timelines
the next bit covers rolling a KSK 🔑 This section walks through the events in the life of a key (called "key N") and how it gets replaced by its successor (key N+1). (The case of introducing the first KSK into the zone is discussed in Section 3.3.5.) 💅
3.3.1. Double-KSK Method ✨
okay so in this rollover 🦋, the new DNSKEY gets added to the zone first. Then we wait long enough that any cached DNSKEY RRsets have the new DNSKEY in them 💖. Only after that does the DS record in the parent zone get changed. Then, after another interval so the old DS record can expire from caches, the old DNSKEY gets removed from the zone 💅.
The timeline for a Double-KSK rollover looks like this, and the diagram follows the convention from Section 3.2.1 🌸
|1| |2| |3| |4|
| | | |
Key N |<-IpubC->|<--->|<-Dreg->|<-----Lksk--- - -
| | | |
Key N+1 | | | |
| | | |
Key N Tpub Trdy Tsbm Tact
Key N+1
---- Time ---->(continued ...)
|5| |6| |7| |8| |9| |10|
| | | | | |
Key N - - --------------Lksk------->|<-Iret->|<----->|
| | | | | |
Key N+1 |<-IpubC->|<--->|<-Dreg->|<--------Lksk----- - -
| | | | | |
Key N Tret Tdea Trem
Key N+1 Tpub Trdy Tsbm Tact
---- Time (cont.) ---->Figure 3: Timeline for a Double-KSK Rollover 🎀
Event 1: Key N is introduced into the zone, and it gets added to the DNSKEY RRset, which is then signed by all currently active KSKs. So at this point, the DNSKEY RRset is signed by both key N and its predecessor KSK. If other KSKs were active, it's signed by those too 🔥. This is the publication time of key N (Tpub), and after this, the key is said to be published.
Event 2: Before it can be used, the key has to be published for long enough to guarantee that any validating resolver with a copy of the DNSKEY RRset in its cache will have a copy of the RRset that includes this key. In other words, any old cached info about the DNSKEY RRset has to expire first ⏳.
The interval is the publication interval in the child zone (IpubC), and it's given by:
IpubC = DprpC + TTLkeyHere DprpC is the propagation delay for the child zone (the zone containing the KSK being rolled), and TTLkey is the TTL for the DNSKEY RRset. The time when this happens is key N's ready time, Trdy, given by:
Trdy(N) = Tpub(N) + IpubCEvent 3: At some later time, the DS record for the new KSK gets submitted to the parent zone for publication. This is the submission time, Tsbm:
Tsbm(N) >= Trdy(N)Event 4: The DS record gets published in the parent zone. This is the moment all the info for authentication (both the DNSKEY and the DS record) is available across the two zones. Like in the other rollover methods, this is called the activation time of key N (Tact) 👑:
Tact(N) = Tsbm(N) + DregHere Dreg is the registration delay, which is the time taken after the DS record has been submitted to the parent zone manager so it can be placed in the zone. (Parent zones are often managed by different entities, so this term covers the organizational overhead of transferring a record. In practice, Dreg won't be a fixed time. Instead, the end of Dreg is signaled by the DS record showing up in the parent zone 🫶.)
Event 5: While key N is active, you need to think about its successor (key N+1). At some point before the scheduled end of the KSK lifetime, the successor KSK gets published in the zone. (Same as before, this means the DNSKEY RRset is signed by all KSKs.) This is the publication time of the successor key N+1, given by:
Tpub(N+1) <= Tact(N) + Lksk - Dreg - IpubCHere Lksk is the actual lifetime of the KSK, and Dreg is the registration delay.
Event 6: After an interval IpubC, key N+1 becomes ready, meaning all caches that have a copy of the DNSKEY RRset have a copy of this key. This is the ready time of the successor key N+1 (Trdy) 🌈.
Event 7: At the submission time of the successor key N+1, Tsbm(N+1), the DS record for key N+1 gets submitted to the parent zone.
Event 8: The successor DS record gets published in the parent zone, and the current DS record is withdrawn. Key N is said to be retired, and the time this happens is Tret(N), given by:
Tret(N) = Tsbm(N+1) + DregEvent 9: Key N has to stay in the zone until any caches holding a copy of the DS RRset have a copy with the new DS record. This interval is the retire interval, given by:
Iret = DprpP + TTLdsHere DprpP is the propagation delay in the parent zone, and TTLds is the TTL of a DS record in the parent zone.
Since the key isn't used for anything anymore, it's said to be dead 💀. This point is the dead time (Tdea), given by:
Tdea(N) = Tret(N) + IretEvent 10: At some later time, key N gets removed from the zone's DNSKEY RRset (at the remove time Trem), and the key is now said to be removed 🧚.
Trem(N) >= Tdea(N)3.3.2. Double-DS Method 💜
In this rollover, the new DS record gets published in the parent zone first. Once any caches holding the DS RRset have a copy of the new record, the KSK in the zone is changed. Then, after another interval for the old DNSKEY RRset to expire from caches, the old DS record is removed from the parent 🍓.
The timeline for a Double-DS rollover is shown below, and the diagram follows the convention from Section 3.2.1 ✨
|1| |2| |3| |4| |5|
| | | | |
Key N |<-Dreg->|<-IpubP->|<-->|<-------Lksk---- - -
| | | | |
Key N+1 | | | | |<--Dreg-- - -
| | | | |
Key N Tsbm Tpub Trdy Tact
Key N+1 Tsbm
---- Time ---->(continued ...)
|6| |7| |8| |9| |10|
| | | | |
Key N - ----------Lksk--------->|<-Iret->|<---->|
| | | | |
Key N+1 - --Dreg-->|<-IpubP->|<-->|<---Lksk------- - -
| | | | |
Key N Tret Tdea Trem
Key N+1 Tpub Trdy Tact
---- Time ---->Figure 4: Timeline for a Double-DS KSK Rollover 🦋
Event 1: The DS RR gets submitted to the parent zone for publication. This is the submission time, Tsbm.
Event 2: After the registration delay, Dreg, the DS record gets published in the parent zone. This is the publication time (Tpub) of key N, given by:
Tpub(N) = Tsbm(N) + DregSame as before, in practice Dreg won't be a fixed time. Instead, the end of Dreg is signaled by the DS record appearing in the parent zone 🫶.
Event 3: At some later time, every cache with a copy of the DS RRset will have a copy of the DS record for key N. At this point, key N, if introduced into the DNSKEY RRset, could be used to validate the zone. For that reason, this time is known as the ready time, Trdy, given by:
Trdy(N) = Tpub(N) + IpubPIpubP is the publication interval of the DS record (in the parent zone), given by:
IpubP = DprpP + TTLdsHere DprpP is the propagation delay for the parent zone, and TTLds is the TTL assigned to DS records in that zone.
Event 4: At some later time, the key rollover happens, and the new key (key N) is introduced into the DNSKEY RRset and used to sign it. This time is key N's activation time (Tact), and at this point key N is said to be active 👑:
Tact(N) >= Trdy(N)Event 5: At some point, you need to think about key replacement. The DS record for the successor key has to be submitted to the parent zone at a time such that, when the current key is withdrawn, any cache holding the zone's DS records has data about the DS record of the successor key. The time this happens is the submission time of the successor key N+1, given by:
Tsbm(N+1) <= Tact(N) + Lksk - IpubP - DregHere Lksk is the actual lifetime of key N (which may differ slightly from the lifetime set in the key management policy), and Dreg is the registration delay.
Event 6. After an interval Dreg, the successor DS record is published in the zone.
Event 7: The successor key (key N+1) enters the ready state, meaning its DS record is now in caches that hold the parent DS RRset 🌸.
Event 8: When key N has been active for its whole lifetime (Lksk), it gets replaced in the DNSKEY RRset by key N+1, and the RRset is then signed with the new key. At this point, both the old and new DS records have been in the parent zone long enough to be in caches holding the DS RRset, so the zone can be authenticated the whole way through the rollover. A validating resolver can authenticate either the old or the new KSK 🔥.
This time is the retire time (Tret) of key N, given by:
Tret(N) = Tact(N) + LkskThis is also the activation time of the successor key N+1.
Event 9: At some later time, all copies of the old DNSKEY RRset have expired from caches, and the old DS record isn't needed anymore. Like in the other rollover methods, this is called the dead time, Tdea, given by:
Tdea(N) = Tret(N) + IretHere Iret is the retire interval of the key, given by:
Iret = DprpC + TTLkeySame as before, this term includes DprpC, the time taken to propagate the RRset change through the master-slave hierarchy of the child zone, and TTLkey, the time taken for the DNSKEY RRset to expire from caches 🧚.
Event 10: At some later time, the DS record is removed from the parent zone. Like in the other rollover methods, this is the removal time (Trem), given by:
Trem(N) >= Tdea(N)3.3.3. Double-RRset Method ✨
okay so the Double-RRset rollover is giving "publish everything at once" 💅 the new DNSKEY and DS records go live in their zones at the same time, and then, once enough time has passed for the old DNSKEY and DS RRsets to expire from caches, the old ones get removed from their zones. no cap, it's clean 🫶
the timeline is in Figure 5 below. it follows the same convention as Section 3.2.1 🎀
|1| |2| |3| |4| |5|
| | | | |
Key N |<-----------Lksk---------->|<---->|
| | | | |
| |<------Ipub----->| |
| | | | |
| |<-Dreg->|<-Iret->| |
| | | | |
Key N+1 | | |<----Lksk-------- - -
| | | | |
Key N Tact Tret Tdea Trem
Key N+1 Tpub Tact
---- Time ---->
Figure 5: Timeline for a Double-RRset KSK RolloverEvent 1 🌸 the DS and DNSKEY records have shown up in their zones, and the DNSKEY has already been used to sign the DNSKEY RRset. the key is published and active, so this is key N's activation time (Tact) ✨
Event 2 🦋 as the current key (key N) gets close to the end of its actual lifetime (Lksk), the successor key (key N+1) gets introduced into the zone and used to sign the DNSKEY RRset. at the same time, the successor DS record gets submitted to the parent zone. this is the publication time of the successor key (Tpub):
Tpub(N+1) <= Tact(N) + Lksk - Ipub... where Ipub is defined below 🧚
Event 3 💜 after the registration delay (Dreg), the DS record shows up in the parent zone. the DNSKEY is already in the child zone, so now both the new key and its data are visible, and this is the key's activation time (Tact). the key is now said to be active 👑
Tact(N+1) = Tpub(N+1) + DregEvent 4 🥹 before key N and its data can be withdrawn, every RRset in the caches of validating resolvers has to contain the new DS and/or DNSKEY. the moment that happens is the dead time of key N (Tdea), given by:
Tdea(N) = Tpub(N+1) + IpubIpub is how long it takes to guarantee that any old cached info about the DNSKEY and the DS RRsets has expired. for the DNSKEY, that's the publication interval of the child (IpubC). for the DS, the publication interval (IpubP) starts once the record appears in the parent zone, which is Dreg after it was submitted. so:
Ipub = max(Dreg + IpubP, IpubC)the parent zone's publication interval is:
IpubP = DprpP + TTLdswhere DprpP is the parent zone's propagation delay and TTLds is the TTL of the DS record in that zone 🍓
the child zone's publication interval is a similar equation:
IpubC = DprpC + TTLkeywhere DprpC is the propagation delay in the child zone and TTLkey is the TTL of a DNSKEY record 💅
just like the other rollovers, we can also define a retire interval, which is the gap between a key becoming active and the time its predecessor is considered dead. here Iret is:
Iret = Ipub - Dregbasically, the retire interval of the old key is the bigger of the parent's publication interval or the child's publication interval minus the registration delay. iconic 🔥
Event 5 🌈 at some later time, key N's DS and DNSKEY records get removed from their zones. like in the other rollover methods, this is the removal time (Trem):
Trem(N) >= Tdea(N)3.3.4. Interaction with Configured Trust Anchors
okay so the earlier sections were all about rolling KSKs, where the trust anchor is a DS record in the parent zone. BUT some validating resolvers might have trust anchors configured directly, so zone managers may wanna think about that too 🎀
rolling a configured trust anchor is handled in [RFC5011]. it means the KSK that will be the trust anchor has to be introduced into the zone for a while before it's used, and then kept around (with the "revoke" bit set) for some time after it's used 🫶
3.3.4.1. Addition of KSK
when the new key comes in, the publication interval of the DNSKEY (IpubC) in the Double-KSK and Double-RRset methods gets changed to:
IpubC >= DprpC + max(Itrp, TTLkey)... and now the right side has the "trust point" interval in it ✨ this is the time needed to guarantee that a resolver set up for automatic key updates under [RFC5011] will accept the new key as a new trust point. that interval is:
Itrp >= queryInterval + AddHoldDownTime + queryInterval... where queryInterval is as defined in Section 2.3 of [RFC5011], and AddHoldDownTime is the Add Hold-Down Time defined in Section 2.4.1 of the same document 🦋
the first term (queryInterval) is the time after which every validating resolver can be guaranteed to have grabbed a copy of the DNSKEY RRset with the new key. once it's retrieved, a validating resolver has to wait for AddHoldDownTime. as long as it doesn't see a validly signed DNSKEY RRset without the new key during that time, it'll treat the key as a trust anchor the next time it retrieves the RRset. that can take up to another queryInterval (the third term) 💜
BUT the expression for queryInterval in [RFC5011] includes the DNSKEY's RRSIG expiration interval, which only the validating resolver can actually calculate. so in practice, a modified query interval that depends only on TTLkey can be used:
modifiedQueryInterval = MAX(1hr, MIN(15 days, TTLkey / 2))(this comes from taking the queryInterval expression in [RFC5011] and assuming a worst case for RRsigExpirationInterval. it's greater than or equal to queryInterval for all values of the expiration time.) after collecting terms, the expression above turns into:
Itrp >= AddHoldDownTime + 2 * modifiedQueryIntervalin the Double-DS method, instead of swapping the KSK RRs in one step, there now has to be a period of overlap. so the new KSK has to be introduced into the zone at least:
DprpC + max(Itrp, TTLkey)... before the switch is made 🔥
3.3.4.2. Removal of KSK
the timeline for removing the key, in all methods, gets changed by adding a new state called "revoked". when the key hits its dead time, instead of being declared "dead", it gets revoked. the "revoke" bit is set in the published DNSKEY RR, and the DNSKEY RRset is re-signed with the current and revoked keys. the key stays in this state for the revoke interval, Irev, given by:
Irev >= DprpC + modifiedQueryIntervalsame as before, DprpC is the time taken for the revoked DNSKEY to propagate to all slave zones, and modifiedQueryInterval is the time after which it can be guaranteed that all validating resolvers that adhere to RFC 5011 have retrieved a copy of the DNSKEY RRset with the revoked key 🌸
after this time, the key is dead and can be removed from the zone ✨
3.3.5. Introduction of First Keys
no timing stuff is involved in introducing the first keys into a zone, other than that they have to be introduced and the zone validly signed before a chain of trust to the zone is created 🧚
if the parent is secure, it means making sure the DS record isn't published in the parent zone until there's no chance that a validating resolver can get the record but not the corresponding DNSKEY 🥹 if the parent is insecure, i.e., the initial creation of a chain of trust or "security apex", it isn't possible to guarantee this. it's up to the operator of the validating resolver to wait for the new KSK to show up at all servers for the zone before configuring the trust anchor 💀
4. Standby Keys ✨
okay so keys usually get rolled on some regular schedule, BUT sometimes an emergency rollover is needed, e.g., if the active key is suspected of being compromised 😭 the goal of an emergency rollover is to get the zone re-signed with a new key ASAP. since a key has to be in the ready state to sign the zone, having at least one extra key (a standby key) in that state at all times will minimize the delay 🎀
for a ZSK, a standby key only really makes sense with the Pre-Publication method. a permanent standby DNSKEY RR should be included in the zone, or successor keys could be introduced as soon as possible after a key becomes active. either way, you end up with one or more extra ZSKs in the DNSKEY RRset that can be used right away to sign the zone if the current key is compromised 🫶
(although, in theory, the mechanism could be used with both the Double-Signature and Double-RRSIG methods, it would need pre-publication of the signatures. basically, the standby key would be permanently active, since it would have to be used regularly to renew signatures. zones would also permanently need two sets of signatures 🙈)
it's also possible to have a standby KSK 🔥 the Double-KSK method requires that the standby KSK be included in the DNSKEY RRset, and then rolling the key only needs the DS record to be introduced in the parent. the standby KSK should also be used to sign the DNSKEY RRset. since the RRset and its signatures travel together, just adding the KSK without using it to sign the DNSKEY RRset doesn't give the time saving you want. for a KSK to be used in a rollover, the DNSKEY RRset has to be signed with it, otherwise there's a delay while the old RRset (not signed with the new key) expires from caches 😤
the idea of a standby KSK in the Double-RRset rollover method effectively means having two active keys, since the standby KSK and its DS record would both be published at the same time in their zones 💜
finally, in the Double-DS method of rolling a KSK, there isn't a standby key present; there's a standby DS record in the parent zone 🌈
whatever algorithm is used, the standby item of data can be included in the zone on a permanent basis, or be a successor introduced as early as possible 🦋
5. Algorithm Considerations 🧚
so far everything has assumed that all keys and signatures use a single algorithm. BUT Section 2.2 of [RFC4035] requires that there be an RRSIG for each RRset using at least one DNSKEY of each algorithm in the zone apex DNSKEY RRset 🎀
except for an algorithm rollover (where the algorithms used to create the signatures are being changed), there's no relationship between keys of different algorithms. that means they can be rolled independently of one another 💅 in other words, the key-rollover logic described above should be run separately for each algorithm. the union of the results goes into the zone, which is signed using the active key for each algorithm 👑
6. Summary ✨
okay so bestie, the vibe for ZSKs is: the Pre-Publication method is generally considered the preferred way to roll keys 💅 and as we just saw, how long the roll takes is totally up to the zone manager. they're in the driver's seat 🚗💖
KSK rollovers are a different story 👑. the Double-RRset method is the most efficient one here, because the new DS records and the new DNSKEY RRsets can propagate in parallel 🦋. ngl the time it takes to roll KSKs might depend on the parent zone too, if the parent is signed 🫶
for zones that want to follow [RFC5011], the rollover time is often set by the timings defined in RFC 5011 🎀. and this is the part I need you to really hear: that delay is a policy choice, not a function of timing values 🙈. it also means the rollover process has to change, because you need to manage revocation of trust anchors 😭
last but not least, emergency key rollover gets SO much simpler once standby keys are standard practice during every type of rollover 🔥✨
7. Security Considerations 💀
this document doesn't introduce any new security issues beyond the ones already covered in [RFC4033], [RFC4034], [RFC4035], and [RFC5011] 🔐🫶
8. Normative References 📚
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, DOI 10.17487/RFC4033, March 2005, <http://www.rfc-editor.org/info/rfc4033>.
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, DOI 10.17487/RFC4034, March 2005, <http://www.rfc-editor.org/info/rfc4034>.
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, <http://www.rfc-editor.org/info/rfc4035>.
[RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC) Trust Anchors", STD 74, RFC 5011, DOI 10.17487/RFC5011, September 2007, <http://www.rfc-editor.org/info/rfc5011>.
[RFC6781] Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC Operational Practices, Version 2", RFC 6781, DOI 10.17487/RFC6781, December 2012, <http://www.rfc-editor.org/info/rfc6781>.
Appendix A. List of Symbols 🧚
the doc defines a bunch of symbols, and they're all listed here. every one has the form:
<TYPE><id><ZONE>where:
<TYPE> is an uppercase character telling you what type the symbol is. the defined types are:
D delay: interval that is a feature of the process
I interval between two events
L lifetime: interval set by the zone manager
T a point in time
TTL TTL of a record
I, T, and TTL are self-explanatory 🙈. like I, both D and L are time periods, but an I value is the gap between two events, while a "D" interval (delay) is a feature of the process (probably outside the zone manager's control), and an "L" interval (lifetime) is chosen by the zone manager as a matter of policy 💅
<id> is lowercase and tells you what object or event the variable is related to, e.g.,
act activation
pub publication
ret retire
<ZONE> is an optional uppercase letter that tells apart the same variable applied to different zones, and it's one of:
C child
P parent
inside the rollover descriptions, times can have a number in parentheses at the end, showing which instance of the key they belong to. e.g., Tact(N) is the activation time of key N, Tpub(N+1) is the publication time of key N+1, and so on 🦋
here's the list of variables used in the text below 📝
Dprp Propagation delay. The amount of time for a change made at a master nameserver to propagate to all the slave nameservers.
DprpC Propagation delay in the child zone.
DprpP Propagation delay in the parent zone.
Dreg Registration delay: the time taken for a DS record submitted to a parent zone to appear in it. As a parent zone is often managed by a different organization than that managing the child zone, the delays associated with passing data between organizations is captured by this term.
Dsgn Signing delay. After the introduction of a new ZSK, the amount of time taken for all the RRs in the zone to be signed with it.
Ipub Publication interval. The amount of time that must elapse after the publication of a DNSKEY and/or its associated data before it can be assumed that any resolvers that have the relevant RRset cached have a copy of the new information.
IpubC Publication interval in the child zone.
IpubP Publication interval in the parent zone.
Iret Retire interval. The amount of time that must elapse after a DNSKEY or associated data enters the retire state for any dependent information (e.g., RRSIG for a ZSK) to be purged from validating resolver caches.
Irev Revoke interval. The amount of time that a KSK must remain published with the "revoke" bit set to satisfy considerations of [RFC5011].
Itrp Trust-point interval. The amount of time that a trust anchor must be published for in order to guarantee that a resolver configured for an automatic update of keys will see the new key at least twice.
Lksk Lifetime of a KSK. This is the actual amount of time for which this particular KSK is regarded as the active KSK. Depending on when the key is rolled over, the actual lifetime may be longer or shorter than the intended key lifetime indicated by management policy.
Lzsk Lifetime of a ZSK. This is the actual amount of time for which the ZSK is used to sign the zone. Depending on when the key is rolled over, the actual lifetime may be longer or shorter than the intended key lifetime indicated by management policy.
Tact Activation time. The time at which the key is regarded as the principal key for the zone.
Tdea Dead time. The time at which any information held in validating resolver caches is guaranteed to contain information related to the successor key. At this point, the current key and its associated information are not longed required for validation purposes.
Tpub Publication time. The time that the key or associated data appears in the zone for the first time.
Trem Removal time. The time at which the key and its associated information starts being removed from their respective zones.
Tret Retire time. The time at which successor information starts being used.
Trdy Ready time. The time at which it can be guaranteed that validating resolvers that have information about the key and/or associated data cached have a copy of the new information.
Tsbm Submission time. The time at which the DS record of a KSK is submitted to the parent zone.
TTLds Time to live of a DS record.
TTLkey Time to live of a DNSKEY record. (By implication, this is also the time to live of the signatures on the DNSKEY RRset.)
TTLsig The maximum time to live of all the RRSIG records in the zone that were created with the ZSK.
Acknowledgements 🫶
the authors gratefully acknowledge help and contributions from Roy Arends, Tim Wicinski, and Wouter Wijngaards 💜
Authors' Addresses 🎀
Stephen Morris Internet Systems Consortium 950 Charter Street Redwood City, CA 94063 United States
Email: stephen@isc.org URI: http://www.isc.org
Johan Ihren Netnod Franzengatan 5 Stockholm SE-112 51 Sweden
Email: johani@netnod.se URI: http://www.netnod.se
John Dickinson Sinodun Internet Technologies Ltd Magdalen Centre Oxford Science Park Robert Robertson Avenue Oxford, Oxfordshire OX4 4GA United Kingdom
Email: jad@sinodun.com URI: http://www.sinodun.com
W. (Matthijs) Mekking Dyn, Inc. 150 Dow St Manchester NH 03101 United States
Email: mmekking@dyn.com URI: https://www.dyn.com
📦 where this page comes from
- ietf: rfc7583 2015-10
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms