GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc7583

Internet Engineering Task Force (IETF) S. Morris Request for Comments: 7583 ISC Category: Informational J. Ihren ISSN: 2070-1721 Netnod

                                                          J. Dickinson
                                                               Sinodun
                                                            W. Mekking
                                                                   Dyn
                                                          October 2015
             DNSSEC Key Rollover Timing Considerations

Abstract

 This document describes the issues surrounding the timing of events
 in the rolling of a key in a DNSSEC-secured zone.  It presents
 timelines for the key rollover and explicitly identifies the
 relationships between the various parameters affecting the process.

Status of This Memo

 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.

Morris, et al. Informational [Page 1] RFC 7583 Key Timing October 2015

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, as they describe your rights and restrictions with respect
 to 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 ................................................31

Morris, et al. Informational [Page 2] RFC 7583 Key Timing October 2015

1. Introduction

1.1. Key Rolling Considerations

 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 or operational reasons.  In
 order to implement a key rollover, the keys need to be introduced
 into and removed from the zone at the appropriate times.
 Considerations that must be taken into account are:
 o  DNSKEY records and associated information (such as the DS records
    or RRSIG records created with the key) are not only held at the
    authoritative nameserver, they are 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.
 o  Zone "bootstrapping" events, where a zone is signed for the first
    time, can be common in configurations where a large number of
    zones are being served.  Procedures should be able to cope with
    the introduction of 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.
 o  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.
 o  A query for the DNSKEY RRset returns all DNSKEY records in the
    zone.  As there is limited space in the UDP packet (even with
    EDNS0 support), key records 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, e.g., how long a key is used for, also needs to be
 considered.  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 ("safe" in this context meaning 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.

Morris, et al. Informational [Page 3] RFC 7583 Key Timing October 2015

 A high-level overview of key rollover can be found in [RFC6781].  In
 contrast, this document 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 the process for the introduction of keys into a zone is
 different from that of rolling a key; see Section 3.3.5 for more
 information.

1.2. Types of Keys

 Although DNSSEC validation treats all keys equally, [RFC4033]
 recognizes the broad classification of ZSKs and KSKs.  A ZSK is used
 to authenticate information within the zone; a KSK is used to
 authenticate the zone's DNSKEY RRset.  The main implication for this
 distinction concerns the consistency of information during a
 rollover.
 During operation, a validating resolver must use separate pieces of
 information to perform an authentication.  At the time of
 authentication, each piece of information may be in its cache or may
 need to be retrieved from an authoritative server.  The rollover
 process needs to happen in such a way that the information is
 consistent at all times during the rollover.  With a ZSK, the
 information is the RRSIG (plus associated RRset) and the DNSKEY.
 These are both obtained from the same zone.  In the case of the KSK,
 the information is the DNSKEY and DS RRset with the latter being
 obtained from a different zone.
 Although there are similarities in the algorithms to roll ZSKs and
 KSKs, there are 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.  All
 are listed in Appendix A.

Morris, et al. Informational [Page 4] RFC 7583 Key Timing October 2015

1.4. Limitation of Scope

 This document represents current thinking at the time of publication.
 However, the subject matter is evolving and it is not possible for
 the document to be comprehensive.  In particular, it does not cover:
 o  Rolling a key that is used as both a ZSK and KSK.
 o  Algorithm rollovers.  Only the rolling of keys of the same
    algorithm is described here: not transitions between algorithms.
 o  Changing TTLs.
 Algorithm rollover is excluded from the document owing to the need
 for there to be an RRSIG for at least one DNSKEY of each algorithm in
 the DNSKEY RRset [RFC4035].  This introduces additional constraints
 on rollovers that are not considered here.  Such considerations do
 not apply where other properties of the key, such as key length, are
 changed during the rollover: the DNSSEC protocol does not impose any
 restrictions in these cases.
 Also excluded from consideration 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 is assumed that TTLs are
 constant.

2. Rollover Methods

2.1. ZSK Rollovers

 For ZSKs, the issue for the zone operator/signer is to ensure that
 any caching validator that has access to a particular signature also
 has access to the corresponding valid ZSK.
 A ZSK can be rolled in one of three ways:
 o  Pre-Publication: described in [RFC6781], the new key is introduced
    into the DNSKEY RRset, which is then re-signed.  This state of
    affairs remains in place for long enough to ensure that any cached
    DNSKEY RRsets contain both keys.  At that point, signatures
    created with the old key can be replaced by those created with the
    new key.  During the re-signing process (which may or may not be
    atomic depending on how the zone is managed), it doesn't matter
    with which key an RRSIG record retrieved by a resolver was
    created; cached copies of the DNSKEY RRset will contain both the
    old and new keys.

Morris, et al. Informational [Page 5] RFC 7583 Key Timing October 2015

    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 caches.  After this, there will be no
    signatures anywhere that were created using the old key, and it
    can be removed from the DNSKEY RRset.
 o  Double-Signature: also mentioned in [RFC6781], this 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), validating
    resolvers are always able to validate RRSIGs: any combination of
    old and new DNSKEY RRset and RRSIGs allows at least one signature
    to be validated.
    Once the signing process is complete and enough time has elapsed
    to make sure that all validators that have the DNSKEY and
    signatures in cache have both the old and new information, the old
    key and signatures can be removed from the zone.  As before,
    during this period any combination of DNSKEY RRset and RRSIGs will
    allow validation of at least one signature.
 o  Double-RRSIG: strictly speaking, the use of the term "Double-
    Signature" above is a misnomer as the method is not only double
    signature, it is also double key as well.  A true Double-Signature
    method (here called the Double-RRSIG method) involves introducing
    new signatures in the zone (while still retaining the old ones)
    but not introducing the new key.
    Once the signing process is complete and enough time has elapsed
    to ensure that all caches that may contain an RR and associated
    RRSIG have a copy of both signatures, the key is changed.  After a
    further interval during which the old DNSKEY RRset expires from
    caches, the old signatures are removed from the zone.
 Of the three methods, Double-Signature is conceptually the simplest:
 introduce the new key and new signatures, then approximately one TTL
 later remove the old key and old signatures.  It is also the fastest,
 but suffers from increasing the size of the zone and the size of
 responses.
 Pre-Publication is more complex: introduce the new key, approximately
 one TTL later sign the records, and approximately one TTL after that
 remove the old key.  It does however keep the zone and response sizes
 to a minimum.

Morris, et al. Informational [Page 6] RFC 7583 Key Timing October 2015

 Double-RRSIG is essentially the reverse of Pre-Publication: introduce
 the new signatures, approximately one TTL later change the key, and
 approximately one TTL after that remove the old signatures.  However,
 it has the disadvantage of the Pre-Publication method in terms of
 time taken to perform the rollover, the disadvantage of the Double-
 Signature rollover in terms of zone and response sizes, and none of
 the advantages of either.  For these reasons, it is unlikely to be
 used in any real-world situations and so will not be considered
 further in this document.

2.2. KSK Rollovers

 In the KSK case, there should be no problem with a caching validator
 not having access to a signature created with a valid KSK.  The KSK
 is only used for one signature (that over the DNSKEY RRset) and both
 the key and the signature travel together.  Instead, the issue is to
 ensure that the KSK is trusted.
 Trust in the KSK is due to either the existence of a signed and
 validated DS record in the parent zone or an explicitly configured
 trust anchor.  If the former, the rollover algorithm will need to
 involve the parent zone in the addition and removal of DS records, so
 timings are not wholly under the control of the zone manager.  If the
 latter, [RFC5011] timings will be needed to roll the keys.  (Even in
 the case where authentication is via a DS record, the zone manager
 may elect to include [RFC5011] timings in the key rolling process so
 as to cope with the possibility that the key has also been explicitly
 configured as a trust anchor.)
 It is important to note that the need to interact with the parent
 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.
 Like the ZSK case, there are three methods for rolling a KSK:
 o  Double-KSK: the new KSK is 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 this change to
    be reflected in caches, the old key is removed from the RRset.

Morris, et al. Informational [Page 7] RFC 7583 Key Timing October 2015

 o  Double-DS: the new DS record is published.  After waiting for this
    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.
 o  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.
 In essence, Double-KSK means that the new KSK is introduced first and
 used to sign the DNSKEY RRset.  The DS record is changed, and finally
 the old KSK is removed.  It limits interactions with the parent to a
 minimum but, for the duration of the rollover, the size of the DNSKEY
 RRset is increased.
 With Double-DS, the order of operations is the other way around:
 introduce the new DS, change the DNSKEY, then remove the old DS.  The
 size of the DNSKEY RRset is kept to a minimum, but two interactions
 are required with the parent.
 Finally, Double-RRset is the fastest way to roll the KSK, but 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 requires both the DNSKEY and information created
 from it (referred to as "associated data" in this section).  In the
 case of validation of an RR, the data associated with the key is the
 corresponding RRSIG.  Where there is a need to validate a chain of
 trust, the associated data is the DS record.
 During the rolling process, keys move through different states.  The
 defined states are:
 Generated   Although keys may be created immediately prior to first
             use, some implementations may find it convenient to
             create a pool of keys in one operation and draw from it
             as required.  (Note: such a pre-generated pool must be
             secured against surreptitious use.)  In the timelines
             below, before the first event, the keys are considered to
             be created but not yet used: they are said to be in the
             "Generated" state.

Morris, et al. Informational [Page 8] RFC 7583 Key Timing October 2015

 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 have been published for
             long enough to guarantee that copies of the key(s) it is
             replacing (or associated data related to that key) have
             expired from caches.
 Active      The data is starting to be used for validation.  In the
             case of a ZSK, it means that the key is now being used to
             sign RRsets and that both it and the created RRSIGs
             appear in the zone.  In the case of a KSK, it means that
             it is possible to use it to validate a DNSKEY RRset as
             both the DNSKEY and DS records are present in their
             respective zones.  Note that when this state is entered,
             it may not be possible for validating resolvers to use
             the data for validation in all cases: the zone signing
             may not have finished or the data might not have reached
             the resolver because of propagation delays and/or caching
             issues.  If this is the case, the resolver will have to
             rely on the predecessor data instead.
 Retired     The data has ceased to be used for validation.  In the
             case of a ZSK, it means that the key is no longer used to
             sign RRsets.  In the case of a KSK, it means that 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 is safe to do so, i.e., when all validating
             resolvers are able to use the new key and associated data
             to validate the zone.  However, until this happens, the
             current key and associated data must remain in their
             respective zones.
 Dead        The key and its associated data are present in their
             respective zones, but there is no longer information
             anywhere that requires their presence for use in
             validation.  Hence, 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 as a way of notifying validating resolvers that
             have configured it as a trust anchor, as used in
             [RFC5011], that it is about to be removed from the zone.
             This state is used when [RFC5011] considerations are in
             effect (see Section 3.3.4).

Morris, et al. Informational [Page 9] RFC 7583 Key Timing October 2015

3.2. ZSK Rollover Timelines

 The following sections describe the rolling of a ZSK.  They show the
 events in the lifetime of a key (referred to as "key N") and cover
 its replacement by its successor (key N+1).

3.2.1. Pre-Publication Method

 In this method, the new key is introduced into the DNSKEY RRset.
 After enough time to ensure that any cached DNSKEY RRsets contain
 both keys, the zone is signed using the new key and the old
 signatures are removed.  Finally, when all signatures created with
 the old key have expired from caches, the old key is removed.
 The following diagram shows the timeline of a Pre-Publication
 rollover.  Time increases along the horizontal scale from left to
 right and the vertical lines indicate events in the process.
 Significant times and time intervals are marked.
               |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
  1. — Time —→
         Figure 1: Timeline for a Pre-Publication ZSK Rollover
 Event 1: 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 currently
 active KSKs.  The time at which this occurs is the publication time
 (Tpub), and the key is now said to be published.  Note that the key
 is not yet used to sign records.
 Event 2: Before it can be used, the key must be published for long
 enough to guarantee that any cached version of the zone's DNSKEY
 RRset includes this key.
 This interval is the publication interval (Ipub) and, for the second
 or subsequent keys in the zone, is given by:
    Ipub = Dprp + TTLkey

Morris, et al. Informational [Page 10] RFC 7583 Key Timing October 2015

 Here, Dprp is the propagation delay -- the time taken for a change
 introduced at the master to replicate to all nameservers.  TTLkey is
 the TTL for the DNSKEY records in the zone.  The sum is therefore the
 maximum time taken for existing DNSKEY records to expire from caches,
 regardless of the nameserver from which they were retrieved.
 (The case of introducing the first ZSK into the zone is discussed in
 Section 3.3.5.)
 After a delay of Ipub, the key is said to be ready and could be used
 to sign records.  The time at which this event occurs is key N's
 ready time (Trdy), which is given by:
    Trdy(N) = Tpub(N) + Ipub
 Event 3: At some later time, the key starts being used to sign
 RRsets.  This point is the activation time (Tact) and after this, key
 N is said to be active.
    Tact(N) >= Trdy(N)
 Event 4: At some point thought must be given to its successor (key
 N+1).  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 activated.  The publication time of key N+1 depends on
 the activation time of key N:
    Tpub(N+1) <= Tact(N) + Lzsk - Ipub
 Here, Lzsk is the length of time for which a ZSK will be used (the
 ZSK lifetime).  It should be noted that in the diagrams, the actual
 key lifetime is represented; this may differ slightly from the
 intended lifetime set by key management policy.
 Event 5: While key N is still active, its successor becomes ready.
 From this time onwards, key N+1 could be used to sign the zone.
 Event 6: When key N has been in use for an interval equal to the ZSK
 lifetime, it is retired (i.e., it will never again be used to
 generate new signatures) and key N+1 activated and used to sign the
 zone.  This is the retire time of key N (Tret), and is given by:
    Tret(N) = Tact(N) + Lzsk
 It is also the activation time of the successor key N+1.  Note that
 operational considerations may cause key N to remain in use for a
 longer (or shorter) time than the lifetime set by the key management
 policy.

Morris, et al. Informational [Page 11] RFC 7583 Key Timing October 2015

 Event 7: 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 caches.  (It is possible that a validating resolver could
 have an old RRSIG record in the cache, but the old DNSKEY RRset has
 expired 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 the propagation delay, required
 to guarantee that the updated zone information has reached all slave
 servers, and TTLsig is the maximum TTL of all the RRSIG records in
 the zone created with the retiring key.
 The time at which all RRSIG records created with this key have
 expired from resolver caches is the dead time (Tdea), given by:
    Tdea(N) = Tret(N) + Iret
 ... at which point the key is said to be dead.
 Event 8: At any time after the key becomes dead, it can be removed
 from the zone's DNSKEY RRset, which must then be re-signed with the
 current KSK.  This time is the removal time (Trem), given by:
    Trem(N) >= Tdea(N)
 ... at which time the key is said to be removed.

3.2.2. Double-Signature Method

 In this rollover, a new key is introduced and used to sign the zone;
 the old key and signatures are retained.  Once all cached DNSKEY and/
 or RRSIG information contains copies of the new DNSKEY and RRSIGs
 created with it, the old DNSKEY and RRSIGs can be removed from the
 zone.
 The timeline for a Double-Signature rollover is shown below.  The
 diagram follows the convention described in Section 3.2.1.

Morris, et al. Informational [Page 12] RFC 7583 Key Timing October 2015

                        |1|           |2|        |3|   |4|
                         |             |          |     |
           Key N         |<-------Lzsk----------->|<--->|
                         |             |          |     |
                         |             |<--Iret-->|     |
                         |             |          |     |
           Key N+1       |             |<----Lzsk------- - -
                         |             |          |     |
           Key N        Tact                     Tdea  Trem
           Key N+1                    Tact
  1. — Time —→
        Figure 2: Timeline for a Double-Signature ZSK Rollover
 Event 1: Key N is added to the DNSKEY RRset and is then used to sign
 the zone; existing signatures in the zone are not removed.  The key
 is published and active: this is key N's activation time (Tact),
 after which the key is said to be active.
 Event 2: As the current key (key N) approaches the end of its actual
 lifetime (Lzsk), the successor key (key N+1) is introduced into the
 zone and starts being used to sign RRsets: neither the current key
 nor the signatures created with it are removed.  The successor key is
 now also active.
    Tact(N+1) = Tact(N) + Lzsk - Iret
 Event 3: Before key N can be withdrawn from the zone, all RRsets that
 need to be signed must have been signed by the successor key (key
 N+1) and any old RRsets that do not include the new key or new RRSIGs
 must have expired from caches.  Note that the signatures are not
 replaced: each RRset is signed by both the old and new key.
 This takes Iret, the retire interval, given by the expression:
    Iret = Dsgn + Dprp + max(TTLkey, TTLsig)
 As before, Dsgn is the delay needed to ensure that all existing
 RRsets have been signed with the new key and Dprp is the propagation
 delay, required to guarantee that the updated zone information has
 reached all slave servers.  The final term (the maximum of TTLkey and
 TTLsig) is the period to wait for key and signature data associated
 with 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.  The two may be different: although the

Morris, et al. Informational [Page 13] RFC 7583 Key Timing October 2015

 TTL of an RRSIG is equal to the TTL of the RRs in the associated
 RRset [RFC4034], the DNSKEY RRset only needs to be signed with the
 KSK.)
 At the end of this interval, key N is said to be dead.  This occurs
 at the dead time (Tdea) so:
    Tdea(N) = Tact(N+1) + Iret
 Event 4: At some later time, key N and the signatures generated with
 it can be removed from the zone.  This is the removal time (Trem),
 given by:
    Trem(N) >= Tdea(N)

3.3. KSK Rollover Timelines

 The following sections describe the rolling of a KSK.  They show the
 events in the lifetime of a key (referred to as "key N") and cover it
 replacement 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

 In this rollover, the new DNSKEY is added to the zone.  After an
 interval long enough to guarantee that any cached DNSKEY RRsets
 contain the new DNSKEY, the DS record in the parent zone is changed.
 After a further interval to allow the old DS record to expire from
 caches, the old DNSKEY is removed from the zone.
 The timeline for a Double-KSK rollover is shown below.  The diagram
 follows the convention described in Section 3.2.1.

Morris, et al. Informational [Page 14] RFC 7583 Key Timing October 2015

                     |1|       |2|   |3|      |4|
                      |         |     |        |
     Key N            |<-IpubC->|<--->|<-Dreg->|<-----Lksk--- - -
                      |         |     |        |
     Key N+1          |         |     |        |
                      |         |     |        |
     Key N           Tpub      Trdy  Tsbm     Tact
     Key N+1
  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
  1. — Time (cont.) —→
             Figure 3: Timeline for a Double-KSK Rollover
 Event 1: Key N is introduced into the zone; it is 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 is signed by these as
 well.)  This is the publication time of key N (Tpub); after this, the
 key is said to be published.
 Event 2: Before it can be used, the key must be published for long
 enough to guarantee that any validating resolver that has a copy of
 the DNSKEY RRset 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 in the child zone (IpubC)
 and is given by:
    IpubC = DprpC + TTLkey

Morris, et al. Informational [Page 15] RFC 7583 Key Timing October 2015

 ... where DprpC is the propagation delay for the child zone (the zone
 containing the KSK being rolled) and TTLkey the TTL for the DNSKEY
 RRset.  The time at which this occurs is the key N's ready time,
 Trdy, given by:
    Trdy(N) = Tpub(N) + IpubC
 Event 3: At some later time, the DS record corresponding to the new
 KSK is submitted to the parent zone for publication.  This time is
 the submission time, Tsbm:
    Tsbm(N) >= Trdy(N)
 Event 4: The DS record is published in the parent zone.  As this is
 the point at which all information for authentication -- both DNSKEY
 and DS record -- is available in the two zones, in analogy with other
 rollover methods, this is called the activation time of key N (Tact):
    Tact(N) = Tsbm(N) + Dreg
 ... where Dreg is the registration delay, the time taken after the DS
 record has been submitted to the parent zone manager for it to be
 placed in the zone.  (Parent zones are often managed by different
 entities, and this term accounts for the organizational overhead of
 transferring a record.  In practice, Dreg will not be a fixed time:
 instead, the end of Dreg will be signaled by the appearance of the DS
 record in the parent zone.)
 Event 5: While key N is active, thought needs to be given to its
 successor (key N+1).  At some time before the scheduled end of the
 KSK lifetime, the successor KSK is published in the zone.  (As
 before, this means that the DNSKEY RRset is signed by all KSKs.)
 This time is the publication time of the successor key N+1, given by:
    Tpub(N+1) <= Tact(N) + Lksk - Dreg - IpubC
 ... where Lksk is the actual lifetime of the KSK, and Dreg the
 registration delay.
 Event 6: After an interval IpubC, key N+1 becomes ready (in that all
 caches that have a copy of the DNSKEY RRset have a copy of this key).
 This time 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 corresponding to key N+1 is submitted to the parent
 zone.

Morris, et al. Informational [Page 16] RFC 7583 Key Timing October 2015

 Event 8: The successor DS record is published in the parent zone and
 the current DS record withdrawn.  Key N is said to be retired and the
 time at which this occurs is Tret(N), given by:
    Tret(N) = Tsbm(N+1) + Dreg
 Event 9: Key N must remain in the zone until any caches that contain
 a copy of the DS RRset have a copy containing the new DS record.
 This interval is the retire interval, given by:
    Iret = DprpP + TTLds
 ... where DprpP is the propagation delay in the parent zone and TTLds
 the TTL of a DS record in the parent zone.
 As the key is no longer used for anything, it is said to be dead.
 This point is the dead time (Tdea), given by:
    Tdea(N) = Tret(N) + Iret
 Event 10: At some later time, key N is removed from the zone's DNSKEY
 RRset (at the remove time Trem); 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 is published in the parent zone.
 When any caches that contain the DS RRset contain a copy of the new
 record, the KSK in the zone is changed.  After a further 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.  The diagram
 follows the convention described in Section 3.2.1.

Morris, et al. Informational [Page 17] RFC 7583 Key Timing October 2015

                   |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
  1. — Time —→
            Figure 4: Timeline for a Double-DS KSK Rollover
 Event 1: The DS RR is submitted to the parent zone for publication.
 This time is the submission time, Tsbm.
 Event 2: After the registration delay, Dreg, the DS record is
 published in the parent zone.  This is the publication time (Tpub) of
 key N, given by:
    Tpub(N) = Tsbm(N) + Dreg
 As before, in practice, Dreg will not be a fixed time.  Instead, the
 end of Dreg will be signaled by the appearance of the DS record in
 the parent zone.
 Event 3: At some later time, any cache that has 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 this reason, this time is known as the ready time,
 Trdy, and is given by:
    Trdy(N) = Tpub(N) + IpubP

Morris, et al. Informational [Page 18] RFC 7583 Key Timing October 2015

 IpubP is the publication interval of the DS record (in the parent
 zone) and is given by the expression:
    IpubP = DprpP + TTLds
 ... where DprpP is the propagation delay for the parent zone and
 TTLds the TTL assigned to DS records in that zone.
 Event 4: At some later time, the key rollover takes place 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, thought must be given to key replacement.
 The DS record for the successor key must be submitted to the parent
 zone at a time such that when the current key is withdrawn, any cache
 that contains the zone's DS records has data about the DS record of
 the successor key.  The time at which this occurs is the submission
 time of the successor key N+1, given by:
    Tsbm(N+1) <= Tact(N) + Lksk - IpubP - Dreg
 ... where 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, i.e.,
 its DS record is now in caches that contain the parent DS RRset.
 Event 8: When key N has been active for its lifetime (Lksk), it is
 replaced in the DNSKEY RRset by key N+1; the RRset is then signed
 with the new key.  At this point, as both the old and new DS records
 have been in the parent zone long enough to ensure that they are in
 caches that contain the DS RRset, the zone can be authenticated
 throughout the rollover.  A validating resolver can authenticate
 either the old or new KSK.
 This time is the retire time (Tret) of key N, given by:
    Tret(N) = Tact(N) + Lksk
 This is also the activation time of the successor key N+1.

Morris, et al. Informational [Page 19] RFC 7583 Key Timing October 2015

 Event 9: At some later time, all copies of the old DNSKEY RRset have
 expired from caches and the old DS record is no longer needed.  In
 analogy with other rollover methods, this is called the dead time,
 Tdea, and is given by:
    Tdea(N) = Tret(N) + Iret
 ... where Iret is the retire interval of the key, given by:
    Iret = DprpC + TTLkey
 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.  In analogy with other rollover methods, this is the
 removal time (Trem), given by:
    Trem(N) >= Tdea(N)

3.3.3. Double-RRset Method

 In the Double-RRset rollover, the new DNSKEY and DS records are
 published simultaneously in the appropriate zones.  Once enough time
 has elapsed for the old DNSKEY and DS RRsets to expire from caches,
 the old DNSKEY and DS records are removed from their respective
 zones.
 The timeline for this rollover is shown below.  The diagram follows
 the convention described in 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
  1. — Time —→
          Figure 5: Timeline for a Double-RRset KSK Rollover

Morris, et al. Informational [Page 20] RFC 7583 Key Timing October 2015

 Event 1: The DS and DNSKEY records have appeared in their respective
 zones and the latter has been used to sign the DNSKEY RRset.  The key
 is published and active: this is key N's activation time (Tact).
 Event 2: As the current key (key N) approaches the end of its actual
 lifetime (Lksk), the successor key (key N+1) is introduced into the
 zone and is used to sign the DNSKEY RRset.  At the same time, the
 successor DS record is 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 appears
 in the parent zone.  The DNSKEY record is already in the child zone,
 so with both the new key and its associated data now visible, this is
 the key's activation time (Tact) and the key is now said to be
 active.
    Tact(N+1) = Tpub(N+1) + Dreg
 Event 4: Before key N and its associated data can be withdrawn, all
 RRsets in the caches of validating resolvers must contain the new DS
 and/or DNSKEY.  The time at which this occurs is the dead time of key
 N (Tdea), given by:
    Tdea(N) = Tpub(N+1) + Ipub
 Ipub is the time it takes to guarantee that any prior cached
 information about the DNSKEY and the DS RRsets have expired.  For the
 DNSKEY, this is 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 has been
 submitted.  Hence:
    Ipub = max(Dreg + IpubP, IpubC)
 The parent zone's publication interval is given by:
    IpubP = DprpP + TTLds
 where DprpP is the parent zone's propagation delay and TTLds is the
 TTL of the DS record in that zone.

Morris, et al. Informational [Page 21] RFC 7583 Key Timing October 2015

 The child zone's publication interval is given by a similar equation:
    IpubC = DprpC + TTLkey
 where DprpC is the propagation delay in the child zone and TTLkey the
 TTL of a DNSKEY record.
 In analogy with other rollovers, we can also define a retire interval
 -- the interval between a key becoming active and the time at which
 its predecessor is considered dead.  In this case, Iret is given by:
    Iret = Ipub - Dreg
 In other words, the retire interval of the predecessor key is the
 greater of the publication interval of the parent, or the publication
 interval of the child minus the registration delay.
 Event 5: At some later time, the key N's DS and DNSKEY records are
 removed from their respective zones.  In analogy with other rollover
 methods, this is the removal time (Trem), given by:
    Trem(N) >= Tdea(N)

3.3.4. Interaction with Configured Trust Anchors

 Although the preceding sections have been concerned with rolling
 KSKs, where the trust anchor is a DS record in the parent zone, zone
 managers may want to take account of the possibility that some
 validating resolvers may have configured trust anchors directly.
 Rolling a configured trust anchor is dealt with in [RFC5011].  It
 requires introducing the KSK to be used as the trust anchor into the
 zone for a period of time before use and retaining it (with the
 "revoke" bit set) for some time after use.

3.3.4.1. Addition of KSK

 When the new key is introduced, the expression for the publication
 interval of the DNSKEY (IpubC) in the Double-KSK and Double-RRset
 methods is modified to:
    IpubC >= DprpC + max(Itrp, TTLkey)

Morris, et al. Informational [Page 22] RFC 7583 Key Timing October 2015

 ... where the right-hand side of the expression now includes the
 "trust point" interval.  This term is the interval required to
 guarantee that a resolver configured for the automatic update of keys
 according to [RFC5011] will accept the new key as a new trust point.
 That interval is given by:
    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 of the expression (queryInterval) represents the time
 after which all validating resolvers can be guaranteed to have
 obtained a copy of the DNSKEY RRset containing the new key.  Once
 retrieved, a validating resolver needs to wait for AddHoldDownTime.
 Providing it does not see a validly signed DNSKEY RRset without the
 new key in that period, it will treat it as a trust anchor the next
 time it retrieves the RRset, a process that can take up to another
 queryInterval (the third term).
 However, the expression for queryInterval given in [RFC5011] contains
 the DNSKEY's RRSIG expiration interval, a parameter that only the
 validating resolver can really calculate.  In practice, a modified
 query interval that depends only on TTLkey can be used:
    modifiedQueryInterval = MAX(1hr, MIN(15 days, TTLkey / 2))
 (This is obtained by taking the expression for queryInterval in
 [RFC5011] and assuming a worst case for RRsigExpirationInterval.  It
 is greater than or equal to queryInterval for all values of the
 expiration time.)  The expression above then becomes (after
 collecting terms):
    Itrp >= AddHoldDownTime + 2 * modifiedQueryInterval
 In the Double-DS method, instead of swapping the KSK RRs in a single
 step, there must now be a period of overlap.  In other words, the new
 KSK must be introduced into the zone at least:
    DprpC + max(Itrp, TTLkey)
 ... before the switch is made.

Morris, et al. Informational [Page 23] RFC 7583 Key Timing October 2015

3.3.4.2. Removal of KSK

 The timeline for the removal of the key in all methods is modified by
 introducing a new state, "revoked".  When the key reaches its dead
 time, instead of being declared "dead", it is revoked; the "revoke"
 bit is set in the published DNSKEY RR, and the DNSKEY RRset re-signed
 with the current and revoked keys.  The key is maintained in this
 state for the revoke interval, Irev, given by:
    Irev >= DprpC + modifiedQueryInterval
 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
 containing the revoked key.
 After this time, the key is dead and can be removed from the zone.

3.3.5. Introduction of First Keys

 There are no timing considerations associated with the introduction
 of the first keys into a zone other that they must be introduced and
 the zone validly signed before a chain of trust to the zone is
 created.
 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 validating resolver can obtain the record yet is not able to
 obtain the corresponding DNSKEY.  In the case of an insecure parent,
 i.e., the initial creation of a chain of trust or "security apex", it
 is not possible to guarantee this.  It is up to the operator of the
 validating resolver to wait for the new KSK to appear at all servers
 for the zone before configuring the trust anchor.

4. Standby Keys

 Although keys will usually be rolled according to some regular
 schedule, there may be occasions when an emergency 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 least one additional key
 (a standby key) in this state at all times will minimize delay.
 In the case of 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

Morris, et al. Informational [Page 24] RFC 7583 Key Timing October 2015

 possible after a key becomes active.  Either way results in one or
 more additional ZSKs in the DNSKEY RRset that can immediately be used
 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 require
 pre-publication of the signatures.  Essentially, the standby key
 would be permanently active, as it would have to be periodically used
 to renew signatures.  Zones would also permanently require two sets
 of signatures.)
 It is also possible to have a standby KSK.  The Double-KSK method
 requires that the standby KSK be included in the DNSKEY RRset;
 rolling the key then requires just the introduction of the DS record
 in the parent.  Note that the standby KSK should also be used to sign
 the DNSKEY RRset.  As the RRset and its signatures travel together,
 merely adding the KSK without using it to sign the DNSKEY RRset does
 not provide the desired time saving: for a KSK to be used in a
 rollover, the DNSKEY RRset must be signed with it, and this would
 introduce 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 (as the standby KSK and
 associated DS record would both be published at the same time in
 their respective zones).
 Finally, in the Double-DS method of rolling a KSK, it is not a
 standby key that is present, it is 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

 The preceding sections have implicitly assumed that all keys and
 signatures are created using a single algorithm.  However,
 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 in the case of an algorithm rollover -- where the algorithms
 used to create the signatures are being changed -- there is no
 relationship between the keys of different algorithms.  This means
 that they can be rolled independently of one another.  In other

Morris, et al. Informational [Page 25] RFC 7583 Key Timing October 2015

 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.

6. Summary

 For ZSKs, the Pre-Publication method 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, the Double-RRset method is the most efficient 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], in
 many cases, the rollover time will be determined by the times defined
 by RFC 5011.  It should be emphasized 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 key rollover is significantly
 simplified by the introduction of standby keys as standard practice
 during all types of rollovers.

7. Security Considerations

 This document does not introduce any new security issues beyond those
 already discussed 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>.

Morris, et al. Informational [Page 26] RFC 7583 Key Timing October 2015

 [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>.

Morris, et al. Informational [Page 27] RFC 7583 Key Timing October 2015

Appendix A. List of Symbols

 The document defines a number of symbols, all of which are listed
 here.  All are of the form:
    <TYPE><id><ZONE>
 where:
 <TYPE> is an uppercase character indicating what type the symbol is.
 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 whereas I values are intervals between two events, a "D"
 interval (delay) is a feature of the process, probably outside
 control of the zone manager, and an "L" interval (lifetime) is chosen
 by the zone manager and is a feature of policy.
 <id> is lowercase and defines what object or event the variable is
 related to, e.g.,
 act       activation
 pub       publication
 ret       retire
 <ZONE> is an optional uppercase letter that distinguishes between the
 same variable applied to different zones and is one of:
 C         child
 P         parent
 Within the rollover descriptions, times may have a number in
 parentheses affixed to their end indicating the instance of the key
 to which they apply, e.g., Tact(N) is the activation time of key N,
 Tpub(N+1) the publication time of key N+1 etc.

Morris, et al. Informational [Page 28] RFC 7583 Key Timing October 2015

 The list of variables used in the text given 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.

Morris, et al. Informational [Page 29] RFC 7583 Key Timing October 2015

 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.

Morris, et al. Informational [Page 30] RFC 7583 Key Timing October 2015

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

Morris, et al. Informational [Page 31]

/data/webs/external/dokuwiki/data/pages/rfc/rfc7583.txt · Last modified: 2015/10/21 20:30 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki