This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”
The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.
This Internet-Draft will expire on February 22, 2010.
Copyright (c) 2009 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 in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
This document describes the issues surrounding the timing of events in the rolling of a key in a DNSSEC-secured zone. It presents timlines for the key rollover and explicitly identifies the relationships between the various parameters affecting the process.
1.2. Requirements Language
2. Types of Key Rollover
2.1. Pre-Publication Method
2.2. Double-Signature Method
2.3. Comparison of Rollover Methods
2.4. Timing Considerations
3. Zone-Signing Keys
3.1. Key Timeline
3.2. Key States
3.3. Stand-By Zone-Signing Keys
3.3.1. Stand-By Key Scheduling
3.3.2. Number of Stand-By Keys
4. Key-Signing Keys
4.2. Parent Zone Considerations
4.3. Rollover Strategies
4.4. Key Timeline
4.5. Key States
4.6. Stand-By Key-Signing Keys
5. Algorithm Considerations
7. IANA Considerations
8. Security Considerations
10. Change History
11. Normative References
Appendix A. List of Symbols
§ Authors' Addresses
When a zone is secured with DNSSEC, the zone manager must be prepared to replace ("roll") the keys used in the signing process. The rolling of keys may be caused by compromise of one or more of the existing keys, or it may be due to a management policy that demands periodic key replacement for security reasons. In order to implement a key rollover, the keys need to introduced into and removed from the zone at the appropriate times. Considerations that must be taken into account are:
Management policy, e.g. how long a key is used for, also needs to be taken into account. However, the point of key management logic is not to ensure that a "rollover" is completed at a certain time but rather to ensure that no changes are made to the state of keys published in the zone until it is "safe" to do so. In other words, although key management logic enforces policy, it may not enforce it strictly.
The terminology used in this document is as defined in [RFC4033] (Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, “DNS Security Introduction and Requirements,” March 2005.) and [RFC5011] (StJohns, M., “Automated Updates of DNS Security (DNSSEC) Trust Anchors,” September 2007.).
A large number of symbols are used in this document to identify times, intervals, etc. All are listed in Appendix A (List of Symbols).
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).
As noted in the introduction, client resolvers may cache both key and signature RRsets. This means that when validating a signature record (or passing both RRsets to a client who has issued a query with the CD bit set), an RRSIG just read from an authoritative server may be paired with a cached DNSKEY or vice-versa. For the validation to be successful, the DNSKEY and RRSIG must be consistent.
Key rollover - the replacement of the key use to sign the zone with another - involves changing the contents of the DNSKEY RRset and re- signing the zone (so changing the RRSIG records). In order for a RR to be validated, at least one RRSIG in the associated signature RRset must be able to be validated by one of the keys in the DNSKEY RRset. To ensure uninterrupted security, the aim must be to ensure that this condition is true at all stages during the rollover process.
Two ways to achieve this goal are the pre-publication method and the double signature method.
In pre-publication, the new key is introduced into the DNSKEY RRset, leaving the existing keys and signatures in place. This state of affairs remains in place for long enough to ensure that any DNSKEY RRsets cached in client resolvers contain both keys. At that point, the zone can be signed with the new key and the old signatures removed. During the re-signing process (which may or may not be atomic depending on how the zone is managed), it doesn't matter which key an RRSIG record retrieved by a client was created with; clients will have a copy of the DNSKEY RRset containing both the old and new keys.
Once the zone contains only signatures created with the new key, there is an interval during which RRSIG records created with the old key expire from client caches. After this, the old key can be removed from the DNSKEY RRset because there will be no signatures anywhere created using it.
Double-signature, as the name implies, involves introducing the new key into the zone and using it to create additional RRSIG records; the old key and existing RRSIG records are retained. During the period in which the zone is being signed (again, the signing process may not be atomic), client resolvers are always able to validate RRSIGs: any combination of old and new DNSKEY and RRSIG RRsets allows at least one signature to be validated.
Once the signing process is complete and enough time has elapsed to allow all old DNSKEY and RRSIG RRsets to expire from caches, the old key and signatures can be removed from the zone. As before, during this period any combination of DNSKEY and RRSIG RRsets will allow validation of at least one signature.
Of the two methods, double-signature is the simplest conceptually - introduce the new key and new signatures, then (roughly) one TTL later remove the old key and signatures. The drawback of this method is a noticeable increase in the size of the DNSSEC data. This affects both the overall size of the zone and the size of the responses.
Pre-publication is more complex - introduce the new key, one TTL later sign the records, and one TTL after that remove the old key. However, the amount of DNSSEC data is kept to a minimum, hence reducing the impact on performance.
The rest of this paper describes the timing considerations related to the rolling of zone-signing keys (ZSKs) and key-signing keys (KSKs). Owing to the increase in the amount of DNSSEC data in the double-signature method, the pre-publication approach is preferred for rollover of ZSKs. However, in the case of KSK rollovers, the size increase is negligible and hence the complexity of pre-publication is not justified.
While this combination is the most common choice of rollover logic, there is nothing to preclude other combinations should the situation demand it. The rest of this document describes ZSK and KSK rollover timelines for the common case.
The following diagram shows the time line of a particular ZSK (zone-signing key) and its replacement by its successor. Time increases along the horizontal scale from left to right and the vertical lines indicate events in the life of the key. The events are numbered; significant times and time intervals are marked.
|1| |2| |3| |4| |5| |6| |7| |8| |9| | | | | | | | | | Key N | |<-Ipub->|<--->|<-------Lzsk----->|<-Iret->|<--->| | | | | | | | | | Key N+1 | | | | |<-Ipub->|<->|<---Lzsk-- - - | | | | | | | | | Tgen Tpub Trdy Tact TpubS Tret Tdea Trem ---- Time ---->
| Figure 1: Timeline for a ZSK rollover. |
Event 1: key N is generated at the generate time (Tgen). Although there is no reason why the key cannot be generated immediately prior to publication in the zone (Event 2), some implementations may find it convenient to create a pool of keys in one operation and draw from that pool as required. For this reason, it is shown as a separate event. Keys that are available for use but not published are said to be generated.
Event 2: key N's DNSKEY record is put into the zone, i.e. it is added to the DNSKEY RRset which is then re-signed with the current key-signing key. The time at which this occurs is the key's publication time (Tpub), and the key is now said to be published. Note that key N is not yet used to sign records.
Event 3: before it can be used, the key must be published for long enough to guarantee that any resolver that has a copy of the DNSKEY RRset from the zone in its cache will have a copy of the RRset that includes this key: in other words, that any prior cached information about the DNSKEY RRset has expired.
The interval is the publication interval (Ipub) and, for the second or subsequent keys in the zone, is given by:
Ipub = Dprp + TTLkey
Here, Dprp is the propagation delay - the time take for any change introduced at the master to replicate to all slave servers - which depends on the depth of the master-slave hierarchy. TTLkey is the time-to-live (TTL) for the DNSKEY records in the zone. The sum is therefore the time taken for existing DNSKEY records to expire from the caches of downstream validators, regardless of the nameserver from which they were retrieved.
In the case of the first key in the zone, Ipub is slightly different because it is not information about a DNSKEY RRset that may be cached, it is information about its absence. In this case:
Ipub = Dprp + Ingc
where Ingc is the negative cache interval from the zone's SOA record, calculated according to [RFC2308] (Andrews, M., “Negative Caching of DNS Queries (DNS NCACHE),” March 1998.) as the minimum of the TTL of the SOA record itself (TTLsoa), and the "minimum" field in the record's parameters (SOAmin), i.e.
Ingc = min(TTLsoa, SOAmin)
After a delay of Ipub, the key is said to be ready and can be used to sign records. The time at which this event occurs is the key's ready time (Trdy), which is given by:
Trdy = Tpub + Ipub
Event 4: at some later time, the key starts being used to sign RRsets. This point is the activation time (Tact) and after this, the key is said to be in the active state.
Event 5: while this key is active, thought must be given to its successor. As with the introduction of the currently active key into the zone, the successor key will need to be published at least Ipub before it is used. Denoting the publication time of the successor key by TpubS, then:
TpubS <= Tact + Lzsk - Ipub
Here, Lzsk is the length of time for which a ZSK will be used (the ZSK lifetime). It should be noted that unlike the publication interval, Lzsk is not determined by timing logic, but by key management policy. Lzsk will be set by the operator according to their assessment of the risks posed by continuing to use a key and the risks associated with key rollover. However, operational considerations may mean a key lives for slightly more or less than Lzsk.
Event 6: while the current ZSK is still active, its successor becomes ready. From this time onwards, it could be used to sign the zone.
Event 7: at some point the decision is made to start signing the zone using the successor key. This will be when the current key has been in use for an interval equal to the ZSK lifetime, hence:
Tret = Tact + Lzsk
This point in time is the retire time (Tret) of key N; after this the key is said to be retired. (This time is also the point at which the successor key becomes active.)
Event 8: the retired key needs to be retained in the zone whilst any RRSIG records created using this key are still published in the zone or held in resolver caches. (It is possible that a resolver could have an unexpired RRSIG record and an expired DNSKEY RRset in the cache when it is asked to provide both to a client. In this case the DNSKEY RRset would need to be looked up again.) This means that once the key is no longer used to sign records, it should be retained in the zone for at least the retire interval (Iret) given by:
Iret = Dsgn + Dprp + TTLsig
Dsgn is the delay needed to ensure that all existing RRsets have been re-signed with the new key. Dprp is (as described above) the propagation delay, required to guarantee that the updated zone information has reached all slave servers, and TTLsig is the TTL of the RRSIG records.
(It should be noted that an upper limit on the retire interval is given by:
Iret = Lsig + Dskw
where Lsig is the lifetime of a signature (i.e. the interval between the time the signature was created and the signature end time), and Dskw is the clock skew - the maximum difference in time between the server and a validator. The reasoning here is that whatever happens, a key only has to be available while any signatures created with it are valid. Wherever a signature record is held - published in the zone and/or held in a resolver cache - it won't be valid for longer than Lsig after it was created. The Dskw term is present to account for the fact that the signature end time is an absolute time rather than interval, and systems may not agree exactly about the time.)
The time at which all RRSIG records created with this key expire from resolver caches is the dead time (Tdea), given by:
Tdea = Tret + Iret
Event 9: at any time after the key becomes dead, it can be removed from the zone and the DNSKEY RRset re-signed with the current key-signing key. This time is the removal time (Trem), given by:
Trem >= Tdea
...and the key is said to be in the removed state.
An alternative way of considering the key timeline is to regard the key as moving through a set of states, the state transitions being determined by time. The state transition diagram is linear and is shown in Figure 2 (ZSK State Diagram.):
+-----------+ +-----------+ +-----------+ Start ---->| Generated |----->| Published |----->| Ready | Tgen +-----------+ Tpub +-----------+ Trdy +-----------+ | +-----------+ | +------------| Active |<-----------+ | Tret +-----------+ Tact V +-----------+ +-----------+ +-----------+ | Retired |----->| Dead |----->| Removed | +-----------+ Tdea +-----------+ Trem +-----------+
| Figure 2: ZSK State Diagram. |
The states are:
- The key has been created.
- The DNSKEY record is published in the zone, but resolvers may have earlier versions of the DNSKEY RRset in their cache.
- The key has been published for long enough to guarantee that all cached versions of the zone's DNSKEY RRset contain this key.
- The key is in the zone and is being used to sign RRsets.
- The key is in the zone but is no longer being used to sign RRsets. However, there may still be RRSIG records in caches that were created with this key.
- The key is published in the zone but there are no RRSIGs in existence created with this key.
- The key has been removed from the zone.
Although ZSKs will usually be rolled according to some regular schedule, there may be occasions when an emergency ZSK rollover is required, e.g. if the active key is suspected of being compromised. The aim of the emergency rollover is to allow the zone to be re-signed with a new key as soon as possible. As a key must be in the ready state to sign the zone, having at at least one stand-by ZSK in this state at all times will minimise delay.
One way to achieve this is to regard successor keys as stand-by keys for emergency rollovers and to introduce them in the zone as early as possible. A modification of Figure 1 (Timeline for a ZSK rollover.) illustrates this:
|1| |2| |3| |4| | | | | Key N - - - -----Lzsk---------->| | | | | | Key N+1 - --------------------->|<----Lzsk----->| | | | | Key N+2 |<-Ipub->|<---------------------->|<--Lzsk-- - - | | | | ---- Time ---->
| Figure 3: Timeline showing stand-by key replacement. |
In this figure, it is assumed that key N is initially in the active state and that key N+1 is in the ready state. Key N+1 is the successor to key N but is regarded as the stand-by key for an emergency re-signing until the time comes to use it to sign the zone.
Event 1: At least Ipub before key N's retire time, key N+2 is published in the zone.
Event 2: key N+2 moves into the ready state.
Event 3: key N is retired and key N+1 becomes active (as described in Section 3.1 (Key Timeline), events 7 - 9). Key N+2 is now regarded as the stand-by key.
Event 4: key N+1 is retired and key N+2 becomes the current key. By this time, key N+3 will have been published and be in the ready state.
The above illustrates one way of handling stand-by keys for emergency use. An equally valid alternative would be to have a permanent stand-by key. In this scheme, a key is published in the zone but, unless it needs to be used in an emergency, is never used to sign it. Instead, active keys are replaced by their successors as shown in Figure 1 (Timeline for a ZSK rollover.).
An emergency key rollover could be required at any time. Referring back to Figure 3 (Timeline showing stand-by key replacement.), should an emergency rollover be required between events 2 and 3, the sequence would happen as previously described: there is a already key (key N+2) ready to take over as the stand-by key when the current stand-by key becomes active. In the worst case though, it may be required that the system run without an stand-by key for a while. For example, if a key rollover was required between events 3 and 4 in Figure 3 (Timeline showing stand-by key replacement.), the timeline would look like:
|3a| |3b| | | Key N+1 - ---Lzsk--->| | | | Key N+2 - ---------->|<----------Lzsk---- - - | | Key N+3 |<-Ipub->|<-------- - - | | ---- Time ---->
| Figure 4: Timeline showing emergency key rollover. |
(The interval shown above lies between events 3 and 4 in Figure 3 (Timeline showing stand-by key replacement.), the events being labelled 3a and 3b to highlight this.)
Here it is assumed that key N+1 is initially in the active state and that the single stand-by key (N+2) is in the ready state. It is well before the active key's retire time, so there are only these two ZSKs in the zone. The events are:
Event 3a: an emergency ZSK rollover is required. Key N+1 is retired and key N+2 becomes active. At this time, key N+3 (which will ultimately become the new stand-by key) is published in the zone.
Event 3b: key N+3 moves into the ready state, after which it can be used to replace key N+1 should the need arise.
Between events 3a and 3b however, only the active key (key N+2) can be used to sign the zone. If a second emergency arises in this interval, the active key cannot be replaced: key rollover must wait until the new stand-by key (N+3) becomes ready. Of course, this can be mitigated by having a number of stand-by keys available, but how many is a matter of policy; there is a need to weigh the likelihood of a key compromise against the number of keys required.
There are three significant differences between key-signing keys (KSKs) and ZSKs:
These differences have the following implications for KSK rollovers:
There are some differences in the sequence of events between the cases of a zone where a KSK is authenticated via a DS record in the parent zone and one where it is authenticated by a trust anchor configured into a validator. These will be highlighted as appropriate.
If (as is the usual case) the parent and child zones are managed by different entities, the timing of some of the steps in the KSK rollover operation may be subject to uncertainty.
It is important to note that this does not preclude the development of key rollover logic; in accordance with the goal of the rollover logic being able to determine when a state change is "safe", the only effect of being dependent on the parent is that there may be a period of waiting for the parent to respond, in addition to any delay the key rollover logic requires.
Although this introduces additional delays, even with a parent that is less than ideally responsive the only effect will be a slowdown in the rollover state transitions. This may cause a policy violation, but will not cause any operational problems.
When the parent zone is secured, there are several different ways to roll a KSK whilst ensuring that the zones do not go insecure or bogus in the process:
In essence, "Double KSK" means that the new KSK is introduced first, and then the new DS (for this KSK). With "Double DS" it is the other way around. Finally, Double RRset does both updates more or less in parallel.
Of the three methods, the double RRset method is preferred because:
The timeline for the key rollover is shown below:
|1| |2| |3| |4| |5| |6| |7| |8| | | | | | | | | Key N | |<-Ipub->|<-->|<-------Lksk------->|<-Iret->| | | | | | | | | Key N+1 | | | | |<-Ipub->|<--->|<---Lksk-- - - | | | | | | | | Tgen Tpub Trdy Tact TpubS TrdyS Tret Trem ---- Time ---->
| Figure 5: Timeline for a KSK rollover. |
Event 1: key N is generated at time Tgen and enters the generate state. As before, although there is no reason why the key cannot be generated immediately prior to publication, some implementations may find its convenient to create a central pool of keys and draw from it. For this reason, it is again shown as a separate event.
Event 2: the key is added to and used for signing the DNSKEY RRset and is thereby published in the zone. At this time the corresponding DS record is made available. If the parent zone is secure, this means submitting the DS record to the parent zone for publication; if not, it is distributed by some mechanism to allow validators to configure it as a trust anchor. This time is the publish time (Tpub) and the KSK is said to be in the published state.
Event 3: after some time (the publication interval, Ipub), any validator that has copies of the DNSKEY and/or DS RRsets in its cache will have a copy of the data for key N. This point is the ready time and is given by:
Trdy = Tpub + Ipub
Regarding the associated DS record, there are now two cases to consider, where the parent is signed and where the parent is not signed:
Event 3 (parent signed): In the case of the KSK, the publication interval depends on the publication interval of both the DNSKEY record and the DS record. These are independent, so a suitable expression for Ipub is:
Ipub = max(IpubC, IpubP)
IpubC is the publication interval in the child zone and IpubP that of the parent.
The child term comprises two parts - the time taken for the introduction of the DNSKEY record to be registered on the downstream secondary servers (= DprpC, the child propagation delay) and the time taken for information about the DNSKEY RRset to expire from the validator cache, i.e.
IpubC = DprpC + TTLkeyC
(TTLkeyC is the TTL for a DNSKEY record in the child zone.)
The parent term is similar, but also includes the time taken for the DS record to be included in the parent zone after the request has been made. In other words:
IpubP = Dreg + DprpP + TTLds
Dreg is the registration delay, which is the time taken between the submission of the DS record to the parent zone and its publication in the zone. DprpP the propagation delay in the parent zone and TTLds the TTL for a DS record.
Throughout the introduction of the two RRs, the zone can be validated by by the existing KSK and DS record. However, there are special considerations regarding the first KSK in a zone, and these are discussed below.
Event 3 (parent not signed): if the parent is not signed then there is no parent publication interval (theoretically the DS record could be configured in a validator immediately it is made available), in which case the minimumn value of the publication interval is given by:
Ipub = IpubC
Event 3 (common): In both cases, if the management policy is to support [RFC5011] (StJohns, M., “Automated Updates of DNS Security (DNSSEC) Trust Anchors,” September 2007.), there is also the additional condition that the new key needs to be published for at least as long as the RFC5011 add hold-down time, defined in that document as "30 days or the expiration time of the original TTL of the first trust point DNSKEY RRSet that contained the new key, whichever is greater".
This can be expressed as the condition:
Ipub >= max(30 days, TTLkey)
At Trdy, as the key has already been used to sign the DNSKEY RRset, the key is also active in that all other KSKs could be withdrawn from the zone at this point and the zone would still be valid. However, while a predecessor key is active, it is convenient to regard the successor key as merely being ready.
Event 4: at some later time, the predecessor key is withdrawn from the zone and, in the absence of any emergency keys, key N becomes the only KSK for the zone. The key is said to be active, and this time is the active time (Tact).
Event 5: as with the ZSK, at some point we need to give thought to key replacement. The successor key must be introduced into the zone at a time such that when the current key is withdrawn, any validator that has key information (DNSKEY and/or DS records) in its cache will have data about the successor key.
As before, this interval is the publication interval, Ipub. Denoting the publication time of the successor key as TpubS, we get:
TpubS <= Tact + Lksk - Ipub
... where Lksk is the lifetime of the KSK.
Event 6: the successor key (key N+1) enters the ready state. This occurs at TrdyS, given by:
TrdyS = TpubS + Ipub
Event 7: at some time after that a decision will be made to retire the current key (key N). This will be when the current key has been active for its lifetime (Lksk). At this point, the retire time, the successor key becomes active and the current key is said to be retired:
Tret = Tact + Lksk
(... with the obvious condition that Tret >= TrdyS.)
If the management policy is to support [RFC5011] (StJohns, M., “Automated Updates of DNS Security (DNSSEC) Trust Anchors,” September 2007.), the retired key should now have the revoke bit set and be included in the DNSKEY RRset. the revoked key should also be used to sign it.
Event 8: at some later time, the DNSKEY record can be removed from the child zone. If there is a secure parent, a request can be made to remove the DS record from the parent zone. This is the removal time, Trem and is given by:
Trem = Tret + Iret
where, as before, Iret is the retire interval. This will be zero unless [RFC5011] (StJohns, M., “Automated Updates of DNS Security (DNSSEC) Trust Anchors,” September 2007.) is being followed, in which case Iret will be equal to the RFC5011 remove hold-down time value of 30 days.
The second point is important: in the case of a secure parent, it means ensuring that the DS record is not published in the parent zone until there is no possibility that a validator can obtain the record yet not be able to obtain the corresponding DNSKEY. In the case of an insecure parent, i.e. the initial creation of a new security apex, it is important to not configure trust anchors in validators until the DNSKEY RRset has had sufficient time to propagate. In both cases, this time is the trust anchor availability time (Ttaa) given by:
Ttaa >= Tpub + IpubC
IpubC = DprpC + TTLkeyC
IpubC = DprpC + IngcC
The first expression applies if there was previously a DNSKEY RRset in the child zone, the expression for IpubC including the TTLkeyC term to account for the time taken for that RRset to expire from caches. If the introduction of the KSK caused the appearance of the first DNSKEY RRset in the child zone, the second expression applies in which the TTLkeyC term is replaced by one to allow for the effect of negative caching.
The key states for a KSK during the rollover are identical to those in Figure 2 (ZSK State Diagram.).
In the same way that additional ZSKs are kept in a ready state in the zone to act as emergency keys, additional KSKs need to be available in the ready state for the same reason. The number of stand-by keys kept available is a matter of key management policy, and the logic for the introduction of stand-by keys into the zone follows the same reasoning as that given in Section 3.3 (Stand-By Zone-Signing Keys) on the introduction of stand-by ZSKs.
The preceding sections have implicitly assumed that all keys and signatures are created using a single algorithm. However, [RFC4035] (Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, “Protocol Modifications for the DNS Security Extensions,” March 2005.) (section 2.4) states that "There MUST be an RRSIG for each RRset using at least one DNSKEY of each algorithm in the zone apex DNSKEY RRset".
Except in the case of an algorithm rollover - where the algorithms used to create the signatures are being changes - there is no relationship between the keys of different algorithms. This means that they can be rolled independently of one another. (Indeed, the keys for each algorithm could, if desired, have different TTLs.) In other words, the key rollover logic described above should be run separately for each algorithm; the union of the results is included in the zone, which is signed using the active key for each algorithm.
For ZSKs, "pre-publication" is generally considered to be the preferred way of rolling keys. As shown in this document, the time taken to roll is wholly dependent on parameters under the control of the zone manager.
In contrast, "double RRset" is the most efficient method for KSK rollover due to the ability to have new DS records and DNSKEY RRsets propagate in parallel. The time taken to roll KSKs may depend on factors related to the parent zone if the parent is signed. For zones that intend to comply with the recommendations of [RFC5011] (StJohns, M., “Automated Updates of DNS Security (DNSSEC) Trust Anchors,” September 2007.), in virtually all cases the rollover time will be determined by the RFC5011 add and remove hold-down times. It should be emphasised that this delay is a policy choice and not a function of timing values and that it also requires changes to the rollover process due to the need to manage revocation of trust anchors.
Finally, the treatment of emergency rollover is significantly simplified by the introduction of stand-by keys as standard practice during all types of rollovers.
This memo includes no request to IANA.
This document does not introduce any new security issues beyond those already discussed in [RFC4033] (Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, “DNS Security Introduction and Requirements,” March 2005.), [RFC4034] (Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, “Resource Records for the DNS Security Extensions,” March 2005.), [RFC4035] (Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, “Protocol Modifications for the DNS Security Extensions,” March 2005.) and [RFC5011] (StJohns, M., “Automated Updates of DNS Security (DNSSEC) Trust Anchors,” September 2007.).
The authors gratefully acknowledge help and contributions from Roy Arends and Wouter Wijngaards.
|[RFC2119]||Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML).|
|[RFC2308]||Andrews, M., “Negative Caching of DNS Queries (DNS NCACHE),” RFC 2308, March 1998 (TXT, HTML, XML).|
|[RFC4033]||Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, “DNS Security Introduction and Requirements,” RFC 4033, March 2005 (TXT).|
|[RFC4034]||Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, “Resource Records for the DNS Security Extensions,” RFC 4034, March 2005 (TXT).|
|[RFC4035]||Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, “Protocol Modifications for the DNS Security Extensions,” RFC 4035, March 2005 (TXT).|
|[RFC5011]||StJohns, M., “Automated Updates of DNS Security (DNSSEC) Trust Anchors,” RFC 5011, September 2007 (TXT).|
The document defines a number of symbols, all of which are listed here. All are of the form:
All symbols used in the text are of the form:
<TYPE> is an upper-case character indicating what type the symbol is. Defined types are:
- delay: interval that is a feature of the process
- lifetime: calculated interval set by the zone manager
- interval between two events
- lifetime: interval set by the zone manager
- parameter related to SOA RR
- a point in time
- TTL of a record
T and I are self-explanatory. D, and L are also time periods, but whereas I values are intervals between two events (even if the events are defined in terms of the interval, e.g. the dead time occurs "retire interval" after the retire time), D, and L are fixed intervals. An "L" interval (lifetime) is chosen by the zone manager and is a feature of policy. A "D" interval (delay) is a feature of the process, probably outside control of the zone manager. SOA and TTL are used just because they are common terms terms.
<id> is lower-case and defines what object or event the variable is related to, e.g.
- negative cache
Finally, <INST> is a capital letter that distinguishes between the same variable applying to different instances of an object and is one of:
The list of variables used in the text is:
- Propagation delay. The amount of time for a change made at a master nameserver to propagate to all the slave nameservers.
- Propagation delay in the parent zone.
- Registration delay. As a parent zone are often managed by a different organisation to the one under consideration, the delays associated with passing data between zones is captured by this term.
- Clock skew. The maximum difference in time between the signing system and the resolver.
- 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.
- Negative cache interval.
- Publication interval. The amount of time that must elapse after the publication of a key before it can be considered to have entered the ready state.
- Publication interval in the child zone.
- Publication interval in the parent zone.
- Retire interval. The amount of time that must elapse after a key enters the retire state for any signatures created with it to be purged from validator caches.
- Lifetime of a key-signing key. This is the intended 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 this.
- Lifetime of a zone-signing key. This is the intended 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 this.
- Lifetime of a signature: the difference in time between the signature's expiration time and the time at which the signature was created. (Note that this is not the difference between the signature's expiration and inception times: the latter is usually set a small amount of time before the signature is created to allow for clock skew between the signing system and the validator.)
- Value of the "minimum" field from an SOA record.
- Active time of the key. For a ZSK, the time that they key is first used to sign the zone. For a KSK, the time at which this key is regarded as being the principal KSK for the zone.
- Dead time of a key. Applicable only to ZSKs, this is the time at which any record signatures held in validator caches are guaranteed to be created with the successor key.
- Generate time of a key. The time that a key is created.
- Publish time of a key. The time that a key appears in a zone for the first time.
- Publish time of the successor key.
- Removal time of a key. The time at which a key is removed from the zone.
- Retire time of a key. The time at which a successor key starts being used to sign the zone.
- Ready time of a key. The time at which it can be guaranteed that a validators that have key information from this zone cached have a copy of this key in their cache. (In the case of KSKs, should the validators also have DS information from the parent zone cached, the cache must include information about the DS record corresponding to the key.)
- Ready time of a successor key.
- Time to live of a DS record (in the parent zone).
- Time to live of a DNSKEY record.
- Time to live of a DNSKEY record in the child zone.
- Time to live of a SOA record.
- Time to live of an RRSIG record.
- Trust anchor availability time. The time at which a trust anchor record can be made available when a KSK is first introduced into a zone.
|Minerva House, Edmund Halley Road|
|Oxford, OX4 4DQ|
|Phone:||+44 1865 332211|
|Stockholm, SE-112 51|
|Phone:||+46 8615 8573|
|Stables 4 Suite 10, Howbery Park|
|Wallingford, OX10 8BA|