draft-ietf-dnsop-dnssec-key-timing-01.txt   draft-ietf-dnsop-dnssec-key-timing-02.txt 
Internet Engineering Task Force S. Morris Internet Engineering Task Force S. Morris
Internet-Draft ISC Internet-Draft ISC
Intended status: Informational J. Ihren Intended status: Informational J. Ihren
Expires: April 28, 2011 Netnod Expires: September 11, 2011 Netnod
J. Dickinson J. Dickinson
Sinodun Sinodun
October 25, 2010 March 10, 2011
DNSSEC Key Timing Considerations DNSSEC Key Timing Considerations
draft-ietf-dnsop-dnssec-key-timing-01.txt draft-ietf-dnsop-dnssec-key-timing-02.txt
Abstract Abstract
This document describes the issues surrounding the timing of events This document describes the issues surrounding the timing of events
in the rolling of a key in a DNSSEC-secured zone. It presents in the rolling of a key in a DNSSEC-secured zone. It presents
timelines for the key rollover and explicitly identifies the timelines for the key rollover and explicitly identifies the
relationships between the various parameters affecting the process. relationships between the various parameters affecting the process.
Status of this Memo Status of this Memo
skipping to change at page 1, line 36 skipping to change at page 1, line 36
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 28, 2011. This Internet-Draft will expire on September 11, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Key Rolling Considerations . . . . . . . . . . . . . . . . 3 1.1. Key Rolling Considerations . . . . . . . . . . . . . . . . 3
1.2. Types of Keys . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Types of Keys . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
1.4. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Rollover Methods . . . . . . . . . . . . . . . . . . . . . . . 4 2. Rollover Methods . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. ZSK Rollovers . . . . . . . . . . . . . . . . . . . . . . 4 2.1. ZSK Rollovers . . . . . . . . . . . . . . . . . . . . . . 4
2.2. KSK Rollovers . . . . . . . . . . . . . . . . . . . . . . 6 2.2. KSK Rollovers . . . . . . . . . . . . . . . . . . . . . . 6
2.3. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.3. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 7
3. Key Rollover Timelines . . . . . . . . . . . . . . . . . . . . 8 3. Key Rollover Timelines . . . . . . . . . . . . . . . . . . . . 7
3.1. Key States . . . . . . . . . . . . . . . . . . . . . . . . 8 3.1. Key States . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2. Zone-Signing Key Timelines . . . . . . . . . . . . . . . . 9 3.2. Zone-Signing Key Timelines . . . . . . . . . . . . . . . . 9
3.2.1. Pre-Publication Method . . . . . . . . . . . . . . . . 9 3.2.1. Pre-Publication Method . . . . . . . . . . . . . . . . 9
3.2.2. Double-Signature Method . . . . . . . . . . . . . . . 13 3.2.2. Double-Signature Method . . . . . . . . . . . . . . . 11
3.2.3. Double-RRSIG Method . . . . . . . . . . . . . . . . . 14 3.2.3. Double-RRSIG Method . . . . . . . . . . . . . . . . . 13
3.3. Key-Signing Key Rollover Timelines . . . . . . . . . . . . 17 3.3. Key-Signing Key Rollover Timelines . . . . . . . . . . . . 15
3.3.1. Double-Signature Method . . . . . . . . . . . . . . . 17 3.3.1. Double-Signature Method . . . . . . . . . . . . . . . 15
3.3.2. Double-DS Method . . . . . . . . . . . . . . . . . . . 20 3.3.2. Double-DS Method . . . . . . . . . . . . . . . . . . . 18
3.3.3. Double-RRset Method . . . . . . . . . . . . . . . . . 22 3.3.3. Double-RRset Method . . . . . . . . . . . . . . . . . 21
3.3.4. Interaction with Configured Trust Anchors . . . . . . 25 3.3.4. Interaction with Configured Trust Anchors . . . . . . 23
3.3.4.1. Addition of KSK . . . . . . . . . . . . . . . . . 25 3.3.4.1. Addition of KSK . . . . . . . . . . . . . . . . . 23
3.3.4.2. Removal of KSK . . . . . . . . . . . . . . . . . . 25 3.3.4.2. Removal of KSK . . . . . . . . . . . . . . . . . . 24
3.3.5. Introduction of First KSK . . . . . . . . . . . . . . 26 3.3.5. Introduction of First KSK . . . . . . . . . . . . . . 24
4. Standby Keys . . . . . . . . . . . . . . . . . . . . . . . . . 27 4. Standby Keys . . . . . . . . . . . . . . . . . . . . . . . . . 24
5. Algorithm Considerations . . . . . . . . . . . . . . . . . . . 28 5. Algorithm Considerations . . . . . . . . . . . . . . . . . . . 25
6. Limitation of Scope . . . . . . . . . . . . . . . . . . . . . 28 6. Limitation of Scope . . . . . . . . . . . . . . . . . . . . . 26
7. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 7. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
9. Security Considerations . . . . . . . . . . . . . . . . . . . 29 9. Security Considerations . . . . . . . . . . . . . . . . . . . 27
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27
11. Change History . . . . . . . . . . . . . . . . . . . . . . . . 29 11. Change History (To be removed on publication) . . . . . . . . 27
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28
12.1. Normative References . . . . . . . . . . . . . . . . . . . 30 12.1. Normative References . . . . . . . . . . . . . . . . . . . 28
12.2. Informative References . . . . . . . . . . . . . . . . . . 31 12.2. Informative References . . . . . . . . . . . . . . . . . . 29
Appendix A. List of Symbols . . . . . . . . . . . . . . . . . . . 31 Appendix A. List of Symbols . . . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 32
1. Introduction 1. Introduction
1.1. Key Rolling Considerations 1.1. Key Rolling Considerations
When a zone is secured with DNSSEC, the zone manager must be prepared When a zone is secured with DNSSEC, the zone manager must be prepared
to replace ("roll") the keys used in the signing process. The 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 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 existing keys, or it may be due to a management policy that demands
periodic key replacement for security or operational reasons. In periodic key replacement for security or operational reasons. In
order to implement a key rollover, the keys need to be introduced order to implement a key rollover, the keys need to be introduced
into and removed from the zone at the appropriate times. into and removed from the zone at the appropriate times.
Considerations that must be taken into account are: Considerations that must be taken into account are:
o DNSKEY records and associated information (such as RRSIG records o DNSKEY records and associated information (such as the associated
created with the key or the associated DS records) are not only DS records or RRSIG records created with the key) are not only
held at the authoritative nameserver, they are also cached at held at the authoritative nameserver, they are also cached by
client resolvers. The data on these systems can be interlinked, resolvers. The data on these systems can be interlinked, e.g. a
e.g. a validating resolver may try to validate a signature validating resolver may try to validate a signature retrieved from
retrieved from a cache with a key obtained separately. a cache with a key obtained separately.
o A query for the key RRset returns all DNSKEY records in the zone.
As there is limited space in the UDP packet (even with EDNS0
support), dead key records must be periodically removed. (For the
same reason, the number of stand-by keys in the zone should be
restricted to the minimum required to support the key management
policy.)
o Zone "boot-strapping" events, where a zone is signed for the first o Zone "boot-strapping" events, where a zone is signed for the first
time, can be common in configurations where a large number of time, can be common in configurations where a large number of
zones are being served. Procedures should be able to cope with zones are being served. Procedures should be able to cope with
the introduction of keys into the zone for the first time as well 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 as "steady-state", where the records are being replaced as part of
normal zone maintenance. normal zone maintenance.
o To allow for an emergency re-signing of the zone as soon as o To allow for an emergency re-signing of the zone as soon as
possible after a key compromise has been detected, stand-by keys possible after a key compromise has been detected, standby keys
(additional keys over and above those used to sign the zone) need (additional keys over and above those used to sign the zone) need
to be present. 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 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 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 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 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 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 at no time during the rollover process does any part of the zone ever
go bogus). In other words, although key management logic enforces go bogus). In other words, although key management logic enforces
policy, it may not enforce it strictly. policy, it may not enforce it strictly.
1.2. Types of Keys 1.2. Types of Keys
Although DNSSEC validation treats all keys equally, [RFC4033] Although DNSSEC validation treats all keys equally, [RFC4033]
recognises the broad classification of zone-signing keys (ZSK) and recognises the broad classification of zone-signing keys (ZSK) and
key-signing keys (KSK). A ZSK is used to authenticate information key-signing keys (KSK). A ZSK is used to authenticate information
within the zone; a KSK is used to authenticate the key set in the within the zone; a KSK is used to authenticate the zone's DNSKEY
zone. The main implication for this distinction concerns the RRset. The main implication for this distinction concerns the
consistency of information during a rollover. consistency of information during a rollover.
During operation, a validating resolver must use separate pieces of During operation, a validating resolver must use separate pieces of
information to perform an authentication. At the time of information to perform an authentication. At the time of
authentication, each piece of information may be in the validating authentication, each piece of information may be in its cache or may
resolver's cache or may need to be retrieved from the authoritative need to be retrieved from the authoritative server. The rollover
server. The rollover process needs to happen in such a way that at process needs to happen in such a way that at all times during the
all times through the rollover the information is consistent. With a rollover the information is consistent. With a ZSK, the information
ZSK, the information is the RRSIG (plus associated RRset) and the is the RRSIG (plus associated RRset) and the DNSKEY. These are both
DNSKEY. These are both obtained from the same zone. In the case of obtained from the same zone. In the case of the KSK, the information
the KSK, the information is the DNSKEY and DS RRset with the latter is the DNSKEY and DS RRset with the latter being obtained from a
being obtained from a different zone. different zone.
There are similarities in the rolling of ZSKs and KSKs: replace the Although there are similarities in the algorithms to roll ZSKs and
RRSIG (plus RR) by the DNSKEY and replace the DNSKEY by the DS, and KSKs, there are a number of differences. For this reason, the two
the ZSK rolling algorithms are virtually the same as the KSK types of rollovers are described separately. It is also possible to
algorithms. However, there are a number of differences, and for this use a single key as both the ZSK and KSK. However, the rolling of
reason the two types of rollovers are described separately in this this type of key is not treated in this document.
document.
1.3. Terminology 1.3. Terminology
The terminology used in this document is as defined in [RFC4033] and The terminology used in this document is as defined in [RFC4033] and
[RFC5011]. [RFC5011].
A large number of symbols are used to identify times, intervals, etc. A number of symbols are used to identify times, intervals, etc. All
All are listed in Appendix A. are listed in Appendix A.
1.4. Requirements Language
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].
2. Rollover Methods 2. Rollover Methods
2.1. ZSK Rollovers 2.1. ZSK Rollovers
A ZSK can be rolled in one of three ways: A ZSK can be rolled in one of three ways:
o Pre-Publication. Described in [RFC4641], the new key is o Pre-Publication: described in [RFC4641], the new key is introduced
introduced into the DNSKEY RRset, leaving the existing keys and into the DNSKEY RRset which is then re-signed. This state of
signatures in place. This state of affairs remains in place for affairs remains in place for long enough to ensure that any cached
long enough to ensure that any DNSKEY RRsets cached in client DNSKEY RRsets contain both keys. At that point signatures created
validating resolvers contain both keys. At that point signatures with the old key can be replaced by those created with the new
created with the old key can be replaced by those created with the key, and the old signatures removed. During the re-signing
new key, and the old signatures removed. During the re-signing
process (which may or may not be atomic depending on how the zone 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 is managed), it doesn't matter which key an RRSIG record retrieved
by a client was created with; clients with a cached copy of the by a resolver was created with; cached copies of the DNSKEY RRset
DNSKEY RRset will have a copy containing both the old and new will contain both the old and new keys.
keys.
Once the zone contains only signatures created with the new key, Once the zone contains only signatures created with the new key,
there is an interval during which RRSIG records created with the there is an interval during which RRSIG records created with the
old key expire from client caches. After this, there will be no old key expire from caches. After this, there will be no
signatures anywhere that were created using the old key, and it signatures anywhere that were created using the old key, and it
can can be removed from the DNSKEY RRset. can can be removed from the DNSKEY RRset.
o Double-Signature. Also mentioned in [RFC4641], this involves o Double-Signature: also mentioned in [RFC4641], this involves
introducing the new key into the zone and using it to create introducing the new key into the zone and using it to create
additional RRSIG records; the old key and existing RRSIG records additional RRSIG records; the old key and existing RRSIG records
are retained. During the period in which the zone is being signed are retained. During the period in which the zone is being signed
(again, the signing process may not be atomic), client resolvers (again, the signing process may not be atomic), validating
are always able to validate RRSIGs: any combination of old and new resolvers are always able to validate RRSIGs: any combination of
DNSKEY RRset and RRSIG allows at least one signature to be old and new DNSKEY RRset and RRSIG allows at least one signature
validated. to be validated.
Once the signing process is complete and enough time has elapsed Once the signing process is complete and enough time has elapsed
to allow all old information to expire from caches, the old key to allow all old information to expire from caches, the old key
and signatures can be removed from the zone. As before, during and signatures can be removed from the zone. As before, during
this period any combination of DNSKEY RRset and RRSIG will allow this period any combination of DNSKEY RRset and RRSIG will allow
validation of at least one signature. validation of at least one signature.
o Double-RRSIG. Strictly speaking, the use of the term "Double- o Double-RRSIG: strictly speaking, the use of the term "Double-
Signature" above is a misnomer as the method is not only 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 signature, it is also double key as well. A true Double-Signature
method (here called the Double-RRSIG method) involves introducing method (here called the Double-RRSIG method) involves introducing
new signatures in the zone (while still retaining the old ones) new signatures in the zone (while still retaining the old ones)
but not the new key. but not introducing the new key.
Once the signing process is complete and enough time has elapsed Once the signing process is complete and enough time has elapsed
to ensure that all caches that may contain an RR and associated to ensure that all caches that may contain an RR and associated
RRSIG to have a copy of both signatures, the ZSK is changed. RRSIG have a copy of both signatures, the key is changed. After a
After a further interval during which the old DNSKEY RRset expires further interval during which the old DNSKEY RRset expires from
from caches, the old signatures are removed from the zone. caches, the old signatures are removed from the zone.
Of three methods, Double-Signature is the simplest conceptually - Of three methods, Double-Signature is conceptually the simplest -
introduce the new key and new signatures, then approximately one TTL introduce the new key and new signatures, then approximately one TTL
later remove the old key and signatures. The drawback of this method later remove the old key and old signatures. Pre-Publication is more
is a noticeable increase in the size of the DNSSEC data, affecting complex - introduce the new key, approximately one TTL later sign the
both the overall size of the zone and the size of the responses. records, and approximately one TTL after that remove the old key.
Double-RRSIG is essentially the reverse of Pre-Publication -
Pre-Publication is more complex - introduce the new key, introduce the new signatures, approximately one TTL later change the
approximately one TTL later sign the records, and approximately one key, and approximately one TTL after that remove the old signatures.
TTL after that remove the old key. However, the amount of DNSSEC
data is kept to a minimum which reduces the impact on performance.
The Double-RRSIG combines the increase in data volume of the Double-
Signature method with the complexity of Pre-Publication. It has few
(if any) advantages and a description is only included here for
completeness.
2.2. KSK Rollovers 2.2. KSK Rollovers
In the ZSK case the issue for the validating resolver is to ensure For ZSKs, the issue for the validating resolver is to ensure that it
that it has access to the ZSK that corresponds to a particular has access to the ZSK that corresponds to a particular signature. In
signature. In the KSK case this can never be a problem as the KSK is the KSK case this can never be a problem as the KSK is only used for
only used for one signature (that over the DNSKEY RRset) and both the one signature (that over the DNSKEY RRset) and both the key the
key the signature travel together. Instead, the issue is to ensure signature travel together. Instead, the issue is to ensure that the
that the KSK is trusted. KSK is trusted.
Trust in the KSK is either due to the existence of an explicitly Trust in the KSK is either due to the existence of a DS record in the
configured trust anchor in the validating resolver or DS record in parent zone (which is itself trusted) or an explicitly configured
the parent zone (which is itself trusted). If the former, [RFC5011] trust anchor. If the former, the rollover algorithm will need to
timings will be needed to roll the keys. If the latter, the rollover involve the parent zone in the addition and removal of DS records, so
algorithm will need to involve the parent zone in the addition and timings are not wholly under the control of the zone manager. If the
removal of DS records, so timings are not wholly under the control of latter, [RFC5011] timings will be needed to roll the keys. (Even in
the zone manager. (The zone manager may elect to include [RFC5011] the case where authentication is via a DS record, the zone manager
timings in the key rolling process so as to cope with the possibility may elect to include [RFC5011] timings in the key rolling process so
that the key has also been explicitly configured as a trust anchor.) as to cope with the possibility that the key has also been explicitly
configured as a trust anchor.)
It is important to note that this does not preclude the development It is important to note that this does not preclude the development
of key rollover logic; in accordance with the goal of the rollover 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 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 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 of waiting for the parent to respond in addition to any delay the key
rollover logic requires. Although this introduces additional delays, rollover logic requires. Although this introduces additional delays,
even with a parent that is less than ideally responsive the only even with a parent that is less than ideally responsive the only
effect will be a slowdown in the rollover state transitions. This effect will be a slowdown in the rollover state transitions. This
may cause a policy violation, but will not cause any operational may cause a policy violation, but will not cause any operational
problems. problems.
Like the ZSK case, there are three methods for rolling a KSK: Like the ZSK case, there are three methods for rolling a KSK:
o Double-Signature: Also known as Double-DNSKEY, the new KSK is o Double-Signature: also known as Double-DNSKEY, the new KSK is
added to the DNSKEY RRset which is then signed with both the old 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 and new key. After waiting for the old RRset to expire from
caches, the DS record in the parent zone is changed. After caches, the DS record in the parent zone is changed. After
waiting a further interval for this change to be reflected in waiting a further interval for this change to be reflected in
caches, the old key is removed from the RRset. (The name "Double- caches, the old key is removed from the RRset. (The name "Double-
Signature" is used because, like the ZSK method of the same name, Signature" is used because, like the ZSK method of the same name,
the new key is introduced and immediately used for signing.) the new key is introduced and immediately used for signing.)
o Double-DS: the new DS record is published. After waiting for this o Double-DS: the new DS record is published. After waiting for this
change to propagate into the caches of all validating resolvers, change to propagate into caches, the KSK is changed. After a
the KSK is changed. After a further interval during which the old further interval during which the old DNSKEY RRset expires from
DNSKEY RRset expires from caches, the old DS record is removed. caches, the old DS record is removed.
o Double-RRset: the new KSK is added to the DNSKEY RRset which is 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 then signed with both the old and new key, and the new DS record
added to the parent zone. After waiting a suitable interval for added to the parent zone. After waiting a suitable interval for
the old DS and DNSKEY RRsets to expire from validating resolver the old DS and DNSKEY RRsets to expire from caches, the old DNSKEY
caches, the old DNSKEY and DS record are removed. and DS record are removed.
In essence, "Double-Signature" means that the new KSK is introduced In essence, "Double-Signature" means that the new KSK is introduced
first and used to sign the DNSKEY RRset. The DS record is changed, first and used to sign the DNSKEY RRset. The DS record is changed,
and finally the old KSK removed. With "Double-DS" it is the other and finally the old KSK removed. With "Double-DS" it is the other
way around. Finally, Double-RRset does both updates more or less in way around. Finally, Double-RRset does both updates more or less in
parallel. parallel.
The strategies have different advantages and disadvantages:
o Double-Signature minimizes the number of interactions with the
parent zone. However, for the period of the rollover the DNSKEY
RRset is signed with two KSKs, so increasing the size of the
response to a query for this data.
o Double-DS keeps the size of the DNSKEY RRset to a minimum, but
does require the additional administrative overhead of two
interactions with the parent to roll a KSK. (Although this can be
mitigated if the parent has the ability for a child zone to
schedule the withdrawal of the old key at the same time as the
introduction of the new one.)
o Finally, Double-RRset allows the rollover to be done in roughly
half the time of the other two methods; it also supports policies
that require a period of running with old and new KSKs
simultaneously. However, it does have the disadvantages of both
the other two methods - it requires two signatures during the
period of the rollover and two interactions with the parent.
2.3. Summary 2.3. Summary
The methods can be summarised as follows: The methods can be summarised as follows:
+------------------+------------------+-----------------------------+ +------------------+------------------+-----------------------------+
| ZSK Method | KSK Method | Description | | ZSK Method | KSK Method | Description |
+------------------+------------------+-----------------------------+ +------------------+------------------+-----------------------------+
| Pre-Publication | (not applicable) | Publish the DNSKEY before | | Pre-Publication | (not applicable) | Publish the DNSKEY before |
| | | the RRSIG. | | | | the RRSIG. |
| Double-Signature | Double-Signature | Publish the DNSKEY and | | Double-Signature | Double-Signature | Publish the DNSKEY and |
| | | RRSIG at same time. (For a | | | | RRSIG at same time. (For a |
| | | KSK, this happens before | | | | KSK, this happens before |
| | | the DS is published.) | | | | the DS is published.) |
| Double-RRSIG | (not applicable) | Publish RRSIG before the | | Double-RRSIG | (not applicable) | Publish RRSIG before the |
| | | DNSKEY. | | | | DNSKEY. |
| (not applicable) | Double-DS | Publish DS before the | | (not applicable) | Double-DS | Publish DS before the |
| | | DNSKEY. | | | | DNSKEY. |
| (not applicable) | Double-RRset | Publish DNSKEY and DS in | | (not applicable) | Double-RRset | Publish DNSKEY and DS in |
| | | parallel. | | | | parallel. |
+------------------+------------------+-----------------------------+ +------------------+------------------+-----------------------------+
Table 1 Table 1
3. Key Rollover Timelines 3. Key Rollover Timelines
3.1. Key States 3.1. Key States
During the rolling process, a key moves through different states. During the rolling process, a key moves through different states.
These states are: The defined states are:
Generated The key has been created, but has not yet been used for Generated The key has been created, but has not yet been used for
anything. anything.
Published The DNSKEY record - or information associated with it - Published The DNSKEY record - or information associated with it -
is published in the zone, but predecessors of the key (or is published in the zone, but predecessors of the key (or
associated information) may be held in resolver caches. associated information) may be held in caches.
The idea of "associated information" is used in rollover The idea of "associated information" is used in rollover
methods where RRSIG or DS records are published first and methods where RRSIG or DS records are published first and
the DNSKEY is changed in an atomic operation. It allows the DNSKEY is changed in an atomic operation. It allows
the rollover still to be thought of as moving through a the rollover still to be thought of as moving through a
set of states. In the rest of this section, the term set of states. In the rest of this section, the term
"key" should be taken to mean "key or associated "key data" should be taken to mean "key or associated
information". information".
Ready The key has been published for long enough to guarantee Ready The new key data has been published for long enough to
that all caches that might contain a copy of the key guarantee that any previous versions of it have expired
RRset have a copy that includes this key. from caches.
Active The key is in the zone and has started to be used to sign Active The key has started to be used to sign RRsets. Note that
RRsets or authenticate the DNSKEY RRset. Note that when when this state is entered, it may not be possible for
this state is entered, it might not be possible for every validating resolvers to use the key for validation in all
validating resolver to use the key for validation: the cases: the zone signing may not have finished, or the
zone signing may not have finished, or the data might not data might not have reached the resolver because of
have reached the resolver because of propagation delays propagation delays and/or caching issues. If this is the
and/or caching issues. If this is the case, the resolver case, the resolver will have to rely on the key's
will have to rely on the key's predecessor instead. predecessor instead.
Retired The key is in the zone but a successor key has become Retired The key is in the zone but a successor key has become
active. As there may still be information in caches that active. As there may still be information in caches that
that require use of the key, it is being retained until that require use of the key, it is being retained until
this information expires. this information expires.
Dead The key is published in the zone but there is no Dead The key is published in the zone but there is no longer
information anywhere that requires its presence. information anywhere that requires its presence. Hence
the key can be removed from the zone at any time.
Removed The key has been removed from the zone. Removed The key has been removed from the zone.
There is one additional state, used where [RFC5011] considerations There is one additional state, used where [RFC5011] considerations
are in effect (see Section 3.3.4): are in effect (see Section 3.3.4):
Revoked The key is published for a period with the "revoke" bit Revoked The key is published for a period with the "revoke" bit
set as a way of notifying validating resolvers that have set as a way of notifying validating resolvers that have
configured it as a trust anchor that it is about to be configured it as an [RFC5011] trust anchor that it is
removed from the zone. about to be removed from the zone.
3.2. Zone-Signing Key Timelines 3.2. Zone-Signing Key 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 3.2.1. Pre-Publication Method
The following diagram shows the time line of a particular ZSK and its The following diagram shows the timeline of a Pre-Publication
replacement by its successor using the Pre-Publication method. Time rollover. Time increases along the horizontal scale from left to
increases along the horizontal scale from left to right and the right and the vertical lines indicate events in the process.
vertical lines indicate events in the life of the key. The events Significant times and time intervals are marked.
are numbered; significant times and time intervals are marked.
|1| |2| |3| |4| |5| |6| |7| |8| |9| |1| |2| |3| |4| |5| |6| |7| |8| |9|
| | | | | | | | | | | | | | | | | |
Key N | |<-Ipub->|<--->|<-------Lzsk----->|<-Iret->|<--->| Key N | |<-Ipub->|<--->|<-------Lzsk----->|<-Iret->|<--->|
| | | | | | | | | | | | | | | | | |
Key N+1 | | | | |<-Ipub->|<->|<---Lzsk-- - - Key N+1 | | | | |<-Ipub->|<->|<---Lzsk-- - -
| | | | | | | | | | | | | | | | | |
Tgen Tpub Trdy Tact TpubS Tret Tdea Trem Tgen Tpub Trdy Tact TpubS Tret Tdea Trem
---- Time ----> ---- Time ---->
Figure 1: Timeline for a Pre-Publication ZSK rollover. Figure 1: Timeline for a Pre-Publication ZSK rollover.
Event 1: key N is generated at the generate time (Tgen). Although Event 1: key N is generated at the generate time (Tgen). Although
there is no reason why the key cannot be generated immediately prior there is no reason why the key cannot be generated immediately prior
to publication in the zone (Event 2), some implementations may find to its publication in the zone (Event 2), some implementations may
it convenient to create a pool of keys in one operation and draw from find it convenient to create a pool of keys in one operation and draw
that pool as required. For this reason, it is shown as a separate from that pool as required. For this reason, it is shown as a
event. Keys that are available for use but not published are said to separate event. Keys that are available for use but not published
be generated. are said to be generated.
Event 2: key N's DNSKEY record is put into the zone, i.e. it is added 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- 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 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 the time (Tpub), and the key is now said to be published. Note that the
key is not yet used to sign records. key is not yet used to sign records.
Event 3: before it can be used, the key must be published for long 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 enough to guarantee that any cached version of the zone's DNSKEY
RRset from the zone in its cache will have a copy of the RRset that RRset includes this key.
includes this key: in other words, that any prior cached information
about the DNSKEY RRset has expired.
This interval is the publication interval (Ipub) and, for the second This interval is the publication interval (Ipub) and, for the second
or subsequent keys in the zone, is given by: or subsequent keys in the zone, is given by:
Ipub = Dprp + TTLkey Ipub = Dprp + TTLkey
Here, Dprp is the propagation delay - the time taken for any change Here, Dprp is the propagation delay - the time taken in the worst-
introduced at the master to replicate to all slave servers - which case situation for a change introduced at the master to replicate to
depends on the depth of the master-slave hierarchy. TTLkey is the all slave servers - which depends on the depth of the master-slave
time-to-live (TTL) for the DNSKEY records in the zone. The sum is hierarchy. TTLkey is the time-to-live (TTL) for the DNSKEY records
therefore the time taken for existing DNSKEY records to expire from in the zone. The sum is therefore the maximum time taken for
the caches of downstream validating resolvers, regardless of the existing DNSKEY records to expire from caches, regardless of the
nameserver from which they were retrieved. nameserver from which they were retrieved.
In the case of the first key in the zone, Ipub is slightly different (The case of introducing the first ZSK into the zone is discussed in
because it is not information about a DNSKEY RRset that may be Section 3.3.5.)
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] 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 could be used 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 the key's to sign records. The time at which this event occurs is the key's
ready time (Trdy), which is given by: ready time (Trdy), which is given by:
Trdy = Tpub + Ipub Trdy = Tpub + Ipub
Event 4: at some later time, the key starts being used to sign Event 4: at some later time, the key starts being used to sign
RRsets. This point is the active time (Tact) and after this, the key RRsets. This point is the activation time (Tact) and after this, the
is said to be active. key is said to be active.
Event 5: while this key is active, thought must be given to its Event 5: at some point thought must be given to its successor (key
successor (key N+1). As with the introduction of the currently N+1). As with the introduction of the currently active key into the
active key into the zone, the successor key will need to be published zone, the successor key will need to be published at least Ipub
at least Ipub before it is used. Denoting the publication time of before it is activated. Denoting the publication time of the
the successor key by TpubS, then: successor key by TpubS, then:
TpubS <= Tact + Lzsk - Ipub TpubS <= Tact + Lzsk - Ipub
Here, Lzsk is the length of time for which a ZSK will be used (the 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 ZSK lifetime). It should be noted that unlike the publication
interval, Lzsk is not determined by timing logic, but by key interval, Lzsk is not determined by timing logic, but by key
management policy. Lzsk will be set by the operator according to management policy. Lzsk will be set by the operator according to
their assessment of the risks posed by continuing to use a key and their assessment of the risks posed by continuing to use a key and
the risks associated with key rollover. However, operational the risks associated with key rollover. However, operational
considerations may mean a key is active for slightly more or less considerations may mean a key is active for slightly more or less
than Lzsk. than Lzsk.
Event 6: while the key N is still active, its successor becomes Event 6: while key N is still active, its successor becomes ready.
ready. From this time onwards, it could be used to sign the zone. From this time onwards, key N+1 could be used to sign the zone.
Event 7: at some point the decision is made to start signing the zone Event 7: When key N has been in use for an interval equal to the the
using the successor key. This will be when the current key has been ZSK lifetime, it is retired (i.e. it will never again be used to
in use for an interval equal to the ZSK lifetime, hence: 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 = Tact + Lzsk Tret = Tact + Lzsk
This point in time is the retire time (Tret) of key N; after this the It is also the activation time of the successor key (TactS). Note
key is said to be retired. (This time is also the point at which the that operational considerations may cause key N to remain in use for
successor key becomes active.) longer than Lzsk; if so, the retirement actually occurs when the
successor key is made active.
Event 8: the retired key needs to be retained in the zone whilst any 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 RRSIG records created using this key are still published in the zone
or held in resolver caches. (It is possible that a resolver could or held in caches. (It is possible that a validating resolver could
have an unexpired RRSIG record and an expired DNSKEY RRset in the 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 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 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 key is no longer used to sign records, it should be retained in
the zone for at least the retire interval (Iret) given by: the zone for at least the retire interval (Iret) given by:
Iret = Dsgn + Dprp + TTLsig Iret = Dsgn + Dprp + TTLsig
Dsgn is the delay needed to ensure that all existing RRsets have been 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 re-signed with the new key. Dprp is (as described above) the
propagation delay, required to guarantee that the updated zone propagation delay, required to guarantee that the updated zone
information has reached all slave servers, and TTLsig is the TTL of information has reached all slave servers, and TTLsig is the maximum
the RRSIG records. TTL of all the RRSIG records in the zone.
(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 validating resolver. 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 have The time at which all RRSIG records created with this key have
expired from resolver caches is the dead time (Tdea), given by: expired from resolver caches is the dead time (Tdea), given by:
Tdea = Tret + Iret Tdea = Tret + Iret
...at which point the key is said to be dead. ...at which point the key is said to be dead.
Event 9: at any time after the key becomes dead, it can be removed 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- from the zone and the DNSKEY RRset re-signed with the current key-
signing key. This time is the removal time (Trem), given by: signing key. This time is the removal time (Trem), given by:
Trem >= Tdea Trem >= Tdea
...at which time the key is said to be removed. ...at which time the key is said to be removed.
3.2.2. Double-Signature Method 3.2.2. Double-Signature Method
In the Double-Signature method, both the new key and signatures The timeline for a double-signature rollover is shown below. The
created using it are introduced at the same time. After a period diagram follows the convention described in Section 3.2.1
during which this information propagates to validating resolver |1| |2| |3| |4| |5|
caches, the old key and signature are removed. The time line for the | | | | |
method is shown below: Key N | |<----Lzsk--->|<---Iret--->| |
| | | | |
|1| |2| |3| |4| |5| |6| Key N+1 | | |<-----Lzsk------- - -
| | | | | | | | | | |
Key N | |<-------Lzsk------>|<-----Iret----->| | Tgen Tact Tret Tdea Trem
| | | | | |
Key N+1 | | | |<----------Lzsk------- - -
| | | | | |
Tgen Tact Tret Tdea Trem
---- Time ----> ---- Time ---->
Figure 2: Timeline for a Double-Signature ZSK rollover. Figure 2: Timeline for a Double-Signature ZSK rollover.
Event 1: key N is generated at the generate time (Tgen). Although Event 1: key N is generated at the generate time (Tgen). Although
there is no reason why the key cannot be generated immediately prior there is no reason why the key cannot be generated immediately prior
to publication in the zone (Event 2), some implementations may find to its publication in the zone (Event 2), some implementations may
it convenient to create a pool of keys in one operation and draw from find it convenient to create a pool of keys in one operation and draw
that pool as required. For this reason, it is shown as a separate from that pool as required. For this reason, it is shown as a
event. Keys that are available for use but not published are said to separate event. Keys that are available for use but not published
be generated. are said to be generated.
Event 2: key N is added to the DNSKEY RRset and is immediately used
to sign the zone; existing signatures in the zone are not removed.
This is the active time (Tact) and the key is said to be active.
Event 3: at some time later, the predecessor key (key N-1) and its Event 2: key N is added to the DNSKEY RRset and is then used to sign
signatures can be withdrawn from the zone. (The timing of key the zone; existing signatures in the zone are not removed. This is
removal is discussed further in the description of event 5.) the activation time (Tact), after which the key is said to be active.
Event 4: the successor key (key N+1) is introduced into the zone and Event 3: after the current key (key N) has been in use for its
starts being used to sign RRsets. The successor is key is now active intended lifetime (Lzsk), the successor key (key N+1) is introduced
and the current key (key N) is said to be retired. This time is the into the zone and starts being used to sign RRsets: neither the
retire time of the key (Tret); it is also the active time of the current key nor the signatures created with it are removed. The
successor key (TactS). successor is key is now active and the current key is said to be
retired. This time is the retire time of the key (Tret); it is also
the activation time of the successor key (TactS).
Tret = Tact + Lzsk Tret = Tact + Lzsk
Event 5: before key N can be withdrawn from the zone, all RRsets that Event 4: before key N can be withdrawn from the zone, all RRsets that
need to be signed must have been signed by the successor key (as a need to be signed must have been signed by the successor key (key
result, all these RRsets are now signed twice, once by key N and once N+1) and any old RRsets that do not include the new key or new RRSIGs
by its successor) and the information must have reached all must have expired from caches. Note that the signatures are not
validating resolvers that may have RRsets from this zone cached. replaced - each RRset is signed by both the old and new key.
This takes Iret, the retire interval, given by the expression: This takes Iret, the retire interval, given by the expression:
Iret = Dsgn + Dprp + max(TTLkey, TTLsig) Iret = Dsgn + Dprp + max(TTLkey, TTLsig)
As before, Dsgn is the time taken to sign the zone with the new key As before, Dsgn is the delay needed to ensure that all existing
and Dprp is the propagation delay. The final term is the period to RRsets have been signed with the new key, Dprp is the propagation
wait for old key and signature data to expire from caches. After the delay. The final term (the maximum of TTLkey and TTLsig) is the
end of this interval, key N is said to be dead. This occurs at the period to wait for key and signature data associated with key N to
dead time (Tdea) so: 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 as although the 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 = Tret + Iret Tdea = Tret + Iret
Event 6: at some later time key N and its signatures can be removed Event 5: at some later time key N and its signatures can be removed
from the zone. This is the removal time Trem, given by: from the zone. This is the removal time Trem, given by:
Trem >= Tdea Trem >= Tdea
3.2.3. Double-RRSIG Method 3.2.3. Double-RRSIG Method
As noted above, "Double-Signature" is simultaneous rollover of both The timeline for a double-signature rollover is shown below. The
signature and key. The time line for a pure Double-Signature ZSK diagram follows the convention described in Section 3.2.1
rollover (the Double-RRSIG method) - where new signatures are
introduced, the key changed, and finally the old signatures removed -
is shown below:
|1||2| |3| |4||5| |6||7| |8||9| |10| |11| |1||2| |3| |4||5| |6| |7||8| |9| |10|
| | | | | | | | | | | | | | | | | | | | |
Key N | |<-Dsgn->| | |<-----------Lzsk-------->|<-Iret->| | Key N | |<-Dsgn->| | |<--------Lzsk-------->|<-Iret->| |
| |<---IpubG-->| |<-IpubK->| | | | | | | |<---IpubG-->| | | | | | |
| | | | | | | | | | | | | | | | | | | | |
Key N+1 | | | | | | |<-IpubG->| | | | Key N+1 | | | | | |<-IpubG->| | | |
| | | | | | | | | | | | | | | | | | | | |
Tgen Tpub Trdy Tact TpubS TrdyS Tret Tdea Trem Tgen Tpub Trdy Tact TpubS TrdyS Tret Tdea Trem
---- Time ----> ---- Time ---->
Figure 3: Timeline for a Double-Signature ZSK rollover. Figure 3: Timeline for a Double-Signature ZSK rollover.
Event 1: key N is generated at the generate time (Tgen). Although Event 1: key N is generated at the generate time (Tgen). Although
there is no reason why the key cannot be generated immediately prior there is no reason why the key cannot be generated immediately prior
to publication in the zone (Event 2), some implementations may find to its publication in the zone (Event 2), some implementations may
it convenient to create a pool of keys in one operation and draw from find it convenient to create a pool of keys in one operation and draw
that pool as required. For this reason, it is shown as a separate from that pool as required. For this reason, it is shown as a
event. Keys that are available for use but not published are said to separate event. Keys that are available for use but not published
be generated. are said to be generated.
Event 2: key N is used to sign the zone but existing signatures are Event 2: key N is used to sign the zone but existing signatures are
retained. Although the new ZSK is not published in the zone at this retained. Although the new ZSK is not published in the zone at this
point, for analogy with the other ZSK rollover methods and because point, for analogy with the other ZSK rollover methods and because
this is the first time that key information is visible (albeit this is the first time that key information is visible (albeit
indirectly through the created signatures) this time is called the indirectly through the created signatures) this time is called the
publish time (Tpub). publication time (Tpub).
Event 3: after the signing interval, Dsgn, all RRsets that need to be Event 3: after the signing interval, Dsgn, all RRsets that need to be
signed have been signed by the new key. (As a result, all these signed have been signed by the new key. (As a result, all these
RRsets are now signed twice, once by the existing key and once by the RRsets are now signed twice, once by the (still-absent) key N and
(still-absent) key N. once by its predecessor.
Event 4: there is now a delay while the this information reaches all Event 4: there is now a delay while the old signature information
validating resolvers that may have RRsets from the zone cached. This expires from caches. This interval is given by the expression:
interval is given by the expression:
Dprp + TTLsig Dprp + TTLsig
...comprising the delay for the information to propagate through the As before, Dprp is the propagation delay and TTLsig is the maximum
nameserver infrastructure plus the time taken for signature TTL of all the RRSIG records in the zone.
information to expire from caches.
Again in analogy with other key rollover methods, this is defined as Again in analogy with other key rollover methods, this is defined as
key N's ready time (Trdy) and the key is said to be in the ready key N's ready time (Trdy) and the key is said to be in the ready
state. (Although the key is not in the zone, it is ready to be state. (Although the key is not in the zone, it is ready to be
used.) The interval between the publication and ready times is the used.) The interval between the publication and ready times is the
publication interval of the signature, IpubG, i.e. publication interval of the signature, IpubG, i.e.
Trdy = Tpub + IpubG Trdy = Tpub + IpubG
where where
IpubG = Dsgn + Dprp + TTLsig IpubG = Dsgn + Dprp + TTLsig
Event 5: at some later time the predecessor key is removed and the Event 5: at some later time the predecessor key is removed and the
key N added to the DNSKEY RRset. As all the RRs have signatures key N added to the DNSKEY RRset. As all the signed RRs have
created by the old and new keys, the records can still be signatures created by the old and new keys, the records can still be
authenticated. This time is the active time (Tact) and the key is authenticated. This time is the activation time (Tact) and the key
now said to be active. is now said to be active.
Event 6: After IpubK - the publication interval of the key - the
newly added DNSKEY RRset has propagated through to all validating
resolvers. At this point the old signatures can be removed from the
zone. IpubK is given by:
IpubK = Dprp + TTLkey
Event 7: as before, at some later time thought must be given to Event 6: at some point thought must be given to rolling the key. The
rolling the key. The first step is to publish signatures created by first step is to publish signatures created by the successor key (key
the successor key (key N+1) early enough so that key N can be N+1) early enough for key N to be replaced after it has been active
replaced after it has been active for its scheduled lifetime. This for its scheduled lifetime. This occurs at TpubS (the publication
occurs at TpubS (the publication time of the successor), given by: time of the successor), given by:
TpubS <= Tact + Lzsk - IpubG TpubS <= Tact + Lzsk - IpubG
Event 8: the signatures have propagated through the zone and the new Event 7: the signatures have propagated and the new key could be
key could be added to the zone. This time is the ready time of the added to the zone. This time is the ready time of the successor key
successor (TrdyS). (TrdyS).
TrdyS = TpubS + IpubG TrdyS = TpubS + IpubG
... where IpubG is as defined above. ... where IpubG is as defined above.
Event 9: at some later time key N is removed from the zone and the Event 8: at some later time key N is removed from the zone and the
successor key added. This is the retire time of the key (Tret). successor key (key N+1) added. This is the retire time of the key
(Tret).
Event 10: The signatures must remain in the zone for long enough that Event 9: the signatures must remain in the zone for long enough that
the new DNSKEY RRset has had enough time to propagate to all caches. the new DNSKEY RRset has had enough time to propagate to all caches.
Once caches contain the new DNSKEY, the old signatures are no longer Once caches contain the new DNSKEY, the old signatures are no longer
of use and can be considered to be dead. The time at which this of use and can be considered to be dead. The time at which this as
occurs is the dead time (Tdea), given by: they can not be validated by any key. In analogy with other rollover
methods, the time at which this occurs is the dead time (Tdea), given
by:
Tdea = Tret + Iret Tdea = Tret + Iret
... where Iret is the retire interval, given by: ... where Iret is the retire interval, given by:
Iret = IpubK Iret = Dprp + TTLkey
Event 11: At some later time the signatures can be removed from the Dprp is as defined earlier and TTLkey is the TTL of the DNSKEY RRset.
zone. Although the key has is not longer in the zone, this is
information associated with it and so the time can be regarded as the Event 10: at some later time the signatures can be removed from the
key's remove time (Trem), given by: zone. In analogy with other rollover methods this time is called the
remove time (Trem) and is given by:
Trem >= Tdea Trem >= Tdea
3.3. Key-Signing Key Rollover Timelines 3.3. Key-Signing Key Rollover Timelines
3.3.1. Double-Signature Method 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
The Double-Signature method (also knows as the double-DNSKEY method) replacement by its successor (key N+1).
involves introducing the new KSK to the zone and waiting until its
presence has been registered by all validating resolvers. At this
point, the DS record in the parent is changed. Once that change has
propagated to all validating resolvers, the old KSK is removed.
The timing diagram for such a rollover is: 3.3.1. Double-Signature Method
|1| |2| |3| |4| |5| |6| The timeline for a double-signature rollover is shown below. The
| | | | | | diagram follows the convention described in Section 3.2.1
Key N | |<-Ipub->|<--->|<-Dreg->|<---------Lksk--- - - |1| |2| |3| |4| |5|
| | | | | | | | | | |
Key N+1 | | | | | | Key N | |<-Ipub->|<--->|<-Dreg->|<-----Lksk--- - -
| | | | | | | | | | |
Tgen Tpub Trdy Tsub Tact Key N+1 | | | | |
| | | | |
Tgen Tpub Trdy Tsub Tact
---- Time ----> ---- Time ---->
(continued...) (continued...)
|7| |8| |9| |10| |11| |12| |6| |7| |8| |9| |10| |11|
| | | | | | | | | | | |
Key N - - -------------Lksk------->|<-Iret->| | Key N - - -------------Lksk------->|<-Iret->| |
| | | | | | | | | | | |
Key N+1 |<-Ipub->|<--->|<-Dreg->|<--------Lksk----- - - Key N+1 |<-Ipub->|<--->|<-Dreg->|<--------Lksk----- - -
| | | | | | | | | | | |
TpubS TrdyS TsubS Tret Tdea Trem TpubS TrdyS TsubS Tret Tdea Trem
---- Time (cont) ----> ---- Time (cont) ---->
Figure 4: Timeline for a Double-Signature KSK rollover. Figure 4: Timeline for a Double-Signature KSK rollover.
Event 1: key N is generated at time Tgen. As before, although there Event 1: key N is generated at the generate time (Tgen). Although
is no reason why the key cannot be generated immediately prior to there is no reason why the key cannot be generated immediately prior
publication, some implementations may find it convenient to create a to its publication in the zone (Event 2), some implementations may
central pool of keys and draw from it. For this reason, it is again find it convenient to create a pool of keys in one operation and draw
shown as a separate event. 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 is introduced into the zone; it is added to the DNSKEY Event 2: key N is introduced into the zone; it is added to the DNSKEY
RRset, which is then signed by key N and all currently active KSKs. RRset, which is then signed by key N and all currently active KSKs.
(So at this point, the DNSKEY RRset is signed by both key N and its (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 predecessor KSK. If other KSKs were active, it is signed by these as
well.) This is the publication time (Tpub); after this the key is well.) This is the publication time (Tpub); after this the key is
said to be published. said to be published.
Event 3: before it can be used, the key must be published for long Event 3: before it can be used, the key must be published for long
enough to guarantee that any validating resolver that has a copy of enough to guarantee that any validating resolver that has a copy of
the DNSKEY RRset from the zone in its cache will have a copy of the the DNSKEY RRset in its cache will have a copy of the RRset that
RRset that includes this key: in other words, that any prior cached includes this key: in other words, that any prior cached information
information about the DNSKEY RRset has expired. about the DNSKEY RRset has expired.
The interval is the publication interval (Ipub) and, for the second The interval is the publication interval (Ipub) and, for the second
or subsequent KSKs in the zone, is given by: or subsequent KSKs in the zone, is given by:
Ipub = Dprp + TTLkey Ipub = DprpC + TTLkey
... where Dprp is the propagation delay for the zone and TTLkey the ... where DprpC is the propagation delay for the child zone (the zone
TTL for the DNSKEY RRset. The time at which this occurs is the key's containing the KSK being rolled) and TTLkey the TTL for the DNSKEY
ready time, Trdy, given by: RRset. The time at which this occurs is the key's ready time, Trdy,
given by:
Trdy = Tpub + Ipub Trdy = Tpub + Ipub
Event 4: at some later time, the DS RR corresponding to the new KSK (The case of introducing the first KSK into the zone is discussed in
is submitted to the parent zone for publication. This time is the Section 3.3.5.)
submission time, Tsub.
Event 4: 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, Tsub.
Event 5: the DS record is published in the parent zone. As this is Event 5: the DS record is published in the parent zone. As this is
the point at which all information for authentication - both DNSKEY the point at which all information for authentication - both DNSKEY
and DS record - is available in the two zones, it is the active time and DS record - is available in the two zones, in analogy with other
of the key: rollover methods, this is called the activation time of the key
(Tact):
Tact = Tsub + Dreg Tact = Tsub + Dreg
... where Dreg is the registration delay, the time taken after the DS ... where Dreg is the registration delay, the time taken after the DS
record has been received by the parent zone manager for it to be record has been received by the parent zone manager for it to be
placed in the zone. (Parent zones are often managed by different placed in the zone. (Parent zones are often managed by different
entities, and this term accounts of the organisational overhead of entities, and this term accounts for the organisational overhead of
transferring a record.) transferring a record.)
Event 6: at some time later, all validating resolvers that have the Event 6: while key N is active, thought needs to be given to its
DS RRset cached will have a copy that includes the new DS record. successor (key N+1). At some time before the scheduled end of the
For the second or subsequent DS records, this interval is given by KSK lifetime, the successor KSK is published in the zone. (As
the expression: before, this means that the DNSKEY RRset is signed by both the
current and successor KSK.) This time is the publication time of the
DprpP + TTLds successor key, TpubS, given by:
... where DprpP is the propagation delay in the parent zone and TTLds
the TTL assigned to DS records in that zone.
In the case of the first DS record for the zone in question, the
expression is slightly different because it is not information about
a DS RRset that may be cached, it is information about its absence.
In this case, the interval is:
DprpP + IngcP
where IngcP is the negative cache interval from the zone's SOA
record, calculated according to [RFC2308] as the minimum of the TTL
of the parent SOA record itself (TTLsoaP), and the "minimum" field in
the record's parameters (SOAminP), i.e.
IngcP = min(TTLsoaP, SOAminP) TpubS <= Tact + Lksk - Dreg - Ipub
Event 7: while key N is active, thought needs to be given to its ... where Lksk is the scheduled lifetime of the KSK.
successor (key N+1). At some time before the scheduled end of the
KSK lifetime, the successor KSK is introduced into the zone and is
used to sign the DNSKEY RRset. (As before, this means that the
DNSKEY RRset is signed by both the current and successor KSK.) This
is the publication time of the successor key, TpubS.
Event 8: after an interval Ipub, the successor key becomes ready (in Event 7: after an interval Ipub, key N+1 becomes ready (in that all
that all validating resolvers that have a copy of the DNSKEY RRset caches that have a copy of the DNSKEY RRset have a copy of this key).
have a copy of this key). This is the successor ready time, TrdyS. This time is the ready time of the successor (TrdyS).
Event 9: at the successor submission time (TsubS), the DS record Event 8: at the submission time of the successor (TsubS), the DS
corresponding to the successor key is submitted to the parent zone. record corresponding to key N+1 is submitted to the parent zone.
Event 10: the successor DS record is published in the parent zone and Event 9: the successor DS record is published in the parent zone and
the current DS record withdrawn. The current key is said to be the current DS record withdrawn. The current key is said to be
retired and the time at which this occurs is Tret, given by: retired and the time at which this occurs is Tret, given by:
The relationships between these times are:
TpubS <= Tact + Lksk - Dreg - Ipub
Tret = Tact + Lksk Tret = Tact + Lksk
... where Lksk is the scheduled lifetime of the KSK. Event 10: 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.
Event 11: key N must remain in the zone until any validators that This interval is the retire interval, given by:
have the DS RRset cached have a copy of the DS RRset containing the
new DS record. This interval is the retire interval, given by:
Iret = DprpP + TTLds Iret = DprpP + TTLds
... where DprpP is the propagation delay in the parent zone and TTLds ... where DprpP is the propagation delay in the parent zone and TTLds
the TTL of a DS record. the TTL of a DS record in the parent zone.
As the key is no longer used for anything, it can also be said to be As the key is no longer used for anything, is said to be dead. This
dead, in which case: point is the dead time (Tdea), given by:
Tdea = Tret + Iret Tdea = Tret + Iret
Event 12: at some later time, key N is removed from the zone (at the Event 11: at some later time, key N is removed from the zone (at the
remove time Trem); the key is now said to be removed. remove time Trem); the key is now said to be removed.
Trem >= Tdea Trem >= Tdea
3.3.2. Double-DS Method 3.3.2. Double-DS Method
The Double-DS method is the reverse of the Double-Signature method is The timeline for a double-DS rollover is shown below. The diagram
that it is the DS record that is pre-published (in the parent), and follows the convention described in Section 3.2.1
not the DNSKEY.
The timeline for the key rollover is shown below:
|1| |2| |3| |4| |5| |6| |1| |2| |3| |4| |5| |6|
| | | | | | | | | | | |
Key N | |<-Dreg->|<-IpubP->|<-->|<---------Lksk------- - - Key N | |<-Dreg->|<-IpubP->|<-->|<---------Lksk------- - -
| | | | | | | | | | | |
Key N+1 | | | | |<---->|<--Dreg+IpubP- - - Key N+1 | | | | |<---->|<--Dreg+IpubP- - -
| | | | | | | | | | | |
Tgen Tsub Tpub Trdy Tact TsubS Tgen Tsub Tpub Trdy Tact TsubS
---- Time ----> ---- Time ---->
skipping to change at page 20, line 47 skipping to change at page 19, line 28
Key N - - -----Lksk---------->|<-Iret->| | Key N - - -----Lksk---------->|<-Iret->| |
| | | | | | | |
Key N+1 - - --Dreg+IpubP->|<--->|<------Lksk------ - - Key N+1 - - --Dreg+IpubP->|<--->|<------Lksk------ - -
| | | | | | | |
TrdyS Tret Tdea Trem TrdyS Tret Tdea Trem
---- Time ----> ---- Time ---->
Figure 5: Timeline for a Double-DS KSK rollover. Figure 5: Timeline for a Double-DS KSK rollover.
Event 1: key N is generated at time Tgen. As before, although there Event 1: key N is generated at the generate time (Tgen). Although
is no reason why the key cannot be generated immediately prior to there is no reason why the key cannot be generated immediately prior
publication, some implementations may find it convenient to create a to its publication in the zone (Event 2), some implementations may
central pool of keys and draw from it. For this reason, it is again find it convenient to create a pool of keys in one operation and draw
shown as a separate event. 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: the DS record corresponding to key N is submitted for Event 2: the DS RR is submitted to the parent zone for publication.
publication in the parent zone. This time is the submission time This time is the submission time, Tsub.
(Tsub).
Event 3: after the registration delay, Dreg, the DS record is Event 3: after the registration delay, Dreg, the DS record is
published in the parent zone. This is the publication time Tpub, published in the parent zone. This is the publication time Tpub,
given by: given by:
Tpub = Tsub + Dreg Tpub = Tsub + Dreg
Event 4: at some later time, any validating resolver that has copies Event 4: at some later time, any cache that has a copy of the DS
of the DS RRset in its cache will have a copy of the DS record for RRset will have a copy of the DS record for key N. At this point, key
key N. At this point, key N, if introduced into the DNSKEY RRset, N, if introduced into the DNSKEY RRset, could be used to validate the
could be used to validate the zone. For this reason, this time is zone. For this reason, this time is known as the key's ready time,
known as the key's ready time, Trdy, and is given by: Trdy, and is given by:
Trdy = Tpub + IpubP Trdy = Tpub + IpubP
IpubP is the parent publication interval and is given by the IpubP is the parent publication interval and is given by the
expression: expression:
IpubP = DprpP + TTLds IpubP = DprpP + TTLds
... where DprpP is the propagation delay in the parent zone and TTLds ... where DprpP is the propagation delay for the parent zone and
the TTL assigned to DS records in that zone. TTLds the TTL assigned to DS records in that zone.
Event 5: at some later time, the key rollover takes place. The Event 5: at some later time, the key rollover takes place and the new
predecessor key is withdrawn from the DNSKEY RRset and the new key key (key N) introduced and used to sign the RRset.
(key N) introduced and used to sign the RRset.
As both DS records have been in the parent zone long enough to ensure As both the old and new DS records have been in the parent zone long
that they are in the cache of any validating resolvers that have the enough to ensure that they are in caches that contain the DS RRset,
DS RRset cached, the zone can be authenticated throughout the the zone can be authenticated throughout the rollover - either the
rollover - either the resolver has a copy of the DNSKEY RRset (and resolver has a copy of the DNSKEY RRset authenticated by the
associated RRSIGs) authenticated by the predecessor key, or it has a predecessor key, or it has a copy of the updated RRset authenticated
copy of the updated RRset authenticated with the new key. with the new key.
This time is the key's active time (Tact) and at this point the key This time is key N's activation time (Tact) and at this point the key
is said to be active. is said to be active.
Event 6: at some point thought must be given to key replacement. The Event 6: at some point thought must be given to key replacement. The
DS record for the successor key must be submitted to the parent zone 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 validating at a time such that when the current key is withdrawn, any cache that
resolver that has DS records in its cache will have data about the DS contains the zone's DS records have data about the DS record of the
record of the successor key. The time at which this occurs is the successor key. The time at which this occurs is the submission time
submission time of the successor, given by: of the successor, given by:
TsubS <= Tact + Lksk - IpubP - Dreg TsubS <= Tact + Lksk - IpubP - Dreg
... where Lksk is the lifetime of the KSK. ... where Lksk is the lifetime of key N according to policy.
Event 7: the successor key (key N+1) enters the ready state i.e. its Event 7: the successor key (key N+1) enters the ready state i.e. its
DS record is now in the caches of all validating resolvers that have DS record is now in caches that contain the parent DS RRset. This is
the parent DS RRset cached. (This is the ready time of the the ready time of the successor key, TrdyS.
successor, TrdyS.)
Event 8: when the current key has been active for its lifetime (The interval between events 6 and 7 for the key N+1 correspond to
(Lksk), the current key is removed from the DNSKEY RRset and the the the interval between events 2 and 4 for key N)
successor key added; the RRset is then signed with the successor key.
This point is the retire time of the key, Tret, given by: Event 8: when key N has been active for its lifetime (Lksk), it is
removed from the DNSKEY RRset and key N+1 added; the RRset is then
signed with the new key. This is the retire time of the key, Tret,
given by:
Tret = Tact + Lksk Tret = Tact + Lksk
Event 9: at some later time, all copies of the old DNSKEY RRset have 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. This expired from caches and the old DS record is no longer needed. In
is called the dead time, Tdea, and is given by: analogy with other rollover methods, this is called the dead time,
Tdea, and is given by:
Tdea = Tret + Iret Tdea = Tret + Iret
... where Iret is the retire interval, given by: ... where Iret is the retire interval, given by:
Iret = Dprp + TTLkey Iret = DprpC + TTLkey
As before, this term includes the time taken to propagate the RRset As before, this term includes DprpC, the time taken to propagate the
change through the master-slave hierarchy and the time take for the RRset change through the master-slave hierarchy of the child zone and
DNSKEY RRset to expire from caches. 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 Event 10: at some later time, the DS record is removed from the
parent zone. This is the removal time (Trem), given by: parent zone. In analogy with other rollover methods, this is the
removal time (Trem), given by:
Trem >= Tdea Trem >= Tdea
3.3.3. Double-RRset Method 3.3.3. Double-RRset Method
In the Double-RRset method, both the DS and DNSKEY records are The timeline for a double-RRset rollover is shown below. The diagram
changed at the same time, so for a period the zone can be follows the convention described in Section 3.2.1
authenticated with either key. The advantage of this method is its
applicability in cases where zone management policy requires overlap
of authentication keys during a roll.
The timeline for this rollover is shown below:
|1| |2| |3| |4| |5| |6| |7| |1| |2| |3| |4| |5| |6|
| | | | | | | | | | | | |
Key N | |<-Dreg->|<-----Lksk----->|<-Iret->| | Key N | |<-Ipub->|<-----Lksk----->| |
| | | | | | | | | | | | |
Key N+1 | | | |<-Dreg->|<-----Lksk-- - - Key N+1 | | | |<-Ipub->| |
| | | | | | | | | | | | |
Tgen Tpub Tact TpubS Tret Tdea Trem Tgen Tpub Tact TpubS Tret Trem
---- Time ----> ---- Time ---->
Figure 6: Timeline for a Double-RRset KSK rollover. Figure 6: Timeline for a Double-RRset KSK rollover.
Event 1: key N is created at time Tgen and thereby immediately Event 1: key N is generated at the generate time (Tgen). Although
becomes generated. As before, although there is no reason why the there is no reason why the key cannot be generated immediately prior
key cannot be generated immediately prior to publication, some to its publication in the zone (Event 2), some implementations may
implementations may find it convenient to create a central pool of find it convenient to create a pool of keys in one operation and draw
keys and draw from it. For this reason, it is again shown as a from that pool as required. For this reason, it is shown as a
separate event. separate event. Keys that are available for use but not published
are said to be generated.
Event 2: the key is added to and used for signing the DNSKEY RRset Event 2: the key is added to and used for signing the DNSKEY RRset
and is thereby published in the zone. At the same time the and is thereby published in the zone. At the same time the
corresponding DS record is submitted to the parent zone for corresponding DS record is submitted to the parent zone for
publication. This time is the publish time (Tpub) and the key is now publication. This time is the publish time (Tpub) and the key is now
said to be published. said to be published.
Event 3: after Dreg, the registration delay, the DS record is Event 3: at some later time, the DS record is published in the parent
published in the parent zone. At this point, the zones have all the zone and at some time after that, the updated information has reached
information needed for a validating resolver to authenticate the all caches: any cache that holds a DNSKEY RRset from the child zone
zone, although the information may not yet have reached all will have a copy that includes the new KSK, and any cache that has a
validating resolver caches. This time is the active time (Tact) and copy of the parent DS RRset will have a copy that includes the new DS
the key is said to be active. record.
Tact = Tpub + Dreg
Event 4: at some point we need to give thought to key replacement. The time at which this occurs is called the activation time of the
The successor key must be introduced into the zone (and its DS record new KSK (Tact), given by:
submitted to the parent) at a time such that it becomes active when
the current key has been active for its lifetime, Lksk. This time is
TpubS, the publication time of the successor key, and is given by:
TpubS <= Tact + Lksk - Dreg Tact = Tpub + Ipub
... where Lksk is the lifetime of the KSK. ... where Ipub is the publication interval, given by:
Event 5: the successor key's DS record appears in the parent zone and Ipub = max(IpubP, IpubC),
the successor key becomes active. At this point, the current key
becomes retired. This occurs at Tret, given by:
Tret = Tact + Lksk IpubP being the publication interval in the parent zone and IpubC the
publication interval in the child zone. The parent zone's
publication interval is given by:
Event 6: the current DNSKEY and DS record must be retained in the IpubP = Dreg + DprpP + TTLds
zones until any any validating resolver that has cached the DNSKEY
and/or DS RRsets will have a copy of the data for the successor key.
At this point the current key information is dead, as any validating
resolver can perform authentication using the successor key. This is
the dead time, Tdea, given by:
Tdea = Tret + Iret where Dreg is the registration delay, the time taken for the DS
record to be published in the parent zone. DprpP is the parent
zone's propagation delay and TTLds is the TTL of the DS record in
that zone.
... where Iret is the retire interval. This depends on how long both The child's publication interval is given by a similar equation:
the successor DNSKEY and DS records take to propagate through the
nameserver infrastructure and thence into validator caches. These
delays are the publication intervals of the child and parent zones
respectively, so a suitable expression for Iret is:
Iret = max(IpubP, IpubC) IpubC = DprpC + TTLkey
IpubC is the publication interval of the DNSKEY in the child zone, ... where DprpC is the propagation delay in the child zone and TTLkey
IpubP that of the DS record in the parent. the TTL of a DNSKEY record.
The child term comprises two parts - the time taken for the Event 4: at some point we need to give thought to key replacement.
introduction of the DNSKEY record to be propagated to the downstream The successor key (key N+1) must be introduced into the zone (and its
secondary servers (= DprpC, the child propagation delay) and the time DS record submitted to the parent) at a time such that it becomes
taken for information about the DNSKEY RRset to expire from the active when the current key has been active for its lifetime, Lksk.
validating resolver cache, i.e. This time is TpubS, the publication time of the successor key, and is
given by:
IpubC = DprpC + TTLkey TpubS <= Tact + Lksk - Ipub
TTLkey is the TTL for a DNSKEY record in the child zone. The parent ... where Lksk is the lifetime of the KSK.
term is similar:
IpubP = DprpP + TTLds Event 5: key N+1's DNSKEY and DS records are in any caches that
contain the child zone DNSKEY and/or the parent zone DS RR, and so
the zone can be validated with the new key. This is the activation
time of the successor key (TactS) and by analogy with other rollover
methods, it is also the retire time of the current key. Since at
this time the zone can be validated by the successor key, there is no
reason to keep the current key in the zone and the time can also be
regarded as the current key's dead time. Thus:
DprpP the propagation delay in the parent zone and TTLds the TTL for Tret = Tdea = TactS = Tact + Lksk
a DS record in the parent zone.
Event 7: at some later time, the DNSKEY record can be removed from Event 6: at some later time, the key N's DS and DNSKEY records can be
the child zone and a request can be made to remove the DS record from removed from their respective zones. In analogy with other rollover
the parent zone. This is the removal time, Trem and is given by: methods, this is the removal time (Trem), given by:
Trem >= Tdea Trem >= Tdea
3.3.4. Interaction with Configured Trust Anchors 3.3.4. Interaction with Configured Trust Anchors
Although the preceding sections have been concerned with rolling KSKs Although the preceding sections have been concerned with rolling KSKs
where the trust anchor is a DS record in the parent zone, zone where the trust anchor is a DS record in the parent zone, zone
managers may want to take account of the possibility that some managers may want to take account of the possibility that some
validating resolvers may have configured trust anchors directly. validating resolvers may have configured trust anchors directly.
Rolling a configured trust anchor is dealt with in [RFC5011]. It Rolling a configured trust anchor is dealt with in [RFC5011]. It
requires introducing the KSK to be used as the trust anchor into the 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 zone for a period of time before use, and retaining it (with the
"revoke" bit set) for some time after use. The Double-Signature and "revoke" bit set) for some time after use.
Double-RRset methods can be adapted to include [RFC5011]
recommendations so that the rollover will also be signalled to
validating resolvers with configured trust anchors. (The
recommendations are not suitable for the Double-DS method.
Introducing the new key early and retaining the old key after use
effectively converts it into a form of Double-RRset.)
3.3.4.1. Addition of KSK 3.3.4.1. Addition of KSK
When the new key is introduced, the publication interval (Ipub) in When the new key is introduced, the publication interval (Ipub) in
the Double-Signature method should also be subject to the condition: the Double-Signature and Double-RRset methods should also be subject
to the condition:
Ipub >= max(30 days, TTLkey) Ipub >= Dprp + max(30 days, TTLkey)
... where the right had side of the expression is the add hold-down ... where the right hand side of the expression is the time taken for
time defined in section 2.4.1 of [RFC5011]. the change to propagate to all nameservers for the zone plus the add
hold-down time defined in section 2.4.1 of [RFC5011].
In the Double-RRSIG method, the key should not be regarded as being In the Double-DS method, instead of the changing of the KSK RR being
active until the add hold-down time has passed. In other words, the instantaneous, there must now be a period of overlap. In other
following condition should be enforced: words, the new KSK must be introduced into the zone at least:
Tact >= Tpub + max(30 days, TTLkey) DprpC + max(30 days, TTLkey)
(Effectively, this means extending the lifetime of the key by an ... before the switch is made.
appropriate amount.)
3.3.4.2. Removal of KSK 3.3.4.2. Removal of KSK
The timeline for the removal of the key in both methods is modified The timeline for the removal of the key in all methods is modified by
by introducing a new state, "revoked". When the key reaches the end introducing a new state, "revoked". When the key reaches its dead
of the retire period, instead of being declared "dead", it is time, instead of being declared "dead", it is revoked; the "revoke"
revoked; the "revoke" bit is set on the DNSKEY RR and is published in bit is set on the DNSKEY RR and is published in (and used to sign)
(and used to sign) the DNSKEY RRset. The key is maintained in this the DNSKEY RRset. The key is maintained in this state for the
state for the "revoke" interval, Irev, given by: "revoke" interval, Irev, given by:
Irev >= 30 days Irev >= 30 days
... 30 days being the [RFC5011] remove hold-down time. After this ... 30 days being the [RFC5011] remove hold-down time. After this
time, the key is dead and can be removed from the zone when time, the key is dead and can be removed from the zone.
convenient.
3.3.5. Introduction of First KSK 3.3.5. Introduction of First KSK
There is an additional consideration when introducing a KSK into a There is an additional consideration when introducing a KSK into a
zone for the first time, and that is that no validating resolver zone for the first time, and that is that no validating resolver
should be in a position where it can access the trust anchor before should be in a position where it can access the trust anchor before
the KSK appears in the zone. To do so will cause the validating the KSK appears in the zone. To do so will cause it to declare the
resolver to declare the zone to be bogus. zone to be bogus.
This is important: in the case of a secure parent, it means ensuring This 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 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 no possibility that a validating resolver can obtain the record yet
not be able to obtain the corresponding DNSKEY. In the case of an 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 insecure parent, i.e. the initial creation of a new security apex, it
is important to not configure trust anchors in validating resolvers is not possible to guarantee this. It is up to the operator of the
until the DNSKEY RRset has had sufficient time to propagate. In both validating resolver to wait for the new KSK to appear at all servers
cases, this time is the trust anchor availability time (Ttaa) given for the zone before configuring the trust anchor.
by:
Ttaa >= Tpub + IpubC
where
IpubC = DprpC + TTLkeyC
or
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. (It is possible that the zone was signed but that the trust
anchor had not been submitted to the parent.)
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 Ingc to allow for the effect of
negative caching.
As before, IngcC is the negative cache interval from the child zone's
SOA record, calculated according to [RFC2308] as the minimum of the
TTL of the SOA record itself (TTLsoaC), and the "minimum" field in
the record's parameters (SOAminC), i.e.
IngcC = min(TTLsoaC, SOAminC)
4. Standby Keys 4. Standby Keys
Although keys will usually be rolled according to some regular Although keys will usually be rolled according to some regular
schedule, there may be occasions when an emergency rollover is schedule, there may be occasions when an emergency rollover is
required, e.g. if the active key is suspected of being compromised. 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- 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 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 ready state to sign the zone, having at least one additional key (a
standby key) in this state at all times will minimise delay. standby key) in this state at all times will minimise delay.
In the case of a ZSK, a standby key only really makes sense with the 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 Pre-Publication method. A permanent standby DNSKEY RR should be
included in zone or successor keys could be introduced as soon as included in zone or successor keys could be introduced as soon as
possible after a key becomes active. Either way results in an possible after a key becomes active. Either way results in one or
additional ZSK in the DNSKEY RRset that can immediately be used to more additional ZSKs in the DNSKEY RRset that can immediately be used
sign the zone if the current key is compromised. to sign the zone if the current key is compromised.
(Although in theory the mechanism could be used with both the Double- (Although in theory the mechanism could be used with both the Double-
Signature and Double-RRSIG methods, it would require Pre-Publication Signature and Double-RRSIG methods, it would require pre-publication
of the signatures. Essentially, the standby key would be permanently of the signatures. Essentially, the standby key would be permanently
active, as it would have to be periodically used to renew signatures. active, as it would have to be periodically used to renew signatures.
Zones would also permanently require two sets of signatures, Zones would also permanently require two sets of signatures.)
something that could have a performance impact in large zones.)
A standby key can also be used with the Double-Signature and It is also possible to have a standby KSK. The Double-Signature
Double-DS methods of rolling a KSK. (The idea of a standby key in method requires that the standby KSK be included in the DNSKEY RRset;
the Double-RRset effectively means having two active keys.) The rolling the key then requires just the introduction of the DS record
Double-Signature method requires that the standby KSK be included in in the parent. Note that the standby KSK should also be used to sign
the DNSKEY RRset; rolling the key then requires just the introduction the DNSKEY RRset. As the RRset and its signatures travel together,
of the DS record in the parent. (Note that the DNSKEY should also be merely adding the KSK without using it to sign the DNSKEY RRset does
used to sign the DNSKEY RRset. As the RRset and its signatures not provide the desired time saving: for a KSK to be used in a
travel together, merely adding the DNSKEY does not provide the rollover the DNSKEY RRset must be signed with it, and this would
desired time saving; to be used in a rollover requires that the introduce a delay while the old RRset (not signed with the new key)
DNSKEY RRset be signed with the standby key, and this introduces a expires from caches.
delay whilst the RRset and its signatures propagate to the caches of
validating resolvers. There is no time advantage over introducing a
new DNSKEY and signing the RRset with it at the same time.)
In the Double-DS method of rolling a KSK, it is not a standby key The idea of a standby KSK in the Double-RRset rollover method
that is present, it is a standby DS record in the parent zone. effectively means having two active keys (as the standby KSK and
Whatever algorithm is used, the standby item of data can be associated DS record would both be published at the same time in
introduced as a permanent standby, or be a successor introduced as 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. early as possible.
5. Algorithm Considerations 5. Algorithm Considerations
The preceding sections have implicitly assumed that all keys and The preceding sections have implicitly assumed that all keys and
signatures are created using a single algorithm. However, [RFC4035] signatures are created using a single algorithm. However, [RFC4035]
(section 2.4) states that "There MUST be an RRSIG for each RRset (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 using at least one DNSKEY of each algorithm in the zone apex DNSKEY
RRset". RRset".
skipping to change at page 28, line 27 skipping to change at page 26, line 16
words, the key rollover logic described above should be run words, the key rollover logic described above should be run
separately for each algorithm; the union of the results is included separately for each algorithm; the union of the results is included
in the zone, which is signed using the active key for each algorithm. in the zone, which is signed using the active key for each algorithm.
6. Limitation of Scope 6. Limitation of Scope
This document represents current thinking at the time of publication. This document represents current thinking at the time of publication.
However, the subject matter is evolving and it is more than likely However, the subject matter is evolving and it is more than likely
that this document will need to be revised in the future. that this document will need to be revised in the future.
Some of the techniques and ideas that DNSSEC operators are thinking Some of the techniques and ideas that DNSSEC operators considering
about differ from this those described in this document. Of note are differ from this those described in this document. Of note are
alternatives to the strict split into KSK and ZSK key roles and the alternatives to the strict split into KSK and ZSK key roles and the
consequences for rollover logic from partial signing (i.e. when the consequences for rollover logic from partial signing (i.e. when the
new key initially only signs a fraction of the zone while leaving new key initially only signs a fraction of the zone while leaving
other signatures generated by the old key in place). other signatures generated by the old key in place).
Furthermore, as noted in section 5, this document covers only rolling Furthermore, as noted in section 5, this document covers only rolling
keys of the same algorithm, it does not cover transition to/from/ keys of the same algorithm, it does not cover transition to/from/
addition/deletion of different algorithm. Algorithm rollovers will addition/deletion of different algorithms. Algorithm rollovers will
require a separate document. require a separate document.
The reader is therefore reminded that DNSSEC is as of publication in The reader is therefore reminded that DNSSEC is as of publication in
early stages of deployment, and best practices will likely change in early stages of deployment, and best practices may further develop
the near term. over time.
7. Summary 7. Summary
For ZSKs, "Pre-Publication" is generally considered to be the For ZSKs, "Pre-Publication" is generally considered to be the
preferred way of rolling keys. As shown in this document, the time preferred way of rolling keys. As shown in this document, the time
taken to roll is wholly dependent on parameters under the control of taken to roll is wholly dependent on parameters under the control of
the zone manager. the zone manager.
In contrast, "Double-RRset" is the most efficient method for KSK In contrast, "Double-RRset" is the most efficient method for KSK
rollover due to the ability to have new DS records and DNSKEY RRsets 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 propagate in parallel. The time taken to roll KSKs may depend on
factors related to the parent zone if the parent is signed. For factors related to the parent zone if the parent is signed. For
zones that intend to comply with the recommendations of [RFC5011], in zones that intend to comply with the recommendations of [RFC5011], in
virtually all cases the rollover time will be determined by the virtually all cases the rollover time will be determined by the
RFC5011 "add hold-down" and "remove hold-down" times. It should be RFC5011 "add hold-down" and "remove hold-down" times. It should be
emphasized that this delay is a policy choice and not a function of emphasized that this delay is a policy choice and not a function of
timing values and that it also requires changes to the rollover timing values and that it also requires changes to the rollover
process due to the need to manage revocation of trust anchors. process due to the need to manage revocation of trust anchors.
Finally, the treatment of emergency key rollover is significantly Finally, the treatment of emergency key rollover is significantly
simplified by the introduction of stand-by keys as standard practice simplified by the introduction of standby keys as standard practice
during all types of rollovers. during all types of rollovers.
8. IANA Considerations 8. IANA Considerations
This memo includes no request to IANA. This memo includes no request to IANA.
9. Security Considerations 9. Security Considerations
This document does not introduce any new security issues beyond those This document does not introduce any new security issues beyond those
already discussed in [RFC4033], [RFC4034], [RFC4035] and [RFC5011]. already discussed in [RFC4033], [RFC4034], [RFC4035] and [RFC5011].
10. Acknowledgements 10. Acknowledgements
The authors gratefully acknowledge help and contributions from Roy The authors gratefully acknowledge help and contributions from Roy
Arends and Wouter Wijngaards. Arends, Matthijs Mekking and Wouter Wijngaards.
11. Change History 11. Change History (To be removed on publication)
o draft-ietf-dnsop-dnssec-key-timing-00 o draft-ietf-dnsop-dnssec-key-timing-02
* Significant re-wording of some sections.
* Removal of events noting change of state of predecessor key from
ZSK Double-RRSIG and Double-Signature methods.
* Change order of bullet points (and some wording) in section 1.1.
* Remove discussion of advantages and disadvantages of key roll
methods from section 2: draft is informative and does not give
recommendations.
* Removal of discussion of upper limit to retire time relationship
to signature lifetime.
* Remove timing details of first key in the zone and move
discussion of first signing of a zone to later in the document).
(Matthijs Mekking)
* Removal of redundant symbols from Appendix A.
o draft-ietf-dnsop-dnssec-key-timing-01
* Added section on limitation of scope. * Added section on limitation of scope.
o draft-ietf-dnsop-dnssec-key-timing-00
* Change to author contact details.
o draft-morris-dnsop-dnssec-key-timing-02 o draft-morris-dnsop-dnssec-key-timing-02
* General restructuring. * General restructuring.
* Added descriptions of more rollovers (IETF-76 meeting). * Added descriptions of more rollovers (IETF-76 meeting).
* Improved description of key states and removed diagram. * Improved description of key states and removed diagram.
* Provided simpler description of standby keys. * Provided simpler description of standby keys.
* Added section concerning first key in a zone. * Added section concerning first key in a zone.
* Moved [RFC5011] to a separate section. * Moved [RFC5011] to a separate section.
* Various nits fixed (Alfred Hoenes, Jeremy Reed, Scott Rose, Sion * Various nits fixed (Alfred Hoenes, Jeremy Reed, Scott Rose, Sion
Lloyd, Tony Finch). Lloyd, Tony Finch).
o draft-morris-dnsop-dnssec-key-timing-01 o draft-morris-dnsop-dnssec-key-timing-01
* Use latest boilerplate for IPR text. * Use latest boilerplate for IPR text.
* List different ways to roll a KSK (acknowledgements to Mark * List different ways to roll a KSK (acknowledgements to Mark
skipping to change at page 30, line 32 skipping to change at page 28, line 39
* Retained distinction between first and subsequent keys in * Retained distinction between first and subsequent keys in
definition of initial publication interval (Matthijs Mekking). definition of initial publication interval (Matthijs Mekking).
o draft-morris-dnsop-dnssec-key-timing-00 o draft-morris-dnsop-dnssec-key-timing-00
Initial draft. Initial draft.
12. References 12. References
12.1. Normative References 12.1. Normative References
[RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
NCACHE)", RFC 2308, March 1998. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements", Rose, "DNS Security Introduction and Requirements",
RFC 4033, March 2005. RFC 4033, March 2005.
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for the DNS Security Extensions", Rose, "Resource Records for the DNS Security Extensions",
RFC 4034, March 2005. RFC 4034, March 2005.
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
skipping to change at page 31, line 30 skipping to change at page 29, line 34
<TYPE> is an upper-case character indicating what type the symbol is. <TYPE> is an upper-case character indicating what type the symbol is.
Defined types are: Defined types are:
D delay: interval that is a feature of the process D delay: interval that is a feature of the process
I interval between two events I interval between two events
L lifetime: interval set by the zone manager L lifetime: interval set by the zone manager
SOA parameter related to SOA RR
T a point in time T a point in time
TTL TTL of a record TTL TTL of a record
T and I are self-explanatory. D, and L are also time periods, but I and T and TTL are self-explanatory. Like I, D, and L are time
whereas I values are intervals between two events (even if the events periods, but whereas I values are intervals between two events (even
are defined in terms of the interval, e.g. the dead time occurs if the events are defined in terms of the interval, e.g. the dead
"retire interval" after the retire time), D, and L are fixed time occurs "retire interval" after the retire time), D, and L are
intervals. An "L" interval (lifetime) is chosen by the zone manager fixed intervals: a "D" interval (delay) is a feature of the process,
and is a feature of policy. A "D" interval (delay) is a feature of probably outside control of the zone manager, whereas an "L" interval
the process, probably outside control of the zone manager. SOA and (lifetime) is chosen by the zone manager and is a feature of policy.
TTL are used just because they are common terms.
<id> is lower-case and defines what object or event the variable is <id> is lower-case and defines what object or event the variable is
related to, e.g. related to, e.g.
act active act activation
ngc negative cache
pub publication pub publication
ret retire
Finally, <INST> is a capital letter that distinguishes between the Finally, <INST> is a capital letter that distinguishes between the
same variable applying to different instances of an object and is one same variable applying to different instances of an object and is one
of: of:
C child C child
G signature G signature
K key K key
skipping to change at page 32, line 35 skipping to change at page 30, line 35
The list of variables used in the text is: The list of variables used in the text is:
Dprp Propagation delay. The amount of time for a change made at Dprp Propagation delay. The amount of time for a change made at
a master nameserver to propagate to all the slave a master nameserver to propagate to all the slave
nameservers. nameservers.
DprpC Propagation delay in the child zone. DprpC Propagation delay in the child zone.
DprpP Propagation delay in the parent zone. DprpP Propagation delay in the parent zone.
Dreg Registration delay. As a parent zone is often managed by a Dreg Registration delay: the time taken for a DS record
different organisation to that managing the child zone, the submitted to a parent zone to appear in it. As a parent
delays associated with passing data between zones is zone is often managed by a different organisation to that
captured by this term. managing the child zone, the delays associated with passing
data between zones is captured by this term.
Dskw Clock skew. The maximum difference in time between the
signing system and the resolver.
Dsgn Signing delay. After the introduction of a new ZSK, the Dsgn Signing delay. After the introduction of a new ZSK, the
amount of time taken for all the RRs in the zone to be amount of time taken for all the RRs in the zone to be
signed with it. signed with it.
Ingc Negative cache interval.
IngcP Negative cache interval of the child zone.
IngcP Negative cache interval of the parent zone.
Ipub Publication interval. The amount of time that must elapse Ipub Publication interval. The amount of time that must elapse
after the publication of a key before it can be considered after the publication of a key before it can be assumed
to have entered the ready state. that any resolvers that have the DNSKEY RRset cached have a
copy of this key.
IpubC Publication interval in the child zone. IpubC Publication interval in the child zone.
IpubG Publication interval for the signature. IpubG Publication interval for the signature created by a ZSK:
the amount of time that must elapse after the signature has
IpubK Publication interval for the key. been created before it can be assumed that any resolves
that have the RRset and RRSIG cached have a copy of this
signature.
IpubP Publication interval in the parent zone. IpubP Publication interval in the parent zone.
Iret Retire interval. The amount of time that must elapse after Iret Retire interval. The amount of time that must elapse after
a key enters the retire state for any signatures created a key enters the retire state for any signatures created
with it to be purged from validating resolver caches. with it to be purged from validating resolver caches.
Irev Revoke interval. The amount of time that a KSK must remain Irev Revoke interval. The amount of time that a KSK must remain
published with the revoke bit set to satisfy [RFC5011] published with the revoke bit set to satisfy [RFC5011]
considerations. considerations.
skipping to change at page 33, line 37 skipping to change at page 31, line 33
Lksk Lifetime of a key-signing key. This is the intended amount Lksk Lifetime of a key-signing key. This is the intended amount
of time for which this particular KSK is regarded as the of time for which this particular KSK is regarded as the
active KSK. Depending on when the key is rolled-over, the active KSK. Depending on when the key is rolled-over, the
actual lifetime may be longer or shorter than this. actual lifetime may be longer or shorter than this.
Lzsk Lifetime of a zone-signing key. This is the intended Lzsk Lifetime of a zone-signing key. This is the intended
amount of time for which the ZSK is used to sign the zone. amount of time for which the ZSK is used to sign the zone.
Depending on when the key is rolled-over, the actual Depending on when the key is rolled-over, the actual
lifetime may be longer or shorter than this. lifetime may be longer or shorter than this.
Lsig Lifetime of a signature: the difference in time between the Tact Activation time of the key; the time at which the key is
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 validating resolver.)
SOAmin Value of the "minimum" field from an SOA record.
SOAminC Value of the "minimum" field from an SOA record in the
child zone.
SOAminP Value of the "minimum" field from an SOA record in the
parent zone.
Tact Active time of the key; the time at which the key is
regarded as the principal key for the zone. regarded as the principal key for the zone.
TactS Active time of the successor key. TactS Activation time of the successor key.
Tdea Dead time of a key. Applicable only to ZSKs, this is the Tdea Dead time of a key. Applicable only to ZSKs, this is the
time at which any record signatures held in validating time at which any record signatures held in validating
resolver caches are guaranteed to be created with the resolver caches are guaranteed to be created with the
successor key. successor key.
Tgen Generate time of a key. The time that a key is created. Tgen Generate time of a key. The time that a key is created.
Tpub Publish time of a key. The time that a key appears in a Tpub Publication time of a key. The time that a key appears in
zone for the first time. a zone for the first time.
TpubS Publish time of the successor key. TpubS Publication time of the successor key.
Trem Removal time of a key. The time at which a key is removed Trem Removal time of a key. The time at which a key is removed
from the zone. from the zone.
Tret Retire time of a key. The time at which a successor key Tret Retire time of a key. The time at which a successor key
starts being used to sign the zone. starts being used to sign the zone.
Trdy Ready time of a key. The time at which it can be Trdy Ready time of a key. The time at which it can be
guaranteed that validating resolvers that have key guaranteed that validating resolvers that have key
information from this zone cached have a copy of this key information from this zone cached have a copy of this key
in their cache. (In the case of KSKs, should the in their cache. (In the case of KSKs, should the
validating resolvers also have DS information from the validating resolvers also have DS information from the
parent zone cached, the cache must include information parent zone cached, the cache must include information
about the DS record corresponding to the key.) about the DS record corresponding to the key.)
TrdyS Ready time of a successor key. TrdyS Ready time of a successor key.
Tsub Submit time - the time at which the DS record of a KSK is Tsub Submission time - the time at which the DS record of a KSK
submitted to the parent. is submitted to the parent.
TsubS Submit time of the successor key. TsubS Submission time of the successor key.
TTLds Time to live of a DS record (in the parent zone). TTLds Time to live of a DS record (in the parent zone).
TTLkey Time to live of a DNSKEY record. TTLkey Time to live of a DNSKEY record.
TTLkeyC Time to live of a DNSKEY record in the child zone. TTLsig The maximum time to live of all the RRSIG records in the
zone that were created with the ZSK.
TTLsoa Time to live of a SOA record.
TTLsoaC Time to live of a SOA record in the child zone.
TTLsoaP Time to live of a SOA record in the parent zone.
TTLsig Time to live of an RRSIG record.
Ttaa 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.
Authors' Addresses Authors' Addresses
Stephen Morris Stephen Morris
Internet Systems Consortium Internet Systems Consortium
950 Charter Street 950 Charter Street
Redwood City, CA 94063 Redwood City, CA 94063
USA USA
Phone: +1 650 423 1300 Phone: +1 650 423 1300
 End of changes. 175 change blocks. 
684 lines changed or deleted 553 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/