diff options
Diffstat (limited to 'doc/draft')
| -rw-r--r-- | doc/draft/draft-faltstrom-uri-06.txt | 729 | ||||
| -rw-r--r-- | doc/draft/draft-ietf-dnsext-rfc2671bis-edns0-02.txt | 616 | ||||
| -rw-r--r-- | doc/draft/draft-ietf-dnsext-rfc2671bis-edns0-05.txt | 728 | ||||
| -rw-r--r-- | doc/draft/draft-ietf-dnsop-dnssec-key-timing-00.txt | 1960 | ||||
| -rw-r--r-- | doc/draft/draft-ietf-dnsop-dnssec-key-timing-02.txt | 1848 |
5 files changed, 3305 insertions, 2576 deletions
diff --git a/doc/draft/draft-faltstrom-uri-06.txt b/doc/draft/draft-faltstrom-uri-06.txt new file mode 100644 index 0000000000000..cf4fd832e1f45 --- /dev/null +++ b/doc/draft/draft-faltstrom-uri-06.txt @@ -0,0 +1,729 @@ + + + +Network Working Group P. Faltstrom +Internet-Draft Cisco +Updates: 3404, 3959 O. Kolkman +(if approved) NLNet +Intended status: Standards Track October 11, 2010 +Expires: April 14, 2011 + + + The Uniform Resource Identifier (URI) DNS Resource Record + draft-faltstrom-uri-06.txt + +Abstract + + This document defines a new DNS resource record, called the Uniform + Resource Identifier (URI) RR, for publishing mappings from hostnames + to URIs. + +Status of this Memo + + This Internet-Draft is submitted in full conformance with the + provisions of BCP 78 and BCP 79. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF). Note that other groups may also distribute + working documents as Internet-Drafts. The list of current Internet- + Drafts is at http://datatracker.ietf.org/drafts/current/. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + This Internet-Draft will expire on April 14, 2011. + +Copyright Notice + + Copyright (c) 2010 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + + + +Faltstrom & Kolkman Expires April 14, 2011 [Page 1] + +Internet-Draft URI Resource Record October 2010 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Applicability Statement . . . . . . . . . . . . . . . . . . . 3 + 3. DNS considerations . . . . . . . . . . . . . . . . . . . . . . 4 + 4. The format of the URI RR . . . . . . . . . . . . . . . . . . . 4 + 4.1. Ownername, class and type . . . . . . . . . . . . . . . . 4 + 4.2. Priority . . . . . . . . . . . . . . . . . . . . . . . . . 5 + 4.3. Weight . . . . . . . . . . . . . . . . . . . . . . . . . . 5 + 4.4. Target . . . . . . . . . . . . . . . . . . . . . . . . . . 5 + 4.5. URI RDATA Wire Format . . . . . . . . . . . . . . . . . . 6 + 5. Definition of the flag 'D' for NAPTR records . . . . . . . . . 6 + 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 + 6.1. Homepage at one domain, but two domains in use . . . . . . 7 + 7. Relation to S-NAPTR . . . . . . . . . . . . . . . . . . . . . 7 + 8. Relation to U-NAPTR . . . . . . . . . . . . . . . . . . . . . 7 + 9. Relation to SRV . . . . . . . . . . . . . . . . . . . . . . . 8 + 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 + 10.1. Registration of the URI Resource Record Type . . . . . . . 8 + 10.2. Registration of services . . . . . . . . . . . . . . . . . 8 + 11. Security Considerations . . . . . . . . . . . . . . . . . . . 8 + 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 + Appendix A. RRTYPE Allocation Request . . . . . . . . . . . . . . 9 + 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 + 13.1. Normative References . . . . . . . . . . . . . . . . . . . 12 + 13.2. Non-normative references . . . . . . . . . . . . . . . . . 12 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 + + + + + + + + + + + + + + + + + + + + + + + + +Faltstrom & Kolkman Expires April 14, 2011 [Page 2] + +Internet-Draft URI Resource Record October 2010 + + +1. Introduction + + This document explains the use of the Domain Name System (DNS) for + the storage of URIs, and how to resolve hostnames to such URIs that + can be used by various applications. For resolution the application + need to know both the hostname and the protocol that the URI is to be + used for. The protocol is registered by IANA. + + Currently, looking up URIs given a hostname uses the DDDS [RFC3401] + application framework with the DNS as a database as specified in RFC + 3404 [RFC3404]. This has a number of implications such as the + inability to select what NAPTR records that match the query are + interesting. The RRSet returned will always consist of all URIs + "connected" with the domain in question. + + The URI resource record specified in this document enables the + querying party to select which ones of the NAPTR records one is + interested in. This because data in the service field of the NAPTR + record is included in the owner part of the URI resource record type. + + Querying for URI resource records is not replacing querying for NAPTR + resource records (or use of S-NAPTR [RFC3958]). Instead, the URI + resource record type provides a complementary mechanism to use when + one already knows what service field is interesting. With it, one + can directly query for the specific subset of the otherwise possibly + large RRSet given back when querying for NAPTR resource records. + + This document updates RFC 3958 and RFC 3404 by adding the flag "D" to + the list of defined terminal flags in section 2.2.3 of RFC 3958 and + 4.3 of RFC 3404. + + 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 BCP 14, RFC 2119 + [RFC2119]. + + +2. Applicability Statement + + In general, it is expected that URI records will be used by clients + for applications where the relevant protocol to be used is known, + but, for example, an extra abstraction is needed in order to separate + a domain name from a point of service (as addressed by the URI). One + example of such a situation is when an organisation has many domain + names, but only one official web page. + + Applications MUST know the specific service fields to prepend the + hostname with. Using repetitive queries for URI records MUST NOT be + + + +Faltstrom & Kolkman Expires April 14, 2011 [Page 3] + +Internet-Draft URI Resource Record October 2010 + + + a replacement for querying for NAPTR records according to the NAPTR + (DDDS) or S-NAPTR algorithms. NAPTR records serve the purpose to + discover the various services and URIs for looking up access points + for a given service. Those are two very different kinds of needs. + + +3. DNS considerations + + Using prefix labels, such as underscored service tags, prevents the + use of wildcards, as constructs as _s2._s1.*.example.net. are not + possible in the DNS, see RFC 4592 [RFC4592]. Besides, underscored + service tags used for the URI RR (based on the NAPTR service + descriptions) may have slightly different semantics than service tags + used for underscored prefix labels that are used in combination with + other (yet unspecified) RR types. This may cause subtle management + problems when delegation structure that has developed within the + context of URI RRs is also to be used for other RR types. Since the + service labels might be overloaded, applications should carefully + check that the application level protocol is indeed the protocol they + expect. + + Subtle management issues may also arise when the delegations from + service to sub service label involves several parties and different + stake holders. + + +4. The format of the URI RR + + This is the presentation format of the URI RR: + + + Ownername TTL Class URI Priority Weight Target + + + The URI RR does not cause any kind of Additional Section processing. + +4.1. Ownername, class and type + + The URI ownername is subject to special conventions. + + Just like the SRV RR [RFC2782] the URI RR has service information + encoded in its ownername. In order to encode the service for a + specific owner name one uses service parameters. Valid service + parameters used are those used for SRV resource records, or + registered by IANA for Enumservice Registrations. The Enumservice + Registration parameters are reversed (subtype(s) before type), + prepended with an underscore (_) and prepended to the owner name in + separate labels. The underscore is prepended to the service + + + +Faltstrom & Kolkman Expires April 14, 2011 [Page 4] + +Internet-Draft URI Resource Record October 2010 + + + parameters to avoid collisions with DNS labels that occur in nature, + and the order is reversed to make it possible to do delegations, if + needed, to different zones (and therefore providers of DNS). + + It should be noted that the usage of a prefix must be described in + detail in for example the Enumservice Registration documentation, or + in a specific document that clarifies potential overload of + parameters in the same URI. Specifically, registered URI schemes are + not automatically acceptable as a service. With the HTTP scheme, one + can for example have multiple methods (GET, PUT, etc), and this with + the same URI. + + For example, suppose we are looking for the URI for a service with + Service Parameter "A:B:C" for host example.com.. Then we would query + for (QNAME,QTYPE)=("_C._B._A.example.com","URI") + + The type number for the URI record is TBD1 (to be assigned by IANA). + + The URI resource record is class independent. + + The URI RR has no special TTL requirements. + +4.2. Priority + + The priority of the target URI in this RR. Its range is 0-65535. A + client MUST attempt to contact the URI with the lowest-numbered + priority it can reach; URIs with the same priority SHOULD be tried in + the order defined by the weight field. + +4.3. Weight + + A server selection mechanism. The weight field specifies a relative + weight for entries with the same priority. Larger weights SHOULD be + given a proportionately higher probability of being selected. The + range of this number is 0-65535. + +4.4. Target + + The URI of the target, enclosed in double-quote characters ('"'). + Resolution of the URI is according to the definitions for the Scheme + of the URI. + + The URI is encoded as one or more <character-string> RFC1035 section + 3.3 [RFC1035]. + + + + + + + +Faltstrom & Kolkman Expires April 14, 2011 [Page 5] + +Internet-Draft URI Resource Record October 2010 + + +4.5. URI RDATA Wire Format + + The RDATA for a URI RR consists of a 2 octet Priority field, a two + octet Weight field, and a variable length target field. + + Priority and Weight are unsigned integers in network byte order. + + The Target field contains the URI (without the enclosing double- + quote characters used in the presentation format), encoded as a + sequence of one or more <character-string> (as specified in section + 3.3 of RFC 1035 [RFC1035]), where all but the last <character-string> + are filled up to the maximum length of 255 octets. + + The Target field can also contain an IRI, but with the additional + requirements that it is in UTF-8 [RFC3629] and possible to convert to + a URI according to section 3.1 of RFC 3987 [RFC3987] and back again + to an IRI according to section 3.2. Other character sets than UTF-8 + are not allowed. The domain name part of the IRI can be either an + U-LABEL or A-LABEL as defined in RFC 5890 [RFC5890]. + + + 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Priority | Weight | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + / / + / Target / + / / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + +5. Definition of the flag 'D' for NAPTR records + + This document specifies the flag "D" for use as a flag in NAPTR + records. The flag indicate a terminal NAPTR record because it + denotes the end of the DDDS/NAPTR processing rules. In the case of a + "D" flag, the Replacement field in the NAPTR record, prepended with + the service flags, is used as the Owner of a DNS query for URI + records, and normal URI processing as defined in this document is + applied. + + The replacement field MUST NOT include any of the service parameters. + Those are to be prepended (together with underscore) as described in + other places in this document. + + The Regexp field in the NAPTR record MUST be empty when the 'D' flag + + + +Faltstrom & Kolkman Expires April 14, 2011 [Page 6] + +Internet-Draft URI Resource Record October 2010 + + + is in use. + + +6. Examples + +6.1. Homepage at one domain, but two domains in use + + An organisation has the domain names example.com and example.net, but + the official URI http://www.example.com/. Given the service type + "web" and subtype "http" (from the IANA registry), the following URI + Resource Records could be made available in the respective zones + (example.com and example.net): + + + $ORIGIN example.com. + _http._web IN URI 10 1 "http://www.example.com/" + + $ORIGIN example.net. + _http._web IN URI 10 1 "http://www.example.com/" + + + +7. Relation to S-NAPTR + + The URI resource record type is not a replacement for the S-NAPTR. + It is instead an extension and the seond step of the S-NAPTR + resolution can resolve a URI resource record instead of using SRV + records and yet another algorithm for how to use SRV records for the + specific protocol. + + + $ORIGIN example.com. + ;; order pref flags + IN NAPTR 100 10 "s" "EM:ProtA" ( ; service + "" ; regexp + _ProtA._tcp.example.com. ; replacement + _ProtA._tcp IN URI "schemeA:service.example.com/example" + + + +8. Relation to U-NAPTR + + The URI Resource Record Type, together with S-NAPTR, can be viewed as + a replacement for the U-NAPTR. The URI Resource Record Type is + though only interesting when one know a base domain name, a protocol + and service so that one can compose the record to look up. NAPTR + records of any kind are used to look up what services exists for a + certain domain, which is one step before the URI resource record is + + + +Faltstrom & Kolkman Expires April 14, 2011 [Page 7] + +Internet-Draft URI Resource Record October 2010 + + + used. + + +9. Relation to SRV + + The URI Resource Record Type can be viewed as a replacement for the + SRV record. This because it like the SRV record can only be looked + up if one know the base domain, the protocol and the service. It has + a similar functionality, but instead of returning a hostname and port + number, the URI record return a full URI. As such, it can be viewed + as a more powerful resource record than SRV. + + +10. IANA Considerations + +10.1. Registration of the URI Resource Record Type + + IANA has assigned Resource Record Type TBD1 for the URI Resource + Record Type and added the line depicted below to the registry named + Resource Record (RR) TYPEs and QTYPEs as defined in BCP 42 RFC 5395 + [RFC5395] and located at + http://www.iana.org/assignments/dns-parameters. + + + TYPE Value and meaning Reference + ----------- --------------------------------------------- --------- + URI TBD1 a URI for a service (per the owner name) [RFCXXXX] + + +10.2. Registration of services + + No new registry is needed for the registration of services as the + Enumservice Registrations registry is used also for the URI resource + record type. + + +11. Security Considerations + + The authors do not believe this resource record cause any new + security problems. Deployment must though be done in a proper way as + misconfiguration of this resource record might make it impossible to + reach the service that was originally intended to be accessed. + + Using the URI resource record together with security mechanisms that + relies on verification of authentication of hostnames, like TLS, + makes it important to choose the correct domain name when doing the + comparison. + + + + +Faltstrom & Kolkman Expires April 14, 2011 [Page 8] + +Internet-Draft URI Resource Record October 2010 + + + The basic mechanism works as follows: + + 1. Announce the fact example.com is hosted at example.org (with + some URL) in DNS + 2. Secure the URI resource record with DNSSEC. + 3. Verify the TLS (for example) certificate for the connection to + example.org matches, i.e. use the hostname in the URI and not + the hostname used originally when looking up the URI resource + record. + 4. If needed, do application layer authentication etc over the then + encrypted connection. + + What also can happen is that the URI in the resource record type has + errors in it. Applications using the URI resource record type for + resolution should behave similarly as if the user typed (or copy and + pasted) the URI. At least it must be clear to the user that the + error is not due to any error from his side. + + One SHOULD not include userinfo (see User Information, Section 3.2.1, + in RFC 3986 [RFC3986]) in a URI that is used in a URI resource record + as DNS data must be viewed as publicly available information. + + +12. Acknowledgements + + Ideas on how to split the two different kind of queries "What + services exists for this domain name" and "What is the URI for this + service" came from Scott Bradner and Lawrence Conroy. Other people + that have contributed to this document include Richard Barnes, Leslie + Daigle, Olafur Gudmundsson, Ted Hardie, Peter Koch and Penn Pfautz. + + +Appendix A. RRTYPE Allocation Request + + A. Submission Date: + + May 23, 2009 + + B. Submission Type: + + [X] New RRTYPE + [ ] Modification to existing RRTYPE + + C. Contact Information for submitter: + + Name: Patrik Faltstrom + Email Address: paf@cisco.com + International telephone number: +46-8-6859131 + + + +Faltstrom & Kolkman Expires April 14, 2011 [Page 9] + +Internet-Draft URI Resource Record October 2010 + + + Other contact handles: + (Note: This information will be publicly posted.) + + D. Motivation for the new RRTYPE application? + + There is no easy way to get from a domain name to a URI (or + IRI). Some mechanisms exists via use of the NAPTR [RFC3403] + resource record. That implies quite complicated rules that are + simplified via the S-NAPTR [RFC3958] specification. But, the + ability to directly look up a URI still exists. This + specification uses a prefix based naming mechanism originated in + the definition of the SRV [RFC2782] resource record, and the + RDATA is a URI, encoded as one text field. + + See also above (Section 1). + + E. Description of the proposed RR type. + + The format of the URI resource record is as follows: + + + Ownername TTL Class URI Priority Weight Target + + + The URI RR has service information encoded in its ownername. In + order to encode the service for a specific owner name one uses + service parameters. Valid service parameters used are either + Enumservice Registrations registered by IANA, or prefixes used + for the SRV resource record. + + The wire format of the RDATA is as follows: + + + 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Priority | Weight | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + / / + / Target / + / / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + + + + + + + +Faltstrom & Kolkman Expires April 14, 2011 [Page 10] + +Internet-Draft URI Resource Record October 2010 + + + F. What existing RRTYPE or RRTYPEs come closest to filling that + need and why are they unsatisfactory? + + The RRTYPE that come closest is the NAPTR resource record. It + is for example used in the DDDS and S-NAPTR algorithms. The + main problem with the NAPTR is that selection of what record (or + records) one is interested in is based on data stored in the + RDATA portion of the NAPTR resource record. This, as explained + in RFC 5507 [RFC5507], is not optimal for DNS lookups. Further, + most applications using NAPTR resource records uses regular + expression based rewrite rules for creation of the URI, and that + has shown be complicated to implement. + + The second closest RRTYPE is the SRV record that given a + prefixed based naming just like is suggested for the URI + resource record, one get back a port number and domain name. + This can also be used for creation of a URI, but, only URIs + without path components. + + G. What mnemonic is requested for the new RRTYPE (optional)? + + URI + + H. Does the requested RRTYPE make use of any existing IANA Registry + or require the creation of a new IANA sub-registry in DNS + Parameters? + + Yes, partially. + + One of the mechanisms to select a service is to use the + Enumservice Registry managed by IANA. Another is to use + services and protocols used for SRV records. + + I. Does the proposal require/expect any changes in DNS servers/ + resolvers that prevent the new type from being processed as an + unknown RRTYPE (see [RFC3597])? + + No + + J. Comments: + + None + + + +13. References + + + + + +Faltstrom & Kolkman Expires April 14, 2011 [Page 11] + +Internet-Draft URI Resource Record October 2010 + + +13.1. Normative References + + [E164] ITU-T, "The International Public Telecommunication Number + Plan", Recommendation E.164, May 1997. + + [RFC1035] Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, November 1987. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO + 10646", STD 63, RFC 3629, November 2003. + + [RFC3958] Daigle, L. and A. Newton, "Domain-Based Application + Service Location Using SRV RRs and the Dynamic Delegation + Discovery Service (DDDS)", RFC 3958, January 2005. + + [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource + Identifiers (IRIs)", RFC 3987, January 2005. + + [RFC5395] Eastlake, D., "Domain Name System (DNS) IANA + Considerations", BCP 42, RFC 5395, November 2008. + + [RFC5890] Klensin, J., "Internationalized Domain Names for + Applications (IDNA): Definitions and Document Framework", + RFC 5890, August 2010. + +13.2. Non-normative references + + [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for + specifying the location of services (DNS SRV)", RFC 2782, + February 2000. + + [RFC3401] Mealling, M., "Dynamic Delegation Discovery System (DDDS) + Part One: The Comprehensive DDDS", RFC 3401, October 2002. + + [RFC3403] Mealling, M., "Dynamic Delegation Discovery System (DDDS) + Part Three: The Domain Name System (DNS) Database", + RFC 3403, October 2002. + + [RFC3404] Mealling, M., "Dynamic Delegation Discovery System (DDDS) + Part Four: The Uniform Resource Identifiers (URI)", + RFC 3404, October 2002. + + [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform + Resource Identifier (URI): Generic Syntax", STD 66, + RFC 3986, January 2005. + + + +Faltstrom & Kolkman Expires April 14, 2011 [Page 12] + +Internet-Draft URI Resource Record October 2010 + + + [RFC4592] Lewis, E., "The Role of Wildcards in the Domain Name + System", RFC 4592, July 2006. + + [RFC4848] Daigle, L., "Domain-Based Application Service Location + Using URIs and the Dynamic Delegation Discovery Service + (DDDS)", RFC 4848, April 2007. + + [RFC5507] IAB, Faltstrom, P., Austein, R., and P. Koch, "Design + Choices When Expanding the DNS", RFC 5507, April 2009. + + +Authors' Addresses + + Patrik Faltstrom + Cisco Systems + + Email: paf@cisco.com + + + Olaf Kolkman + NLnet Labs + + Email: olaf@NLnetLabs.nl + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Faltstrom & Kolkman Expires April 14, 2011 [Page 13] + + diff --git a/doc/draft/draft-ietf-dnsext-rfc2671bis-edns0-02.txt b/doc/draft/draft-ietf-dnsext-rfc2671bis-edns0-02.txt deleted file mode 100644 index ba1b4147f4dbc..0000000000000 --- a/doc/draft/draft-ietf-dnsext-rfc2671bis-edns0-02.txt +++ /dev/null @@ -1,616 +0,0 @@ - - - -DNSEXT Working Group M. Graff -Internet-Draft P. Vixie -Obsoletes: 2671 (if approved) Internet Systems Consortium -Intended status: Standards Track July 28, 2009 -Expires: January 29, 2010 - - - Extension Mechanisms for DNS (EDNS0) - draft-ietf-dnsext-rfc2671bis-edns0-02 - -Status of this Memo - - This Internet-Draft is submitted to IETF in full conformance with the - provisions of BCP 78 and BCP 79. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as Internet- - Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt. - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - This Internet-Draft will expire on January 29, 2010. - -Copyright Notice - - Copyright (c) 2009 IETF Trust and the persons identified as the - document authors. All rights reserved. - - This document is subject to BCP 78 and the IETF Trust's Legal - Provisions Relating to IETF Documents in effect on the date of - publication of this document (http://trustee.ietf.org/license-info). - Please review these documents carefully, as they describe your rights - and restrictions with respect to this document. - -Abstract - - The Domain Name System's wire protocol includes a number of fixed - fields whose range has been or soon will be exhausted and does not - - - -Graff & Vixie Expires January 29, 2010 [Page 1] - -Internet-Draft EDNS0 Extensions July 2009 - - - allow requestors to advertise their capabilities to responders. This - document describes backward compatible mechanisms for allowing the - protocol to grow. - - This document updates the EDNS0 specification based on 10 years of - operational experience. - - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 - 3. EDNS Support Requirement . . . . . . . . . . . . . . . . . . . 3 - 4. Affected Protocol Elements . . . . . . . . . . . . . . . . . . 3 - 4.1. Message Header . . . . . . . . . . . . . . . . . . . . . . 3 - 4.2. Label Types . . . . . . . . . . . . . . . . . . . . . . . 4 - 4.3. UDP Message Size . . . . . . . . . . . . . . . . . . . . . 4 - 5. Extended Label Types . . . . . . . . . . . . . . . . . . . . . 4 - 6. OPT pseudo-RR . . . . . . . . . . . . . . . . . . . . . . . . 4 - 6.1. OPT Record Behavior . . . . . . . . . . . . . . . . . . . 4 - 6.2. OPT Record Format . . . . . . . . . . . . . . . . . . . . 5 - 6.3. Requestor's Payload Size . . . . . . . . . . . . . . . . . 6 - 6.4. Responder's Payload Size . . . . . . . . . . . . . . . . . 6 - 6.5. Payload Size Selection . . . . . . . . . . . . . . . . . . 7 - 6.6. Middleware Boxes . . . . . . . . . . . . . . . . . . . . . 7 - 6.7. Extended RCODE . . . . . . . . . . . . . . . . . . . . . . 7 - 6.8. OPT Options Type Allocation Procedure . . . . . . . . . . 8 - 7. Transport Considerations . . . . . . . . . . . . . . . . . . . 8 - 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 - 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 - 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 - 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 - 11.1. Normative References . . . . . . . . . . . . . . . . . . . 10 - 11.2. Informative References . . . . . . . . . . . . . . . . . . 10 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 - - - - - - - - - - - - - - - - -Graff & Vixie Expires January 29, 2010 [Page 2] - -Internet-Draft EDNS0 Extensions July 2009 - - -1. Introduction - - DNS [RFC1035] specifies a Message Format and within such messages - there are standard formats for encoding options, errors, and name - compression. The maximum allowable size of a DNS Message is fixed. - Many of DNS's protocol limits are too small for uses which are or - which are desired to become common. There is no way for - implementations to advertise their capabilities. - - Unextended agents will not know how to interpret the protocol - extensions detailed here. In practice, these clients will be - upgraded when they have need of a new feature, and only new features - will make use of the extensions. Extended agents must be prepared - for behaviour of unextended clients in the face of new protocol - elements, and fall back gracefully to unextended DNS. [RFC2671] - originally proposed extensions to the basic DNS protocol to overcome - these deficiencies. This memo refines that specification and - obsoletes [RFC2671]. - - -2. 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 RFC 2119 [RFC2119]. - - -3. EDNS Support Requirement - - EDNS support is manditory in a modern world. DNSSEC requires EDNS - support, and many other featres are made possible only by EDNS - support to request or advertise them. - - -4. Affected Protocol Elements - -4.1. Message Header - - The DNS Message Header's (see , section 4.1.1 [RFC1035]) second full - 16-bit word is divided into a 4-bit OPCODE, a 4-bit RCODE, and a - number of 1-bit flags. The original reserved Z bits have been - allocated to various purposes, and most of the RCODE values are now - in use. More flags and more possible RCODEs are needed. The OPT - pseudo-RR specified below contains subfields that carry a bit field - extension of the RCODE field and additional flag bits, respectively. - - - - - - -Graff & Vixie Expires January 29, 2010 [Page 3] - -Internet-Draft EDNS0 Extensions July 2009 - - -4.2. Label Types - - The first two bits of a wire format domain label are used to denote - the type of the label. ,section 4.1.4 [RFC1035] allocates two of the - four possible types and reserves the other two. More label types - were proposed in [RFC2671] section 3. - -4.3. UDP Message Size - - DNS Messages are limited to 512 octets in size when sent over UDP. - While the minimum maximum reassembly buffer size still allows a limit - of 512 octets of UDP payload, most of the hosts now connected to the - Internet are able to reassemble larger datagrams. Some mechanism - must be created to allow requestors to advertise larger buffer sizes - to responders. To this end, the OPT pseudo-RR specified below - contains a maximum payload size field. - - -5. Extended Label Types - - The first octet in the on-the-wire representation of a DNS label - specifies the label type; the basic DNS specification [RFC1035] - dedicates the two most significant bits of that octet for this - purpose. - - This document reserves DNS label type 0b01 for use as an indication - for Extended Label Types. A specific extended label type is selected - by the 6 least significant bits of the first octet. Thus, Extended - Label Types are indicated by the values 64-127 (0b01xxxxxx) in the - first octet of the label. - - This document does not describe any specific Extended Label Type. - - In practice, Extended Label Types are difficult to use due to support - in clients and intermediate gateways. Therefore, the registry of - Extended Label Types is requested to be closed. They cause - interoperability problems and at present no defined label types are - in use. - - -6. OPT pseudo-RR - -6.1. OPT Record Behavior - - One OPT pseudo-RR (RR type 41) MAY be added to the additional data - section of a request. If present in requests, compliant responders - which implement EDNS MUST include an OPT record in non-truncated - responses, and SHOULD attempt to include them in all responses. An - - - -Graff & Vixie Expires January 29, 2010 [Page 4] - -Internet-Draft EDNS0 Extensions July 2009 - - - OPT is called a pseudo-RR because it pertains to a particular - transport level message and not to any actual DNS data. OPT RRs MUST - NOT be cached, forwarded, or stored in or loaded from master files. - The quantity of OPT pseudo-RRs per message MUST be either zero or - one, but not greater. - -6.2. OPT Record Format - - An OPT RR has a fixed part and a variable set of options expressed as - {attribute, value} pairs. The fixed part holds some DNS meta data - and also a small collection of basic extension elements which we - expect to be so popular that it would be a waste of wire space to - encode them as {attribute, value} pairs. - - The fixed part of an OPT RR is structured as follows: - - +------------+--------------+------------------------------+ - | Field Name | Field Type | Description | - +------------+--------------+------------------------------+ - | NAME | domain name | empty (root domain) | - | TYPE | u_int16_t | OPT | - | CLASS | u_int16_t | requestor's UDP payload size | - | TTL | u_int32_t | extended RCODE and flags | - | RDLEN | u_int16_t | describes RDATA | - | RDATA | octet stream | {attribute,value} pairs | - +------------+--------------+------------------------------+ - - OPT RR Format - - The variable part of an OPT RR is encoded in its RDATA and is - structured as zero or more of the following: - - - +0 (MSB) +1 (LSB) - +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ - 0: | OPTION-CODE | - +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ - 2: | OPTION-LENGTH | - +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ - 4: | | - / OPTION-DATA / - / / - +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ - - - - - - - - -Graff & Vixie Expires January 29, 2010 [Page 5] - -Internet-Draft EDNS0 Extensions July 2009 - - - OPTION-CODE - Assigned by Expert Review. - - OPTION-LENGTH - Size (in octets) of OPTION-DATA. - - OPTION-DATA - Varies per OPTION-CODE. - - Order of appearance of option tuples is never relevant. Any option - whose meaning is affected by other options is so affected no matter - which one comes first in the OPT RDATA. - - Any OPTION-CODE values not understood by a responder or requestor - MUST be ignored. Specifications of such options might wish to - include some kind of signalled acknowledgement. For example, an - option specification might say that if a responder sees option XYZ, - it SHOULD include option XYZ in its response. - -6.3. Requestor's Payload Size - - The requestor's UDP payload size (which OPT stores in the RR CLASS - field) is the number of octets of the largest UDP payload that can be - reassembled and delivered in the requestor's network stack. Note - that path MTU, with or without fragmentation, may be smaller than - this. Values lower than 512 MUST be treated as equal to 512. - - Note that a 512-octet UDP payload requires a 576-octet IP reassembly - buffer. Choosing 1280 for IPv4 over Ethernet would be reasonable. - The consequence of choosing too large a value may be an ICMP message - from an intermediate gateway, or even a silent drop of the response - message. - - The requestor's maximum payload size can change over time, and MUST - therefore not be cached for use beyond the transaction in which it is - advertised. - -6.4. Responder's Payload Size - - The responder's maximum payload size can change over time, but can be - reasonably expected to remain constant between two sequential - transactions; for example, a meaningless QUERY to discover a - responder's maximum UDP payload size, followed immediately by an - UPDATE which takes advantage of this size. (This is considered - preferrable to the outright use of TCP for oversized requests, if - there is any reason to suspect that the responder implements EDNS, - and if a request will not fit in the default 512 payload size limit.) - - - - -Graff & Vixie Expires January 29, 2010 [Page 6] - -Internet-Draft EDNS0 Extensions July 2009 - - -6.5. Payload Size Selection - - Due to transaction overhead, it is unwise to advertise an - architectural limit as a maximum UDP payload size. Just because your - stack can reassemble 64KB datagrams, don't assume that you want to - spend more than about 4KB of state memory per ongoing transaction. - - A requestor MAY choose to implement a fallback to smaller advertised - sizes to work around firewall or other network limitations. A - requestor SHOULD choose to use a fallback mechanism which begins with - a large size, such as 4096. If that fails, a fallback around the - 1220 byte range SHOULD be tried, as it has a reasonable chance to fit - within a single Ethernet frame. Failing that, a requestor MAY choose - a 512 byte packet, which with large answers may cause a TCP retry. - -6.6. Middleware Boxes - - Middleware boxes MUST NOT limit DNS messages over UDP to 512 bytes. - - Middleware boxes which simply forward requests to a recursive - resolver MUST NOT modify the OPT record contents in either direction. - -6.7. Extended RCODE - - The extended RCODE and flags (which OPT stores in the RR TTL field) - are structured as follows: - - +0 (MSB) +1 (LSB) - +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ - 0: | EXTENDED-RCODE | VERSION | - +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ - 2: | DO| Z | - +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ - - EXTENDED-RCODE - Forms upper 8 bits of extended 12-bit RCODE. Note that - EXTENDED-RCODE value "0" indicates that an unextended RCODE is - in use (values "0" through "15"). - - VERSION - Indicates the implementation level of whoever sets it. Full - conformance with this specification is indicated by version - ``0.'' Requestors are encouraged to set this to the lowest - implemented level capable of expressing a transaction, to - minimize the responder and network load of discovering the - greatest common implementation level between requestor and - responder. A requestor's version numbering strategy MAY - ideally be a run time configuration option. - - - -Graff & Vixie Expires January 29, 2010 [Page 7] - -Internet-Draft EDNS0 Extensions July 2009 - - - If a responder does not implement the VERSION level of the - request, then it answers with RCODE=BADVERS. All responses - MUST be limited in format to the VERSION level of the request, - but the VERSION of each response SHOULD be the highest - implementation level of the responder. In this way a requestor - will learn the implementation level of a responder as a side - effect of every response, including error responses and - including RCODE=BADVERS. - - DO - DNSSEC OK bit as defined by [RFC3225]. - - Z - Set to zero by senders and ignored by receivers, unless - modified in a subsequent specification. - -6.8. OPT Options Type Allocation Procedure - - Allocations assigned by expert review. TBD - - -7. Transport Considerations - - The presence of an OPT pseudo-RR in a request should be taken as an - indication that the requestor fully implements the given version of - EDNS, and can correctly understand any response that conforms to that - feature's specification. - - Lack of presence of an OPT record in a request MUST be taken as an - indication that the requestor does not implement any part of this - specification and that the responder MUST NOT use any protocol - extension described here in its response. - - Responders who do not implement these protocol extensions MUST - respond with FORMERR messages without any OPT record. - - If there is a problem with processing the OPT record itself, such as - an option value that is badly formatted or includes out of range - values, a FORMERR MAY be retured. If this occurs the response MUST - include an OPT record. This MAY be used to distinguish between - servers whcih do not implement EDNS and format errors within EDNS. - - If EDNS is used in a request, and the response arrives with TC set - and with no EDNS OPT RR, a requestor SHOULD assume that truncation - prevented the OPT RR from being appended by the responder, and - further, that EDNS is not used in the response. Correspondingly, an - EDNS responder who cannot fit all necessary elements (including an - OPT RR) into a response, SHOULD respond with a normal (unextended) - - - -Graff & Vixie Expires January 29, 2010 [Page 8] - -Internet-Draft EDNS0 Extensions July 2009 - - - DNS response, possibly setting TC if the response will not fit in the - unextended response message's 512-octet size. - - -8. Security Considerations - - Requestor-side specification of the maximum buffer size may open a - new DNS denial of service attack if responders can be made to send - messages which are too large for intermediate gateways to forward, - thus leading to potential ICMP storms between gateways and - responders. - - Announcing very large UDP buffer sizes may result in dropping by - firewalls. This could cause retransmissions with no hope of success. - Some devices reject fragmented UDP packets. - - Announcing too small UDP buffer sizes may result in fallback to TCP. - This is especially important with DNSSEC, where answers are much - larger. - - -9. IANA Considerations - - The IANA has assigned RR type code 41 for OPT. - - [RFC2671] specified a number of IANA sub-registries within "DOMAIN - NAME SYSTEM PARAMETERS:" "EDNS Extended Label Type", "EDNS Option - Codes", "EDNS Version Numbers", and "Domain System Response Code." - IANA is advised to re-parent these subregistries to this document. - - RFC 2671 created an extended label type registry. We request that - this registry be closed. - - This document assigns extended label type 0bxx111111 as "Reserved for - future extended label types." We request that IANA record this - assignment. - - This document assigns option code 65535 to "Reserved for future - expansion." - - This document expands the RCODE space from 4 bits to 12 bits. This - will allow IANA to assign more than the 16 distinct RCODE values - allowed in RFC 1035 [RFC1035]. - - This document assigns EDNS Extended RCODE "16" to "BADVERS". - - IESG approval should be required to create new entries in the EDNS - Extended Label Type or EDNS Version Number registries, while any - - - -Graff & Vixie Expires January 29, 2010 [Page 9] - -Internet-Draft EDNS0 Extensions July 2009 - - - published RFC (including Informational, Experimental, or BCP) should - be grounds for allocation of an EDNS Option Code. - - -10. Acknowledgements - - Paul Mockapetris, Mark Andrews, Robert Elz, Don Lewis, Bob Halley, - Donald Eastlake, Rob Austein, Matt Crawford, Randy Bush, and Thomas - Narten were each instrumental in creating and refining this - specification. - - -11. References - -11.1. Normative References - - [RFC1035] Mockapetris, P., "Domain names - implementation and - specification", STD 13, RFC 1035, November 1987. - - [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", - RFC 2671, August 1999. - - [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", - RFC 3225, December 2001. - -11.2. Informative References - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - -Authors' Addresses - - Michael Graff - Internet Systems Consortium - 950 Charter Street - Redwood City, California 94063 - US - - Phone: +1 650.423.1304 - Email: mgraff@isc.org - - - - - - - - - - -Graff & Vixie Expires January 29, 2010 [Page 10] - -Internet-Draft EDNS0 Extensions July 2009 - - - Paul Vixie - Internet Systems Consortium - 950 Charter Street - Redwood City, California 94063 - US - - Phone: +1 650.423.1301 - Email: vixie@isc.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Graff & Vixie Expires January 29, 2010 [Page 11] - diff --git a/doc/draft/draft-ietf-dnsext-rfc2671bis-edns0-05.txt b/doc/draft/draft-ietf-dnsext-rfc2671bis-edns0-05.txt new file mode 100644 index 0000000000000..a46655affe0af --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-rfc2671bis-edns0-05.txt @@ -0,0 +1,728 @@ + + + +DNSEXT Working Group J. Damas +Internet-Draft M. Graff +Obsoletes: 2671, 2673 P. Vixie +(if approved) Internet Systems Consortium +Intended status: Standards Track March 7, 2011 +Expires: September 8, 2011 + + + Extension Mechanisms for DNS (EDNS0) + draft-ietf-dnsext-rfc2671bis-edns0-05 + +Abstract + + The Domain Name System's wire protocol includes a number of fixed + fields whose range has been or soon will be exhausted and does not + allow requestors to advertise their capabilities to responders. This + document describes backward compatible mechanisms for allowing the + protocol to grow. + + This document updates the EDNS0 specification [RFC2671] based on 10 + years of deployment experience. + +Status of this Memo + + This Internet-Draft is submitted in full conformance with the + provisions of BCP 78 and BCP 79. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF). Note that other groups may also distribute + working documents as Internet-Drafts. The list of current Internet- + Drafts is at http://datatracker.ietf.org/drafts/current/. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + This Internet-Draft will expire on September 8, 2011. + +Copyright Notice + + Copyright (c) 2011 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + + + +Damas, et al. Expires September 8, 2011 [Page 1] + +Internet-Draft EDNS0 Extensions March 2011 + + + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 3. EDNS Support Requirement . . . . . . . . . . . . . . . . . . . 3 + 4. DNS Message changes . . . . . . . . . . . . . . . . . . . . . 4 + 4.1. Message Header . . . . . . . . . . . . . . . . . . . . . . 4 + 4.2. Label Types . . . . . . . . . . . . . . . . . . . . . . . 4 + 4.3. UDP Message Size . . . . . . . . . . . . . . . . . . . . . 4 + 5. Extended Label Types . . . . . . . . . . . . . . . . . . . . . 4 + 6. The OPT pseudo-RR . . . . . . . . . . . . . . . . . . . . . . 5 + 6.1. OPT Record Definition . . . . . . . . . . . . . . . . . . 5 + 6.2. OPT Record Wire Format . . . . . . . . . . . . . . . . . . 5 + 6.3. Cache behaviour . . . . . . . . . . . . . . . . . . . . . 7 + 6.4. Fallback . . . . . . . . . . . . . . . . . . . . . . . . . 7 + 6.5. Requestor's Payload Size . . . . . . . . . . . . . . . . . 7 + 6.6. Responder's Payload Size . . . . . . . . . . . . . . . . . 7 + 6.7. Payload Size Selection . . . . . . . . . . . . . . . . . . 8 + 6.8. Middleware Boxes . . . . . . . . . . . . . . . . . . . . . 8 + 6.9. OPT Record TTL Field Use . . . . . . . . . . . . . . . . . 8 + 6.10. Flags . . . . . . . . . . . . . . . . . . . . . . . . . . 9 + 6.11. OPT Options Code Allocation Procedure . . . . . . . . . . 9 + 7. Transport Considerations . . . . . . . . . . . . . . . . . . . 10 + 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 + 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 + Appendix A. Document Editing History . . . . . . . . . . . . . . 11 + Appendix A.1. Changes since RFC2671 . . . . . . . . . . . . . . . 11 + Appendix A.2. Changes since -02 . . . . . . . . . . . . . . . . . 12 + 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 + 10.1. Normative References . . . . . . . . . . . . . . . . . . . 12 + 10.2. Informative References . . . . . . . . . . . . . . . . . . 12 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 + + + + + + + + + + + + +Damas, et al. Expires September 8, 2011 [Page 2] + +Internet-Draft EDNS0 Extensions March 2011 + + +1. Introduction + + DNS [RFC1035] specifies a Message Format and within such messages + there are standard formats for encoding options, errors, and name + compression. The maximum allowable size of a DNS Message is limited + to 512 bytes. Many of DNS's protocol limits are too small for uses + which are commom or desired to become common. RFC 1035 does not + define any way for implementations to advertise their capabilities. + + [RFC2671] added extension mechanism to DNS, this mechanism is widely + supported and number of new DNS uses and protocol extensions depend + on the presence of these extensions. This memo refines that + specification and obsoletes [RFC2671]. + + Unextended agents will not know how to interpret the protocol + extensions defined in [RFC2671] and restated here. Extended agents + must be prepared for handling the interactions with unextended + clients in the face of new protocol elements, and fall back + gracefully to unextended DNS. [RFC2671] proposed extensions to the + basic DNS protocol to overcome these deficiencies. This memo refines + that specification and obsoletes [RFC2671]. + + [RFC2671] specified extended label types. The only one proposed was + in RFC2673 for a label type called "Bitstring Labels." For various + reasons introducing a new label type was found to be extremely + difficult, and RFC2673 was moved to Experimental. This document + Obsoletes Extended Labels. + + +2. Terminology + + "Requestor" is the side which sends a request. "Responder" is an + authoritative, recursive resolver, or other DNS component which + responds to questions. + + 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 RFC 2119 [RFC2119]. + + +3. EDNS Support Requirement + + EDNS support is practically mandatory in a modern world. DNSSEC + requires EDNS support, and many other features are made possible only + by EDNS support to request or advertise them. Many organizations are + requiring DNSSEC. Without common interoperability, DNSSEC cannot be + as easily deployed. + + + + +Damas, et al. Expires September 8, 2011 [Page 3] + +Internet-Draft EDNS0 Extensions March 2011 + + + DNS publishers are wanting to put more data in answers. DNSSEC + DNSKEY records, negative answers, and many other DNSSEC queries cause + larger answers to be returned. In order to support this, DNS + servers, middleware, and stub resolvers MUST support larger packet + sizes advertised via EDNS0. + + +4. DNS Message changes + +4.1. Message Header + + The DNS Message Header's second full 16-bit word is divided into a + 4-bit OPCODE, a 4-bit RCODE, and a number of 1-bit flags (see , + section 4.1.1 [RFC1035]). Some of these were marked for future use, + and most these have since been allocated. Also, most of the RCODE + values are now in use. The OPT pseudo-RR specified below contains + extensions to the RCODE bit field as well as additional flag bits. + +4.2. Label Types + + The first two bits of a wire format domain label are used to denote + the type of the label. [RFC1035] allocates two of the four possible + types and reserves the other two. More label types were defined in + [RFC2671]. This document obsoletes the use of the 2-bit combination + defined by [RFC2671] to identify extended label types. + +4.3. UDP Message Size + + Traditional DNS Messages are limited to 512 octets in size when sent + over UDP ([RFC1035]). Today, many organizations wish to return many + records in a single reply, and special tricks are needed to make the + responses fit in this 512-byte limit. Additionally, inclusion of + DNSSEC records frequently requires a much larger response than a 512 + byte message can hold. + + EDNS0 is intended to address these larger packet sizes and continue + to use UDP. It specifies a way to advertise additional features such + as larger response size capability, which is intended to help avoid + truncated UDP responses which then cause retry over TCP. + + +5. Extended Label Types + + The first octet in the on-the-wire representation of a DNS label + specifies the label type; the basic DNS specification [RFC1035] + dedicates the two most significant bits of that octet for this + purpose. + + + + +Damas, et al. Expires September 8, 2011 [Page 4] + +Internet-Draft EDNS0 Extensions March 2011 + + + [RFC2671] defined DNS label type 0b01 for use as an indication for + Extended Label Types. A specific Extended Label Type is selected by + the 6 least significant bits of the first octet. Thus, Extended + Label Types are indicated by the values 64-127 (0b01xxxxxx) in the + first octet of the label. + + Extended Label Types are difficult to use due to support in clients + and intermediate gateways as described in [RFC3364] which moves them + to experimental status and [RFC3363], which describes the pros and + cons. + + Therefore, this document moves them from experimental to historical, + making them obsoleted. Additionally, the registry of Extended Label + Types is requested to be closed. + + +6. The OPT pseudo-RR + +6.1. OPT Record Definition + + An OPT pseudo-RR (sometimes called a meta-RR) MAY be added to the + additional data section of a request. + + The OPT RR has RR type 41. + + If present in requests, compliant responders MUST include an OPT + record in their respective responses. + + An OPT record does not carry any DNS data. It is used only to + contain control information pertaining to the question and answer + sequence of a specific transaction. OPT RRs MUST NOT be cached, + forwarded, or stored in or loaded from master files. + + The OPT RR MAY be placed anywhere within the additional data section. + Only one OPT RR MAY be included within any DNS message. If a message + with more than one OPT RR is received, a FORMERR (RCODE=1) MUST be + returned. The placement flexibility for the OPT RR does not override + the need for the TSIG or SIG(0) RRs to be the last in the additional + section whenever they are present. + +6.2. OPT Record Wire Format + + An OPT RR has a fixed part and a variable set of options expressed as + {attribute, value} pairs. The fixed part holds some DNS meta data + and also a small collection of basic extension elements which we + expect to be so popular that it would be a waste of wire space to + encode them as {attribute, value} pairs. + + + + +Damas, et al. Expires September 8, 2011 [Page 5] + +Internet-Draft EDNS0 Extensions March 2011 + + + The fixed part of an OPT RR is structured as follows: + + +------------+--------------+------------------------------+ + | Field Name | Field Type | Description | + +------------+--------------+------------------------------+ + | NAME | domain name | Must be 0 (root domain) | + | TYPE | u_int16_t | OPT (42) | + | CLASS | u_int16_t | requestor's UDP payload size | + | TTL | u_int32_t | extended RCODE and flags | + | RDLEN | u_int16_t | length of all RDATA | + | RDATA | octet stream | {attribute,value} pairs | + +------------+--------------+------------------------------+ + + OPT RR Format + + The variable part of an OPT RR may contain zero or more options in + the RDATA. Each option must be treated as binary. Each option is + encoded as: + + + +0 (MSB) +1 (LSB) + +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ + 0: | OPTION-CODE | + +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ + 2: | OPTION-LENGTH | + +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ + 4: | | + / OPTION-DATA / + / / + +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ + + OPTION-CODE + Assigned by Expert Review. + + OPTION-LENGTH + Size (in octets) of OPTION-DATA. + + OPTION-DATA + Varies per OPTION-CODE. MUST be treated as binary. + + The order of appearance of option tuples is not defined. If one + option modifies the behavior of another or multiple options are + related to one another in some way, they have the same effect + regardless of ordering in the RDATA wire encoding. + + Any OPTION-CODE values not understood by a responder or requestor + MUST be ignored. Specifications of such options might wish to + include some kind of signaled acknowledgement. For example, an + + + +Damas, et al. Expires September 8, 2011 [Page 6] + +Internet-Draft EDNS0 Extensions March 2011 + + + option specification might say that if a responder sees option XYZ, + it MUST include option XYZ in its response. + +6.3. Cache behaviour + + The OPT record MUST NOT be cached. + +6.4. Fallback + + If a requestor detects that the remote end does not support EDNS0, it + MAY issue queries without an OPT record. It MAY cache this knowledge + for a brief time in order to avoid fallback delays in the future. + However, if DNSSEC or any future option using EDNS is required, no + fallback should be performed as they are only signaled through EDNS0. + If an implementation detects that some servers for the zone support + EDNS(0) while others would force the use of TCP to fetch all data, + preference SHOULD be given to those support EDNS(0). + +6.5. Requestor's Payload Size + + The requestor's UDP payload size (encoded in the RR CLASS field) is + the number of octets of the largest UDP payload that can be + reassembled and delivered in the requestor's network stack. Note + that path MTU, with or without fragmentation, could be smaller than + this. Values lower than 512 MUST be treated as equal to 512. + + The requestor SHOULD place a value in this field that it can actually + receive. For example, if a requestor sits behind a firewall which + will block fragmented IP packets, a requestor SHOULD not choose a + value which will cause fragmentation. Doing so will prevent large + responses from being received, and can cause fallback to occur. + + Note that a 512-octet UDP payload requires a 576-octet IP reassembly + buffer. Choosing between 1280 and 1410 bytes for IP (v4 or v6) over + Ethernet would be reasonable. Choosing a very large value will + guarantee fragmentation at the IP layer, and may prevent answers from + being received due to a single fragment loss or misconfigured + firewalls. + + The requestor's maximum payload size can change over time. It MUST + not be cached for use beyond the transaction in which it is + advertised. + +6.6. Responder's Payload Size + + The responder's maximum payload size can change over time, but can be + reasonably expected to remain constant between two closely spaced + sequential transactions; for example, a meaningless QUERY to discover + + + +Damas, et al. Expires September 8, 2011 [Page 7] + +Internet-Draft EDNS0 Extensions March 2011 + + + a responder's maximum UDP payload size, followed immediately by an + UPDATE which takes advantage of this size. This is considered + preferable to the outright use of TCP for oversized requests, if + there is any reason to suspect that the responder implements EDNS, + and if a request will not fit in the default 512 payload size limit. + +6.7. Payload Size Selection + + Due to transaction overhead, it is unwise to advertise an + architectural limit as a maximum UDP payload size. Just because your + stack can reassemble 64KB datagrams, don't assume that you want to + spend more than about 4KB of state memory per ongoing transaction. + + A requestor MAY choose to implement a fallback to smaller advertised + sizes to work around firewall or other network limitations. A + requestor SHOULD choose to use a fallback mechanism which begins with + a large size, such as 4096. If that fails, a fallback around the + 1280-1410 byte range SHOULD be tried, as it has a reasonable chance + to fit within a single Ethernet frame. Failing that, a requestor MAY + choose a 512 byte packet, which with large answers may cause a TCP + retry. + +6.8. Middleware Boxes + + Middleware boxes (e.g. firewalls, SOHO routers, load balancers, etc) + MUST NOT limit DNS messages over UDP to 512 bytes. + + Middleware boxes which simply forward requests to a recursive + resolver MUST NOT modify and MUST NOT delete the OPT record contents + in either direction. + + Middleware boxes which have additional functionality, such as + answering certain queries or acting like an intelligent forwarder, + MUST understand the OPT record. These boxes MUST consider the + incoming request and any outgoing requests as separate transactions + if the characteristics of the messages are different. + + A complete discussion of middleware boxes acting as DNS proxies and + the impact of EDNS in those implementations is described in + [RFC5625]. + +6.9. OPT Record TTL Field Use + + The extended RCODE and flags (which OPT stores in the RR TTL field) + are structured as follows: + + + + + + +Damas, et al. Expires September 8, 2011 [Page 8] + +Internet-Draft EDNS0 Extensions March 2011 + + + +0 (MSB) +1 (LSB) + +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ + 0: | EXTENDED-RCODE | VERSION | + +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ + 2: | DO| Z | + +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ + + EXTENDED-RCODE + Forms upper 8 bits of extended 12-bit RCODE (together with the + 4 bits defined in [RFC1035]. Note that EXTENDED-RCODE value 0 + indicates that an unextended RCODE is in use (values 0 through + 15). + + VERSION + Indicates the implementation level of whoever sets it. Full + conformance with this specification is indicated by version + ``0.'' Requestors are encouraged to set this to the lowest + implemented level capable of expressing a transaction, to + minimize the responder and network load of discovering the + greatest common implementation level between requestor and + responder. A requestor's version numbering strategy MAY + ideally be a run time configuration option. + If a responder does not implement the VERSION level of the + request, then it answers with RCODE=BADVERS. All responses + MUST be limited in format to the VERSION level of the request, + but the VERSION of each response SHOULD be the highest + implementation level of the responder. In this way a requestor + will learn the implementation level of a responder as a side + effect of every response, including error responses and + including RCODE=BADVERS. + +6.10. Flags + + DO + DNSSEC OK bit as defined by [RFC3225]. + + Z + Set to zero by senders and ignored by receivers, unless + modified in a subsequent specification. + +6.11. OPT Options Code Allocation Procedure + + Allocations assigned by expert review. Assignment of Option Codes + should be liberal, but duplicate functionality is to be avoided. + + + + + + + +Damas, et al. Expires September 8, 2011 [Page 9] + +Internet-Draft EDNS0 Extensions March 2011 + + +7. Transport Considerations + + The presence of an OPT pseudo-RR in a request should be taken as an + indication that the requestor fully implements the given version of + EDNS, and can correctly understand any response that conforms to that + feature's specification. + + Lack of presence of an OPT record in a request MUST be taken as an + indication that the requestor does not implement any part of this + specification and that the responder MUST NOT include an OPT record + in its response. + + Responders who do not implement these protocol extensions MUST + respond with FORMERR messages without any OPT record. + + If there is a problem with processing the OPT record itself, such as + an option value that is badly formatted or includes out of range + values, a FORMERR MUST be returned. If this occurs the response MUST + include an OPT record. This is intended to allow the requestor to to + distinguish between servers which do not implement EDNS and format + errors within EDNS. + + The minimal response must be the DNS header, question section, and an + OPT record. This must also occur when an truncated response (using + the DNS header's TC bit) is returned. + + +8. Security Considerations + + Requestor-side specification of the maximum buffer size may open a + DNS denial of service attack if responders can be made to send + messages which are too large for intermediate gateways to forward, + thus leading to potential ICMP storms between gateways and + responders. + + Announcing very large UDP buffer sizes may result in dropping by + middleboxes (see Section 6.8). This could cause retransmissions with + no hope of success. Some devices have been found to reject + fragmented UDP packets. + + Announcing too small UDP buffer sizes may result in fallback to TCP + with a corresponding load impact on DNS servers. This is especially + important with DNSSEC, where answers are much larger. + + +9. IANA Considerations + + The IANA has assigned RR type code 41 for OPT. + + + +Damas, et al. Expires September 8, 2011 [Page 10] + +Internet-Draft EDNS0 Extensions March 2011 + + + [RFC2671] specified a number of IANA sub-registries within "DOMAIN + NAME SYSTEM PARAMETERS:" + + o EDNS Extended Label Type + + o EDNS Option Codes + + o EDNS Version Numbers + + o Domain System Response Code + + IANA is advised to re-parent these sub-registries to this document. + + [RFC2671] created the "EDNS Extended Label Type Registry". We + request that this registry be closed. + + This document assigns option code 65535 in the "EDNS Option Codes" + registry to "Reserved for future expansion." + + [RFC2671] expands the RCODE space from 4 bits to 12 bits. This + allows more than the 16 distinct RCODE values allowed in [RFC1035]. + IETF Standards Action is required to add a new RCODE. Adding new + RCODEs should be avoided due to the difficulty in upgrading the + installed base. + + This document assigns EDNS Extended RCODE 16 to "BADVERS". + + IETF Standards Action is required for assignments of new EDNS0 flags. + Flags SHOULD be used only when necessary for DNS resolution to + function. For many uses, a EDNS Option Code may be preferred. + + IETF Standards Action is required to create new entries in the EDNS + Version Number registry. Expert Review is required for allocation of + an EDNS Option Code. + + +Appendix A. Document Editing History + + Following is a list of high-level changes made to the original + RFC2671. + +Appendix A.1. Changes since RFC2671 + + o Support for the OPT record is now mandatory. + + o Extended label types obsoleted and the registry is closed. + + + + + +Damas, et al. Expires September 8, 2011 [Page 11] + +Internet-Draft EDNS0 Extensions March 2011 + + + o The bitstring label type, which was already moved from draft to + experimental, is requested to be moved to historical. + + o Changes in how EDNS buffer sizes are selected, with + recommendations on how to select them. + + o Front material (IPR notice and such) was updated to current + requirements. + +Appendix A.2. Changes since -02 + + o Specified the method for allocation of constants. + + o Cleaned up a lot of wording, along with quite a bit of document + structure changes. + + +10. References + +10.1. Normative References + + [RFC1035] Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, November 1987. + + [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", + RFC 2671, August 1999. + + [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", + RFC 3225, December 2001. + + [RFC3363] Bush, R., Durand, A., Fink, B., Gudmundsson, O., and T. + Hain, "Representing Internet Protocol version 6 (IPv6) + Addresses in the Domain Name System (DNS)", RFC 3363, + August 2002. + +10.2. Informative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC3364] Austein, R., "Tradeoffs in Domain Name System (DNS) + Support for Internet Protocol version 6 (IPv6)", RFC 3364, + August 2002. + + [RFC5625] Bellis, R., "DNS Proxy Implementation Guidelines", + BCP 152, RFC 5625, August 2009. + + + + + +Damas, et al. Expires September 8, 2011 [Page 12] + +Internet-Draft EDNS0 Extensions March 2011 + + +Authors' Addresses + + Joao Damas + Internet Systems Consortium + 950 Charter Street + Redwood City, California 94063 + US + + Phone: +1 650.423.1312 + Email: joao@isc.org + + + Michael Graff + Internet Systems Consortium + 950 Charter Street + Redwood City, California 94063 + US + + Phone: +1 650.423.1304 + Email: mgraff@isc.org + + + Paul Vixie + Internet Systems Consortium + 950 Charter Street + Redwood City, California 94063 + US + + Phone: +1 650.423.1301 + Email: vixie@isc.org + + + + + + + + + + + + + + + + + + + + + +Damas, et al. Expires September 8, 2011 [Page 13] + diff --git a/doc/draft/draft-ietf-dnsop-dnssec-key-timing-00.txt b/doc/draft/draft-ietf-dnsop-dnssec-key-timing-00.txt deleted file mode 100644 index 6028ee89d64bd..0000000000000 --- a/doc/draft/draft-ietf-dnsop-dnssec-key-timing-00.txt +++ /dev/null @@ -1,1960 +0,0 @@ - - - -Internet Engineering Task Force S. Morris -Internet-Draft ISC -Intended status: Informational J. Ihren -Expires: January 2, 2011 Netnod - J. Dickinson - Sinodun - July 1, 2010 - - - DNSSEC Key Timing Considerations - draft-ietf-dnsop-dnssec-key-timing-00.txt - -Abstract - - This document describes the issues surrounding the timing of events - in the rolling of a key in a DNSSEC-secured zone. It presents - timelines for the key rollover and explicitly identifies the - relationships between the various parameters affecting the process. - -Status of this Memo - - This Internet-Draft is submitted in full conformance with the - provisions of BCP 78 and BCP 79. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF). Note that other groups may also distribute - working documents as Internet-Drafts. The list of current Internet- - Drafts is at http://datatracker.ietf.org/drafts/current/. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - This Internet-Draft will expire on January 2, 2011. - -Copyright Notice - - Copyright (c) 2010 IETF Trust and the persons identified as the - document authors. All rights reserved. - - This document is subject to BCP 78 and the IETF Trust's Legal - Provisions Relating to IETF Documents - (http://trustee.ietf.org/license-info) in effect on the date of - publication of this document. Please review these documents - carefully, as they describe your rights and restrictions with respect - to this document. Code Components extracted from this document must - include Simplified BSD License text as described in Section 4.e of - - - -Morris, et al. Expires January 2, 2011 [Page 1] - -Internet-Draft DNSSEC Key Timing Considerations July 2010 - - - the Trust Legal Provisions and are provided without warranty as - described in the Simplified BSD License. - - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 1.1. Key Rolling Considerations . . . . . . . . . . . . . . . . 3 - 1.2. Types of Keys . . . . . . . . . . . . . . . . . . . . . . 4 - 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 - 2. Rollover Methods . . . . . . . . . . . . . . . . . . . . . . . 4 - 2.1. ZSK Rollovers . . . . . . . . . . . . . . . . . . . . . . 4 - 2.2. KSK Rollovers . . . . . . . . . . . . . . . . . . . . . . 6 - 2.3. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . 13 - 3.2.3. Double-RRSIG Method . . . . . . . . . . . . . . . . . 14 - 3.3. Key-Signing Key Rollover Timelines . . . . . . . . . . . . 17 - 3.3.1. Double-Signature Method . . . . . . . . . . . . . . . 17 - 3.3.2. Double-DS Method . . . . . . . . . . . . . . . . . . . 20 - 3.3.3. Double-RRset Method . . . . . . . . . . . . . . . . . 22 - 3.3.4. Interaction with Configured Trust Anchors . . . . . . 25 - 3.3.4.1. Addition of KSK . . . . . . . . . . . . . . . . . 25 - 3.3.4.2. Removal of KSK . . . . . . . . . . . . . . . . . . 25 - 3.3.5. Introduction of First KSK . . . . . . . . . . . . . . 26 - 4. Standby Keys . . . . . . . . . . . . . . . . . . . . . . . . . 27 - 5. Algorithm Considerations . . . . . . . . . . . . . . . . . . . 28 - 6. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 - 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 - 8. Security Considerations . . . . . . . . . . . . . . . . . . . 28 - 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29 - 10. Change History . . . . . . . . . . . . . . . . . . . . . . . . 29 - 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30 - 11.1. Normative References . . . . . . . . . . . . . . . . . . . 30 - 11.2. Informative References . . . . . . . . . . . . . . . . . . 30 - Appendix A. List of Symbols . . . . . . . . . . . . . . . . . . . 30 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34 - - - - - - - - - - - -Morris, et al. Expires January 2, 2011 [Page 2] - -Internet-Draft DNSSEC Key Timing Considerations July 2010 - - -1. Introduction - -1.1. Key Rolling Considerations - - When a zone is secured with DNSSEC, the zone manager must be prepared - to replace ("roll") the keys used in the signing process. The - rolling of keys may be caused by compromise of one or more of the - existing keys, or it may be due to a management policy that demands - periodic key replacement for security or operational reasons. In - order to implement a key rollover, the keys need to be introduced - into and removed from the zone at the appropriate times. - Considerations that must be taken into account are: - - o DNSKEY records and associated information (such as RRSIG records - created with the key or the associated DS records) are not only - held at the authoritative nameserver, they are also cached at - client resolvers. The data on these systems can be interlinked, - e.g. a validating resolver may try to validate a signature - retrieved from a cache with a key obtained separately. - - o 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 - time, can be common in configurations where a large number of - zones are being served. Procedures should be able to cope with - the introduction of keys into the zone for the first time as well - as "steady-state", where the records are being replaced as part of - normal zone maintenance. - - o To allow for an emergency re-signing of the zone as soon as - possible after a key compromise has been detected, stand-by keys - (additional keys over and above those used to sign the zone) need - to be present. - - Management policy, e.g. how long a key is used for, also needs to be - considered. However, the point of key management logic is not to - ensure that a "rollover" is completed at a certain time but rather to - ensure that no changes are made to the state of keys published in the - zone until it is "safe" to do so ("safe" in this context meaning that - at no time during the rollover process does any part of the zone ever - go bogus). In other words, although key management logic enforces - policy, it may not enforce it strictly. - - - - -Morris, et al. Expires January 2, 2011 [Page 3] - -Internet-Draft DNSSEC Key Timing Considerations July 2010 - - -1.2. Types of Keys - - Although DNSSEC validation treats all keys equally, [RFC4033] - recognises the broad classification of zone-signing keys (ZSK) and - 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 - zone. The main implication for this distinction concerns the - consistency of information during a rollover. - - During operation, a validating resolver must use separate pieces of - information to perform an authentication. At the time of - authentication, each piece of information may be in the validating - resolver's cache or may need to be retrieved from the authoritative - server. The rollover process needs to happen in such a way that at - all times through the rollover the information is consistent. With a - ZSK, the information is the RRSIG (plus associated RRset) and the - DNSKEY. These are both obtained from the same zone. In the case of - the KSK, the information is the DNSKEY and DS RRset with the latter - being obtained from a different zone. - - There are similarities in the rolling of ZSKs and KSKs: replace the - RRSIG (plus RR) by the DNSKEY and replace the DNSKEY by the DS, and - the ZSK rolling algorithms are virtually the same as the KSK - algorithms. However, there are a number of differences, and for this - reason the two types of rollovers are described separately in this - document. - -1.3. Terminology - - The terminology used in this document is as defined in [RFC4033] and - [RFC5011]. - - A large number of symbols are used to identify times, intervals, etc. - All are listed in Appendix A. - - -2. Rollover Methods - -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, leaving the existing keys and - signatures in place. This state of affairs remains in place for - long enough to ensure that any DNSKEY RRsets cached in client - validating resolvers contain both keys. At that point signatures - created with the old key can be replaced by those created with the - - - -Morris, et al. Expires January 2, 2011 [Page 4] - -Internet-Draft DNSSEC Key Timing Considerations July 2010 - - - new key, and the old signatures removed. During the re-signing - process (which may or may not be atomic depending on how the zone - is managed), it doesn't matter which key an RRSIG record retrieved - by a client was created with; clients with a cached copy of the - DNSKEY RRset will have a copy containing both the old and new - keys. - - Once the zone contains only signatures created with the new key, - there is an interval during which RRSIG records created with the - old key expire from client caches. After this, there will be no - 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), client 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 - and signatures can be removed from the zone. As before, during - this period any combination of DNSKEY RRset and RRSIG will allow - validation of at least one signature. - - o Double-RRSIG. Strictly speaking, the use of the term "Double- - Signature" above is a misnomer as the method is not only double - signature, it is also double key as well. A true Double-Signature - method (here called the Double-RRSIG method) involves introducing - new signatures in the zone (while still retaining the old ones) - but not the new key. - - Once the signing process is complete and enough time has elapsed - to ensure that all caches that may contain an RR and associated - RRSIG to have a copy of both signatures, the ZSK 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 the simplest conceptually - - introduce the new key and new signatures, then approximately one TTL - later remove the old key and signatures. The drawback of this method - is a noticeable increase in the size of the DNSSEC data, affecting - both the overall size of the zone and the size of the responses. - - Pre-Publication is more complex - introduce the new key, - - - -Morris, et al. Expires January 2, 2011 [Page 5] - -Internet-Draft DNSSEC Key Timing Considerations July 2010 - - - approximately one TTL later sign the records, and approximately one - 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 - - In the ZSK case 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 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 an explicitly - configured trust anchor in the validating resolver or DS record in - the parent zone (which is itself trusted). If the former, [RFC5011] - timings will be needed to roll the keys. If the latter, 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. (The zone manager may elect to include [RFC5011] - timings in the key rolling process so as to cope with the possibility - that the key has also been explicitly configured as a trust anchor.) - - It is important to note that this does not preclude the development - of key rollover logic; in accordance with the goal of the rollover - logic being able to determine when a state change is "safe", the only - effect of being dependent on the parent is that there may be a period - of waiting for the parent to respond in addition to any delay the key - rollover logic requires. Although this introduces additional delays, - even with a parent that is less than ideally responsive the only - effect will be a slowdown in the rollover state transitions. This - may cause a policy violation, but will not cause any operational - problems. - - Like the ZSK case, there are three methods for rolling a KSK: - - 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, - - - -Morris, et al. Expires January 2, 2011 [Page 6] - -Internet-Draft DNSSEC Key Timing Considerations July 2010 - - - 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 the caches of all validating resolvers, - the KSK is changed. After a further interval during which the old - DNSKEY RRset expires from caches, the old DS record is removed. - - o Double-RRset: the new KSK is added to the DNSKEY RRset which is - then signed with both the old and new key, and the new DS record - added to the parent zone. After waiting a suitable interval for - the old DS and DNSKEY RRsets to expire from validating resolver - caches, the old DNSKEY and DS record are removed. - - In essence, "Double-Signature" means that the new KSK is introduced - first and used to sign the DNSKEY RRset. The DS record is changed, - and finally the old KSK removed. With "Double-DS" it is the other - way around. Finally, Double-RRset does both updates more or less in - 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 - - The methods can be summarised as follows: - - - - - - - - -Morris, et al. Expires January 2, 2011 [Page 7] - -Internet-Draft DNSSEC Key Timing Considerations July 2010 - - - +------------------+------------------+-----------------------------+ - | ZSK Method | KSK Method | Description | - +------------------+------------------+-----------------------------+ - | Pre-Publication | (not applicable) | Publish the DNSKEY before | - | | | the RRSIG. | - | Double-Signature | Double-Signature | Publish the DNSKEY and | - | | | RRSIG at same time. (For a | - | | | KSK, this happens before | - | | | the DS is published.) | - | Double-RRSIG | (not applicable) | Publish RRSIG before the | - | | | DNSKEY. | - | (not applicable) | Double-DS | Publish DS before the | - | | | DNSKEY. | - | (not applicable) | Double-RRset | Publish DNSKEY and DS in | - | | | parallel. | - +------------------+------------------+-----------------------------+ - - Table 1 - - -3. Key Rollover Timelines - -3.1. Key States - - During the rolling process, a key moves through different states. - These states are: - - Generated The key has been created, but has not yet been used for - anything. - - Published The DNSKEY record - or information associated with it - - is published in the zone, but predecessors of the key (or - associated information) may be held in resolver caches. - - The idea of "associated information" is used in rollover - methods where RRSIG or DS records are published first and - the DNSKEY is changed in an atomic operation. It allows - the rollover still to be thought of as moving through a - set of states. In the rest of this section, the term - "key" should be taken to mean "key or associated - information". - - Ready The key has been published for long enough to guarantee - that all caches that might contain a copy of the key - RRset have a copy that includes this key. - - - - - - -Morris, et al. Expires January 2, 2011 [Page 8] - -Internet-Draft DNSSEC Key Timing Considerations July 2010 - - - Active The key is in the zone and has started to be used to sign - RRsets or authenticate the DNSKEY RRset. Note that when - this state is entered, it might not be possible for every - validating resolver to use the key for validation: the - zone signing may not have finished, or the data might not - have reached the resolver because of propagation delays - and/or caching issues. If this is the case, the resolver - will have to rely on the 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. - - Dead The key is published in the zone but there is no - information anywhere that requires its presence. - - Removed The key has been removed from the zone. - - There is one additional state, used where [RFC5011] considerations - are in effect (see Section 3.3.4): - - Revoked The key is published for a period with the "revoke" bit - set as a way of notifying validating resolvers that have - configured it as a trust anchor that it is about to be - removed from the zone. - -3.2. Zone-Signing Key Timelines - -3.2.1. Pre-Publication Method - - The following diagram shows the time line of a particular ZSK and its - replacement by its successor using the Pre-Publication method. Time - increases along the horizontal scale from left to right and the - vertical lines indicate events in the life of the key. The events - are numbered; significant times and time intervals are marked. - - - - - - - - - - - - - - - -Morris, et al. Expires January 2, 2011 [Page 9] - -Internet-Draft DNSSEC Key Timing Considerations July 2010 - - - |1| |2| |3| |4| |5| |6| |7| |8| |9| - | | | | | | | | | - Key N | |<-Ipub->|<--->|<-------Lzsk----->|<-Iret->|<--->| - | | | | | | | | | - Key N+1 | | | | |<-Ipub->|<->|<---Lzsk-- - - - | | | | | | | | | - Tgen Tpub Trdy Tact TpubS Tret Tdea Trem - - ---- Time ----> - - - Figure 1: Timeline for a Pre-Publication ZSK rollover. - - Event 1: key N is generated at the generate time (Tgen). Although - there is no reason why the key cannot be generated immediately prior - to publication in the zone (Event 2), some implementations may find - it convenient to create a pool of keys in one operation and draw from - that pool as required. For this reason, it is shown as a separate - event. Keys that are available for use but not published are said to - be generated. - - Event 2: key N's DNSKEY record is put into the zone, i.e. it is added - to the DNSKEY RRset which is then re-signed with the current key- - signing key. The time at which this occurs is the key's publication - time (Tpub), and the key is now said to be published. Note that 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 resolver that has a copy of the DNSKEY - RRset from the zone in its cache will have a copy of the RRset that - includes this key: in other words, that any prior cached information - about the DNSKEY RRset has expired. - - This interval is the publication interval (Ipub) and, for the second - or subsequent keys in the zone, is given by: - - Ipub = Dprp + TTLkey - - Here, Dprp is the propagation delay - the time taken for any change - introduced at the master to replicate to all slave servers - which - depends on the depth of the master-slave hierarchy. TTLkey is the - time-to-live (TTL) for the DNSKEY records in the zone. The sum is - therefore the time taken for existing DNSKEY records to expire from - the caches of downstream validating resolvers, regardless of the - nameserver from which they were retrieved. - - In the case of the first key in the zone, Ipub is slightly different - because it is not information about a DNSKEY RRset that may be - - - -Morris, et al. Expires January 2, 2011 [Page 10] - -Internet-Draft DNSSEC Key Timing Considerations July 2010 - - - 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 - to sign records. The time at which this event occurs is the key's - ready time (Trdy), which is given by: - - Trdy = Tpub + Ipub - - Event 4: at some later time, the key starts being used to sign - RRsets. This point is the active time (Tact) and after this, the key - is said to be active. - - Event 5: while this key is active, 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 used. Denoting the publication time of - the successor key by TpubS, then: - - TpubS <= Tact + Lzsk - Ipub - - Here, Lzsk is the length of time for which a ZSK will be used (the - ZSK lifetime). It should be noted that unlike the publication - interval, Lzsk is not determined by timing logic, but by key - management policy. Lzsk will be set by the operator according to - their assessment of the risks posed by continuing to use a key and - the risks associated with key rollover. However, operational - considerations may mean a key is active for slightly more or less - than Lzsk. - - Event 6: while the key N is still active, its successor becomes - ready. From this time onwards, it could be used to sign the zone. - - Event 7: at some point the decision is made to start signing the zone - using the successor key. This will be when the current key has been - in use for an interval equal to the ZSK lifetime, hence: - - Tret = Tact + Lzsk - - This point in time is the retire time (Tret) of key N; after this the - - - -Morris, et al. Expires January 2, 2011 [Page 11] - -Internet-Draft DNSSEC Key Timing Considerations July 2010 - - - key is said to be retired. (This time is also the point at which the - successor key becomes active.) - - Event 8: the retired key needs to be retained in the zone whilst any - RRSIG records created using this key are still published in the zone - or held in resolver caches. (It is possible that a resolver could - have an unexpired RRSIG record and an expired DNSKEY RRset in the - cache when it is asked to provide both to a client. In this case the - DNSKEY RRset would need to be looked up again.) This means that once - the key is no longer used to sign records, it should be retained in - the zone for at least the retire interval (Iret) given by: - - Iret = Dsgn + Dprp + TTLsig - - Dsgn is the delay needed to ensure that all existing RRsets have been - re-signed with the new key. Dprp is (as described above) the - propagation delay, required to guarantee that the updated zone - information has reached all slave servers, and TTLsig is the TTL of - the RRSIG records. - - (It should be noted that an upper limit on the retire interval is - given by: - - Iret = Lsig + Dskw - - where Lsig is the lifetime of a signature (i.e. the interval between - the time the signature was created and the signature end time), and - Dskw is the clock skew - the maximum difference in time between the - server and a 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 - expired from resolver caches is the dead time (Tdea), given by: - - Tdea = Tret + Iret - - ...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: - - - - -Morris, et al. Expires January 2, 2011 [Page 12] - -Internet-Draft DNSSEC Key Timing Considerations July 2010 - - - Trem >= Tdea - - ...at which time the key is said to be removed. - -3.2.2. Double-Signature Method - - In the Double-Signature method, both the new key and signatures - created using it are introduced at the same time. After a period - during which this information propagates to validating resolver - caches, the old key and signature are removed. The time line for the - method is shown below: - - - - |1| |2| |3| |4| |5| |6| - | | | | | | - Key N | |<-------Lzsk------>|<-----Iret----->| | - | | | | | | - Key N+1 | | | |<----------Lzsk------- - - - | | | | | | - Tgen Tact Tret Tdea Trem - - ---- Time ----> - - - Figure 2: Timeline for a Double-Signature ZSK rollover. - - Event 1: key N is generated at the generate time (Tgen). Although - there is no reason why the key cannot be generated immediately prior - to publication in the zone (Event 2), some implementations may find - it convenient to create a pool of keys in one operation and draw from - that pool as required. For this reason, it is shown as a separate - event. Keys that are available for use but not published are said to - be generated. - - Event 2: key N 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 - signatures can be withdrawn from the zone. (The timing of key - removal is discussed further in the description of event 5.) - - Event 4: the successor key (key N+1) is introduced into the zone and - starts being used to sign RRsets. The successor is key is now active - and the current key (key N) is said to be retired. This time is the - retire time of the key (Tret); it is also the active time of the - successor key (TactS). - - - -Morris, et al. Expires January 2, 2011 [Page 13] - -Internet-Draft DNSSEC Key Timing Considerations July 2010 - - - Tret = Tact + Lzsk - - Event 5: 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 - result, all these RRsets are now signed twice, once by key N and once - by its successor) and the information must have reached all - validating resolvers that may have RRsets from this zone cached. - - This takes Iret, the retire interval, given by the expression: - - Iret = Dsgn + Dprp + max(TTLkey, TTLsig) - - As before, Dsgn is the time taken to sign the zone with the new key - and Dprp is the propagation delay. The final term is the period to - wait for old key and signature data to expire from caches. After the - end of this interval, key N is said to be dead. This occurs at the - dead time (Tdea) so: - - Tdea = Tret + Iret - - Event 6: at some later time key N and its signatures can be removed - from the zone. This is the removal time Trem, given by: - - Trem >= Tdea - -3.2.3. Double-RRSIG Method - - As noted above, "Double-Signature" is simultaneous rollover of both - signature and key. The time line for a pure Double-Signature ZSK - 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| - | | | | | | | | | | | - Key N | |<-Dsgn->| | |<-----------Lzsk-------->|<-Iret->| | - | |<---IpubG-->| |<-IpubK->| | | | | | - | | | | | | | | | | | - Key N+1 | | | | | | |<-IpubG->| | | | - | | | | | | | | | | | - Tgen Tpub Trdy Tact TpubS TrdyS Tret Tdea Trem - - ---- Time ----> - - - Figure 3: Timeline for a Double-Signature ZSK rollover. - - - -Morris, et al. Expires January 2, 2011 [Page 14] - -Internet-Draft DNSSEC Key Timing Considerations July 2010 - - - Event 1: key N is generated at the generate time (Tgen). Although - there is no reason why the key cannot be generated immediately prior - to publication in the zone (Event 2), some implementations may find - it convenient to create a pool of keys in one operation and draw from - that pool as required. For this reason, it is shown as a separate - event. Keys that are available for use but not published are said to - be generated. - - Event 2: key N is used to sign the zone but existing signatures are - retained. Although the new ZSK is not published in the zone at this - 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 - publish time (Tpub). - - 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 existing key and once by the - (still-absent) key N. - - Event 4: there is now a delay while the this information reaches all - validating resolvers that may have RRsets from the zone cached. This - interval is given by the expression: - - Dprp + TTLsig - - ...comprising the delay for the information to propagate through the - nameserver infrastructure plus the time taken for signature - information to expire from caches. - - 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. - - Trdy = Tpub + IpubG - - where - - IpubG = Dsgn + Dprp + TTLsig - - 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 - created by the old and new keys, the records can still be - authenticated. This time is the active time (Tact) and the key is - now said to be active. - - - - -Morris, et al. Expires January 2, 2011 [Page 15] - -Internet-Draft DNSSEC Key Timing Considerations July 2010 - - - 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 - rolling the key. The first step is to publish signatures created by - the successor key (key N+1) early enough so that key N can 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 8: the signatures have propagated through the zone and the new - key could be added to the zone. This time is the ready time of the - successor (TrdyS). - - TrdyS = TpubS + IpubG - - ... where IpubG is as defined above. - - Event 9: 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). - - Event 10: 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 - occurs is the dead time (Tdea), given by: - - Tdea = Tret + Iret - - ... where Iret is the retire interval, given by: - - Iret = IpubK - - Event 11: At some later time the signatures can be removed from the - 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 - key's remove time (Trem), given by: - - Trem >= Tdea - - - - - - - -Morris, et al. Expires January 2, 2011 [Page 16] - -Internet-Draft DNSSEC Key Timing Considerations July 2010 - - -3.3. Key-Signing Key Rollover Timelines - -3.3.1. Double-Signature Method - - The Double-Signature method (also knows as the double-DNSKEY method) - 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: - - - - |1| |2| |3| |4| |5| |6| - | | | | | | - Key N | |<-Ipub->|<--->|<-Dreg->|<---------Lksk--- - - - | | | | | | - Key N+1 | | | | | | - | | | | | | - Tgen Tpub Trdy Tsub Tact - - ---- Time ----> - - (continued...) - - |7| |8| |9| |10| |11| |12| - | | | | | | - Key N - - -------------Lksk------->|<-Iret->| | - | | | | | | - Key N+1 |<-Ipub->|<--->|<-Dreg->|<--------Lksk----- - - - | | | | | | - TpubS TrdyS TsubS Tret Tdea Trem - - ---- Time (cont) ----> - - - Figure 4: Timeline for a Double-Signature KSK rollover. - - Event 1: key N is generated at time Tgen. As before, although there - is no reason why the key cannot be generated immediately prior to - publication, some implementations may find it convenient to create a - central pool of keys and draw from it. For this reason, it is again - shown as a separate event. - - Event 2: 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 - - - -Morris, et al. Expires January 2, 2011 [Page 17] - -Internet-Draft DNSSEC Key Timing Considerations July 2010 - - - 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 - 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 - 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: - - Ipub = Dprp + TTLkey - - ... where Dprp is the propagation delay for the zone and TTLkey the - TTL for the DNSKEY RRset. The time at which this occurs is the key's - ready time, Trdy, given by: - - Trdy = Tpub + Ipub - - Event 4: at some later time, the DS RR 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 - the point at which all information for authentication - both DNSKEY - and DS record - is available in the two zones, it is the active time - of the key: - - Tact = Tsub + Dreg - - ... 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 - placed in the zone. (Parent zones are often managed by different - entities, and this term accounts of the organisational overhead of - transferring a record.) - - Event 6: at some time later, all validating resolvers that have the - DS RRset cached will have a copy that includes the new DS record. - For the second or subsequent DS records, this interval is given by - the expression: - - DprpP + TTLds - - ... where DprpP is the propagation delay in the parent zone and TTLds - the TTL assigned to DS records in that zone. - - - - -Morris, et al. Expires January 2, 2011 [Page 18] - -Internet-Draft DNSSEC Key Timing Considerations July 2010 - - - 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) - - Event 7: 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 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 - that all validating resolvers that have a copy of the DNSKEY RRset - have a copy of this key). This is the successor ready time, TrdyS. - - Event 9: at the successor submission time (TsubS), the DS record - corresponding to the successor key is submitted to the parent zone. - - Event 10: 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: - - The relationships between these times are: - - TpubS <= Tact + Lksk - Dreg - Ipub - - Tret = Tact + Lksk - - ... where Lksk is the scheduled lifetime of the KSK. - - Event 11: key N must remain in the zone until any validators that - 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 - - ... where DprpP is the propagation delay in the parent zone and TTLds - the TTL of a DS record. - - - -Morris, et al. Expires January 2, 2011 [Page 19] - -Internet-Draft DNSSEC Key Timing Considerations July 2010 - - - As the key is no longer used for anything, it can also be said to be - dead, in which case: - - Tdea = Tret + Iret - - Event 12: at some later time, key N is removed from the zone (at the - remove time Trem); the key is now said to be removed. - - Trem >= Tdea - -3.3.2. Double-DS Method - - The Double-DS method is the reverse of the Double-Signature method is - that it is the DS record that is pre-published (in the parent), and - not the DNSKEY. - - The timeline for the key rollover is shown below: - - - - |1| |2| |3| |4| |5| |6| - | | | | | | - Key N | |<-Dreg->|<-IpubP->|<-->|<---------Lksk------- - - - | | | | | | - Key N+1 | | | | |<---->|<--Dreg+IpubP- - - - | | | | | | - Tgen Tsub Tpub Trdy Tact TsubS - - ---- Time ----> - - (continued...) - - |7| |8| |9| |10| - | | | | - Key N - - -----Lksk---------->|<-Iret->| | - | | | | - Key N+1 - - --Dreg+IpubP->|<--->|<------Lksk------ - - - | | | | - TrdyS Tret Tdea Trem - - ---- Time ----> - - - Figure 5: Timeline for a Double-DS KSK rollover. - - Event 1: key N is generated at time Tgen. As before, although there - is no reason why the key cannot be generated immediately prior to - publication, some implementations may find it convenient to create a - - - -Morris, et al. Expires January 2, 2011 [Page 20] - -Internet-Draft DNSSEC Key Timing Considerations July 2010 - - - central pool of keys and draw from it. For this reason, it is again - shown as a separate event. - - Event 2: the DS record corresponding to key N is submitted for - publication in the parent zone. This time is the submission time - (Tsub). - - 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 validating resolver that has copies - of the DS RRset in its cache 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, Trdy, and is given by: - - Trdy = Tpub + IpubP - - IpubP is the parent publication interval and is given by the - expression: - - IpubP = DprpP + TTLds - - ... where DprpP is the propagation delay in 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. The - predecessor key is withdrawn from the DNSKEY RRset and the new key - (key N) introduced and used to sign the RRset. - - As both DS records have been in the parent zone long enough to ensure - that they are in the cache of any validating resolvers that have the - DS RRset cached, the zone can be authenticated throughout the - rollover - either the resolver has a copy of the DNSKEY RRset (and - associated RRSIGs) authenticated by the predecessor key, or it has a - copy of the updated RRset authenticated with the new key. - - This time is the key's active 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 - 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 - resolver that has DS records in its cache will have data about the DS - record of the successor key. The time at which this occurs is the - - - -Morris, et al. Expires January 2, 2011 [Page 21] - -Internet-Draft DNSSEC Key Timing Considerations July 2010 - - - submission time of the successor, given by: - - TsubS <= Tact + Lksk - IpubP - Dreg - - ... where Lksk is the lifetime of the KSK. - - 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 - the parent DS RRset cached. (This is the ready time of the - successor, TrdyS.) - - Event 8: when the current key has been active for its lifetime - (Lksk), the current key is removed from the DNSKEY RRset and the - successor key added; the RRset is then signed with the successor key. - This point is the retire time of the key, Tret, given by: - - Tret = Tact + Lksk - - 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 - is called the dead time, Tdea, and is given by: - - Tdea = Tret + Iret - - ... where Iret is the retire interval, given by: - - Iret = Dprp + TTLkey - - As before, this term includes the time taken to propagate the RRset - change through the master-slave hierarchy and the time take for the - DNSKEY RRset to expire from caches. - - Event 10: at some later time, the DS record is removed from the - parent zone. This is the removal time (Trem), given by: - - Trem >= Tdea - -3.3.3. Double-RRset Method - - In the Double-RRset method, both the DS and DNSKEY records are - changed at the same time, so for a period the zone can be - 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: - - - - - -Morris, et al. Expires January 2, 2011 [Page 22] - -Internet-Draft DNSSEC Key Timing Considerations July 2010 - - - |1| |2| |3| |4| |5| |6| |7| - | | | | | | | - Key N | |<-Dreg->|<-----Lksk----->|<-Iret->| | - | | | | | | | - Key N+1 | | | |<-Dreg->|<-----Lksk-- - - - | | | | | | | - Tgen Tpub Tact TpubS Tret Tdea Trem - - ---- Time ----> - - - Figure 6: Timeline for a Double-RRset KSK rollover. - - Event 1: key N is created at time Tgen and thereby immediately - becomes generated. As before, although there is no reason why the - key cannot be generated immediately prior to publication, some - implementations may find it convenient to create a central pool of - keys and draw from it. For this reason, it is again shown as a - separate event. - - Event 2: the key is added to and used for signing the DNSKEY RRset - and is thereby published in the zone. At 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: after Dreg, the registration delay, the DS record is - published in the parent zone. At this point, the zones have all the - information needed for a validating resolver to authenticate the - zone, although the information may not yet have reached all - validating resolver caches. This time is the active time (Tact) and - the key is said to be active. - - Tact = Tpub + Dreg - - Event 4: at some point we need to give thought to key replacement. - The successor key 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: - - TpubS <= Tact + Lksk - Dreg - - ... where Lksk is the lifetime of the KSK. - - Event 5: the successor key's DS record appears in the parent zone and - the successor key becomes active. At this point, the current key - becomes retired. This occurs at Tret, given by: - - - -Morris, et al. Expires January 2, 2011 [Page 23] - -Internet-Draft DNSSEC Key Timing Considerations July 2010 - - - Tret = Tact + Lksk - - Event 6: the current DNSKEY and DS record must be retained in the - 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 Iret is the retire interval. This depends on how long both - 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 is the publication interval of the DNSKEY in the child zone, - IpubP that of the DS record in the parent. - - The child term comprises two parts - the time taken for the - introduction of the DNSKEY record to be propagated to the downstream - secondary servers (= DprpC, the child propagation delay) and the time - taken for information about the DNSKEY RRset to expire from the - validating resolver cache, i.e. - - IpubC = DprpC + TTLkey - - TTLkey is the TTL for a DNSKEY record in the child zone. The parent - term is similar: - - IpubP = DprpP + TTLds - - DprpP the propagation delay in the parent zone and TTLds the TTL for - a DS record in the parent zone. - - Event 7: at some later time, the DNSKEY record can be removed from - the child zone and a request can be made to remove the DS record from - the parent zone. This is the removal time, Trem and is given by: - - Trem >= Tdea - - - - - - - - -Morris, et al. Expires January 2, 2011 [Page 24] - -Internet-Draft DNSSEC Key Timing Considerations July 2010 - - -3.3.4. Interaction with Configured Trust Anchors - - Although the preceding sections have been concerned with rolling KSKs - where the trust anchor is a DS record in the parent zone, zone - managers may want to take account of the possibility that some - validating resolvers may have configured trust anchors directly. - - Rolling a configured trust anchor is dealt with in [RFC5011]. It - requires introducing the KSK to be used as the trust anchor into the - zone for a period of time before use, and retaining it (with the - "revoke" bit set) for some time after use. The Double-Signature and - 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 - - When the new key is introduced, the publication interval (Ipub) in - the Double-Signature method should also be subject to the condition: - - Ipub >= max(30 days, TTLkey) - - ... where the right had side of the expression is 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 - active until the add hold-down time has passed. In other words, the - following condition should be enforced: - - Tact >= Tpub + max(30 days, TTLkey) - - (Effectively, this means extending the lifetime of the key by an - appropriate amount.) - -3.3.4.2. Removal of KSK - - The timeline for the removal of the key in both methods is modified - by introducing a new state, "revoked". When the key reaches the end - of the retire period, 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: - - - - - - -Morris, et al. Expires January 2, 2011 [Page 25] - -Internet-Draft DNSSEC Key Timing Considerations July 2010 - - - 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 when - convenient. - -3.3.5. Introduction of First KSK - - 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 the validating - resolver to declare the zone to be bogus. - - 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 important to not configure trust anchors in validating resolvers - until the DNSKEY RRset has had sufficient time to propagate. In both - cases, this time is the trust anchor availability time (Ttaa) given - by: - - Ttaa >= Tpub + IpubC - - 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 - - - -Morris, et al. Expires January 2, 2011 [Page 26] - -Internet-Draft DNSSEC Key Timing Considerations July 2010 - - - the record's parameters (SOAminC), i.e. - - IngcC = min(TTLsoaC, SOAminC) - - -4. Standby Keys - - Although keys will usually be rolled according to some regular - schedule, there may be occasions when an emergency rollover is - required, e.g. if the active key is suspected of being compromised. - The aim of the emergency rollover is to allow the zone to be re- - signed with a new key as soon as possible. As a key must be in the - ready state to sign the zone, having at least one additional key (a - standby key) in this state at all times will minimise delay. - - In the case of a ZSK, a standby key only really makes sense with the - Pre-Publication method. A permanent standby DNSKEY RR should be - included in zone or successor keys could be introduced as soon as - possible after a key becomes active. Either way results in an - additional ZSK in the DNSKEY RRset that can immediately be used to - sign the zone if the current key is compromised. - - (Although in theory the mechanism could be used with both the Double- - Signature and Double-RRSIG methods, it would require Pre-Publication - of the signatures. Essentially, the standby key would be permanently - active, as it would have to be periodically used to renew signatures. - Zones would also permanently require two sets of signatures, - something that could have a performance impact in large zones.) - - A standby key can also be used with the Double-Signature and - Double-DS methods of rolling a KSK. (The idea of a standby key in - the Double-RRset effectively means having two active keys.) The - Double-Signature method requires that the standby KSK be included in - the DNSKEY RRset; rolling the key then requires just the introduction - of the DS record in the parent. (Note that the DNSKEY should also be - used to sign the DNSKEY RRset. As the RRset and its signatures - travel together, merely adding the DNSKEY does not provide the - desired time saving; to be used in a rollover requires that the - DNSKEY RRset be signed with the standby key, and this introduces a - 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 - that is present, it is a standby DS record in the parent zone. - Whatever algorithm is used, the standby item of data can be - introduced as a permanent standby, or be a successor introduced as - early as possible. - - - -Morris, et al. Expires January 2, 2011 [Page 27] - -Internet-Draft DNSSEC Key Timing Considerations July 2010 - - -5. Algorithm Considerations - - The preceding sections have implicitly assumed that all keys and - signatures are created using a single algorithm. However, [RFC4035] - (section 2.4) states that "There MUST be an RRSIG for each RRset - using at least one DNSKEY of each algorithm in the zone apex DNSKEY - RRset". - - Except in the case of an algorithm rollover - where the algorithms - used to create the signatures are being changed - there is no - 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 - separately for each algorithm; the union of the results is included - in the zone, which is signed using the active key for each algorithm. - - -6. Summary - - For ZSKs, "Pre-Publication" is generally considered to be the - preferred way of rolling keys. As shown in this document, the time - taken to roll is wholly dependent on parameters under the control of - the zone manager. - - In contrast, "Double-RRset" is the most efficient method for KSK - rollover due to the ability to have new DS records and DNSKEY RRsets - propagate in parallel. The time taken to roll KSKs may depend on - factors related to the parent zone if the parent is signed. For - zones that intend to comply with the recommendations of [RFC5011], in - virtually all cases the rollover time will be determined by the - 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 - timing values and that it also requires changes to the rollover - process due to the need to manage revocation of trust anchors. - - Finally, the treatment of emergency key rollover is significantly - simplified by the introduction of stand-by keys as standard practice - during all types of rollovers. - - -7. IANA Considerations - - This memo includes no request to IANA. - - -8. Security Considerations - - This document does not introduce any new security issues beyond those - - - -Morris, et al. Expires January 2, 2011 [Page 28] - -Internet-Draft DNSSEC Key Timing Considerations July 2010 - - - already discussed in [RFC4033], [RFC4034], [RFC4035] and [RFC5011]. - - -9. Acknowledgements - - The authors gratefully acknowledge help and contributions from Roy - Arends and Wouter Wijngaards. - - -10. Change History - - 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 Hones, Jeremy Reed, Scott Rose, Sion - Lloyd, Tony FinchX). - - 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. - - -11. References - - - - - -Morris, et al. Expires January 2, 2011 [Page 29] - -Internet-Draft DNSSEC Key Timing Considerations July 2010 - - -11.1. Normative References - - [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS - NCACHE)", RFC 2308, March 1998. - - [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. - Rose, "Resource Records for the DNS Security Extensions", - RFC 4034, March 2005. - - [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. - Rose, "Protocol Modifications for the DNS Security - Extensions", RFC 4035, March 2005. - - [RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC) - Trust Anchors", RFC 5011, September 2007. - -11.2. Informative References - - [RFC4641] Kolkman, O. and R. Gieben, "DNSSEC Operational Practices", - RFC 4641, September 2006. - - -Appendix A. List of Symbols - - The document defines a number of symbols, all of which are listed - here. All are of the form: - - All symbols used in the text are of the form: - - <TYPE><id><INST> - - where: - - <TYPE> is an upper-case character indicating what type the symbol is. - Defined types are: - - D delay: interval that is a feature of the process - - I interval between two events - - L lifetime: interval set by the zone manager - - - - - - -Morris, et al. Expires January 2, 2011 [Page 30] - -Internet-Draft DNSSEC Key Timing Considerations July 2010 - - - SOA parameter related to SOA RR - - T a point in time - - TTL TTL of a record - - T and I are self-explanatory. D, and L are also time periods, but - whereas I values are intervals between two events (even if the events - are defined in terms of the interval, e.g. the dead time occurs - "retire interval" after the retire time), D, and L are fixed - intervals. An "L" interval (lifetime) is chosen by the zone manager - and is a feature of policy. A "D" interval (delay) is a feature of - the process, probably outside control of the zone manager. SOA and - TTL are used just because they are common terms. - - <id> is lower-case and defines what object or event the variable is - related to, e.g. - - act active - - ngc negative cache - - pub publication - - Finally, <INST> is a capital letter that distinguishes between the - same variable applying to different instances of an object and is one - of: - - C child - - G signature - - K key - - P parent - - S successor - - The list of variables used in the text is: - - Dprp Propagation delay. The amount of time for a change made at - a master nameserver to propagate to all the slave - nameservers. - - DprpC Propagation delay in the child zone. - - - - - - -Morris, et al. Expires January 2, 2011 [Page 31] - -Internet-Draft DNSSEC Key Timing Considerations July 2010 - - - DprpP Propagation delay in the parent zone. - - Dreg Registration delay. As a parent zone is often managed by a - different organisation to that 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 - amount of time taken for all the RRs in the zone to be - 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 - after the publication of a key before it can be considered - to have entered the ready state. - - IpubC Publication interval in the child zone. - - IpubG Publication interval for the signature. - - IpubK Publication interval for the key. - - IpubP Publication interval in the parent zone. - - Iret Retire interval. The amount of time that must elapse after - a key enters the retire state for any signatures created - with it to be purged from validating resolver caches. - - Irev Revoke interval. The amount of time that a KSK must remain - published with the revoke bit set to satisfy [RFC5011] - considerations. - - 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 - actual lifetime may be longer or shorter than this. - - - - - - - -Morris, et al. Expires January 2, 2011 [Page 32] - -Internet-Draft DNSSEC Key Timing Considerations July 2010 - - - Lzsk Lifetime of a zone-signing key. This is the intended - amount of time for which the ZSK is used to sign the zone. - Depending on when the key is rolled-over, the actual - lifetime may be longer or shorter than this. - - Lsig Lifetime of a signature: the difference in time between the - signature's expiration time and the time at which the - signature was created. (Note that this is not the - difference between the signature's expiration and inception - times: the latter is usually set a small amount of time - before the signature is created to allow for clock skew - between the signing system and the 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. - - TactS Active time of the successor key. - - Tdea Dead time of a key. Applicable only to ZSKs, this is the - time at which any record signatures held in validating - resolver caches are guaranteed to be created with the - successor key. - - 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 - zone for the first time. - - TpubS Publish time of the successor key. - - Trem Removal time of a key. The time at which a key is removed - from the zone. - - Tret Retire time of a key. The time at which a successor key - starts being used to sign the zone. - - Trdy Ready time of a key. The time at which it can be - guaranteed that validating resolvers that have key - information from this zone cached have a copy of this key - in their cache. (In the case of KSKs, should the - - - -Morris, et al. Expires January 2, 2011 [Page 33] - -Internet-Draft DNSSEC Key Timing Considerations July 2010 - - - validating resolvers also have DS information from the - parent zone cached, the cache must include information - about the DS record corresponding to the key.) - - TrdyS Ready time of a successor key. - - Tsub Submit time - the time at which the DS record of a KSK is - submitted to the parent. - - TsubS Submit time of the successor key. - - TTLds Time to live of a DS record (in the parent zone). - - TTLkey Time to live of a DNSKEY record. - - TTLkeyC Time to live of a DNSKEY record in the child zone. - - 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 - - Stephen Morris - Internet Systems Consortium - 950 Charter Street - Redwood City, CA 94063 - USA - - Phone: +1 650 423 1300 - Email: stephen@isc.org - - - - - - - - - - - -Morris, et al. Expires January 2, 2011 [Page 34] - -Internet-Draft DNSSEC Key Timing Considerations July 2010 - - - Johan Ihren - Netnod - Franzengatan 5 - Stockholm, SE-112 51 - Sweden - - Phone: +46 8615 8573 - Email: johani@autonomica.se - - - John Dickinson - Sinodun Internet Technologies Ltd - Stables 4 Suite 11, Howbery Park - Wallingford, Oxfordshire OX10 8BA - UK - - Phone: +44 1491 818120 - Email: jad@sinodun.com - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Morris, et al. Expires January 2, 2011 [Page 35] - diff --git a/doc/draft/draft-ietf-dnsop-dnssec-key-timing-02.txt b/doc/draft/draft-ietf-dnsop-dnssec-key-timing-02.txt new file mode 100644 index 0000000000000..60d2772b5dc3b --- /dev/null +++ b/doc/draft/draft-ietf-dnsop-dnssec-key-timing-02.txt @@ -0,0 +1,1848 @@ + + + +Internet Engineering Task Force S. Morris +Internet-Draft ISC +Intended status: Informational J. Ihren +Expires: September 11, 2011 Netnod + J. Dickinson + Sinodun + March 10, 2011 + + + DNSSEC Key Timing Considerations + draft-ietf-dnsop-dnssec-key-timing-02.txt + +Abstract + + This document describes the issues surrounding the timing of events + in the rolling of a key in a DNSSEC-secured zone. It presents + timelines for the key rollover and explicitly identifies the + relationships between the various parameters affecting the process. + +Status of this Memo + + This Internet-Draft is submitted in full conformance with the + provisions of BCP 78 and BCP 79. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF). Note that other groups may also distribute + working documents as Internet-Drafts. The list of current Internet- + Drafts is at http://datatracker.ietf.org/drafts/current/. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + This Internet-Draft will expire on September 11, 2011. + +Copyright Notice + + Copyright (c) 2011 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + + + +Morris, et al. Expires September 11, 2011 [Page 1] + +Internet-Draft DNSSEC Key Timing Considerations March 2011 + + + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.1. Key Rolling Considerations . . . . . . . . . . . . . . . . 3 + 1.2. Types of Keys . . . . . . . . . . . . . . . . . . . . . . 4 + 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 + 1.4. Requirements Language . . . . . . . . . . . . . . . . . . 4 + 2. Rollover Methods . . . . . . . . . . . . . . . . . . . . . . . 4 + 2.1. ZSK Rollovers . . . . . . . . . . . . . . . . . . . . . . 4 + 2.2. KSK Rollovers . . . . . . . . . . . . . . . . . . . . . . 6 + 2.3. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 7 + 3. Key Rollover Timelines . . . . . . . . . . . . . . . . . . . . 7 + 3.1. Key States . . . . . . . . . . . . . . . . . . . . . . . . 7 + 3.2. Zone-Signing Key Timelines . . . . . . . . . . . . . . . . 9 + 3.2.1. Pre-Publication Method . . . . . . . . . . . . . . . . 9 + 3.2.2. Double-Signature Method . . . . . . . . . . . . . . . 11 + 3.2.3. Double-RRSIG Method . . . . . . . . . . . . . . . . . 13 + 3.3. Key-Signing Key Rollover Timelines . . . . . . . . . . . . 15 + 3.3.1. Double-Signature Method . . . . . . . . . . . . . . . 15 + 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 + 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 + + + + + + + + + +Morris, et al. Expires September 11, 2011 [Page 2] + +Internet-Draft DNSSEC Key Timing Considerations March 2011 + + +1. Introduction + +1.1. Key Rolling Considerations + + When a zone is secured with DNSSEC, the zone manager must be prepared + to replace ("roll") the keys used in the signing process. The + rolling of keys may be caused by compromise of one or more of the + existing keys, or it may be due to a management policy that demands + periodic key replacement for security or operational reasons. In + order to implement a key rollover, the keys need to be introduced + into and removed from the zone at the appropriate times. + Considerations that must be taken into account are: + + o DNSKEY records and associated information (such as the 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 + validating resolver may try to validate a signature retrieved from + a cache with a key obtained separately. + + o Zone "boot-strapping" events, where a zone is signed for the first + time, can be common in configurations where a large number of + zones are being served. Procedures should be able to cope with + the introduction of keys into the zone for the first time as well + as "steady-state", where the records are being replaced as part of + normal zone maintenance. + + o To allow for an emergency re-signing of the zone as soon as + possible after a key compromise has been detected, standby keys + (additional keys over and above those used to sign the zone) need + to be present. + + o A query for the DNSKEY RRset returns all DNSKEY records in the + zone. As there is limited space in the UDP packet (even with + EDNS0 support), key records no longer needed must be periodically + removed. (For the same reason, the number of standby keys in the + zone should be restricted to the minimum required to support the + key management policy.) + + Management policy, e.g. how long a key is used for, also needs to be + considered. However, the point of key management logic is not to + ensure that a rollover is completed at a certain time but rather to + ensure that no changes are made to the state of keys published in the + zone until it is "safe" to do so ("safe" in this context meaning that + at no time during the rollover process does any part of the zone ever + go bogus). In other words, although key management logic enforces + policy, it may not enforce it strictly. + + + + +Morris, et al. Expires September 11, 2011 [Page 3] + +Internet-Draft DNSSEC Key Timing Considerations March 2011 + + +1.2. Types of Keys + + Although DNSSEC validation treats all keys equally, [RFC4033] + recognises the broad classification of zone-signing keys (ZSK) and + key-signing keys (KSK). A ZSK is used to authenticate information + within the zone; a KSK is used to authenticate the zone's DNSKEY + RRset. The main implication for this distinction concerns the + consistency of information during a rollover. + + During operation, a validating resolver must use separate pieces of + information to perform an authentication. At the time of + authentication, each piece of information may be in its cache or may + need to be retrieved from the authoritative server. The rollover + process needs to happen in such a way that at all times during the + rollover the information is consistent. With a ZSK, the information + is the RRSIG (plus associated RRset) and the DNSKEY. These are both + obtained from the same zone. In the case of the KSK, the information + is the DNSKEY and DS RRset with the latter being obtained from a + different zone. + + Although there are similarities in the algorithms to roll ZSKs and + KSKs, there are a number of differences. For this reason, the two + types of rollovers are described separately. It is also possible to + use a single key as both the ZSK and KSK. However, the rolling of + this type of key is not treated in this document. + +1.3. Terminology + + The terminology used in this document is as defined in [RFC4033] and + [RFC5011]. + + A number of symbols are used to identify times, intervals, etc. All + are listed in Appendix A. + +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.1. ZSK Rollovers + + A ZSK can be rolled in one of three ways: + + + + + +Morris, et al. Expires September 11, 2011 [Page 4] + +Internet-Draft DNSSEC Key Timing Considerations March 2011 + + + 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. + + Once the zone contains only signatures created with the new key, + there is an interval during which RRSIG records created with the + old key expire from caches. After this, there will be no + signatures anywhere that were created using the old key, and it + can 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. + + Once the signing process is complete and enough time has elapsed + to allow all old information to expire from caches, the old key + and signatures can be removed from the zone. As before, during + this period any combination of DNSKEY RRset and RRSIG will allow + validation of at least one signature. + + o Double-RRSIG: strictly speaking, the use of the term "Double- + Signature" above is a misnomer as the method is not only double + signature, it is also double key as well. A true Double-Signature + method (here called the Double-RRSIG method) involves introducing + new signatures in the zone (while still retaining the old ones) + but not introducing the new key. + + Once the signing process is complete and enough time has elapsed + to ensure that all caches that may contain an RR and associated + RRSIG have a copy of both signatures, the key is changed. After a + further interval during which the old DNSKEY RRset expires from + caches, the old signatures are removed from the zone. + + Of 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] + +Internet-Draft DNSSEC Key Timing Considerations March 2011 + + + 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 - + introduce the new signatures, approximately one TTL later change the + key, and approximately one TTL after that remove the old signatures. + +2.2. KSK Rollovers + + 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 + 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 anchor. If the former, the rollover algorithm will need to + involve the parent zone in the addition and removal of DS records, so + timings are not wholly under the control of the zone manager. If the + latter, [RFC5011] timings will be needed to roll the keys. (Even in + the case where authentication is via a DS record, the zone manager + may elect to include [RFC5011] timings in the key rolling process so + as to cope with the possibility that the key has also been explicitly + configured as a trust anchor.) + + It is important to note that this does not preclude the development + of key rollover logic; in accordance with the goal of the rollover + logic being able to determine when a state change is "safe", the only + effect of being dependent on the parent is that there may be a period + of waiting for the parent to respond in addition to any delay the key + rollover logic requires. Although this introduces additional delays, + even with a parent that is less than ideally responsive the only + effect will be a slowdown in the rollover state transitions. This + may cause a policy violation, but will not cause any operational + problems. + + Like the ZSK case, there are three methods for rolling a KSK: + + 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] + +Internet-Draft DNSSEC Key Timing Considerations March 2011 + + + o Double-DS: the new DS record is published. After waiting for this + change to propagate into caches, the KSK is changed. After a + further interval during which the old DNSKEY RRset expires from + caches, the old DS record is removed. + + o Double-RRset: the new KSK is added to the DNSKEY RRset which is + then signed with both the old and new key, and the new DS record + added to the parent zone. After waiting a suitable interval for + the old DS and DNSKEY RRsets to expire from caches, the old DNSKEY + and DS record are removed. + + In essence, "Double-Signature" means that the new KSK is introduced + first and used to sign the DNSKEY RRset. The DS record is changed, + and finally the old KSK removed. With "Double-DS" it is the other + way around. Finally, Double-RRset does both updates more or less in + parallel. + +2.3. Summary + + The methods can be summarised as follows: + + +------------------+------------------+-----------------------------+ + | ZSK Method | KSK Method | Description | + +------------------+------------------+-----------------------------+ + | Pre-Publication | (not applicable) | Publish the DNSKEY before | + | | | the RRSIG. | + | Double-Signature | Double-Signature | Publish the DNSKEY and | + | | | RRSIG at same time. (For a | + | | | KSK, this happens before | + | | | the DS is published.) | + | Double-RRSIG | (not applicable) | Publish RRSIG before the | + | | | DNSKEY. | + | (not applicable) | Double-DS | Publish DS before the | + | | | DNSKEY. | + | (not applicable) | Double-RRset | Publish DNSKEY and DS in | + | | | parallel. | + +------------------+------------------+-----------------------------+ + + 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 September 11, 2011 [Page 7] + +Internet-Draft DNSSEC Key Timing Considerations March 2011 + + + Generated The key has been created, but has not yet been used for + anything. + + Published The DNSKEY record - or information associated with it - + is published in the zone, but predecessors of the key (or + associated information) may be held in caches. + + The idea of "associated information" is used in rollover + methods where RRSIG or DS records are published first and + the DNSKEY is changed in an atomic operation. It allows + the rollover still to be thought of as moving through a + set of states. In the rest of this section, the term + "key data" should be taken to mean "key or associated + information". + + Ready The new key data has been published for long enough to + guarantee that any previous versions of it 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 + validating resolvers to use the key for validation in all + cases: the zone signing may not have finished, or the + data might not have reached the resolver because of + propagation delays and/or caching issues. If this is the + case, the resolver will have to rely on the 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. + + 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. + + Removed The key has been removed from the zone. + + There is one additional state, used where [RFC5011] considerations + are in effect (see Section 3.3.4): + + Revoked The key is published for a period with the "revoke" bit + set as a way of notifying validating resolvers that have + 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] + +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 + 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 + + The following diagram shows the timeline of a Pre-Publication + rollover. Time increases along the horizontal scale from left to + right and the vertical lines indicate events in the process. + Significant times and time intervals are marked. + + + + |1| |2| |3| |4| |5| |6| |7| |8| |9| + | | | | | | | | | + Key N | |<-Ipub->|<--->|<-------Lzsk----->|<-Iret->|<--->| + | | | | | | | | | + Key N+1 | | | | |<-Ipub->|<->|<---Lzsk-- - - + | | | | | | | | | + Tgen Tpub Trdy Tact TpubS Tret Tdea Trem + + ---- Time ----> + + + Figure 1: Timeline for a Pre-Publication ZSK rollover. + + Event 1: key N is generated at the generate time (Tgen). Although + there is no reason why the key cannot be generated immediately prior + to 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 + 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 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 September 11, 2011 [Page 9] + +Internet-Draft DNSSEC Key Timing Considerations March 2011 + + + Ipub = Dprp + TTLkey + + Here, Dprp is the propagation delay - the time taken in the worst- + case situation for a change introduced at the master to replicate to + all slave servers - which depends on the depth of the master-slave + hierarchy. TTLkey is the time-to-live (TTL) for the DNSKEY records + in the zone. The sum is therefore the maximum time taken for + existing DNSKEY records to expire from caches, regardless of the + nameserver from which they were retrieved. + + (The case of introducing the first ZSK into the zone is discussed in + Section 3.3.5.) + + After a delay of Ipub, the key is said to be ready and could be used + to sign records. The time at which this event occurs is the key's + ready time (Trdy), which is given by: + + Trdy = Tpub + Ipub + + Event 4: at some later time, the key starts being used to sign + RRsets. This point is the activation time (Tact) and after this, the + key is said to be active. + + 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 + successor key by TpubS, then: + + TpubS <= Tact + Lzsk - Ipub + + Here, Lzsk is the length of time for which a ZSK will be used (the + ZSK lifetime). It should be noted that unlike the publication + interval, Lzsk is not determined by timing logic, but by key + management policy. Lzsk will be set by the operator according to + their assessment of the risks posed by continuing to use a key and + the risks associated with key rollover. However, operational + considerations may mean a key 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 September 11, 2011 [Page 10] + +Internet-Draft DNSSEC Key Timing Considerations March 2011 + + + Tret = Tact + Lzsk + + It is also the activation time of the successor key (TactS). Note + that operational considerations may cause key N to remain in use for + 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 + 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 + cache when it is asked to provide both to a client. In this case the + DNSKEY RRset would need to be looked up again.) This means that once + the key is no longer used to sign records, it should be retained in + the zone for at least the retire interval (Iret) given by: + + Iret = Dsgn + Dprp + TTLsig + + Dsgn is the delay needed to ensure that all existing RRsets have been + re-signed with the new key. Dprp is (as described above) the + propagation delay, required to guarantee that the updated zone + information has reached all slave servers, and TTLsig is the maximum + TTL of all the RRSIG records in the zone. + + 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. + + Event 9: at any time after the key becomes dead, it can be removed + from the zone and the DNSKEY RRset re-signed with the current key- + signing key. This time is the removal time (Trem), given by: + + Trem >= Tdea + + ...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] + +Internet-Draft DNSSEC Key Timing Considerations March 2011 + + + |1| |2| |3| |4| |5| + | | | | | + Key N | |<----Lzsk--->|<---Iret--->| | + | | | | | + Key N+1 | | |<-----Lzsk------- - - + | | | | | + Tgen Tact Tret Tdea Trem + + ---- Time ----> + + + Figure 2: Timeline for a Double-Signature ZSK rollover. + + Event 1: key N is generated at the generate time (Tgen). Although + there is no reason why the key cannot be generated immediately prior + to 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 + are said to be generated. + + 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 + 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 + 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 + + 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 + must have expired from caches. Note that the signatures are not + replaced - each RRset is signed by both the old and new key. + + This takes Iret, the retire interval, given by the expression: + + Iret = Dsgn + Dprp + max(TTLkey, TTLsig) + + As before, Dsgn is the delay needed to ensure that all existing + RRsets have been signed with the new key, 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] + +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 + [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 + + 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: + + Trem >= Tdea + +3.2.3. Double-RRSIG Method + + The timeline for a double-signature rollover is shown below. The + diagram follows the convention described in Section 3.2.1 + + + + |1||2| |3| |4||5| |6| |7||8| |9| |10| + | | | | | | | | | | + Key N | |<-Dsgn->| | |<--------Lzsk-------->|<-Iret->| | + | |<---IpubG-->| | | | | | | + | | | | | | | | | | + Key N+1 | | | | | |<-IpubG->| | | | + | | | | | | | | | | + Tgen Tpub Trdy Tact TpubS TrdyS Tret Tdea Trem + + ---- Time ----> + + + Figure 3: Timeline for a Double-Signature ZSK rollover. + + Event 1: key N is generated at the generate time (Tgen). Although + there is no reason why the key cannot be generated immediately prior + to 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 + are said to be generated. + + 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] + +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 + 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 + 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. + + 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. + + Trdy = Tpub + IpubG + + where + + IpubG = Dsgn + Dprp + TTLsig + + 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 + first step is to publish signatures created by the successor key (key + 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 + added to the zone. This time is the ready time of the successor key + (TrdyS). + + + + +Morris, et al. Expires September 11, 2011 [Page 14] + +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 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: + + Tdea = Tret + Iret + + ... where Iret is the retire interval, given by: + + Iret = Dprp + TTLkey + + 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: + + Trem >= Tdea + +3.3. Key-Signing Key Rollover Timelines + + The following sections describe the rolling of a KSK. They show the + events in the lifetime of a key (referred to as "key N") and cover it + replacement by its successor (key N+1). + +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] + +Internet-Draft DNSSEC Key Timing Considerations March 2011 + + + |1| |2| |3| |4| |5| + | | | | | + Key N | |<-Ipub->|<--->|<-Dreg->|<-----Lksk--- - - + | | | | | + Key N+1 | | | | | + | | | | | + Tgen Tpub Trdy Tsub Tact + + ---- Time ----> + + (continued...) + + |6| |7| |8| |9| |10| |11| + | | | | | | + Key N - - -------------Lksk------->|<-Iret->| | + | | | | | | + Key N+1 |<-Ipub->|<--->|<-Dreg->|<--------Lksk----- - - + | | | | | | + TpubS TrdyS TsubS Tret Tdea Trem + + ---- Time (cont) ----> + + + Figure 4: Timeline for a Double-Signature KSK rollover. + + Event 1: key N is generated at the generate time (Tgen). Although + there is no reason why the key cannot be generated immediately prior + to 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 + are said to be generated. + + 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 + enough to guarantee that any validating resolver that has a copy of + the DNSKEY RRset in its cache will have a copy of the RRset that + includes this key: in other words, that any prior cached information + about the DNSKEY RRset has expired. + + The interval is the publication interval (Ipub) and, for the second + or subsequent KSKs in the zone, is given by: + + + +Morris, et al. Expires September 11, 2011 [Page 16] + +Internet-Draft DNSSEC Key Timing Considerations March 2011 + + + Ipub = DprpC + TTLkey + + ... where DprpC is the propagation delay for the child zone (the zone + containing the KSK being rolled) and TTLkey the TTL for the DNSKEY + RRset. The time at which this occurs is the key's ready time, Trdy, + given by: + + Trdy = Tpub + Ipub + + (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 + 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 + 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 + (Tact): + + Tact = Tsub + Dreg + + ... 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 + placed in the zone. (Parent zones are often managed by different + 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 + 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 + current and successor KSK.) This time is the publication time of the + successor key, TpubS, given by: + + TpubS <= Tact + Lksk - Dreg - Ipub + + ... 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 September 11, 2011 [Page 17] + +Internet-Draft DNSSEC Key Timing Considerations March 2011 + + + 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 + a copy of the DS RRset have a copy containing the new DS record. + This interval is the retire interval, given by: + + Iret = DprpP + TTLds + + ... where DprpP is the propagation delay in the parent zone and TTLds + the TTL of a DS record in the parent zone. + + As the key is no longer used for anything, is said to be dead. This + point is the dead time (Tdea), 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. + + Trem >= Tdea + +3.3.2. Double-DS Method + + The timeline for a double-DS rollover is shown below. The diagram + follows the convention described in Section 3.2.1 + + + + + + + + + + + + + + + + + + + + + + +Morris, et al. Expires September 11, 2011 [Page 18] + +Internet-Draft DNSSEC Key Timing Considerations March 2011 + + + |1| |2| |3| |4| |5| |6| + | | | | | | + Key N | |<-Dreg->|<-IpubP->|<-->|<---------Lksk------- - - + | | | | | | + Key N+1 | | | | |<---->|<--Dreg+IpubP- - - + | | | | | | + Tgen Tsub Tpub Trdy Tact TsubS + + ---- Time ----> + + (continued...) + + |7| |8| |9| |10| + | | | | + Key N - - -----Lksk---------->|<-Iret->| | + | | | | + Key N+1 - - --Dreg+IpubP->|<--->|<------Lksk------ - - + | | | | + TrdyS Tret Tdea Trem + + ---- Time ----> + + + Figure 5: Timeline for a Double-DS KSK rollover. + + Event 1: key N is generated at the generate time (Tgen). Although + there is no reason why the key cannot be generated immediately prior + to 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 + are said to be generated. + + 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 + 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 + 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, + Trdy, and is given by: + + + + +Morris, et al. Expires September 11, 2011 [Page 19] + +Internet-Draft DNSSEC Key Timing Considerations March 2011 + + + Trdy = Tpub + IpubP + + IpubP is the parent publication interval and is given by the + expression: + + IpubP = DprpP + TTLds + + ... where DprpP is the propagation delay for the parent zone and + TTLds the TTL assigned to DS records in that zone. + + Event 5: at some later time, the key rollover takes place and the new + key (key N) introduced and used to sign the RRset. + + 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. + + 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 + 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 + successor key. The time at which this occurs is the submission time + of the successor, given by: + + TsubS <= Tact + Lksk - IpubP - Dreg + + ... 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. + + (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) + + 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: + + + + + + +Morris, et al. Expires September 11, 2011 [Page 20] + +Internet-Draft DNSSEC Key Timing Considerations March 2011 + + + Tret = Tact + Lksk + + Event 9: at some later time, all copies of the old DNSKEY RRset have + expired from caches and the old DS record is no longer needed. In + analogy with other rollover methods, this is called the dead time, + Tdea, and is given by: + + Tdea = Tret + Iret + + ... where Iret is the retire interval, given by: + + Iret = DprpC + TTLkey + + As before, this term includes DprpC, the time taken to propagate the + RRset change through the master-slave hierarchy of the child zone and + TTLkey, the time taken for the DNSKEY RRset to expire from caches. + + Event 10: at some later time, the DS record is removed from the + parent zone. In analogy with other rollover methods, this is the + removal time (Trem), given by: + + Trem >= Tdea + +3.3.3. Double-RRset Method + + The timeline for a double-RRset rollover is shown below. The diagram + follows the convention described in Section 3.2.1 + + + + |1| |2| |3| |4| |5| |6| + | | | | | | + Key N | |<-Ipub->|<-----Lksk----->| | + | | | | | | + Key N+1 | | | |<-Ipub->| | + | | | | | | + Tgen Tpub Tact TpubS Tret Trem + + ---- Time ----> + + + Figure 6: Timeline for a Double-RRset KSK rollover. + + Event 1: key N is generated at the generate time (Tgen). Although + there is no reason why the key cannot be generated immediately prior + to 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 + + + +Morris, et al. Expires September 11, 2011 [Page 21] + +Internet-Draft DNSSEC Key Timing Considerations March 2011 + + + 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 + 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 + 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 + copy of the parent DS RRset will have a copy that includes the new DS + record. + + The time at which this occurs is called the activation time of the + new KSK (Tact), given by: + + Tact = Tpub + Ipub + + ... where Ipub is the publication interval, given by: + + Ipub = max(IpubP, IpubC), + + 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: + + IpubP = Dreg + DprpP + TTLds + + 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. + + The child's publication interval is given by a similar equation: + + IpubC = DprpC + TTLkey + + ... where DprpC is the propagation delay in the child zone and TTLkey + the TTL of a DNSKEY record. + + 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 + + + +Morris, et al. Expires September 11, 2011 [Page 22] + +Internet-Draft DNSSEC Key Timing Considerations March 2011 + + + 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 + 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: + + Tret = Tdea = TactS = Tact + Lksk + + Event 6: at some later time, the key N's DS and DNSKEY records can be + removed from their respective zones. In analogy with other rollover + methods, this is the removal time (Trem), given by: + + Trem >= Tdea + +3.3.4. Interaction with Configured Trust Anchors + + Although the preceding sections have been concerned with rolling KSKs + where the trust anchor is a DS record in the parent zone, zone + managers may want to take account of the possibility that some + validating resolvers may have configured trust anchors directly. + + Rolling a configured trust anchor is dealt with in [RFC5011]. It + requires introducing the KSK to be used as the trust anchor into the + zone for a period of time before use, and retaining it (with the + "revoke" bit set) for some time after use. + +3.3.4.1. Addition of KSK + + When the new key is introduced, the publication interval (Ipub) in + the Double-Signature and Double-RRset methods should also be subject + to the condition: + + Ipub >= Dprp + max(30 days, 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]. + + In the Double-DS method, instead of the changing of the KSK RR being + + + +Morris, et al. Expires September 11, 2011 [Page 23] + +Internet-Draft DNSSEC Key Timing Considerations March 2011 + + + instantaneous, there must now be a period of overlap. In other + words, the new KSK must be introduced into the zone at least: + + DprpC + max(30 days, TTLkey) + + ... before the switch is made. + +3.3.4.2. Removal of KSK + + The timeline for the removal of the key in all methods is modified by + introducing a new state, "revoked". When the key reaches its dead + time, instead of being declared "dead", it is revoked; the "revoke" + bit is set 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: + + 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 + + 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. + + 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. + + +4. Standby Keys + + Although keys will usually be rolled according to some regular + schedule, there may be occasions when an emergency rollover is + required, e.g. if the active key is suspected of being compromised. + The aim of the emergency rollover is to allow the zone to be re- + signed with a new key as soon as possible. As a key must be in the + ready state to sign the zone, having at least one additional key (a + standby key) in this state at all times will minimise delay. + + + +Morris, et al. Expires September 11, 2011 [Page 24] + +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 + possible after a key becomes active. Either way results in one or + more additional ZSKs in the DNSKEY RRset that can immediately be used + to sign the zone if the current key is compromised. + + (Although in theory the mechanism could be used with both the Double- + Signature and Double-RRSIG methods, it would require pre-publication + of the signatures. Essentially, the standby key would be permanently + active, as it would have to be periodically used to renew signatures. + Zones would also permanently require two sets of signatures.) + + It is also possible to have a standby KSK. The Double-Signature + method requires that the standby KSK be included in the DNSKEY RRset; + rolling the key then requires just the introduction of the DS record + in the parent. Note that the standby KSK should also be used to sign + the DNSKEY RRset. As the RRset and its signatures travel together, + merely adding the KSK without using it to sign the DNSKEY RRset does + not provide the desired time saving: for a KSK to be used in a + rollover the DNSKEY RRset must be signed with it, and this would + introduce a delay while the old RRset (not signed with the new key) + expires from caches. + + The idea of a standby KSK in the Double-RRset rollover method + effectively means having two active keys (as the standby KSK and + associated DS record would both be published at the same time in + their respective zones). + + Finally, in the Double-DS method of rolling a KSK, it is not a + standby key that is present, it is a standby DS record in the parent + zone. + + Whatever algorithm is used, the standby item of data can be included + in the zone on a permanent basis, or be a successor introduced as + early as possible. + + +5. Algorithm Considerations + + The preceding sections have implicitly assumed that all keys and + signatures are created using a single algorithm. However, [RFC4035] + (section 2.4) states that "There MUST be an RRSIG for each RRset + using at least one DNSKEY of each algorithm in the zone apex DNSKEY + RRset". + + Except in the case of an algorithm rollover - where the algorithms + used to create the signatures are being changed - there is no + + + +Morris, et al. Expires September 11, 2011 [Page 25] + +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 + separately for each algorithm; the union of the results is included + in the zone, which is signed using the active key for each algorithm. + + +6. Limitation of Scope + + This document represents current thinking at the time of publication. + 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). + + 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. + + The reader is therefore reminded that DNSSEC is as of publication in + 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 + taken to roll is wholly dependent on parameters under the control of + the zone manager. + + In contrast, "Double-RRset" is the most efficient method for KSK + rollover due to the ability to have new DS records and DNSKEY RRsets + propagate in parallel. The time taken to roll KSKs may depend on + factors related to the parent zone if the parent is signed. For + zones that intend to comply with the recommendations of [RFC5011], in + virtually all cases the rollover time will be determined by the + 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 + 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] + +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. + + +8. IANA Considerations + + This memo includes no request to IANA. + + +9. Security Considerations + + This document does not introduce any new security issues beyond those + already discussed in [RFC4033], [RFC4034], [RFC4035] and [RFC5011]. + + +10. Acknowledgements + + The authors gratefully acknowledge help and contributions from Roy + 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. + + 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). + + + +Morris, et al. Expires September 11, 2011 [Page 27] + +Internet-Draft DNSSEC Key Timing Considerations March 2011 + + + * 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. + Rose, "Resource Records for the DNS Security Extensions", + RFC 4034, March 2005. + + [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] + +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 + + The document defines a number of symbols, all of which are listed + here. All are of the form: + + All symbols used in the text are of the form: + + <TYPE><id><INST> + + where: + + <TYPE> is an upper-case character indicating what type the symbol is. + Defined types are: + + D delay: interval that is a feature of the process + + I interval between two events + + L lifetime: interval set by the zone manager + + T a point in time + + TTL TTL of a record + + I and T and TTL are self-explanatory. Like I, 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 + 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. + + + + + + +Morris, et al. Expires September 11, 2011 [Page 29] + +Internet-Draft DNSSEC Key Timing Considerations March 2011 + + + act activation + + pub publication + + ret retire + + Finally, <INST> is a capital letter that distinguishes between the + same variable applying to different instances of an object and is one + of: + + C child + + G signature + + K key + + P parent + + S successor + + The list of variables used in the text is: + + Dprp Propagation delay. The amount of time for a change made at + a master nameserver to propagate to all the slave + nameservers. + + DprpC Propagation delay in the child zone. + + DprpP Propagation delay in the parent zone. + + Dreg Registration delay: the time taken for a DS record + submitted to a parent zone to appear in it. As a parent + zone is often managed by a different organisation to that + managing the child zone, the delays associated with passing + data between zones is captured by this term. + + Dsgn Signing delay. After the introduction of a new ZSK, the + amount of time taken for all the RRs in the zone to be + signed with it. + + Ipub Publication interval. The amount of time that must elapse + after the publication of a key before it can be assumed + that any resolvers that have the DNSKEY RRset cached have a + copy of this key. + + + + + + + +Morris, et al. Expires September 11, 2011 [Page 30] + +Internet-Draft DNSSEC Key Timing Considerations March 2011 + + + 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 + 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. + + Iret Retire interval. The amount of time that must elapse after + a key enters the retire state for any signatures created + with it to be purged from validating resolver caches. + + Irev Revoke interval. The amount of time that a KSK must remain + published with the revoke bit set to satisfy [RFC5011] + considerations. + + 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 + actual lifetime may be longer or shorter than this. + + Lzsk Lifetime of a zone-signing key. This is the intended + amount of time for which the ZSK is used to sign the zone. + Depending on when the key is rolled-over, the actual + lifetime may be longer or shorter than this. + + Tact Activation time of the key; the time at which the key is + regarded as the principal key for the zone. + + TactS Activation time of the successor key. + + Tdea Dead time of a key. Applicable only to ZSKs, this is the + time at which any record signatures held in validating + resolver caches are guaranteed to be created with the + successor key. + + Tgen Generate time of a key. The time that a key is created. + + 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] + +Internet-Draft DNSSEC Key Timing Considerations March 2011 + + + Trem Removal time of a key. The time at which a key is removed + from the zone. + + Tret Retire time of a key. The time at which a successor key + starts being used to sign the zone. + + Trdy Ready time of a key. The time at which it can be + guaranteed that validating resolvers that have key + information from this zone cached have a copy of this key + in their cache. (In the case of KSKs, should the + validating resolvers also have DS information from the + parent zone cached, the cache must include information + about the DS record corresponding to the key.) + + TrdyS Ready time of a successor key. + + Tsub Submission time - the time at which the DS record of a KSK + is submitted to the parent. + + TsubS Submission time of the successor key. + + TTLds Time to live of a DS record (in the parent zone). + + TTLkey Time to live of a DNSKEY record. + + TTLsig The maximum time to live of all the RRSIG records in the + zone that were created with the ZSK. + + +Authors' Addresses + + Stephen Morris + Internet Systems Consortium + 950 Charter Street + Redwood City, CA 94063 + USA + + Phone: +1 650 423 1300 + Email: stephen@isc.org + + + + + + + + + + + + +Morris, et al. Expires September 11, 2011 [Page 32] + +Internet-Draft DNSSEC Key Timing Considerations March 2011 + + + Johan Ihren + Netnod + Franzengatan 5 + Stockholm, SE-112 51 + Sweden + + Phone: +46 8615 8573 + Email: johani@autonomica.se + + + John Dickinson + Sinodun Internet Technologies Ltd + Stables 4 Suite 11, Howbery Park + Wallingford, Oxfordshire OX10 8BA + UK + + Phone: +44 1491 818120 + Email: jad@sinodun.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Morris, et al. Expires September 11, 2011 [Page 33] + |