Internet-Draft SPARTA, Inc.
Updates: 4033, 4034, 4035, 5155 D. Blacka
(if approved) Verisign, Inc.
-Intended status: Standards Track April 30, 2012
-Expires: November 1, 2012
+Intended status: Standards Track July 13, 2012
+Expires: January 14, 2013
- Clarifications and Implementation Notes for DNSSECbis
- draft-ietf-dnsext-dnssec-bis-updates-18
+ Clarifications and Implementation Notes for DNSSEC
+ draft-ietf-dnsext-dnssec-bis-updates-19
Abstract
This document is a collection of technical clarifications to the
- DNSSECbis document set. It is meant to serve as a resource to
- implementors as well as a repository of DNSSECbis errata.
+ DNSSEC document set. It is meant to serve as a resource to
+ implementors as well as a repository of DNSSEC errata.
- This document updates the core DNSSECbis documents (RFC4033, RFC4034,
+ This document updates the core DNSSEC documents (RFC4033, RFC4034,
and RFC4035) as well as the NSEC3 specification (RFC5155). It also
- defines NSEC3 and SHA-2 as core parts of the DNSSECbis specification.
+ defines NSEC3 and SHA-2 as core parts of the DNSSEC specification.
Status of this Memo
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
- This Internet-Draft will expire on November 1, 2012.
+ This Internet-Draft will expire on January 14, 2013.
Copyright Notice
-Weiler & Blacka Expires November 1, 2012 [Page 1]
+Weiler & Blacka Expires January 14, 2013 [Page 1]
\f
-Internet-Draft DNSSECbis Implementation Notes April 2012
+Internet-Draft DNSSEC Implementation Notes July 2012
to this document. Code Components extracted from this document must
-Weiler & Blacka Expires November 1, 2012 [Page 2]
+Weiler & Blacka Expires January 14, 2013 [Page 2]
\f
-Internet-Draft DNSSECbis Implementation Notes April 2012
+Internet-Draft DNSSEC Implementation Notes July 2012
Table of Contents
1. Introduction and Terminology . . . . . . . . . . . . . . . . . 4
1.1. Structure of this Document . . . . . . . . . . . . . . . . 4
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
- 2. Important Additions to DNSSSECbis . . . . . . . . . . . . . . 4
+ 2. Important Additions to DNSSEC . . . . . . . . . . . . . . . . 4
2.1. NSEC3 Support . . . . . . . . . . . . . . . . . . . . . . 4
2.2. SHA-2 Support . . . . . . . . . . . . . . . . . . . . . . 5
3. Scaling Concerns . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. Clarifications on Non-Existence Proofs . . . . . . . . . . 5
4.2. Validating Responses to an ANY Query . . . . . . . . . . . 6
4.3. Check for CNAME . . . . . . . . . . . . . . . . . . . . . 6
- 4.4. Insecure Delegation Proofs . . . . . . . . . . . . . . . . 6
+ 4.4. Insecure Delegation Proofs . . . . . . . . . . . . . . . . 7
5. Interoperability Concerns . . . . . . . . . . . . . . . . . . 7
5.1. Errors in Canonical Form Type Code List . . . . . . . . . 7
5.2. Unknown DS Message Digest Algorithms . . . . . . . . . . . 7
5.3. Private Algorithms . . . . . . . . . . . . . . . . . . . . 8
- 5.4. Caution About Local Policy and Multiple RRSIGs . . . . . . 8
+ 5.4. Caution About Local Policy and Multiple RRSIGs . . . . . . 9
5.5. Key Tag Calculation . . . . . . . . . . . . . . . . . . . 9
5.6. Setting the DO Bit on Replies . . . . . . . . . . . . . . 9
5.7. Setting the AD Bit on Queries . . . . . . . . . . . . . . 9
- 5.8. Setting the AD Bit on Replies . . . . . . . . . . . . . . 9
+ 5.8. Setting the AD Bit on Replies . . . . . . . . . . . . . . 10
5.9. Always set the CD bit on Queries . . . . . . . . . . . . . 10
5.10. Nested Trust Anchors . . . . . . . . . . . . . . . . . . . 10
5.11. Mandatory Algorithm Rules . . . . . . . . . . . . . . . . 11
- 5.12. Ignore Extra Signatures From Unknown Keys . . . . . . . . 11
+ 5.12. Ignore Extra Signatures From Unknown Keys . . . . . . . . 12
6. Minor Corrections and Clarifications . . . . . . . . . . . . . 12
6.1. Finding Zone Cuts . . . . . . . . . . . . . . . . . . . . 12
6.2. Clarifications on DNSKEY Usage . . . . . . . . . . . . . . 12
- 6.3. Errors in Examples . . . . . . . . . . . . . . . . . . . . 12
+ 6.3. Errors in Examples . . . . . . . . . . . . . . . . . . . . 13
6.4. Errors in RFC 5155 . . . . . . . . . . . . . . . . . . . . 13
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
8. Security Considerations . . . . . . . . . . . . . . . . . . . 13
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
9.1. Normative References . . . . . . . . . . . . . . . . . . . 14
- 9.2. Informative References . . . . . . . . . . . . . . . . . . 14
+ 9.2. Informative References . . . . . . . . . . . . . . . . . . 15
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 15
- Appendix B. Discussion of Setting the CD Bit . . . . . . . . . . 15
- Appendix C. Discussion of Trust Anchor Preference Options . . . . 18
- C.1. Closest Encloser . . . . . . . . . . . . . . . . . . . . . 18
- C.2. Accept Any Success . . . . . . . . . . . . . . . . . . . . 19
- C.3. Preference Based on Source . . . . . . . . . . . . . . . . 19
- Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
+ Appendix B. Discussion of Setting the CD Bit . . . . . . . . . . 16
+ Appendix C. Discussion of Trust Anchor Preference Options . . . . 19
+ C.1. Closest Encloser . . . . . . . . . . . . . . . . . . . . . 19
+ C.2. Accept Any Success . . . . . . . . . . . . . . . . . . . . 20
+ C.3. Preference Based on Source . . . . . . . . . . . . . . . . 20
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
-Weiler & Blacka Expires November 1, 2012 [Page 3]
+Weiler & Blacka Expires January 14, 2013 [Page 3]
\f
-Internet-Draft DNSSECbis Implementation Notes April 2012
+Internet-Draft DNSSEC Implementation Notes July 2012
1. Introduction and Terminology
This document lists some additions, clarifications and corrections to
- the core DNSSECbis specification, as originally described in
- [RFC4033], [RFC4034], and [RFC4035], and later amended by [RFC5155].
- (See section Section 2 for more recent additions to that core
- document set.)
+ the core DNSSEC specification, as originally described in [RFC4033],
+ [RFC4034], and [RFC4035], and later amended by [RFC5155]. (See
+ section Section 2 for more recent additions to that core document
+ set.)
It is intended to serve as a resource for implementors and as a
repository of items that need to be addressed when advancing the
- DNSSECbis documents from Proposed Standard to Draft Standard.
+ DNSSEC documents along the Standards Track.
1.1. Structure of this Document
- The clarifications and changes to DNSSECbis are sorted according to
+ The clarifications and changes to DNSSEC are sorted according to
their importance, starting with ones which could, if ignored, lead to
security problems and progressing down to clarifications that are
expected to have little operational impact.
[RFC2119].
-2. Important Additions to DNSSSECbis
+2. Important Additions to DNSSEC
- This section lists some documents that should be considered core
- DNSSEC protocol documents in addition to those originally specified
- in Section 10 of [RFC4033].
+ This section lists some documents that are now considered core DNSSEC
+ protocol documents in addition to those originally specified in
+ Section 10 of [RFC4033].
2.1. NSEC3 Support
validation of responses using NSEC3 will be hampered in validating
large portions of the DNS space.
- [RFC5155] should be considered part of the DNS Security Document
- Family as described by [RFC4033], Section 10.
+ [RFC5155] is now considered part of the DNS Security Document Family
+ as described by [RFC4033], Section 10.
Note that the algorithm identifiers defined in RFC5155 (DSA-NSEC3-
SHA1 and RSASHA1-NSEC3-SHA1) and RFC5702 (RSASHA256 and RSASHA512)
- signal that a zone MAY be using NSEC3, rather than NSEC. The zone
+ signal that a zone might be using NSEC3, rather than NSEC. The zone
-Weiler & Blacka Expires November 1, 2012 [Page 4]
+Weiler & Blacka Expires January 14, 2013 [Page 4]
\f
-Internet-Draft DNSSECbis Implementation Notes April 2012
+Internet-Draft DNSSEC Implementation Notes July 2012
- MAY be using either and validators supporting these algorithms MUST
+ may be using either and validators supporting these algorithms MUST
support both NSEC3 and NSEC responses.
2.2. SHA-2 Support
Validator implementations are strongly encouraged to include support
for these algorithms for DS, DNSKEY, and RRSIG records.
- Both [RFC4509] and [RFC5702] should also be considered part of the
- DNS Security Document Family as described by [RFC4033], Section 10.
+ Both [RFC4509] and [RFC5702] are now considered part of the DNS
+ Security Document Family as described by [RFC4033], Section 10.
3. Scaling Concerns
3.1. Implement a BAD cache
Section 4.7 of RFC4035 permits security-aware resolvers to implement
- a BAD cache. Because of scaling concerns not discussed in this
- document, that guidance has changed: security-aware resolvers SHOULD
- implement a BAD cache as described in RFC4035.
+ a BAD cache. That guidance has changed: security-aware resolvers
+ SHOULD implement a BAD cache as described in RFC4035.
+
+ This change in guidance is based on operational experience with
+ DNSSEC administrative errors leading to significant increases in DNS
+ traffic, with an accompanying realization that such events are more
+ likely and more damaging than originally supposed. An example of one
+ such event is documented in "Roll Over and Die" [Huston].
4. Security Concerns
o the NS bit set,
o the SOA bit clear, and
+
+
+
+
+
+Weiler & Blacka Expires January 14, 2013 [Page 5]
+\f
+Internet-Draft DNSSEC Implementation Notes July 2012
+
+
o a signer field that is shorter than the owner name of the NSEC RR,
or the original owner name for the NSEC3 RR.
that (original) owner name other than DS RRs, and all RRs below that
owner name regardless of type.
-
-
-Weiler & Blacka Expires November 1, 2012 [Page 5]
-\f
-Internet-Draft DNSSECbis Implementation Notes April 2012
-
-
Similarly, the algorithm would also allow an NSEC RR at the same
owner name as a DNAME RR, or an NSEC3 RR at the same original owner
name as a DNAME, to prove the non-existence of names beneath that
4.3. Check for CNAME
- Section 5 of [RFC4035] says little about validating responses based
- on (or that should be based on) CNAMEs. When validating a NOERROR/
- NODATA response, validators MUST check the CNAME bit in the matching
- NSEC or NSEC3 RR's type bitmap in addition to the bit for the query
- type.
+ Section 5 of [RFC4035] says nothing explicit about validating
+ responses based on (or that should be based on) CNAMEs. When
+ validating a NOERROR/NODATA response, validators MUST check the CNAME
+ bit in the matching NSEC or NSEC3 RR's type bitmap in addition to the
+ bit for the query type.
Without this check, an attacker could successfully transform a
positive CNAME response into a NOERROR/NODATA response by (e.g.)
set, and thus the response should have been a positive CNAME
response.
+
+
+
+
+Weiler & Blacka Expires January 14, 2013 [Page 6]
+\f
+Internet-Draft DNSSEC Implementation Notes July 2012
+
+
4.4. Insecure Delegation Proofs
[RFC4035] Section 5.2 specifies that a validator, when proving a
alternately make sure that the delegation is covered by an NSEC3 RR
with the Opt-Out flag set.
-
-
-Weiler & Blacka Expires November 1, 2012 [Page 6]
-\f
-Internet-Draft DNSSECbis Implementation Notes April 2012
-
-
Without this check, an attacker could reuse an NSEC or NSEC3 RR
matching a non-delegation name to spoof an unsigned delegation at
that name. This would claim that an existing signed RRset (or set of
The existing text says:
+
+
+Weiler & Blacka Expires January 14, 2013 [Page 7]
+\f
+Internet-Draft DNSSEC Implementation Notes July 2012
+
+
If the validator does not support any of the algorithms listed in
an authenticated DS RRset, then the resolver has no supported
authentication path leading from the parent to the child. The
In other words, when determining the security status of a zone, a
validator disregards any authenticated DS records that specify
-
-
-
-Weiler & Blacka Expires November 1, 2012 [Page 7]
-\f
-Internet-Draft DNSSECbis Implementation Notes April 2012
-
-
unknown or unsupported DNSKEY algorithms. If none are left, the zone
is treated as if it were unsigned.
In the remaining cases, the security status of the zone depends on
whether or not the resolver supports any of the private algorithms in
- use (provided that these DS records use supported hash functions, as
- discussed in Section 5.2). In these cases, the resolver MUST
- retrieve the corresponding DNSKEY for each private algorithm DS
- record and examine the public key field to determine the algorithm in
- use. The security-aware resolver MUST ensure that the hash of the
- DNSKEY RR's owner name and RDATA matches the digest in the DS RR as
- described in Section 5.2 of [RFC4035], authenticating the DNSKEY. If
- all of the retrieved and authenticated DNSKEY RRs use unknown or
- unsupported private algorithms, then the zone is treated as if it
- were unsigned.
+ use (provided that these DS records use supported message digest
+ algorithms, as discussed in Section 5.2 of this document). In these
+ cases, the resolver MUST retrieve the corresponding DNSKEY for each
+ private algorithm DS record and examine the public key field to
+ determine the algorithm in use. The security-aware resolver MUST
+ ensure that the hash of the DNSKEY RR's owner name and RDATA matches
+ the digest in the DS RR as described in Section 5.2 of [RFC4035],
+ authenticating the DNSKEY. If all of the retrieved and authenticated
+ DNSKEY RRs use unknown or unsupported private algorithms, then the
+ zone is treated as if it were unsigned.
Note that if none of the private algorithm DS RRs can be securely
matched to DNSKEY RRs and no other DS establishes that the zone is
secure, the referral should be considered Bogus data as discussed in
+
+
+
+Weiler & Blacka Expires January 14, 2013 [Page 8]
+\f
+Internet-Draft DNSSEC Implementation Notes July 2012
+
+
[RFC4035].
This clarification facilitates the broader use of private algorithms,
When multiple RRSIGs cover a given RRset, [RFC4035] Section 5.3.3
suggests that "the local resolver security policy determines whether
-
-
-
-Weiler & Blacka Expires November 1, 2012 [Page 8]
-\f
-Internet-Draft DNSSECbis Implementation Notes April 2012
-
-
the resolver also has to test these RRSIG RRs and how to resolve
conflicts if these RRSIG RRs lead to differing results."
5.6. Setting the DO Bit on Replies
- As stated in [RFC3225], the DO bit of the query MUST be copied in the
- response. However, in order to interoperate with implementations
- that ignore this rule on sending, resolvers MUST ignore the DO bit in
- responses.
+ As stated in Section 3 of [RFC3225], the DO bit of the query MUST be
+ copied in the response. However, in order to interoperate with
+ implementations that ignore this rule on sending, resolvers MUST
+ ignore the DO bit in responses.
5.7. Setting the AD Bit on Queries
- The use of the AD bit in the query was previously undefined. This
- document defines it as a signal indicating that the requester
- understands and is interested in the value of the AD bit in the
- response. This allows a requestor to indicate that it understands
- the AD bit without also requesting DNSSEC data via the DO bit.
+ The semantics of the AD bit in the query were previously undefined.
+ Section 4.6 of [RFC4035] instructed resolvers to always clear the AD
+ bit when composing queries.
+
+ This document defines setting the AD bit in a query as a signal
+ indicating that the requester understands and is interested in the
+
+
+
+Weiler & Blacka Expires January 14, 2013 [Page 9]
+\f
+Internet-Draft DNSSEC Implementation Notes July 2012
+
+
+ value of the AD bit in the response. This allows a requestor to
+ indicate that it understands the AD bit without also requesting
+ DNSSEC data via the DO bit.
5.8. Setting the AD Bit on Replies
in RFC 4035, section 3.2.3, and the request contained either a set DO
bit or a set AD bit.
-
-
-Weiler & Blacka Expires November 1, 2012 [Page 9]
-\f
-Internet-Draft DNSSECbis Implementation Notes April 2012
-
-
5.9. Always set the CD bit on Queries
When processing a request with the CD bit set, a resolver SHOULD
does the cache need to track the state of the CD bit used to make a
given query. The problem arises when the cached response is a server
failure (RCODE 2), which may indicate that the requested data failed
- DNSSEC validation at an upstream validating resolver. (RFC2308
+ DNSSEC validation at an upstream validating resolver. ([RFC2308]
permits caching of server failures for up to five minutes.) In these
cases, a new query with the CD bit set is required.
trust to the response zone. For example, imagine a validator
configured with trust anchors for "example." and "zone.example."
When the validator is asked to validate a response to
+
+
+
+Weiler & Blacka Expires January 14, 2013 [Page 10]
+\f
+Internet-Draft DNSSEC Implementation Notes July 2012
+
+
"www.sub.zone.example.", either trust anchor could apply.
When presented with this situation, DNSSEC validators have a choice
The "Accept Any Success" policy is to try all applicable trust
anchors until one gives a validation result of Secure, in which case
-
-
-
-Weiler & Blacka Expires November 1, 2012 [Page 10]
-\f
-Internet-Draft DNSSECbis Implementation Notes April 2012
-
-
the final validation result is Secure. If and only if all applicable
trust anchors give a result of Insecure, the final validation result
is Insecure. If one or more trust anchors lead to a Bogus result and
Likewise, if there are DS records for multiple keys of the same
algorithm, any subset of those may appear in the DNSKEY RRset.
- Lastly, note that this a requirement at the server side, not the
- client side. Validators SHOULD accept any single valid path. They
- SHOULD NOT insist that all algorithms signaled in the DS RRset work,
- and they MUST NOT insist that all algorithms signaled in the DNSKEY
- RRset work. A validator MAY have a configuration option to perform a
- signature completeness test to support troubleshooting.
+ This requirement applies to servers, not validators. Validators
+ SHOULD accept any single valid path. They SHOULD NOT insist that all
+ algorithms signaled in the DS RRset work, and they MUST NOT insist
+ that all algorithms signaled in the DNSKEY RRset work. A validator
+ MAY have a configuration option to perform a signature completeness
+
+
+
+Weiler & Blacka Expires January 14, 2013 [Page 11]
+\f
+Internet-Draft DNSSEC Implementation Notes July 2012
+
+
+ test to support troubleshooting.
5.12. Ignore Extra Signatures From Unknown Keys
zone.
-
-
-Weiler & Blacka Expires November 1, 2012 [Page 11]
-\f
-Internet-Draft DNSSECbis Implementation Notes April 2012
-
-
6. Minor Corrections and Clarifications
6.1. Finding Zone Cuts
Appendix C.8 of [RFC4035] discusses sending DS queries to the servers
- for a parent zone. To do that, a resolver may first need to apply
- special rules to discover what those servers are.
-
- As explained in Section 3.1.4.1 of [RFC4035], security-aware name
- servers need to apply special processing rules to handle the DS RR,
- and in some situations the resolver may also need to apply special
- rules to locate the name servers for the parent zone if the resolver
- does not already have the parent's NS RRset. Section 4.2 of
- [RFC4035] specifies a mechanism for doing that.
+ for a parent zone but does not state how to find those servers.
+ Specific instructions can be found in Section 4.2 of [RFC4035].
6.2. Clarifications on DNSKEY Usage
also possible to use a single DNSKEY, with or without the SEP bit
set, to sign the entire zone, including the DNSKEY RRset itself.
+
+
+
+
+
+Weiler & Blacka Expires January 14, 2013 [Page 12]
+\f
+Internet-Draft DNSSEC Implementation Notes July 2012
+
+
6.3. Errors in Examples
The text in [RFC4035] Section C.1 refers to the examples in B.1 as
(antithetically, a label count of 3 would imply the answer was the
result of a wildcard expansion).
-
-
-Weiler & Blacka Expires November 1, 2012 [Page 12]
-\f
-Internet-Draft DNSSECbis Implementation Notes April 2012
-
-
The first paragraph of [RFC4035] Section C.6 also has a minor error:
the reference to "a.z.w.w.example" should instead be "a.z.w.example",
as in the previous line.
in the documents defining them. Additionally, this document
addresses some ambiguities and omissions in the core DNSSEC documents
that, if not recognized and addressed in implementations, could lead
+
+
+
+Weiler & Blacka Expires January 14, 2013 [Page 13]
+\f
+Internet-Draft DNSSEC Implementation Notes July 2012
+
+
to security failures. In particular, the validation algorithm
clarifications in Section 4 are critical for preserving the security
properties DNSSEC offers. Furthermore, failure to address some of
of trust anchors at an upstream validator.
-
-
-Weiler & Blacka Expires November 1, 2012 [Page 13]
-\f
-Internet-Draft DNSSECbis Implementation Notes April 2012
-
-
9. References
9.1. Normative References
and RRSIG Resource Records for DNSSEC", RFC 5702,
October 2009.
+
+
+
+Weiler & Blacka Expires January 14, 2013 [Page 14]
+\f
+Internet-Draft DNSSEC Implementation Notes July 2012
+
+
9.2. Informative References
+ [Huston] Michaelson, G., Wallstrom, P., Arends, R., and G. Huston,
+ "Roll Over and Die?", February 2010.
+
+ [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS
+ NCACHE)", RFC 2308, March 1998.
+
[RFC3755] Weiler, S., "Legacy Resolver Compatibility for Delegation
Signer (DS)", RFC 3755, May 2004.
July 2007.
[RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC)
-
-
-
-Weiler & Blacka Expires November 1, 2012 [Page 14]
-\f
-Internet-Draft DNSSECbis Implementation Notes April 2012
-
-
Trust Anchors", RFC 5011, September 2007.
[RFC5074] Weiler, S., "DNSSEC Lookaside Validation (DLV)", RFC 5074,
an editor of this document.
The editors are extremely grateful to those who, in addition to
- finding errors and omissions in the DNSSECbis document set, have
+ finding errors and omissions in the DNSSEC document set, have
provided text suitable for inclusion in this document.
The lack of specificity about handling private algorithms, as
The errors in the [RFC4035] examples were found by Roy Arends, who
also contributed text for Section 6.3 of this document.
+
+
+
+Weiler & Blacka Expires January 14, 2013 [Page 15]
+\f
+Internet-Draft DNSSEC Implementation Notes July 2012
+
+
Text on the mandatory algorithm rules was derived from suggestions by
Matthijs Mekking and Ed Lewis.
The editors would like to thank Alfred Hoenes, Ed Lewis, Danny Mayer,
Olafur Gudmundsson, Suzanne Woolf, Rickard Bellgrim, Mike St. Johns,
Mark Andrews, Wouter Wijngaards, Matthijs Mekking, Andrew Sullivan,
- and Scott Rose for their substantive comments on the text of this
+ Jeremy Reed, Paul Hoffman, Mohan Parthasarathy, Florian Weimer,
+ Warren Kumari and Scott Rose for their contributions to this
document.
Appendix B. Discussion of Setting the CD Bit
- RFC 4035 may be read as relying on the implicit assumption that there
- is at most one validating system between the stub resolver and the
- authoritative server for a given zone. It is entirely possible,
-
-
-
-Weiler & Blacka Expires November 1, 2012 [Page 15]
-\f
-Internet-Draft DNSSECbis Implementation Notes April 2012
-
-
+ [RFC4035] may be read as relying on the implicit assumption that
+ there is at most one validating system between the stub resolver and
+ the authoritative server for a given zone. It is entirely possible,
however, for more than one validator to exist between a stub resolver
and an authoritative server. If these different validators have
disjoint trust anchors configured, then it is possible that each
as local policy or from the API in the case of a stub). The second
column indicates whether the query needs to be forwarded for
resolution (F) or can be satisfied from a local cache (C). The third
+
+
+
+Weiler & Blacka Expires January 14, 2013 [Page 16]
+\f
+Internet-Draft DNSSEC Implementation Notes July 2012
+
+
column is a line number, so that it can be referred to later in the
table. The fourth column indicates any relevant conditions at the
resolver: whether the resolver has a covering trust anchor and so on.
final column indicates what action the resolver takes.
The tables differentiate between "cached data" and "cached RCODE=2".
- This is a shorthand; the point is that one has to treat RCODE=2 as
- special, because it might indicate a validation failure somewhere
- upstream. The distinction is really between "cached RCODE=2" and
- "cached everything else".
+ This is a shorthand; the point is that one has to treat RCODE=2
+ (server failure) as special, because it might indicate a validation
+ failure somewhere upstream. The distinction is really between
+ "cached RCODE=2" and "cached everything else".
The tables are probably easiest to think of in terms of describing
what happens when a stub resolver sends a query to an intermediate
resolver, but they are perfectly general and can be applied to any
validating resolver.
-
-
-
-
-
-Weiler & Blacka Expires November 1, 2012 [Page 16]
-\f
-Internet-Draft DNSSECbis Implementation Notes April 2012
-
-
Model 1: "always set"
This model is so named because the validating resolver sets the CD
0 C A5 covering TA Validate cached result and
return it.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Weiler & Blacka Expires January 14, 2013 [Page 17]
+\f
+Internet-Draft DNSSEC Implementation Notes July 2012
+
+
Model 2: "never set when receiving CD=0"
This model is so named because it sets CD=0 on upstream queries for
-Weiler & Blacka Expires November 1, 2012 [Page 17]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Weiler & Blacka Expires January 14, 2013 [Page 18]
\f
-Internet-Draft DNSSECbis Implementation Notes April 2012
+Internet-Draft DNSSEC Implementation Notes July 2012
Model 3: "sometimes set"
-Weiler & Blacka Expires November 1, 2012 [Page 18]
+Weiler & Blacka Expires January 14, 2013 [Page 19]
\f
-Internet-Draft DNSSECbis Implementation Notes April 2012
+Internet-Draft DNSSEC Implementation Notes July 2012
Encloser" policy would choose the "zone.example." trust anchor.
-Weiler & Blacka Expires November 1, 2012 [Page 19]
+Weiler & Blacka Expires January 14, 2013 [Page 20]
\f
-Internet-Draft DNSSECbis Implementation Notes April 2012
+Internet-Draft DNSSEC Implementation Notes July 2012
Conversely, a validator might choose to prefer manually configured
-Weiler & Blacka Expires November 1, 2012 [Page 20]
+Weiler & Blacka Expires January 14, 2013 [Page 21]
\f
Internet Engineering Task Force S. Morris
Internet-Draft ISC
Intended status: Informational J. Ihren
-Expires: September 11, 2011 Netnod
+Expires: January 10, 2013 Netnod
J. Dickinson
Sinodun
- March 10, 2011
+ July 9, 2012
DNSSEC Key Timing Considerations
- draft-ietf-dnsop-dnssec-key-timing-02.txt
+ draft-ietf-dnsop-dnssec-key-timing-03.txt
Abstract
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
- This Internet-Draft will expire on September 11, 2011.
+ This Internet-Draft will expire on January 10, 2013.
Copyright Notice
- Copyright (c) 2011 IETF Trust and the persons identified as the
+ Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
-Morris, et al. Expires September 11, 2011 [Page 1]
+Morris, et al. Expires January 10, 2013 [Page 1]
\f
-Internet-Draft DNSSEC Key Timing Considerations March 2011
+Internet-Draft DNSSEC Key Timing Considerations July 2012
the Trust Legal Provisions and are provided without warranty as
1.2. Types of Keys . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
1.4. Requirements Language . . . . . . . . . . . . . . . . . . 4
- 2. Rollover Methods . . . . . . . . . . . . . . . . . . . . . . . 4
- 2.1. ZSK Rollovers . . . . . . . . . . . . . . . . . . . . . . 4
+ 2. Rollover Methods . . . . . . . . . . . . . . . . . . . . . . . 5
+ 2.1. ZSK Rollovers . . . . . . . . . . . . . . . . . . . . . . 5
2.2. KSK Rollovers . . . . . . . . . . . . . . . . . . . . . . 6
2.3. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 7
- 3. Key Rollover Timelines . . . . . . . . . . . . . . . . . . . . 7
- 3.1. Key States . . . . . . . . . . . . . . . . . . . . . . . . 7
+ 3. Key Rollover Timelines . . . . . . . . . . . . . . . . . . . . 8
+ 3.1. Key States . . . . . . . . . . . . . . . . . . . . . . . . 8
3.2. Zone-Signing Key Timelines . . . . . . . . . . . . . . . . 9
3.2.1. Pre-Publication Method . . . . . . . . . . . . . . . . 9
- 3.2.2. Double-Signature Method . . . . . . . . . . . . . . . 11
+ 3.2.2. Double-Signature Method . . . . . . . . . . . . . . . 12
3.2.3. Double-RRSIG Method . . . . . . . . . . . . . . . . . 13
3.3. Key-Signing Key Rollover Timelines . . . . . . . . . . . . 15
- 3.3.1. Double-Signature Method . . . . . . . . . . . . . . . 15
+ 3.3.1. Double-Signature Method . . . . . . . . . . . . . . . 16
3.3.2. Double-DS Method . . . . . . . . . . . . . . . . . . . 18
3.3.3. Double-RRset Method . . . . . . . . . . . . . . . . . 21
3.3.4. Interaction with Configured Trust Anchors . . . . . . 23
- 3.3.4.1. Addition of KSK . . . . . . . . . . . . . . . . . 23
- 3.3.4.2. Removal of KSK . . . . . . . . . . . . . . . . . . 24
- 3.3.5. Introduction of First KSK . . . . . . . . . . . . . . 24
- 4. Standby Keys . . . . . . . . . . . . . . . . . . . . . . . . . 24
- 5. Algorithm Considerations . . . . . . . . . . . . . . . . . . . 25
+ 3.3.5. Introduction of First Keys . . . . . . . . . . . . . . 24
+ 4. Standby Keys . . . . . . . . . . . . . . . . . . . . . . . . . 25
+ 5. Algorithm Considerations . . . . . . . . . . . . . . . . . . . 26
6. Limitation of Scope . . . . . . . . . . . . . . . . . . . . . 26
7. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
9. Security Considerations . . . . . . . . . . . . . . . . . . . 27
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27
- 11. Change History (To be removed on publication) . . . . . . . . 27
- 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28
- 12.1. Normative References . . . . . . . . . . . . . . . . . . . 28
- 12.2. Informative References . . . . . . . . . . . . . . . . . . 29
- Appendix A. List of Symbols . . . . . . . . . . . . . . . . . . . 29
- Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 32
+ 11. Normative References . . . . . . . . . . . . . . . . . . . . . 27
+ Appendix A. List of Symbols . . . . . . . . . . . . . . . . . . . 28
+ Appendix B. Change History (To be removed on publication) . . . . 31
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33
-Morris, et al. Expires September 11, 2011 [Page 2]
+
+
+
+
+Morris, et al. Expires January 10, 2013 [Page 2]
\f
-Internet-Draft DNSSEC Key Timing Considerations March 2011
+Internet-Draft DNSSEC Key Timing Considerations July 2012
1. Introduction
o DNSKEY records and associated information (such as the associated
DS records or RRSIG records created with the key) are not only
held at the authoritative nameserver, they are also cached by
- resolvers. The data on these systems can be interlinked, e.g. a
+ resolvers. The data on these systems can be interlinked, e.g., a
validating resolver may try to validate a signature retrieved from
a cache with a key obtained separately.
zone 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
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
-Morris, et al. Expires September 11, 2011 [Page 3]
+Morris, et al. Expires January 10, 2013 [Page 3]
\f
-Internet-Draft DNSSEC Key Timing Considerations March 2011
+Internet-Draft DNSSEC Key Timing Considerations July 2012
+ A high-level overview of key rollover can be found in
+ [I-D.ietf-dnsop-rfc4641bis]. In contrast, this document focuses on
+ the low-level timing detail of two classes of operations described
+ there, the rollover of key-signing keys, and the rollover of zone
+ signing keys.
+
1.2. Types of Keys
Although DNSSEC validation treats all keys equally, [RFC4033]
document are to be interpreted as described in [RFC2119].
-2. Rollover Methods
-2.1. ZSK Rollovers
- A ZSK can be rolled in one of three ways:
+Morris, et al. Expires January 10, 2013 [Page 4]
+\f
+Internet-Draft DNSSEC Key Timing Considerations July 2012
+2. Rollover Methods
-Morris, et al. Expires September 11, 2011 [Page 4]
-\f
-Internet-Draft DNSSEC Key Timing Considerations March 2011
+2.1. ZSK Rollovers
+ A ZSK can be rolled in one of three ways:
- o Pre-Publication: described in [RFC4641], the new key is introduced
- into the DNSKEY RRset which is then re-signed. This state of
- affairs remains in place for long enough to ensure that any cached
- DNSKEY RRsets contain both keys. At that point signatures created
- with the old key can be replaced by those created with the new
- key, and the old signatures removed. During the re-signing
- process (which may or may not be atomic depending on how the zone
- is managed), it doesn't matter which key an RRSIG record retrieved
- by a resolver was created with; cached copies of the DNSKEY RRset
- will contain both the old and new keys.
+ o Pre-Publication: described in [I-D.ietf-dnsop-rfc4641bis], the new
+ key is introduced into the DNSKEY RRset which is then re-signed.
+ This state of affairs remains in place for long enough to ensure
+ that any cached DNSKEY RRsets contain both keys. At that point
+ signatures created with the old key can be replaced by those
+ created with the new key, and the old signatures removed. During
+ the re-signing process (which may or may not be atomic depending
+ on how the zone is managed), it doesn't matter which key an RRSIG
+ record retrieved by a resolver was created with; cached copies of
+ the DNSKEY RRset will contain both the old and new keys.
Once the zone contains only signatures created with the new key,
there is an interval during which RRSIG records created with the
signatures anywhere that were created using the old key, and it
can can be removed from the DNSKEY RRset.
- o Double-Signature: also mentioned in [RFC4641], this involves
- introducing the new key into the zone and using it to create
- additional RRSIG records; the old key and existing RRSIG records
- are retained. During the period in which the zone is being signed
- (again, the signing process may not be atomic), validating
- resolvers are always able to validate RRSIGs: any combination of
- old and new DNSKEY RRset and RRSIG allows at least one signature
- to be validated.
+ o Double-Signature: also mentioned in [I-D.ietf-dnsop-rfc4641bis],
+ this involves introducing the new key into the zone and using it
+ to create additional RRSIG records; the old key and existing RRSIG
+ records are retained. During the period in which the zone is
+ being signed (again, the signing process may not be atomic),
+ validating resolvers are always able to validate RRSIGs: any
+ combination of old and new DNSKEY RRset and RRSIG allows at least
+ one signature to be validated.
Once the signing process is complete and enough time has elapsed
to allow all old information to expire from caches, the old key
Once the signing process is complete and enough time has elapsed
to ensure that all caches that may contain an RR and associated
RRSIG have a copy of both signatures, the key is changed. After a
- further interval during which the old DNSKEY RRset expires from
- caches, the old signatures are removed from the zone.
-
- Of three methods, Double-Signature is conceptually the simplest -
- introduce the new key and new signatures, then approximately one TTL
- later remove the old key and old signatures. Pre-Publication is more
-Morris, et al. Expires September 11, 2011 [Page 5]
+Morris, et al. Expires January 10, 2013 [Page 5]
\f
-Internet-Draft DNSSEC Key Timing Considerations March 2011
+Internet-Draft DNSSEC Key Timing Considerations July 2012
+ further interval during which the old DNSKEY RRset expires from
+ caches, the old signatures are removed from the zone.
+
+ Of three methods, Double-Signature is conceptually the simplest -
+ introduce the new key and new signatures, then approximately one TTL
+ later remove the old key and old signatures. Pre-Publication is more
complex - introduce the new key, approximately one TTL later sign the
records, and approximately one TTL after that remove the old key.
Double-RRSIG is essentially the reverse of Pre-Publication -
For ZSKs, the issue for the validating resolver is to ensure that it
has access to the ZSK that corresponds to a particular signature. In
- the KSK case this can never be a problem as the KSK is only used for
- one signature (that over the DNSKEY RRset) and both the key the
+ the KSK case, this can never be a problem as the KSK is only used for
+ one signature (that over the DNSKEY RRset) and both the key and the
signature travel together. Instead, the issue is to ensure that the
KSK is trusted.
- Trust in the KSK is either due to the existence of a DS record in the
- parent zone (which is itself trusted) or an explicitly configured
+ Trust in the KSK is either due to the existence of a signed and
+ validated DS record in the parent zone or an explicitly configured
trust anchor. If the former, the rollover algorithm will need to
involve the parent zone in the addition and removal of DS records, so
timings are not wholly under the control of the zone manager. If the
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
and new key. After waiting for the old RRset to expire from
- caches, the DS record in the parent zone is changed. After
- waiting a further interval for this change to be reflected in
- caches, the old key is removed from the RRset. (The name "Double-
- Signature" is used because, like the ZSK method of the same name,
- the new key is introduced and immediately used for signing.)
-
-Morris, et al. Expires September 11, 2011 [Page 6]
+Morris, et al. Expires January 10, 2013 [Page 6]
\f
-Internet-Draft DNSSEC Key Timing Considerations March 2011
+Internet-Draft DNSSEC Key Timing Considerations July 2012
+ caches, the DS record in the parent zone is changed. After
+ waiting a further interval for this change to be reflected in
+ caches, the old key is removed from the RRset. (The name "Double-
+ Signature" is used because, like the ZSK method of the same name,
+ the new key is introduced and immediately used for signing.)
+
o Double-DS: the new DS record is published. After waiting for this
change to propagate into caches, the KSK is changed. After a
further interval during which the old DNSKEY RRset expires from
| ZSK Method | KSK Method | Description |
+------------------+------------------+-----------------------------+
| Pre-Publication | (not applicable) | Publish the DNSKEY before |
- | | | the RRSIG. |
+ | | | the RRSIGs. |
| Double-Signature | Double-Signature | Publish the DNSKEY and |
- | | | RRSIG at same time. (For a |
+ | | | RRSIGs at same time. For a |
| | | KSK, this happens before |
- | | | the DS is published.) |
- | Double-RRSIG | (not applicable) | Publish RRSIG before the |
+ | | | the DS is published. |
+ | Double-RRSIG | (not applicable) | Publish RRSIGs before the |
| | | DNSKEY. |
| (not applicable) | Double-DS | Publish DS before the |
| | | DNSKEY. |
Table 1
-3. Key Rollover Timelines
-3.1. Key States
- During the rolling process, a key moves through different states.
- The defined states are:
+Morris, et al. Expires January 10, 2013 [Page 7]
+\f
+Internet-Draft DNSSEC Key Timing Considerations July 2012
-Morris, et al. Expires September 11, 2011 [Page 7]
-\f
-Internet-Draft DNSSEC Key Timing Considerations March 2011
+3. Key Rollover Timelines
+
+3.1. Key States
+ During the rolling process, a key moves through different states.
+ The defined states are:
Generated The key has been created, but has not yet been used for
anything.
information".
Ready The new key data has been published for long enough to
- guarantee that any previous versions of it have expired
- from caches.
+ guarantee that any previous versions of the DNSKEY RRset
+ have expired from caches.
Active The key has started to be used to sign RRsets. Note that
when this state is entered, it may not be possible for
case, the resolver will have to rely on the key's
predecessor instead.
- Retired The key is in the zone but a successor key has become
- active. As there may still be information in caches that
- that require use of the key, it is being retained until
- this information expires.
+ Retired A successor key has become active and this key is no
+ longer being used to generate RRSIGs. However, as there
+ may still be RRSIGs in caches that were generated using
+ this key, it is being retained in the zone until they
+ have expired.
Dead The key is published in the zone but there is no longer
information anywhere that requires its presence. Hence
the key can be removed from the zone at any time.
+
+
+
+
+
+
+Morris, et al. Expires January 10, 2013 [Page 8]
+\f
+Internet-Draft DNSSEC Key Timing Considerations July 2012
+
+
Removed The key has been removed from the zone.
There is one additional state, used where [RFC5011] considerations
configured it as an [RFC5011] trust anchor that it is
about to be removed from the zone.
-
-
-
-
-Morris, et al. Expires September 11, 2011 [Page 8]
-\f
-Internet-Draft DNSSEC Key Timing Considerations March 2011
-
-
3.2. Zone-Signing Key Timelines
The following sections describe the rolling of a ZSK. They show the
---- Time ---->
-
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
to its publication in the zone (Event 2), some implementations may
find it convenient to create a pool of keys in one operation and draw
separate event. Keys that are available for use but not published
are said to be generated.
- Event 2: key N's DNSKEY record is put into the zone, i.e. it is added
- to the DNSKEY RRset which is then re-signed with the current key-
- signing key. The time at which this occurs is the key's publication
- time (Tpub), and the key is now said to be published. Note that the
- key is not yet used to sign records.
+ Event 2: Key N's DNSKEY record is put into the zone, i.e., it is
+ added to the DNSKEY RRset which is then re-signed with the current
+ key-signing key. The time at which this occurs is the key's
- Event 3: before it can be used, the key must be published for long
- enough to guarantee that any cached version of the zone's DNSKEY
- RRset includes this key.
- This interval is the publication interval (Ipub) and, for the second
- or subsequent keys in the zone, is given by:
+Morris, et al. Expires January 10, 2013 [Page 9]
+\f
+Internet-Draft DNSSEC Key Timing Considerations July 2012
-Morris, et al. Expires September 11, 2011 [Page 9]
-\f
-Internet-Draft DNSSEC Key Timing Considerations March 2011
+ publication time (Tpub), and the key is now said to be published.
+ Note that the key is not yet used to sign records.
+ Event 3: Before it can be used, the key must be published for long
+ enough to guarantee that any cached version of the zone's DNSKEY
+ RRset includes this key.
+
+ This interval is the publication interval (Ipub) and, for the second
+ or subsequent keys in the zone, is given by:
Ipub = Dprp + TTLkey
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 activation time (Tact) and after this, the
key is said to be active.
- Event 5: at some point thought must be given to its successor (key
+ Event 5: At some point thought must be given to its successor (key
N+1). As with the introduction of the currently active key into the
zone, the successor key will need to be published at least Ipub
before it is activated. Denoting the publication time of the
their assessment of the risks posed by continuing to use a key and
the risks associated with key rollover. However, operational
considerations may mean a key is active for slightly more or less
- than Lzsk.
- Event 6: while key N is still active, its successor becomes ready.
- From this time onwards, key N+1 could be used to sign the zone.
- Event 7: When key N has been in use for an interval equal to the the
- ZSK lifetime, it is retired (i.e. it will never again be used to
- generate new signatures) and key N+1 activated and used to sign the
- zone. This is the retire time of key N (Tret) and is given by:
+Morris, et al. Expires January 10, 2013 [Page 10]
+\f
+Internet-Draft DNSSEC Key Timing Considerations July 2012
+ than Lzsk.
-Morris, et al. Expires September 11, 2011 [Page 10]
-\f
-Internet-Draft DNSSEC Key Timing Considerations March 2011
+ Event 6: While key N is still active, its successor becomes ready.
+ From this time onwards, key N+1 could be used to sign the zone.
+ Event 7: When key N has been in use for an interval equal to the ZSK
+ lifetime, it is retired (i.e., it will never again be used to
+ generate new signatures) and key N+1 activated and used to sign the
+ zone. This is the retire time of key N (Tret) and is given by:
Tret = Tact + Lzsk
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
or held in caches. (It is possible that a validating resolver could
have an unexpired RRSIG record and an expired DNSKEY RRset in the
re-signed with the new key. Dprp is (as described above) the
propagation delay, required to guarantee that the updated zone
information has reached all slave servers, and TTLsig is the maximum
- TTL of all the RRSIG records in the zone.
+ TTL of all the RRSIG records in the zone created with the ZSK.
The time at which all RRSIG records created with this key have
expired from resolver caches is the dead time (Tdea), given by:
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
- from the zone and the DNSKEY RRset re-signed with the current key-
- signing key. This time is the removal time (Trem), given by:
+ Event 9: At any time after the key becomes dead, it can be removed
+ from the zone's DNSKEY RRset, which must then be re-signed with the
+ current key-signing key. This time is the removal time (Trem), given
+ by:
- Trem >= Tdea
- ...at which time the key is said to be removed.
-3.2.2. Double-Signature Method
- The timeline for a double-signature rollover is shown below. The
- diagram follows the convention described in Section 3.2.1
+Morris, et al. Expires January 10, 2013 [Page 11]
+\f
+Internet-Draft DNSSEC Key Timing Considerations July 2012
+ Trem >= Tdea
+ ... at which time the key is said to be removed.
+3.2.2. Double-Signature Method
+ The timeline for a double-signature rollover is shown below. The
+ diagram follows the convention described in Section 3.2.1
-Morris, et al. Expires September 11, 2011 [Page 11]
-\f
-Internet-Draft DNSSEC Key Timing Considerations March 2011
|1| |2| |3| |4| |5|
---- Time ---->
-
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
to its publication in the zone (Event 2), some implementations may
find it convenient to create a pool of keys in one operation and draw
separate event. Keys that are available for use but not published
are said to be generated.
- Event 2: key N is added to the DNSKEY RRset and is then used to sign
+ Event 2: Key N is added to the DNSKEY RRset and is then used to sign
the zone; existing signatures in the zone are not removed. This is
the activation time (Tact), after which the key is said to be active.
- Event 3: after the current key (key N) has been in use for its
+ Event 3: After the current key (key N) has been in use for its
intended lifetime (Lzsk), the successor key (key N+1) is introduced
into the zone and starts being used to sign RRsets: neither the
current key nor the signatures created with it are removed. The
Tret = Tact + Lzsk
- Event 4: 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 (key
N+1) and any old RRsets that do not include the new key or new RRSIGs
+
+
+
+Morris, et al. Expires January 10, 2013 [Page 12]
+\f
+Internet-Draft DNSSEC Key Timing Considerations July 2012
+
+
must have expired from caches. Note that the signatures are not
replaced - each RRset is signed by both the old and new key.
Iret = Dsgn + Dprp + max(TTLkey, TTLsig)
As before, Dsgn is the delay needed to ensure that all existing
- RRsets have been signed with the new key, Dprp is the propagation
+ RRsets have been signed with the new key and Dprp is the propagation
delay. The final term (the maximum of TTLkey and TTLsig) is the
-
-
-
-Morris, et al. Expires September 11, 2011 [Page 12]
-\f
-Internet-Draft DNSSEC Key Timing Considerations March 2011
-
-
period to wait for key and signature data associated with key N to
expire from caches. (TTLkey is the TTL of the DNSKEY RRset and
TTLsig is the maximum TTL of all the RRSIG records in the zone
- created with the ZSK. The two may be different as although the TTL
- of an RRSIG is equal to the TTL of the RRs in the associated RRset
+ created with the ZSK. The two may be different: 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
Tdea = Tret + Iret
- 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:
+ Event 5: At some later time key N and the signatures generated with
+ it can be removed from the zone. This is the removal time Trem,
+ given by:
Trem >= Tdea
---- Time ---->
-
Figure 3: Timeline for a Double-Signature ZSK rollover.
- Event 1: key N is generated at the generate time (Tgen). Although
+
+
+
+Morris, et al. Expires January 10, 2013 [Page 13]
+\f
+Internet-Draft DNSSEC Key Timing Considerations July 2012
+
+
+ Event 1: Key N is generated at the generate time (Tgen). Although
there is no reason why the key cannot be generated immediately prior
to its publication in the zone (Event 2), some implementations may
find it convenient to create a pool of keys in one operation and draw
separate event. Keys that are available for use but not published
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
-
-
-
-Morris, et al. Expires September 11, 2011 [Page 13]
-\f
-Internet-Draft DNSSEC Key Timing Considerations March 2011
-
-
point, for analogy with the other ZSK rollover methods and because
this is the first time that key information is visible (albeit
indirectly through the created signatures) this time is called the
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
RRsets are now signed twice, once by the (still-absent) key N and
once by its predecessor.
- Event 4: there is now a delay while the old signature information
+ Event 4: There is now a delay while the old signature information
expires from caches. This interval is given by the expression:
Dprp + TTLsig
As before, Dprp is the propagation delay and TTLsig is the maximum
- TTL of all the RRSIG records in the zone.
+ TTL of all the RRSIG records in the zone created with the ZSK.
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
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
- publication interval of the signature, IpubG, i.e.
+ publication interval of the signature, IpubG, i.e.,
Trdy = Tpub + IpubG
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 signed RRs have
signatures created by the old and new keys, the records can still be
authenticated. This time is the activation time (Tact) and the key
is now said to be active.
- Event 6: at some point thought must be given to rolling the key. The
+ Event 6: At some point thought must be given to rolling the key. The
first step is to publish signatures created by the successor key (key
+
+
+
+Morris, et al. Expires January 10, 2013 [Page 14]
+\f
+Internet-Draft DNSSEC Key Timing Considerations July 2012
+
+
N+1) early enough for key N to be replaced after it has been active
for its scheduled lifetime. This occurs at TpubS (the publication
time of the successor), given by:
TpubS <= Tact + Lzsk - IpubG
- Event 7: the signatures have propagated and the new key could be
+ Event 7: The signatures have propagated and the new key could be
added to the zone. This time is the ready time of the successor key
(TrdyS).
-
-
-
-Morris, et al. Expires September 11, 2011 [Page 14]
-\f
-Internet-Draft DNSSEC Key Timing Considerations March 2011
-
-
TrdyS = TpubS + IpubG
... where IpubG is as defined above.
- Event 8: at some later time key N is removed from the zone and the
- successor key (key N+1) added. This is the retire time of the key
- (Tret).
+ Event 8: At some later time key N is removed from the zone's DNSKEY
+ RRset and the successor key (key N+1) is added to it. This is the
+ retire time of the key (Tret).
- Event 9: 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.
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 as
- 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:
+ of use and can be considered to be dead as they cannot 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
Dprp is as defined earlier and TTLkey is the TTL of the DNSKEY RRset.
- Event 10: at some later time the signatures can be removed from the
- zone. In analogy with other rollover methods this time is called the
- remove time (Trem) and is given by:
+ Event 10: At some later time the signatures can be removed from the
+ zone. In analogy with other rollover methods, this time is called
+ the remove time (Trem) and is given by:
Trem >= Tdea
events in the lifetime of a key (referred to as "key N") and cover it
replacement by its successor (key N+1).
-3.3.1. Double-Signature Method
-
- The timeline for a double-signature rollover is shown below. The
- diagram follows the convention described in Section 3.2.1
-
+Morris, et al. Expires January 10, 2013 [Page 15]
+\f
+Internet-Draft DNSSEC Key Timing Considerations July 2012
+3.3.1. Double-Signature Method
+ The timeline for a double-signature rollover is shown below. The
+ diagram follows the convention described in Section 3.2.1
-Morris, et al. Expires September 11, 2011 [Page 15]
-\f
-Internet-Draft DNSSEC Key Timing Considerations March 2011
|1| |2| |3| |4| |5|
---- Time ---->
- (continued...)
+ (continued ...)
|6| |7| |8| |9| |10| |11|
| | | | | |
---- Time (cont) ---->
-
Figure 4: Timeline for a Double-Signature KSK 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
to its publication in the zone (Event 2), some implementations may
find it convenient to create a pool of keys in one operation and draw
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.
(So at this point, the DNSKEY RRset is signed by both key N and its
predecessor KSK. If other KSKs were active, it is signed by these as
well.) This is the publication time (Tpub); after this the key is
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
+
+
+
+Morris, et al. Expires January 10, 2013 [Page 16]
+\f
+Internet-Draft DNSSEC Key Timing Considerations July 2012
+
+
the DNSKEY RRset in its cache will have a copy of the RRset that
includes this key: in other words, that any prior cached information
about the DNSKEY RRset has expired.
The interval is the publication interval (Ipub) and, for the second
or subsequent KSKs in the zone, is given by:
-
-
-Morris, et al. Expires September 11, 2011 [Page 16]
-\f
-Internet-Draft DNSSEC Key Timing Considerations March 2011
-
-
Ipub = DprpC + TTLkey
... where DprpC is the propagation delay for the child zone (the zone
(The case of introducing the first KSK into the zone is discussed in
Section 3.3.5.)
- Event 4: at some later time, the DS record corresponding to the new
+ 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
and DS record - is available in the two zones, in analogy with other
rollover methods, this is called the activation time of the key
entities, and this term accounts for the organisational overhead of
transferring a record.)
- Event 6: while key N is active, thought needs to be given to its
+ Event 6: While key N is active, thought needs to be given to its
successor (key N+1). At some time before the scheduled end of the
KSK lifetime, the successor KSK is published in the zone. (As
before, this means that the DNSKEY RRset is signed by both the
... where Lksk is the scheduled lifetime of the KSK.
- Event 7: after an interval Ipub, key N+1 becomes ready (in that all
- caches that have a copy of the DNSKEY RRset have a copy of this key).
- This time is the ready time of the successor (TrdyS).
- Event 8: at the submission time of the successor (TsubS), the DS
- record corresponding to key N+1 is submitted to the parent zone.
+Morris, et al. Expires January 10, 2013 [Page 17]
+\f
+Internet-Draft DNSSEC Key Timing Considerations July 2012
-Morris, et al. Expires September 11, 2011 [Page 17]
-\f
-Internet-Draft DNSSEC Key Timing Considerations March 2011
+ Event 7: After an interval Ipub, key N+1 becomes ready (in that all
+ caches that have a copy of the DNSKEY RRset have a copy of this key).
+ This time is the ready time of the successor (TrdyS).
+ Event 8: At the submission time of the successor (TsubS), the DS
+ record corresponding to key N+1 is submitted to the parent zone.
- Event 9: 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
retired and the time at which this occurs is Tret, given by:
Tret = Tact + Lksk
- Event 10: key N must remain in the zone until any caches that contain
+ 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.
This interval is the retire interval, given by:
Tdea = Tret + Iret
- 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.
+ Event 11: At some later time, key N is removed from the zone's DNSKEY
+ RRset (at the remove time Trem); the key is now said to be removed.
Trem >= Tdea
-
-
-
-
-
-
-
-Morris, et al. Expires September 11, 2011 [Page 18]
+Morris, et al. Expires January 10, 2013 [Page 18]
\f
-Internet-Draft DNSSEC Key Timing Considerations March 2011
+Internet-Draft DNSSEC Key Timing Considerations July 2012
|1| |2| |3| |4| |5| |6|
---- Time ---->
- (continued...)
+ (continued ...)
|7| |8| |9| |10|
| | | |
---- Time ---->
-
Figure 5: Timeline for a Double-DS KSK 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
to its publication in the zone (Event 2), some implementations may
find it convenient to create a pool of keys in one operation and draw
separate event. Keys that are available for use but not published
are said to be generated.
- Event 2: the DS RR is submitted to the parent zone for publication.
+ Event 2: The DS RR is submitted to the parent zone for publication.
This time is the submission time, 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,
given by:
Tpub = Tsub + Dreg
- Event 4: at some later time, any cache that has a copy of the DS
+ Event 4: At some later time, any cache that has a copy of the DS
RRset will have a copy of the DS record for key N. At this point, key
N, if introduced into the DNSKEY RRset, could be used to validate the
zone. For this reason, this time is known as the key's ready time,
-Morris, et al. Expires September 11, 2011 [Page 19]
+
+Morris, et al. Expires January 10, 2013 [Page 19]
\f
-Internet-Draft DNSSEC Key Timing Considerations March 2011
+Internet-Draft DNSSEC Key Timing Considerations July 2012
Trdy = Tpub + IpubP
... where DprpP is the propagation delay for the parent zone and
TTLds the TTL assigned to DS records in that zone.
- Event 5: at some later time, the key rollover takes place and the new
- key (key N) introduced and used to sign the RRset.
+ Event 5: At some later time, the key rollover takes place and the new
+ key (key N) is introduced into the DNSKEY RRset and used to sign
+ that.
As both the old and new DS records have been in the parent zone long
enough to ensure that they are in caches that contain the DS RRset,
- the zone can be authenticated throughout the rollover - either the
- resolver has a copy of the DNSKEY RRset authenticated by the
- predecessor key, or it has a copy of the updated RRset authenticated
- with the new key.
+ the zone can be authenticated throughout the rollover - the
+ validating resolver either has a copy of the DNSKEY RRset
+ authenticated by the predecessor key, or it has a copy of the updated
+ RRset authenticated with the new key.
This time is key N's activation time (Tact) and at this point the key
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
at a time such that when the current key is withdrawn, any cache that
- contains the zone's DS records have data about the DS record of the
+ contains the zone's DS records has data about the DS record of the
successor key. The time at which this occurs is the submission time
of the successor, given by:
... 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
- DS record is now in caches that contain the parent DS RRset. This is
- the ready time of the successor key, TrdyS.
+ Event 7: The successor key (key N+1) enters the ready state, i.e.,
+ its DS record is now in caches that contain the parent DS RRset.
+ This is the ready time of the successor key, TrdyS.
(The interval between events 6 and 7 for the key N+1 correspond to
- the the interval between events 2 and 4 for key N)
+ the interval between events 2 and 4 for key N)
- 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:
+ Event 8: When key N has been active for its lifetime (Lksk), it is
+ replaced in the DNSKEY RRset by key N+1; the RRset is then signed
+ with the new key. This is the retire time (Tret) of key N, given by:
-Morris, et al. Expires September 11, 2011 [Page 20]
+Morris, et al. Expires January 10, 2013 [Page 20]
\f
-Internet-Draft DNSSEC Key Timing Considerations March 2011
+Internet-Draft DNSSEC Key Timing Considerations July 2012
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. In
analogy with other rollover methods, this is called the dead time,
Tdea, and is given by:
RRset change through the master-slave hierarchy of the child zone and
TTLkey, the time taken for the DNSKEY RRset to expire from caches.
- Event 10: at some later time, the DS record is removed from the
+ Event 10: At some later time, the DS record is removed from the
parent zone. In analogy with other rollover methods, this is the
removal time (Trem), given by:
---- Time ---->
-
Figure 6: Timeline for a Double-RRset KSK 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
to its publication in the zone (Event 2), some implementations may
find it convenient to create a pool of keys in one operation and draw
from that pool as required. For this reason, it is shown as a
+ separate event. Keys that are available for use but not published
-Morris, et al. Expires September 11, 2011 [Page 21]
+Morris, et al. Expires January 10, 2013 [Page 21]
\f
-Internet-Draft DNSSEC Key Timing Considerations March 2011
+Internet-Draft DNSSEC Key Timing Considerations July 2012
- 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
corresponding DS record is submitted to the parent zone for
publication. This time is the publish time (Tpub) and the key is now
said to be published.
- Event 3: at some later time, the DS record is published in the parent
+ Event 3: At some later time, the DS record is published in the parent
zone and at some time after that, the updated information has reached
all caches: any cache that holds a DNSKEY RRset from the child zone
will have a copy that includes the new KSK, and any cache that has a
... where DprpC is the propagation delay in the child zone and TTLkey
the TTL of a DNSKEY record.
- Event 4: at some point we need to give thought to key replacement.
+ Event 4: At some point we need to give thought to key replacement.
The successor key (key N+1) must be introduced into the zone (and its
DS record 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:
-Morris, et al. Expires September 11, 2011 [Page 22]
+Morris, et al. Expires January 10, 2013 [Page 22]
\f
-Internet-Draft DNSSEC Key Timing Considerations March 2011
-
+Internet-Draft DNSSEC Key Timing Considerations July 2012
- given by:
TpubS <= Tact + Lksk - Ipub
... where Lksk is the lifetime of the KSK.
- Event 5: key N+1's DNSKEY and DS records are in any caches that
+ 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
Tret = Tdea = TactS = Tact + Lksk
- Event 6: at some later time, the key N's DS and DNSKEY records can be
+ Event 6: At some later time, the key N's DS and DNSKEY records are
removed from their respective zones. In analogy with other rollover
methods, this is the removal time (Trem), given by:
the Double-Signature and Double-RRset methods should also be subject
to the condition:
- Ipub >= Dprp + max(30 days, TTLkey)
+ Ipub >= Dprp + max(Itrp, TTLkey)
... where the right hand side of the expression is the time taken for
- the change to propagate to all nameservers for the zone plus the add
- hold-down time defined in section 2.4.1 of [RFC5011].
+ the change to propagate to all nameservers for the zone plus the
+ "trust point" interval. This latter term is the interval required to
+ guarantee that a resolver configured for the automatic update of keys
+ from a particular trust point will see at least two validated DNSKEY
+ RRsets containing the new key (a requirement from [RFC5011], section
+ 2.4.1). It is defined by the expression:
- In the Double-DS method, instead of the changing of the KSK RR being
-
-Morris, et al. Expires September 11, 2011 [Page 23]
+Morris, et al. Expires January 10, 2013 [Page 23]
\f
-Internet-Draft DNSSEC Key Timing Considerations March 2011
+Internet-Draft DNSSEC Key Timing Considerations July 2012
+
+
+ Itrp >= (2 * queryInterval) + (n * retryTime)
+ ... where queryInterval and retryTime are as defined in section 2.3
+ of [RFC5011]. "n" is the total number of retries needed by the
+ resolver during the two attempts to get the DNSKEY RRset.
- instantaneous, there must now be a period of overlap. In other
- words, the new KSK must be introduced into the zone at least:
+ The first term of the expression (2 * queryInterval) represents the
+ time to obtain two validated DNSKEY RRsets. The second term (n *
+ retryTime) is a safety margin, with the value of "n" reflecting the
+ degree of confidence in the communication between a resolver and the
+ trust point.
- DprpC + max(30 days, TTLkey)
+ In the Double-DS method, instead of swapping the KSK RRs in a single
+ step, there must now be a period of overlap. In other words, the new
+ KSK must be introduced into the zone at least:
+
+ DprpC + max(Itrp, TTLkey)
... before the switch is made.
The timeline for the removal of the key in all methods is modified by
introducing a new state, "revoked". When the key reaches its dead
time, instead of being declared "dead", it is revoked; the "revoke"
- bit is set on the DNSKEY RR and is published in (and used to sign)
- the DNSKEY RRset. The key is maintained in this state for the
- "revoke" interval, Irev, given by:
+ bit is set in the published DNSKEY RR, and the DNSKEY RRset re-signed
+ with the current and revoked keys. The key is maintained in this
+ state for the "revoke" interval, Irev, given by:
Irev >= 30 days
... 30 days being the [RFC5011] remove hold-down time. After this
time, the key is dead and can be removed from the zone.
-3.3.5. Introduction of First KSK
+3.3.5. Introduction of First Keys
- There is an additional consideration when introducing a KSK into a
- 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
- the KSK appears in the zone. To do so will cause it to declare the
- zone to be bogus.
+ There are no timing considerations associated with the introduction
+ of the first keys into a zone other that they must be introduced and
+ the zone validly signed before a chain of trust to the zone is
+ created.
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
no possibility that a validating resolver can obtain the record yet
- not be able to obtain the corresponding DNSKEY. In the case of an
- insecure parent, i.e. the initial creation of a new security apex, it
- is not possible to guarantee this. It is up to the operator of the
- validating resolver to wait for the new KSK to appear at all servers
- for the zone before configuring the trust anchor.
+ is not able to obtain the corresponding DNSKEY. In the case of an
+ insecure parent, i.e., the initial creation of a new security apex,
+ it is not possible to guarantee this. It is up to the operator of
+ the validating resolver to wait for the new KSK to appear at all
+
+
+
+Morris, et al. Expires January 10, 2013 [Page 24]
+\f
+Internet-Draft DNSSEC Key Timing Considerations July 2012
+
+
+ servers for the zone before configuring the trust anchor.
4. Standby Keys
Although keys will usually be rolled according to some regular
schedule, there may be occasions when an emergency rollover is
- required, e.g. if the active key is suspected of being compromised.
+ required, e.g., if the active key is suspected of being compromised.
The aim of the emergency rollover is to allow the zone to be re-
signed with a new key as soon as possible. As a key must be in the
ready state to sign the zone, having at least one additional key (a
standby key) in this state at all times will minimise delay.
-
-
-Morris, et al. Expires September 11, 2011 [Page 24]
-\f
-Internet-Draft DNSSEC Key Timing Considerations March 2011
-
-
In the case of a ZSK, a standby key only really makes sense with the
Pre-Publication method. A permanent standby DNSKEY RR should be
- included in zone or successor keys could be introduced as soon as
+ included in the zone or successor keys could be introduced as soon as
possible after a key becomes active. Either way results in one or
more additional ZSKs in the DNSKEY RRset that can immediately be used
to sign the zone if the current key is compromised.
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
+
+
+
+Morris, et al. Expires January 10, 2013 [Page 25]
+\f
+Internet-Draft DNSSEC Key Timing Considerations July 2012
+
+
early as possible.
Except in the case of an algorithm rollover - where the algorithms
used to create the signatures are being changed - there is no
-
-
-
-Morris, et al. Expires September 11, 2011 [Page 25]
-\f
-Internet-Draft DNSSEC Key Timing Considerations March 2011
-
-
relationship between the keys of different algorithms. This means
that they can be rolled independently of one another. In other
words, the key rollover logic described above should be run
However, the subject matter is evolving and it is more than likely
that this document will need to be revised in the future.
- Some of the techniques and ideas that DNSSEC operators considering
- differ from this those described in this document. Of note are
- alternatives to the strict split into KSK and ZSK key roles and the
- consequences for rollover logic from partial signing (i.e. when the
- new key initially only signs a fraction of the zone while leaving
- other signatures generated by the old key in place).
+ Some of the techniques and ideas that DNSSEC operators are
+ considering differ from this those described in this document. Of
+ particular interest are alternatives to the strict split into KSK and
+ ZSK key roles and the consequences for rollover logic from partial
+ signing (i.e., when the new key initially only signs a fraction of
+ the zone while leaving other signatures generated by the old key in
+ place).
Furthermore, as noted in section 5, this document covers only rolling
- keys of the same algorithm, it does not cover transition to/from/
- addition/deletion of different algorithms. Algorithm rollovers will
- require a separate document.
+ keys of the same algorithm: it does not cover transitions between
+ algorithms. The timing issues associated with algorithm rollovers
+ will require a separate document.
- The reader is therefore reminded that DNSSEC is as of publication in
- early stages of deployment, and best practices may further develop
- over time.
+ The reader is therefore reminded that DNSSEC is, as of date of
+ publication, in the early stages of deployment, and best practices
+ may further develop over time.
7. Summary
For ZSKs, "Pre-Publication" is generally considered to be the
preferred way of rolling keys. As shown in this document, the time
+
+
+
+Morris, et al. Expires January 10, 2013 [Page 26]
+\f
+Internet-Draft DNSSEC Key Timing Considerations July 2012
+
+
taken to roll is wholly dependent on parameters under the control of
the zone manager.
timing values and that it also requires changes to the rollover
process due to the need to manage revocation of trust anchors.
-
-
-
-Morris, et al. Expires September 11, 2011 [Page 26]
-\f
-Internet-Draft DNSSEC Key Timing Considerations March 2011
-
-
Finally, the treatment of emergency key rollover is significantly
simplified by the introduction of standby keys as standard practice
during all types of rollovers.
Arends, Matthijs Mekking and Wouter Wijngaards.
-11. Change History (To be removed on publication)
-
- 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.
+11. Normative References
- o draft-ietf-dnsop-dnssec-key-timing-01
- * Added section on limitation of scope.
+ [I-D.ietf-dnsop-rfc4641bis]
+ Kolkman, O. and M. Mekking, "DNSSEC Operational Practices,
+ Version 2", draft-ietf-dnsop-rfc4641bis-11 (work in
+ progress), April 2012.
- o draft-ietf-dnsop-dnssec-key-timing-00
- * Change to author contact details.
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
- o draft-morris-dnsop-dnssec-key-timing-02
- * General restructuring.
- * Added descriptions of more rollovers (IETF-76 meeting).
+ [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
+ Rose, "DNS Security Introduction and Requirements",
-Morris, et al. Expires September 11, 2011 [Page 27]
+Morris, et al. Expires January 10, 2013 [Page 27]
\f
-Internet-Draft DNSSEC Key Timing Considerations March 2011
+Internet-Draft DNSSEC Key Timing Considerations July 2012
- * Improved description of key states and removed diagram.
- * Provided simpler description of standby keys.
- * Added section concerning first key in a zone.
- * Moved [RFC5011] to a separate section.
- * Various nits fixed (Alfred Hoenes, Jeremy Reed, Scott Rose, Sion
- Lloyd, Tony Finch).
-
- o draft-morris-dnsop-dnssec-key-timing-01
- * Use latest boilerplate for IPR text.
- * List different ways to roll a KSK (acknowledgements to Mark
- Andrews).
- * Restructure to concentrate on key timing, not management
- procedures.
- * Change symbol notation (Diane Davidowicz and others).
- * Added key state transition diagram (Diane Davidowicz).
- * Corrected spelling, formatting, grammatical and style errors
- (Diane Davidowicz, Alfred Hoenes and Jinmei Tatuya).
- * Added note that in the case of multiple algorithms, the
- signatures and rollovers for each algorithm can be considered as
- more or less independent (Alfred Hoenes).
- * Take account of the fact that signing a zone is not atomic
- (Chris Thompson).
- * Add section contrasting pre-publication rollover with double
- signature rollover (Matthijs Mekking).
- * Retained distinction between first and subsequent keys in
- definition of initial publication interval (Matthijs Mekking).
-
- o draft-morris-dnsop-dnssec-key-timing-00
- Initial draft.
-
-
-12. References
-
-12.1. Normative References
-
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
- [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
- Rose, "DNS Security Introduction and Requirements",
RFC 4033, March 2005.
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Protocol Modifications for the DNS Security
-
-
-
-Morris, et al. Expires September 11, 2011 [Page 28]
-\f
-Internet-Draft DNSSEC Key Timing Considerations March 2011
-
-
Extensions", RFC 4035, March 2005.
[RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC)
Trust Anchors", RFC 5011, September 2007.
-12.2. Informative References
-
- [RFC4641] Kolkman, O. and R. Gieben, "DNSSEC Operational Practices",
- RFC 4641, September 2006.
-
Appendix A. List of Symbols
TTL TTL of a record
- I and T and TTL are self-explanatory. Like I, D, and L are time
+ I and T and TTL are self-explanatory. Like I, both D and L are time
periods, but whereas I values are intervals between two events (even
- if the events are defined in terms of the interval, e.g. the dead
- time occurs "retire interval" after the retire time), D, and L are
+ if the events are defined in terms of the interval, e.g., the dead
+ time occurs "retire interval" after the retire time), D and L are
fixed intervals: a "D" interval (delay) is a feature of the process,
probably outside control of the zone manager, whereas an "L" interval
(lifetime) is chosen by the zone manager and is a feature of policy.
<id> is lower-case and defines what object or event the variable is
- related to, e.g.
-
-
-
+ related to, e.g.,
-Morris, et al. Expires September 11, 2011 [Page 29]
+Morris, et al. Expires January 10, 2013 [Page 28]
\f
-Internet-Draft DNSSEC Key Timing Considerations March 2011
+Internet-Draft DNSSEC Key Timing Considerations July 2012
act activation
G signature
- K key
-
P parent
S successor
that any resolvers that have the DNSKEY RRset cached have a
copy of this key.
+ IpubC Publication interval in the child zone.
-Morris, et al. Expires September 11, 2011 [Page 30]
-\f
-Internet-Draft DNSSEC Key Timing Considerations March 2011
+Morris, et al. Expires January 10, 2013 [Page 29]
+\f
+Internet-Draft DNSSEC Key Timing Considerations July 2012
- IpubC Publication interval in the child zone.
IpubG Publication interval for the signature created by a ZSK:
the amount of time that must elapse after the signature has
published with the revoke bit set to satisfy [RFC5011]
considerations.
+ Itrp Trust-point interval. The amount of time that a trust
+ anchor must be published for to guarantee that a resolver
+ configured for an automatic update of keys will see the new
+ key at least twice.
+
Lksk Lifetime of a key-signing key. This is the intended amount
of time for which this particular KSK is regarded as the
active KSK. Depending on when the key is rolled-over, the
Tpub Publication time of a key. The time that a key appears in
a zone for the first time.
- TpubS Publication time of the successor key.
-
-
-Morris, et al. Expires September 11, 2011 [Page 31]
+Morris, et al. Expires January 10, 2013 [Page 30]
\f
-Internet-Draft DNSSEC Key Timing Considerations March 2011
+Internet-Draft DNSSEC Key Timing Considerations July 2012
+ TpubS Publication time of the successor key.
+
Trem Removal time of a key. The time at which a key is removed
from the 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. (By implication, this is
+ also the time to live of the signatures on the DNSKEY
+ RRset.)
TTLsig The maximum time to live of all the RRSIG records in the
zone that were created with the ZSK.
-Authors' Addresses
+Appendix B. Change History (To be removed on publication)
- Stephen Morris
- Internet Systems Consortium
- 950 Charter Street
- Redwood City, CA 94063
- USA
+ o draft-ietf-dnsop-dnssec-key-timing-03
+ * Clarifications of and corrections to wording (Marc Lampo, Alfred
+ Hoenes).
+ * Updated timings related to trust anchor interaction (Matthijs
+ Mekking).
+ * Updated RFC 4641 reference to 4641bis (Alfred Hoenes).
+ * Moved change history to end of document (Alfred Hoenes).
- Phone: +1 650 423 1300
- Email: stephen@isc.org
+ 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.
+Morris, et al. Expires January 10, 2013 [Page 31]
+\f
+Internet-Draft DNSSEC Key Timing Considerations July 2012
+ * 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.
+ o draft-ietf-dnsop-dnssec-key-timing-00
+ * Change to author contact details.
+ o draft-morris-dnsop-dnssec-key-timing-02
+ * General restructuring.
+ * Added descriptions of more rollovers (IETF-76 meeting).
+ * Improved description of key states and removed diagram.
+ * Provided simpler description of standby keys.
+ * Added section concerning first key in a zone.
+ * Moved [RFC5011] to a separate section.
+ * Various nits fixed (Alfred Hoenes, Jeremy Reed, Scott Rose, Sion
+ Lloyd, Tony Finch).
+
+ o draft-morris-dnsop-dnssec-key-timing-01
+ * Use latest boilerplate for IPR text.
+ * List different ways to roll a KSK (acknowledgements to Mark
+ Andrews).
+ * Restructure to concentrate on key timing, not management
+ procedures.
+ * Change symbol notation (Diane Davidowicz and others).
+ * Added key state transition diagram (Diane Davidowicz).
+ * Corrected spelling, formatting, grammatical and style errors
+ (Diane Davidowicz, Alfred Hoenes and Jinmei Tatuya).
+ * Added note that in the case of multiple algorithms, the
+ signatures and rollovers for each algorithm can be considered as
+ more or less independent (Alfred Hoenes).
+ * Take account of the fact that signing a zone is not atomic
+ (Chris Thompson).
+ * Add section contrasting pre-publication rollover with double
+ signature rollover (Matthijs Mekking).
+ * Retained distinction between first and subsequent keys in
+ definition of initial publication interval (Matthijs Mekking).
+ o draft-morris-dnsop-dnssec-key-timing-00
+ Initial draft.
-Morris, et al. Expires September 11, 2011 [Page 32]
+Morris, et al. Expires January 10, 2013 [Page 32]
\f
-Internet-Draft DNSSEC Key Timing Considerations March 2011
+Internet-Draft DNSSEC Key Timing Considerations July 2012
+
+
+Authors' Addresses
+
+ Stephen Morris
+ Internet Systems Consortium
+ 950 Charter Street
+ Redwood City, CA 94063
+ USA
+
+ Phone: +1 650 423 1300
+ Email: stephen@isc.org
Johan Ihren
-
-
-
-
-
-
-
-
-
-
-
-
-Morris, et al. Expires September 11, 2011 [Page 33]
+Morris, et al. Expires January 10, 2013 [Page 33]
\f
projects / thirdparty / bind9.git / commitdiff
