diff --git a/doc/draft/draft-ietf-dnsext-dhcid-rr-08.txt b/doc/draft/draft-ietf-dnsext-dhcid-rr-09.txt similarity index 88% rename from doc/draft/draft-ietf-dnsext-dhcid-rr-08.txt rename to doc/draft/draft-ietf-dnsext-dhcid-rr-09.txt index 09776618f2..2cd972473d 100644 --- a/doc/draft/draft-ietf-dnsext-dhcid-rr-08.txt +++ b/doc/draft/draft-ietf-dnsext-dhcid-rr-09.txt @@ -1,20 +1,22 @@ + + DNSEXT M. Stapp Internet-Draft Cisco Systems, Inc. -Expires: January 14, 2005 T. Lemon +Expires: August 13, 2005 T. Lemon A. Gustafsson Nominum, Inc. - July 16, 2004 + February 9, 2005 A DNS RR for Encoding DHCP Information (DHCID RR) - + Status of this Memo This document is an Internet-Draft and is subject to all provisions - of section 3 of RFC 3667. By submitting this Internet-Draft, each + of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she become aware will be disclosed, in accordance with @@ -30,17 +32,17 @@ Status of this Memo time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - The list of current Internet-Drafts can be accessed at http:// - www.ietf.org/ietf/1id-abstracts.txt. + 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 14, 2005. + This Internet-Draft will expire on August 13, 2005. Copyright Notice - Copyright (C) The Internet Society (2004). All Rights Reserved. + Copyright (C) The Internet Society (2005). Abstract @@ -48,15 +50,15 @@ Abstract same DNS FQDN as they obtain DHCP leases. Whether the DHCP server or the clients themselves perform the DNS updates, conflicts can arise. To resolve such conflicts, "Resolution of DNS Name Conflicts" [1] - proposes storing client identifiers in the DNS to unambiguously -Stapp, et al. Expires January 14, 2005 [Page 1] +Stapp, et al. Expires August 13, 2005 [Page 1] -Internet-Draft The DHCID RR July 2004 +Internet-Draft The DHCID RR February 2005 + proposes storing client identifiers in the DNS to unambiguously associate domain names with the DHCP clients to which they refer. This memo defines a distinct RR type for this purpose for use by DHCP clients and servers, the "DHCID" RR. @@ -79,8 +81,8 @@ Table of Contents 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 - 9.1 Normative References . . . . . . . . . . . . . . . . . . . . 8 - 9.2 Informative References . . . . . . . . . . . . . . . . . . . 8 + 9.1 Normative References . . . . . . . . . . . . . . . . . . . 8 + 9.2 Informative References . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 9 Intellectual Property and Copyright Statements . . . . . . . . 10 @@ -107,10 +109,9 @@ Table of Contents - -Stapp, et al. Expires January 14, 2005 [Page 2] +Stapp, et al. Expires August 13, 2005 [Page 2] -Internet-Draft The DHCID RR July 2004 +Internet-Draft The DHCID RR February 2005 1. Terminology @@ -164,9 +165,9 @@ Internet-Draft The DHCID RR July 2004 -Stapp, et al. Expires January 14, 2005 [Page 3] +Stapp, et al. Expires August 13, 2005 [Page 3] -Internet-Draft The DHCID RR July 2004 +Internet-Draft The DHCID RR February 2005 3.1 DHCID RDATA format @@ -220,9 +221,9 @@ Internet-Draft The DHCID RR July 2004 -Stapp, et al. Expires January 14, 2005 [Page 4] +Stapp, et al. Expires August 13, 2005 [Page 4] -Internet-Draft The DHCID RR July 2004 +Internet-Draft The DHCID RR February 2005 some variable-length identifying data. @@ -276,9 +277,9 @@ Internet-Draft The DHCID RR July 2004 -Stapp, et al. Expires January 14, 2005 [Page 5] +Stapp, et al. Expires August 13, 2005 [Page 5] -Internet-Draft The DHCID RR July 2004 +Internet-Draft The DHCID RR February 2005 3.5.1 Example 1 @@ -289,8 +290,8 @@ Internet-Draft The DHCID RR July 2004 the client. The DHCID RDATA is composed by setting the two type bytes to zero, and performing an MD5 hash computation across a buffer containing the Ethernet MAC type byte, 0x01, the six bytes of MAC - address, and the domain name (represented as specified in Section - 3.4). + address, and the domain name (represented as specified in + Section 3.4). client.example.com. A 10.0.0.1 client.example.com. DHCID AAAUMru0ZM5OK/PdVAJgZ/HU @@ -305,8 +306,8 @@ Internet-Draft The DHCID RR July 2004 data as input in forming a DHCID RR. The DHCID RDATA is formed by setting the two type bytes to the value 0x0001, and performing an MD5 hash computation across a buffer containing the seven bytes from the - client-id option and the FQDN (represented as specified in Section - 3.4). + client-id option and the FQDN (represented as specified in + Section 3.4). chi.example.com. A 10.0.12.99 chi.example.com. DHCID AAHdd5jiQ3kEjANDm82cbObk\012 @@ -332,9 +333,9 @@ Internet-Draft The DHCID RR July 2004 -Stapp, et al. Expires January 14, 2005 [Page 6] +Stapp, et al. Expires August 13, 2005 [Page 6] -Internet-Draft The DHCID RR July 2004 +Internet-Draft The DHCID RR February 2005 that the client desires to use to compute a client identity hash, and @@ -388,9 +389,9 @@ Internet-Draft The DHCID RR July 2004 -Stapp, et al. Expires January 14, 2005 [Page 7] +Stapp, et al. Expires August 13, 2005 [Page 7] -Internet-Draft The DHCID RR July 2004 +Internet-Draft The DHCID RR February 2005 9. References @@ -403,8 +404,8 @@ Internet-Draft The DHCID RR July 2004 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. - [3] Mockapetris, P., "Domain names - concepts and facilities", STD - 13, RFC 1034, November 1987. + [3] Mockapetris, P., "Domain names - concepts and facilities", + STD 13, RFC 1034, November 1987. [4] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. @@ -420,8 +421,8 @@ Internet-Draft The DHCID RR July 2004 [7] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997. - [8] Eastlake, D., "Domain Name System Security Extensions", RFC - 2535, March 1999. + [8] Eastlake, D., "Domain Name System Security Extensions", + RFC 2535, March 1999. [9] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, March 1997. @@ -431,8 +432,8 @@ Internet-Draft The DHCID RR July 2004 (DHCPv6)", RFC 3315, July 2003. [11] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington, - "Secret Key Transaction Authentication for DNS (TSIG)", RFC - 2845, May 2000. + "Secret Key Transaction Authentication for DNS (TSIG)", + RFC 2845, May 2000. [12] Lemon, T. and B. Sommerfeld, "Node-Specific Client Identifiers for DHCPv4 (draft-ietf-dhc-3315id-for-v4-*)", February 2004. @@ -444,9 +445,9 @@ Internet-Draft The DHCID RR July 2004 -Stapp, et al. Expires January 14, 2005 [Page 8] +Stapp, et al. Expires August 13, 2005 [Page 8] -Internet-Draft The DHCID RR July 2004 +Internet-Draft The DHCID RR February 2005 Authors' Addresses @@ -458,7 +459,7 @@ Authors' Addresses USA Phone: 978.936.1535 - EMail: mjs@cisco.com + Email: mjs@cisco.com Ted Lemon @@ -467,7 +468,7 @@ Authors' Addresses Redwood City, CA 94063 USA - EMail: mellon@nominum.com + Email: mellon@nominum.com Andreas Gustafsson @@ -476,7 +477,7 @@ Authors' Addresses Redwood City, CA 94063 USA - EMail: gson@nominum.com + Email: gson@nominum.com @@ -500,9 +501,9 @@ Authors' Addresses -Stapp, et al. Expires January 14, 2005 [Page 9] +Stapp, et al. Expires August 13, 2005 [Page 9] -Internet-Draft The DHCID RR July 2004 +Internet-Draft The DHCID RR February 2005 Intellectual Property Statement @@ -543,7 +544,7 @@ Disclaimer of Validity Copyright Statement - Copyright (C) The Internet Society (2004). This document is subject + Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. @@ -556,6 +557,6 @@ Acknowledgment -Stapp, et al. Expires January 14, 2005 [Page 10] +Stapp, et al. Expires August 13, 2005 [Page 10] diff --git a/doc/draft/draft-ietf-dnsext-dnssec-experiments-00.txt b/doc/draft/draft-ietf-dnsext-dnssec-experiments-00.txt new file mode 100644 index 0000000000..6c897b92b1 --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-dnssec-experiments-00.txt @@ -0,0 +1,841 @@ + + +Network Working Group D. Blacka +Internet-Draft Verisign, Inc. +Expires: August 3, 2005 February 2, 2005 + + + DNSSEC Experiments + draft-ietf-dnsext-dnssec-experiments-00 + +Status of this Memo + + This document is an Internet-Draft and is subject to all provisions + of section 3 of RFC 3667. By submitting this Internet-Draft, each + author represents that any applicable patent or other IPR claims of + which he or she is aware have been or will be disclosed, and any of + which he or she become aware will be disclosed, in accordance with + RFC 3668. + + 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 August 3, 2005. + +Copyright Notice + + Copyright (C) The Internet Society (2005). + +Abstract + + In the long history of the development of the DNS security [1] + extensions (DNSSEC), a number of alternate methodologies and + modifications have been proposed and rejected for practical, rather + than strictly technical, reasons. There is a desire to be able to + experiment with these alternate methods in the public DNS. This + document describes a methodology for deploying alternate, + non-backwards-compatible, DNSSEC methodologies in an experimental + fashion without disrupting the deployment of standard DNSSEC. + + + +Blacka Expires August 3, 2005 [Page 1] + +Internet-Draft DNSSEC Experiments February 2005 + + +Table of Contents + + 1. Definitions and Terminology . . . . . . . . . . . . . . . . 3 + 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 3. Experiments . . . . . . . . . . . . . . . . . . . . . . . . 5 + 4. Method . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 + 5. Defining an Experiment . . . . . . . . . . . . . . . . . . . 8 + 6. Considerations . . . . . . . . . . . . . . . . . . . . . . . 9 + 7. Transitions . . . . . . . . . . . . . . . . . . . . . . . . 10 + 8. Security Considerations . . . . . . . . . . . . . . . . . . 11 + 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 12 + 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 + 10.1 Normative References . . . . . . . . . . . . . . . . . . . 13 + 10.2 Informative References . . . . . . . . . . . . . . . . . . 13 + Editorial Comments . . . . . . . . . . . . . . . . . . . . . 14 + Author's Address . . . . . . . . . . . . . . . . . . . . . . 14 + Intellectual Property and Copyright Statements . . . . . . . 15 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Blacka Expires August 3, 2005 [Page 2] + +Internet-Draft DNSSEC Experiments February 2005 + + +1. Definitions and Terminology + + Throughout this document, familiarity with the DNS system (RFC 1035 + [4]) and the DNS security extensions ([1], [2], and [3]. + + 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 [5]. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Blacka Expires August 3, 2005 [Page 3] + +Internet-Draft DNSSEC Experiments February 2005 + + +2. Overview + + Historically, experimentation with DNSSEC alternatives has been a + problematic endeavor. There has typically been a desire to both + introduce non-backwards-compatible changes to DNSSEC, and to try + these changes on real zones in the public DNS. This creates a + problem when the change to DNSSEC would make all or part of the zone + using those changes appear bogus or otherwise broken to existing + DNSSEC-aware resolvers. + + This document describes a standard methodology for setting up public + DNSSEC experiments. This methodology addresses the issue of + co-existence with standard DNSSEC and DNS by using unknown algorithm + identifiers to hide the experimental DNSSEC protocol modifications + from standard DNSSEC-aware resolvers. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Blacka Expires August 3, 2005 [Page 4] + +Internet-Draft DNSSEC Experiments February 2005 + + +3. Experiments + + When discussing DNSSEC experiments, it is necessary to classify these + experiments into two broad categories: + + Backwards-Compatible: describes experimental changes that, while not + strictly adhering to the DNSSEC standard, are nonetheless + interoperable with clients and server that do implement the DNSSEC + standard. + Non-Backwards-Compatible: describes experiments that would cause a + standard DNSSEC-aware resolver to (incorrectly) determine that all + or part of a zone is bogus, or to otherwise not interoperable with + standard DNSSEC clients and servers. + + Not included in these terms are experiments with the core DNS + protocol itself. + + The methodology described in this document is not necessary for + backwards-compatible experiments, although it certainly could be used + if desired. + + Note that, in essence, this metholodolgy would also be used to + introduce a new DNSSEC algorithm, independently from any DNSSEC + experimental protocol change. + + + + + + + + + + + + + + + + + + + + + + + + + + + +Blacka Expires August 3, 2005 [Page 5] + +Internet-Draft DNSSEC Experiments February 2005 + + +4. Method + + The core of the methodology is the use of only "unknown" algorithms + to sign the experimental zone, and more importantly, having only + unknown algorithm DS records for the delegation to the zone at the + parent. + + This technique works because of the way DNSSEC-compliant validators + are expected to work in the presence of a DS set with only unknown + algorithms. From [3], Section 5.2: + + If the validator does not support any of the algorithms listed in + an authenticated DS RRset, then the resolver has no supported + authentication path leading from the parent to the child. The + resolver should treat this case as it would the case of an + authenticated NSEC RRset proving that no DS RRset exists, as + described above. + + And further: + + If the resolver does not support any of the algorithms listed in + an authenticated DS RRset, then the resolver will not be able to + verify the authentication path to the child zone. In this case, + the resolver SHOULD treat the child zone as if it were unsigned. + + While this behavior isn't strictly mandatory (as marked by MUST), it + is unlikely that a validator would not implement the behavior, or, + more to the point, it will not violate this behavior in an unsafe way + (see below (Section 6).) + + Because we are talking about experiments, it is recommended that + private algorithm numbers be used (see [2], appendix A.1.1 + [Comment.1].) Normally, instead of actually inventing new signing + algorithms, the recommended path is to create alternate algorithm + identifiers that are aliases for the existing, known algorithms. + While, strictly speaking, it is only necessary to create an alternate + identifier for the mandatory algorithms (currently, this is only + algorithm 5, RSASHA1), it is RECOMMENDED that all OPTIONAL defined + algorithms be aliased as well. + + It is RECOMMENDED that for a particular DNSSEC experiment, a + particular domain name base is chosen for all new algorithms, then + the algorithm number (or name) is prepended to it. For example, for + experiment A, the base name of "dnssec-experiment-a.example.com" is + chosen. Then, aliases for algorithms 3 (DSA) and 5 (RSASHA1) are + defined to be "3.dnssec-experiment-a.example.com" and + "5.dnssec-experiment-a.example.com". However, any unique identifier + will suffice. + + + +Blacka Expires August 3, 2005 [Page 6] + +Internet-Draft DNSSEC Experiments February 2005 + + + Using this method, resolvers (or, more specificially, DNSSEC + validators) essentially indicate their ability to understand the + DNSSEC experiment's semantics by understanding what the new algorithm + identifiers signify. + + This method creates two classes of DNSSEC-aware servers and + resolvers: servers and resolvers that are aware of the experiment + (and thus recognize the experiments algorithm identifiers and + experimental semantics), and servers and resolvers that are unware of + the experiment. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Blacka Expires August 3, 2005 [Page 7] + +Internet-Draft DNSSEC Experiments February 2005 + + +5. Defining an Experiment + + The DNSSEC experiment must define the particular set of (previously + unknown) algorithms that identify the experiment, and define what + each unknown algorithm identifier means. Typically, unless the + experiment is actually experimenting with a new DNSSEC algorithm, + this will be a mapping of private algorithm identifiers to existing, + known algorithms. + + Typically, the experiment will choose a DNS name as the algorithm + identifier base. This DNS name SHOULD be under the control of the + authors of the experiment. Then the experiment will define a mapping + between known mandatory and optional algorithms into this private + algorithm identifier space. Alternately, the experiment MAY use the + OID private algorithm space instead (using algorithm number 254), or + may choose non-private algorithm numbers, although this would require + an IANA allocation (see below (Section 9).) + + For example, an experiment might specify in its description the DNS + name "dnssec-experiment-a.example.com" as the base name, and provide + the mapping of "3.dnssec-experiment-a.example.com" is an alias of + DNSSEC algorithm 3 (DSA), and "5.dnssec-experiment-a.example.com" is + an alias of DNSSEC algorithm 5 (RSASHA1). + + Resolvers MUST then only recognize the experiment's semantics when + present in a zone signed by one or more of these private algorithms. + + In general, however, resolvers involved in the experiment are + expected to understand both standard DNSSEC and the defined + experimental DNSSEC protocol, although this isn't, strictly speaking, + required. + + + + + + + + + + + + + + + + + + + + +Blacka Expires August 3, 2005 [Page 8] + +Internet-Draft DNSSEC Experiments February 2005 + + +6. Considerations + + There are a number of considerations with using this methodology. + + 1. Under some circumstances, it may be that the experiment will not + be sufficiently masked by this technique and may cause resolution + problem for resolvers not aware of the experiment. For instance, + the resolver may look at the not validatable response and + conclude that the response is bogus, either due to local policy + or implementation details. This is not expected to be the common + case, however. + 2. It will, in general, not be possible for DNSSEC-aware resolvers + not aware of the experiment to build a chain of trust through an + experimental zone. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Blacka Expires August 3, 2005 [Page 9] + +Internet-Draft DNSSEC Experiments February 2005 + + +7. Transitions + + If an experiment is successful, there may be a desire to move the + experiment to a standards-track extension. One way to do so would be + to move from private algorithm numbers to IANA allocated algorithm + numbers, with otherwise the same meaning. This would still leave a + divide between resolvers that understood the extension versus + resolvers that did not. It would, in essence, create an additional + version of DNSSEC. + + An alternate technique might be to do a typecode rollover, thus + actually creating a definitive new version of DNSSEC. There may be + other transition techniques available, as well. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Blacka Expires August 3, 2005 [Page 10] + +Internet-Draft DNSSEC Experiments February 2005 + + +8. Security Considerations + + Zones using this methodology will be considered insecure by all + resolvers except those aware of the experiment. It is not generally + possible to create a secure delegation from an experimental zone that + will be followed by resolvers unaware of the experiment. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Blacka Expires August 3, 2005 [Page 11] + +Internet-Draft DNSSEC Experiments February 2005 + + +9. IANA Considerations + + IANA may need to allocate new DNSSEC algorithm numbers if that + transition approach is taken, or the experiment decides to use + allocated numbers to begin with. No IANA action is required to + deploy an experiment using private algorithm identifiers. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Blacka Expires August 3, 2005 [Page 12] + +Internet-Draft DNSSEC Experiments February 2005 + + +10. References + +10.1 Normative References + + [1] Arends, R., Austein, R., Massey, D., Larson, M. and S. Rose, + "DNS Security Introduction and Requirements", + draft-ietf-dnsext-dnssec-intro-13 (work in progress), October + 2004. + + [2] Arends, R., "Resource Records for the DNS Security Extensions", + draft-ietf-dnsext-dnssec-records-11 (work in progress), October + 2004. + + [3] Arends, R., "Protocol Modifications for the DNS Security + Extensions", draft-ietf-dnsext-dnssec-protocol-09 (work in + progress), October 2004. + +10.2 Informative References + + [4] Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, November 1987. + + [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + + + + + + + + + + + + + + + + + + + + + + + + + + +Blacka Expires August 3, 2005 [Page 13] + +Internet-Draft DNSSEC Experiments February 2005 + + +Editorial Comments + + [Comment.1] Note: how private algorithms work in DNSSEC is not well + explained in the DNSSECbis RFCs. In particular, how to + validate that the DS records contain only unknown + algorithms is not explained at all. + + +Author's Address + + David Blacka + Verisign, Inc. + 21355 Ridgetop Circle + Dulles, VA 20166 + US + + Phone: +1 703 948 3200 + EMail: davidb@verisign.com + URI: http://www.verisignlabs.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Blacka Expires August 3, 2005 [Page 14] + +Internet-Draft DNSSEC Experiments February 2005 + + +Intellectual Property Statement + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + + +Disclaimer of Validity + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + +Copyright Statement + + Copyright (C) The Internet Society (2005). This document is subject + to the rights, licenses and restrictions contained in BCP 78, and + except as set forth therein, the authors retain all their rights. + + +Acknowledgment + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + +Blacka Expires August 3, 2005 [Page 15] + + diff --git a/doc/draft/draft-ietf-dnsext-dnssec-opt-in-06.txt b/doc/draft/draft-ietf-dnsext-dnssec-opt-in-06.txt new file mode 100644 index 0000000000..c4103183d5 --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-dnssec-opt-in-06.txt @@ -0,0 +1,1177 @@ + + +DNSEXT R. Arends +Internet-Draft Telematica Instituut +Expires: August 4, 2005 M. Kosters + D. Blacka + Verisign, Inc. + February 3, 2005 + + + DNSSEC Opt-In + draft-ietf-dnsext-dnssec-opt-in-06 + +Status of this Memo + + This document is an Internet-Draft and is subject to all provisions + of section 3 of RFC 3667. By submitting this Internet-Draft, each + author represents that any applicable patent or other IPR claims of + which he or she is aware have been or will be disclosed, and any of + which he or she become aware will be disclosed, in accordance with + RFC 3668. + + 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 August 4, 2005. + +Copyright Notice + + Copyright (C) The Internet Society (2005). + +Abstract + + In the DNS security extensions (DNSSEC, defined in RFC 2535bis, [3], + [4], and [5]), delegations to unsigned subzones are cryptographically + secured. Maintaining this cryptography is not practical or + necessary. This document describes an experimental "Opt-In" model + that allows administrators to omit this cryptography and manage the + + + +Arends, et al. Expires August 4, 2005 [Page 1] + +Internet-Draft DNSSEC Opt-In February 2005 + + + cost of adopting DNSSEC with large zones. + +Table of Contents + + 1. Definitions and Terminology . . . . . . . . . . . . . . . . . 3 + 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 3. Experimental Status . . . . . . . . . . . . . . . . . . . . . 5 + 4. Protocol Additions . . . . . . . . . . . . . . . . . . . . . . 6 + 4.1 Server Considerations . . . . . . . . . . . . . . . . . . 7 + 4.1.1 Delegations Only . . . . . . . . . . . . . . . . . . . 7 + 4.1.2 Insecure Delegation Responses . . . . . . . . . . . . 7 + 4.1.3 Wildcards and Opt-In . . . . . . . . . . . . . . . . . 7 + 4.1.4 Dynamic Update . . . . . . . . . . . . . . . . . . . . 8 + 4.2 Client Considerations . . . . . . . . . . . . . . . . . . 8 + 4.2.1 Delegations Only . . . . . . . . . . . . . . . . . . . 8 + 4.2.2 Validation Process Changes . . . . . . . . . . . . . . 8 + 4.2.3 NSEC Record Caching . . . . . . . . . . . . . . . . . 9 + 4.2.4 Use of the AD bit . . . . . . . . . . . . . . . . . . 9 + 5. Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 + 6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 + 7. Transition Issues . . . . . . . . . . . . . . . . . . . . . . 13 + 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 + 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 + 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 17 + 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 + 11.1 Normative References . . . . . . . . . . . . . . . . . . . . 18 + 11.2 Informative References . . . . . . . . . . . . . . . . . . . 18 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 19 + A. Implementing Opt-In using "Views" . . . . . . . . . . . . . . 20 + Intellectual Property and Copyright Statements . . . . . . . . 21 + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires August 4, 2005 [Page 2] + +Internet-Draft DNSSEC Opt-In February 2005 + + +1. Definitions and Terminology + + Throughout this document, familiarity with the DNS system (RFC 1035 + [1]), DNS security extensions ([3], [4], and [5], referred to in this + document as "RFC 2535bis"), and DNSSEC terminology (RFC 3090 [10]) is + assumed. + + The following abbreviations and terms are used in this document: + + RR: is used to refer to a DNS resource record. + RRset: refers to a Resource Record Set, as defined by [8]. In this + document, the RRset is also defined to include the covering RRSIG + records, if any exist. + signed name: refers to a DNS name that has, at minimum, a (signed) + NSEC record. + unsigned name: refers to a DNS name that does not (at least) have a + NSEC record. + covering NSEC record/RRset: is the NSEC record used to prove + (non)existence of a particular name or RRset. This means that for + a RRset or name 'N', the covering NSEC record has the name 'N', or + has an owner name less than 'N' and "next" name greater than 'N'. + delegation: refers to a NS RRset with a name different from the + current zone apex (non-zone-apex), signifying a delegation to a + subzone. + secure delegation: refers to a signed name containing a delegation + (NS RRset), and a signed DS RRset, signifying a delegation to a + signed subzone. + insecure delegation: refers to a signed name containing a delegation + (NS RRset), but lacking a DS RRset, signifying a delegation to an + unsigned subzone. + Opt-In insecure delegation: refers to an unsigned name containing + only a delegation NS RRset. The covering NSEC record uses the + Opt-In methodology described in this document. + + 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 [7]. + + + + + + + + + + + + + + +Arends, et al. Expires August 4, 2005 [Page 3] + +Internet-Draft DNSSEC Opt-In February 2005 + + +2. Overview + + The cost to cryptographically secure delegations to unsigned zones is + high for large delegation-centric zones and zones where insecure + delegations will be updated rapidly. For these zones, the costs of + maintaining the NSEC record chain may be extremely high relative to + the gain of cryptographically authenticating existence of unsecured + zones. + + This document describes an experimental method of eliminating the + superfluous cryptography present in secure delegations to unsigned + zones. Using "Opt-In", a zone administrator can choose to remove + insecure delegations from the NSEC chain. This is accomplished by + extending the semantics of the NSEC record by using a redundant bit + in the type map. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires August 4, 2005 [Page 4] + +Internet-Draft DNSSEC Opt-In February 2005 + + +3. Experimental Status + + This document describes an EXPERIMENTAL extension to DNSSEC. It + interoperates with non-experimental DNSSEC using the technique + described in [6]. This experiment is identified with the following + private algorithms (using algorithm 253): + + "3.optin.verisignlabs.com": is an alias for DNSSEC algorithm 3, DSA, + and + "4.optin.verisignlabs.com": is an alias for DNSSEC algorithm 5, + RSASHA1. + + Servers wishing to sign and serve zones that utilize Opt-In MUST sign + the zone with one or more of these private algorithms. This requires + the signing tools and servers to support private algorithms, as well + as Opt-In. + + Resolvers wishing to validate Opt-In zones MUST only do so when the + zone is signed using one or more of these private algorithms. + + The remainder of this document assumes that the servers and resolvers + involved are aware of and are involved in this experiment. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires August 4, 2005 [Page 5] + +Internet-Draft DNSSEC Opt-In February 2005 + + +4. Protocol Additions + + In RFC 2535bis, delegation NS RRsets are not signed, but are instead + accompanied by a NSEC RRset of the same name and a DS record. The + security status of the subzone is determined by the presence or + absence of the DS RRset, cryptographically proven by the NSEC record. + Opt-In expands this definition by allowing insecure delegations to + exist within an otherwise signed zone without the corresponding NSEC + record at the delegation's owner name. These insecure delegations + are proven insecure by using a covering NSEC record. + + Since this represents a change of the interpretation of NSEC records, + resolvers must be able to distinguish between RFC 2535bis NSEC + records and Opt-In NSEC records. This is accomplished by "tagging" + the NSEC records that cover (or potentially cover) insecure + delegation nodes. This tag is indicated by the absence of the NSEC + bit in the type map. Since the NSEC bit in the type map merely + indicates the existence of the record itself, this bit is redundant + and safe for use as a tag. + + An Opt-In tagged NSEC record does not assert the (non)existence of + the delegations that it covers (except for a delegation with the same + name). This allows for the addition or removal of these delegations + without recalculating or resigning records in the NSEC chain. + However, Opt-In tagged NSEC records do assert the (non)existence of + other RRsets. + + An Opt-In NSEC record MAY have the same name as an insecure + delegation. In this case, the delegation is proven insecure by the + lack of a DS bit in type map and the signed NSEC record does assert + the existence of the delegation. + + Zones using Opt-In MAY contain a mixture of Opt-In tagged NSEC + records and RFC 2535bis NSEC records. If a NSEC record is not + Opt-In, there MUST NOT be any insecure delegations (or any other + records) between it and the RRsets indicated by the 'next domain + name' in the NSEC RDATA. If it is Opt-In, there MUST only be + insecure delegations between it and the next node indicated by the + 'next domain name' in the NSEC RDATA. + + In summary, + + o An Opt-In NSEC type is identified by a zero-valued (or + not-specified) NSEC bit in the type bit map of the NSEC record. + o A RFC2535bis NSEC type is identified by a one-valued NSEC bit in + the type bit map of the NSEC record. + + and, + + + +Arends, et al. Expires August 4, 2005 [Page 6] + +Internet-Draft DNSSEC Opt-In February 2005 + + + o An Opt-In NSEC record does not assert the non-existence of a name + between its owner name and "next" name, although it does assert + that any name in this span MUST be an insecure delegation. + o An Opt-In NSEC record does assert the (non)existence of RRsets + with the same owner name. + +4.1 Server Considerations + + Opt-In imposes some new requirements on authoritative DNS servers. + +4.1.1 Delegations Only + + This specification dictates that only insecure delegations may exist + between the owner and "next" names of an Opt-In tagged NSEC record. + Signing tools SHOULD NOT generate signed zones that violate this + restriction. Servers SHOULD refuse to load and/or serve zones that + violate this restriction. + +4.1.2 Insecure Delegation Responses + + When returning an Opt-In insecure delegation, the server MUST return + the covering NSEC RRset in the Authority section. + + In RFC 2535bis, NSEC records already must be returned along with the + insecure delegation. The primary difference that this proposal + introduces is that the Opt-In tagged NSEC record will have a + different owner name from the delegation RRset. This may require + implementations to do a NSEC search on cached responses. + +4.1.3 Wildcards and Opt-In + + RFC 2535bis describes the practice of returning NSEC records to prove + the non-existence of an applicable wildcard in non-existent name + responses. This NSEC record can be described as a "negative wildcard + proof". The use of Opt-In NSEC records changes the necessity for + this practice. For non-existent name responses when the query name + (qname) is covered by an Opt-In tagged NSEC record, servers MAY + choose to omit the wildcard proof record, and clients MUST NOT treat + the absence of this NSEC record as a validation error. + + The intent of the RFC 2535bis negative wildcard proof requirement is + to prevent malicious users from undetectably removing valid wildcard + responses. In order for this cryptographic proof to work, the + resolver must be able to prove: + + 1. The exact qname does not exist. This is done by the "normal" + NSEC record. + + + + +Arends, et al. Expires August 4, 2005 [Page 7] + +Internet-Draft DNSSEC Opt-In February 2005 + + + 2. No applicable wildcard exists. This is done by returning a NSEC + record proving that the wildcard does not exist (this is the + negative wildcard proof). + + However, if the NSEC record covering the exact qname is an Opt-In + NSEC record, the resolver will not be able to prove the first part of + this equation, as the qname might exist as an insecure delegation. + Thus, since the total proof cannot be completed, the negative + wildcard proof NSEC record is not useful. + + The negative wildcard proof is also not useful when returned as part + of an Opt-In insecure delegation response for a similar reason: the + resolver cannot prove that the qname does or does not exist, and + therefore cannot prove that a wildcard expansion is valid. + + The presence of an Opt-In tagged NSEC record does not change the + practice of returning a NSEC along with a wildcard expansion. Even + though the Opt-In NSEC will not be able to prove that the wildcard + expansion is valid, it will prove that the wildcard expansion is not + masking any signed records. + +4.1.4 Dynamic Update + + Opt-In changes the semantics of Secure DNS Dynamic Update [9]. In + particular, it introduces the need for rules that describe when to + add or remove a delegation name from the NSEC chain. This document + does not attempt to define these rules. Until these rules are + defined, servers MUST NOT process DNS Dynamic Update requests against + zones that use Opt-In NSEC records. + +4.2 Client Considerations + + Opt-In imposes some new requirements on security-aware resolvers + (caching or otherwise). + +4.2.1 Delegations Only + + As stated in the "Server Considerations" section above, this + specification restricts the namespace covered by Opt-In tagged NSEC + records to insecure delegations only. Thus, resolvers MUST reject as + invalid any records that fall within an Opt-In NSEC record's span + that are not NS records or corresponding glue records. + +4.2.2 Validation Process Changes + + This specification does not change the resolver's resolution + algorithm. However, it does change the DNSSEC validation process. + Resolvers MUST be able to use Opt-In tagged NSEC records to + + + +Arends, et al. Expires August 4, 2005 [Page 8] + +Internet-Draft DNSSEC Opt-In February 2005 + + + cryptographically prove the validity and security status (as + insecure) of a referral. Resolvers determine the security status of + the referred-to zone as follows: + + o In RFC 2535bis, the security status is proven by the existence or + absence of a DS RRset at the same name as the delegation. The + existence of the DS RRset indicates that the referred-to zone is + signed. The absence of the DS RRset is proven using a verified + NSEC record of the same name that does not have the DS bit set in + the type map. This NSEC record MAY also be tagged as Opt-In. + o Using Opt-In, the security status is proven by the existence of a + DS record (for signed) or the presence of a verified Opt-In tagged + NSEC record that covers the delegation name. That is, the NSEC + record does not have the NSEC bit set in the type map, and the + delegation name falls between the NSEC's owner and "next" name. + + Using Opt-In does not substantially change the nature of following + referrals within DNSSEC. At every delegation point, the resolver + will have cryptographic proof that the subzone is signed or unsigned. + + When receiving either an Opt-In insecure delegation response or a + non-existent name response where that name is covered by an Opt-In + tagged NSEC record, the resolver MUST NOT require proof (in the form + of a NSEC record) that a wildcard did not exist. + +4.2.3 NSEC Record Caching + + Caching resolvers MUST be able to retrieve the appropriate covering + Opt-In NSEC record when returning referrals that need them. This + requirement differs from RFC 2535bis in that the covering NSEC will + not have the same owner name as the delegation. Some implementations + may have to use new methods for finding these NSEC records. + +4.2.4 Use of the AD bit + + The AD bit, as defined by [2] and [5], MUST NOT be set when: + + o sending a non-existent name (NXDOMAIN) response where the covering + NSEC is tagged as Opt-In. + o sending an Opt-In insecure delegation response, unless the + covering (Opt-In) NSEC record's owner name equals the delegation + name. + + This rule is based on what the Opt-In NSEC record actually proves: + for names that exist between the Opt-In NSEC record's owner and + "next" names, the Opt-In NSEC record cannot prove the non-existence + or existence of the name. As such, not all data in the response has + been cryptographically verified, so the AD bit cannot be set. + + + +Arends, et al. Expires August 4, 2005 [Page 9] + +Internet-Draft DNSSEC Opt-In February 2005 + + +5. Benefits + + Using Opt-In allows administrators of large and/or changing + delegation-centric zones to minimize the overhead involved in + maintaining the security of the zone. + + Opt-In accomplishes this by eliminating the need for NSEC records for + insecure delegations. This, in a zone with a large number of + delegations to unsigned subzones, can lead to substantial space + savings (both in memory and on disk). Additionally, Opt-In allows + for the addition or removal of insecure delegations without modifying + the NSEC record chain. Zones that are frequently updating insecure + delegations (e.g., TLDs) can avoid the substantial overhead of + modifying and resigning the affected NSEC records. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires August 4, 2005 [Page 10] + +Internet-Draft DNSSEC Opt-In February 2005 + + +6. Example + + Consider the zone EXAMPLE, shown below. This is a zone where all of + the NSEC records are tagged as Opt-In. + + Example A: Fully Opt-In Zone. + + EXAMPLE. SOA ... + EXAMPLE. RRSIG SOA ... + EXAMPLE. NS FIRST-SECURE.EXAMPLE. + EXAMPLE. RRSIG NS ... + EXAMPLE. DNSKEY ... + EXAMPLE. RRSIG DNSKEY ... + EXAMPLE. NSEC FIRST-SECURE.EXAMPLE. SOA NS RRSIG DNSKEY + EXAMPLE. RRSIG NSEC ... + + FIRST-SECURE.EXAMPLE. A ... + FIRST-SECURE.EXAMPLE. RRSIG A ... + FIRST-SECURE.EXAMPLE. NSEC NOT-SECURE-2.EXAMPLE. A RRSIG + FIRST-SECURE.EXAMPLE. RRSIG NSEC ... + + NOT-SECURE.EXAMPLE. NS NS.NOT-SECURE.EXAMPLE. + NS.NOT-SECURE.EXAMPLE. A ... + + NOT-SECURE-2.EXAMPLE. NS NS.NOT-SECURE.EXAMPLE. + NOT-SECURE-2.EXAMPLE NSEC SECOND-SECURE.EXAMPLE NS RRSIG + NOT-SECURE-2.EXAMPLE RRSIG NSEC ... + + SECOND-SECURE.EXAMPLE. NS NS.ELSEWHERE. + SECOND-SECURE.EXAMPLE. DS ... + SECOND-SECURE.EXAMPLE. RRSIG DS ... + SECOND-SECURE.EXAMPLE. NSEC EXAMPLE. NS RRSIG DNSKEY + SECOND-SECURE.EXAMPLE. RRSIG NSEC ... + + UNSIGNED.EXAMPLE. NS NS.UNSIGNED.EXAMPLE. + NS.UNSIGNED.EXAMPLE. A ... + + + In this example, a query for a signed RRset (e.g., + "FIRST-SECURE.EXAMPLE A"), or a secure delegation + ("WWW.SECOND-SECURE.EXAMPLE A") will result in a normal RFC 2535bis + response. + + A query for a nonexistent RRset will result in a response that + differs from RFC 2535bis by: the NSEC record will be tagged as + Opt-In, there may be no NSEC record proving the non-existence of a + matching wildcard record, and the AD bit will not be set. + + + + +Arends, et al. Expires August 4, 2005 [Page 11] + +Internet-Draft DNSSEC Opt-In February 2005 + + + A query for an insecure delegation RRset (or a referral) will return + both the answer (in the Authority section) and the corresponding + Opt-In NSEC record to prove that it is not secure. + + Example A.1: Response to query for WWW.UNSIGNED.EXAMPLE. A + + + RCODE=NOERROR, AD=0 + + Answer Section: + + Authority Section: + UNSIGNED.EXAMPLE. NS NS.UNSIGNED.EXAMPLE + SECOND-SECURE.EXAMPLE. NSEC EXAMPLE. NS RRSIG DS + SECOND-SECURE.EXAMPLE. RRSIG NSEC ... + + Additional Section: + NS.UNSIGNED.EXAMPLE. A ... + + In the Example A.1 zone, the EXAMPLE. node MAY use either style of + NSEC record, because there are no insecure delegations that occur + between it and the next node, FIRST-SECURE.EXAMPLE. In other words, + Example A would still be a valid zone if the NSEC record for EXAMPLE. + was changed to the following RR: + + EXAMPLE. NSEC FIRST-SECURE.EXAMPLE. (SOA NS + RRSIG DNSKEY NSEC ) + + However, the other NSEC records (FIRST-SECURE.EXAMPLE. and + SECOND-SECURE.EXAMPLE.) MUST be tagged as Opt-In because there are + insecure delegations in the range they define. (NOT-SECURE.EXAMPLE. + and UNSIGNED.EXAMPLE., respectively). + + NOT-SECURE-2.EXAMPLE. is an example of an insecure delegation that + is part of the NSEC chain and also covered by an Opt-In tagged NSEC + record. Because NOT-SECURE-2.EXAMPLE. is a signed name, it cannot + be removed from the zone without modifying and resigning the prior + NSEC record. Delegations with names that fall between + NOT-SECURE-2.EXAMPLE. and SECOND-SECURE.EXAMPLE. may be added or + removed without resigning any NSEC records. + + + + + + + + + + + +Arends, et al. Expires August 4, 2005 [Page 12] + +Internet-Draft DNSSEC Opt-In February 2005 + + +7. Transition Issues + + Opt-In is not backwards compatible with RFC 2535bis. RFC 2535bis + compliant DNSSEC implementations will not recognize Opt-In tagged + NSEC records as different from RFC 2535bis NSEC records. Because of + this, RFC 2535bis implementations will reject all Opt-In insecure + delegations within a zone as invalid. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires August 4, 2005 [Page 13] + +Internet-Draft DNSSEC Opt-In February 2005 + + +8. Security Considerations + + Opt-In allows for unsigned names, in the form of delegations to + unsigned subzones, to exist within an otherwise signed zone. All + unsigned names are, by definition, insecure, and their validity or + existence cannot by cryptographically proven. + + In general: + + o Records with unsigned names (whether existing or not) suffer from + the same vulnerabilities as records in an unsigned zone. These + vulnerabilites are described in more detail in [12] (note in + particular sections 2.3, "Name Games" and 2.6, "Authenticated + Denial"). + o Records with signed names have the same security whether or not + Opt-In is used. + + Note that with or without Opt-In, an insecure delegation may have its + contents undetectably altered by an attacker. Because of this, the + primary difference in security that Opt-In introduces is the loss of + the ability to prove the existence or nonexistence of an insecure + delegation within the span of an Opt-In NSEC record. + + In particular, this means that a malicious entity may be able to + insert or delete records with unsigned names. These records are + normally NS records, but this also includes signed wildcard + expansions (while the wildcard record itself is signed, its expanded + name is an unsigned name). + + For example, if a resolver received the following response from the + example zone above: + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires August 4, 2005 [Page 14] + +Internet-Draft DNSSEC Opt-In February 2005 + + + Example S.1: Response to query for WWW.DOES-NOT-EXIST.EXAMPLE. A + + RCODE=NOERROR + + Answer Section: + + Authority Section: + DOES-NOT-EXIST.EXAMPLE. NS NS.FORGED. + EXAMPLE. NSEC FIRST-SECURE.EXAMPLE. SOA NS \ + RRSIG DNSKEY + EXAMPLE. RRSIG NSEC ... + + Additional Section: + + + The resolver would have no choice but to believe that the referral to + NS.FORGED. is valid. If a wildcard existed that would have been + expanded to cover "WWW.DOES-NOT-EXIST.EXAMPLE.", an attacker could + have undetectably removed it and replaced it with the forged + delegation. + + Note that being able to add a delegation is functionally equivalent + to being able to add any record type: an attacker merely has to forge + a delegation to nameserver under his/her control and place whatever + records needed at the subzone apex. + + While in particular cases, this issue may not present a significant + security problem, in general it should not be lightly dismissed. + Therefore, it is strongly RECOMMENDED that Opt-In be used sparingly. + In particular, zone signing tools SHOULD NOT default to Opt-In, and + MAY choose to not support Opt-In at all. + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires August 4, 2005 [Page 15] + +Internet-Draft DNSSEC Opt-In February 2005 + + +9. IANA Considerations + + None. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires August 4, 2005 [Page 16] + +Internet-Draft DNSSEC Opt-In February 2005 + + +10. Acknowledgments + + The contributions, suggestions and remarks of the following persons + (in alphabetic order) to this draft are acknowledged: + + Mats Dufberg, Miek Gieben, Olafur Gudmundsson, Bob Halley, Olaf + Kolkman, Edward Lewis, Ted Lindgreen, Rip Loomis, Bill Manning, + Dan Massey, Scott Rose, Mike Schiraldi, Jakob Schlyter, Brian + Wellington. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires August 4, 2005 [Page 17] + +Internet-Draft DNSSEC Opt-In February 2005 + + +11. References + +11.1 Normative References + + [1] Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, November 1987. + + [2] Wellington, B. and O. Gudmundsson, "Redefinition of DNS + Authenticated Data (AD) bit", RFC 3655, November 2003. + + [3] Arends, R., Austein, R., Massey, D., Larson, M. and S. Rose, + "DNS Security Introduction and Requirements", + draft-ietf-dnsext-dnssec-intro-13 (work in progress), October + 2004. + + [4] Arends, R., "Resource Records for the DNS Security Extensions", + draft-ietf-dnsext-dnssec-records-11 (work in progress), October + 2004. + + [5] Arends, R., "Protocol Modifications for the DNS Security + Extensions", draft-ietf-dnsext-dnssec-protocol-09 (work in + progress), October 2004. + + [6] Blacka, D., "DNSSEC Experiments", + draft-blacka-dnssec-experiments-00 (work in progress), December + 2004. + +11.2 Informative References + + [7] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + [8] Elz, R. and R. Bush, "Clarifications to the DNS Specification", + RFC 2181, July 1997. + + [9] Eastlake, D., "Secure Domain Name System Dynamic Update", RFC + 2137, April 1997. + + [10] Lewis, E., "DNS Security Extension Clarification on Zone + Status", RFC 3090, March 2001. + + [11] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC 3225, + December 2001. + + [12] Atkins, D. and R. Austein, "Threat Analysis of the Domain Name + System (DNS)", RFC 3833, August 2004. + + + + + +Arends, et al. Expires August 4, 2005 [Page 18] + +Internet-Draft DNSSEC Opt-In February 2005 + + +Authors' Addresses + + Roy Arends + Telematica Instituut + Drienerlolaan 5 + 7522 NB Enschede + NL + + EMail: roy.arends@telin.nl + + + Mark Kosters + Verisign, Inc. + 21355 Ridgetop Circle + Dulles, VA 20166 + US + + Phone: +1 703 948 3200 + EMail: markk@verisign.com + URI: http://www.verisignlabs.com + + + David Blacka + Verisign, Inc. + 21355 Ridgetop Circle + Dulles, VA 20166 + US + + Phone: +1 703 948 3200 + EMail: davidb@verisign.com + URI: http://www.verisignlabs.com + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires August 4, 2005 [Page 19] + +Internet-Draft DNSSEC Opt-In February 2005 + + +Appendix A. Implementing Opt-In using "Views" + + In many cases, it may be convenient to implement an Opt-In zone by + combining two separately maintained "views" of a zone at request + time. In this context, "view" refers to a particular version of a + zone, not to any specific DNS implementation feature. + + In this scenario, one view is the secure view, the other is the + insecure (or legacy) view. The secure view consists of an entirely + signed zone using Opt-In tagged NSEC records. The insecure view + contains no DNSSEC information. It is helpful, although not + necessary, for the secure view to be a subset (minus DNSSEC records) + of the insecure view. + + In addition, the only RRsets that may solely exist in the insecure + view are non-zone-apex NS RRsets. That is, all non-NS RRsets (and + the zone apex NS RRset) MUST be signed and in the secure view. + + These two views may be combined at request time to provide a virtual, + single Opt-In zone. The following algorithm is used when responding + to each query: + V_A is the secure view as described above. + V_B is the insecure view as described above. + R_A is a response generated from V_A, following RFC 2535bis. + R_B is a response generated from V_B, following DNS resolution as + per RFC 1035 [1]. + R_C is the response generated by combining R_A with R_B, as + described below. + A query is DNSSEC-aware if it either has the DO bit [11] turned + on, or is for a DNSSEC-specific record type. + + + + 1. If V_A is a subset of V_B and the query is not DNSSEC-aware, + generate and return R_B, otherwise + 2. Generate R_A. + 3. If R_A's RCODE != NXDOMAIN, return R_A, otherwise + 4. Generate R_B and combine it with R_A to form R_C: + For each section (ANSWER, AUTHORITY, ADDITIONAL), copy the + records from R_A into R_B, EXCEPT the AUTHORITY section SOA + record, if R_B's RCODE = NOERROR. + 5. Return R_C. + + + + + + + + + +Arends, et al. Expires August 4, 2005 [Page 20] + +Internet-Draft DNSSEC Opt-In February 2005 + + +Intellectual Property Statement + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + + +Disclaimer of Validity + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + +Copyright Statement + + Copyright (C) The Internet Society (2005). This document is subject + to the rights, licenses and restrictions contained in BCP 78, and + except as set forth therein, the authors retain all their rights. + + +Acknowledgment + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + +Arends, et al. Expires August 4, 2005 [Page 21] + + diff --git a/doc/draft/draft-ietf-dnsext-dnssec-trans-00.txt b/doc/draft/draft-ietf-dnsext-dnssec-trans-00.txt deleted file mode 100644 index 94ff297f8a..0000000000 --- a/doc/draft/draft-ietf-dnsext-dnssec-trans-00.txt +++ /dev/null @@ -1,784 +0,0 @@ - - -DNS Extensions Working Group R. Arends -Internet-Draft Telematica Instituut -Expires: December 7, 2004 P. Koch - Universitaet Bielefeld - J. Schlyter - NIC-SE - June 8, 2004 - - - Evaluating DNSSEC Transition Mechanisms - draft-ietf-dnsext-dnssec-trans-00.txt - -Status of this Memo - - This document is an Internet-Draft and is in full conformance with - all provisions of Section 10 of RFC2026. - - 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 December 7, 2004. - -Copyright Notice - - Copyright (C) The Internet Society (2004). All Rights Reserved. - -Abstract - - This document collects and summarizes different proposals for - alternative and additional strategies for authenticated denial in DNS - responses, evaluates these proposals and gives a recommendation for a - way forward. - - - - - - - - -Arends, et al. Expires December 7, 2004 [Page 1] - -Internet-Draft Evaluating DNSSEC Transition Mechanisms June 2004 - - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 - 2. Transition Mechanisms . . . . . . . . . . . . . . . . . . . 3 - 2.1 Mechanisms Updating DNSSEC-bis . . . . . . . . . . . . . . . 4 - 2.1.1 Dynamic NSEC Synthesis . . . . . . . . . . . . . . . . . . . 4 - 2.1.2 Add Versioning/Subtyping to Current NSEC . . . . . . . . . . 4 - 2.1.3 Type Bit Map NSEC Indicator . . . . . . . . . . . . . . . . 5 - 2.1.4 New Apex Type . . . . . . . . . . . . . . . . . . . . . . . 6 - 2.1.5 NSEC White Lies . . . . . . . . . . . . . . . . . . . . . . 7 - 2.1.6 NSEC Optional via DNSSKEY Flag . . . . . . . . . . . . . . . 8 - 2.2 Mechanisms not Updating DNSSEC-bis . . . . . . . . . . . . . 9 - 2.2.1 Partial Type-code and Signal Rollover . . . . . . . . . . . 9 - 2.2.2 A Complete Type-code and Signal Rollover . . . . . . . . . . 9 - 2.2.3 Unknown Algorithm in RRSIG . . . . . . . . . . . . . . . . . 10 - 3. Recommendation . . . . . . . . . . . . . . . . . . . . . . . 11 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 12 - Intellectual Property and Copyright Statements . . . . . . . 13 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires December 7, 2004 [Page 2] - -Internet-Draft Evaluating DNSSEC Transition Mechanisms June 2004 - - -1. Introduction - - The working group consents on not including NSEC-alt in the - DNSSEC-bis documents. The working group considers to take up - "prevention of zone enumeration" as a work item. - - There may be multiple mechanisms to allow for co-existence with - DNSSEC-bis. The chairs allow the working group a little over a week - (up to June 12) to come to consensus on a possible modification to - the document to enable gentle rollover. If that consensus cannot be - reached the DNSSEC-bis documents will go out as-is. - - To ease the process of getting consensus, a summary of the proposed - solutions and analysis of the pros and cons were written during the - weekend. - - This summary includes: - - An inventory of the proposed mechanisms to make a transition to - future work on authenticated denial of existence. - List the known Pros and Cons, possibly provide new arguments, and - possible security considerations of these mechanisms. - Provide a recommendation on a way forward that is least disruptive - to the DNSSEC-bis specifications as they stand and keep an open - path to other methods for authenticated denial existence. - - The descriptions of the proposals in this document are coarse and do - not cover every detail necessary for implementation. In any case, - documentation and further study is needed before implementaion and/or - deployment, including those which seem to be solely operational in - nature. - -2. Transition Mechanisms - - In the light of recent discussions and past proposals, we have found - several ways to allow for transition to future expansion of - authenticated denial. We tried to illuminate the paths and pitfalls - in these ways forward. Some proposals lead to a versioning of DNSSEC, - where DNSSEC-bis may co-exist with DNSSEC-ter, other proposals are - 'clean' but may cause delay, while again others may be plain hacks. - - Some paths do not introduce versioning, and might require the current - DNSSEC-bis documents to be fully updated to allow for extensions to - authenticated denial mechanisms. Other paths introduce versioning and - do not (or minimally) require DNSSEC-bis documents to be updated, - allowing DNSSEC-bis to be deployed, while future versions can be - drafted independent from or partially depending on DNSSEC-bis. - - - - -Arends, et al. Expires December 7, 2004 [Page 3] - -Internet-Draft Evaluating DNSSEC Transition Mechanisms June 2004 - - -2.1 Mechanisms Updating DNSSEC-bis - -2.1.1 Dynamic NSEC Synthesis - - This proposal assumes that NSEC RRs and the authenticating RRSIG will - be generated dynamically to just cover the (non existent) query name. - The owner name is (the) one preceding the name queried for, the Next - Owner Name Field has the value of the Query Name Field + 1 (first - successor in canonical ordering). A separate key (the normal ZSK or a - separate ZSK per authoritative server) would be used for RRSIGs on - NSEC RRs. This is a defense against enumeration, though it has the - presumption of online signing. - -2.1.1.1 Coexistence and Migration - - There is no change in interpretation other then that the next owner - name might or might not exist. - -2.1.1.2 Limitations - - This introduces an unbalanced cost between query and response - generation due to dynamic generation of signatures. - -2.1.1.3 Amendments to DNSSEC-bis - - The current DNSSEC-bis documents might need to be updated to indicate - that the next owner name might not be an existing name in the zone. - This is not a real change to the spec since implementers have been - warned not to synthesize with previously cached NSEC records. A - specific bit to identify the dynamic signature generating Key might - be useful as well, to prevent it from being used to fake positive - data. - -2.1.1.4 Cons - - Unbalanced cost is a ground for DDoS. Though this protects against - enumeration, it is not really a path for versioning. - -2.1.1.5 Pros - - Hardly any amendments to DNSSEC-bis. - -2.1.2 Add Versioning/Subtyping to Current NSEC - - This proposal introduces versioning for the NSEC RR type (a.k.a. - subtyping) by adding a (one octet) version field to the NSEC RDATA. - Version number 0 is assigned to the current (DNSSEC-bis) meaning, - making this an 'Must Be Zero' (MBZ) for the to be published docset. - - - -Arends, et al. Expires December 7, 2004 [Page 4] - -Internet-Draft Evaluating DNSSEC Transition Mechanisms June 2004 - - -2.1.2.1 Coexistence and Migration - - Since the versioning is done inside the NSEC RR, different versions - may coexist. However, depending on future methods, that may or may - not be useful inside a single zone. Resolvers cannot ask for specific - NSEC versions but may be able to indicate version support by means of - a to be defined EDNS option bit. - -2.1.2.2 Limitations - - There are no technical limitations, though it will cause delay to - allow testing of the (currently unknown) new NSEC interpretation. - - Since the versioning and signaling is done inside the NSEC RR, future - methods will likely be restricted to a single RR type authenticated - denial (as opposed to e.g. NSEC-alt, which currently proposes three - RR types). - -2.1.2.3 Amendments to DNSSEC-bis - - Full Update of the current DNSSEC-bis documents to provide for new - fields in NSEC, while specifying behavior in case of unknown field - values. - -2.1.2.4 Cons - - Though this is a clean and clear path without versioning DNSSEC, it - takes some time to design, gain consensus, update the current - dnssec-bis document, test and implement a new authenticated denial - record. - -2.1.2.5 Pros - - Does not introduce an iteration to DNSSEC while providing a clear and - clean migration strategy. - -2.1.3 Type Bit Map NSEC Indicator - - Bits in the type-bit-map are reused or allocated to signify the - interpretation of NSEC. - - This proposal assumes that future extensions make use of the existing - NSEC RDATA syntax, while it may need to change the interpretation of - the RDATA or introduce an alternative denial mechanism, invoked by - the specific type-bit-map-bits. - - - - - - -Arends, et al. Expires December 7, 2004 [Page 5] - -Internet-Draft Evaluating DNSSEC Transition Mechanisms June 2004 - - -2.1.3.1 Coexistence and migration - - Old and new NSEC meaning could coexist, depending how the signaling - would be defined. The bits for NXT, NSEC, RRSIG or other outdated RR - types are available as well as those covering meta/query types or - types to be specifically allocated. - -2.1.3.2 Limitations - - This mechanism uses an NSEC field that was not designed for that - purpose. Similar methods were discussed during the Opt-In discussion - and the Silly-State discussion. - -2.1.3.3 Amendments to DNSSEC-bis - - The specific type-bit-map-bits must be allocated and they need to be - specified as 'Must Be Zero' (MBZ) when used for standard (dnssec-bis) - interpretation. Also, behaviour of the resolver and validator must be - documented in case unknown values are encountered for the MBZ field. - Currently the protocol document specifies that the validator MUST - ignore the setting of the NSEC and the RRSIG bits, while other bits - are only used for the specific purpose of the type-bit-map field - -2.1.3.4 Cons - - The type-bit-map was not designed for this purpose. It is a - straightforward hack. Text in protocol section 5.4 was put in - specially to defend against this usage. - -2.1.3.5 Pros - - No change needed to the on-the-wire protocol as specified in the - current docset. - -2.1.4 New Apex Type - - This introduces a new Apex type (parallel to the zone's SOA) - indicating the DNSSEC version (or authenticated denial) used in or - for this zone. - -2.1.4.1 Coexistence and Migration - - Depending on the design of this new RR type multiple denial - mechanisms may coexist in a zone. Old validators will not understand - and thus ignore the new type, so interpretation of the new NSEC - scheme may fail, negative responses may appear 'bogus'. - - - - - -Arends, et al. Expires December 7, 2004 [Page 6] - -Internet-Draft Evaluating DNSSEC Transition Mechanisms June 2004 - - -2.1.4.2 Limitations - - A record of this kind is likely to carry additional feature/ - versioning indications unrelated to the current question of - authenticated denial. - -2.1.4.3 Amendments to DNSSEC-bis - - The current DNSSEC-bis documents need to be updated to indicate that - the absence of this type indicates dnssec-bis, and that the (mere) - presence of this type indicated unknown versions. - -2.1.4.4 Cons - - The only other 'zone' or 'apex' record is the SOA record. Though this - proposal is not new, it is yet unknown how it might fulfill - authenticated denial extensions. This new RR type would only provide - for a generalized signaling mechanism, not the new authenticated - denial scheme. Since it is likely to be general in nature, due to - this generality consensus is not to be reached soon. - -2.1.4.5 Pros - - This approach would allow for a lot of other per zone information to - be transported or signaled to both (slave) servers and resolvers. - -2.1.5 NSEC White Lies - - This proposal disables one part of NSEC (the pointer part) by means - of a special target (root, apex, owner, ...), leaving intact only the - ability to authenticate denial of existence of RR sets, not denial of - existence of domain names (NXDOMAIN). It may be necessary to have one - working NSEC to prove the absence of a wildcard. - -2.1.5.1 Coexistence and Migration - - The NSEC target can be specified per RR, so standard NSEC and 'white - lie' NSEC can coexist in a zone. There is no need for migration - because no versioning is introduced or intended. - -2.1.5.2 Limitations - - This proposal breaks the protocol and is applicable to certain types - of zones only (no wildcard, no deep names, delegation only). Most of - the burden is put on the resolver side and operational consequences - are yet to be studied. - - - - - -Arends, et al. Expires December 7, 2004 [Page 7] - -Internet-Draft Evaluating DNSSEC Transition Mechanisms June 2004 - - -2.1.5.3 Amendments to DNSSEC-bis - - The current DNSSEC-bis documents need to be updated to indicate that - the NXDOMAIN responses may be insecure. - -2.1.5.4 Cons - - Strictly speaking this breaks the protocol and doesn't fully fulfill - the requirements for authenticated denial of existence. Security - implications need to be carefully documented: search path problems - (forged denial of existence may lead to wrong expansion of non-FQDNs, - cf. RFC 1535); replay attacks to deny existence of records - -2.1.5.5 Pros - - Hardly any amendments to DNSSEC-bis. Operational "trick" that is - available anyway. - -2.1.6 NSEC Optional via DNSSKEY Flag - - A new DNSKEY may be defined to declare NSEC optional per zone. - -2.1.6.1 Coexistence and Migration - - Current resolvers/validators will not understand the Flag bit and - will have to treat negative responses as bogus. Otherwise, no - migration path is needed since NSEC is simply turned off. - -2.1.6.2 Limitations - - NSEC can only be made completely optional at the cost of being unable - to prove unsecure delegations (absence of DS RR). A next to this - approach would just disable authenticated denial for non-existence of - nodes. - -2.1.6.3 Amendments to DNSSEC-bis - - New DNSKEY Flag to be defined. Resolver/Validator behaviour needs to - be specified in the light of absence of authenticated denial. - -2.1.6.4 Cons - - Doesn't fully meet requirements. Operational consequences to be - studied. - -2.1.6.5 Pros - - Official version of the "trick" presented in (8). Operational - - - -Arends, et al. Expires December 7, 2004 [Page 8] - -Internet-Draft Evaluating DNSSEC Transition Mechanisms June 2004 - - - problems can be addressed during future work on validators. - -2.2 Mechanisms not Updating DNSSEC-bis - -2.2.1 Partial Type-code and Signal Rollover - - Carefully crafted type code/signal rollover to define a new - authenticated denial space that extends/replaces DNSSEC-bis - authenticated denial space. This particular path is illuminated by - Paul Vixie in a Message-Id <20040602070859.0F50913951@sa.vix.com> - posted to 2004-06-02. - -2.2.1.1 Coexistence and Migration - - To protect the current resolver for future versions, a new DNSSEC-OK - bit must be allocated to make clear it does or does not understand - the future version. Also, a new DS type needs to be allocated to - allow differentiation between a current signed delegation and a - 'future' signed delegation. Also, current NSEC needs to be rolled - into a new authenticated denial type. - -2.2.1.2 Limitations - - None. - -2.2.1.3 Amendments to DNSSEC-bis - - None. - -2.2.1.4 Cons - - It is cumbersome to carefully craft an TCR that 'just fits'. The - DNSSEC-bis protocol has many 'borderline' cases that needs special - consideration. It might be easier to do a full TCR, since a few of - the types and signals need upgrading anyway. - -2.2.1.5 Pros - - Graceful adoption of future versions of NSEC, while there are no - amendments to DNSSEC-bis. - -2.2.2 A Complete Type-code and Signal Rollover - - A new DNSSEC space is defined which can exist independent of current - DNSSEC-bis space. - - This proposal assumes that all current DNSSEC type-codes (RRSIG/ - DNSKEY/NSEC/DS) and signals (DNSSEC-OK) are not used in any future - - - -Arends, et al. Expires December 7, 2004 [Page 9] - -Internet-Draft Evaluating DNSSEC Transition Mechanisms June 2004 - - - versions of DNSSEC. Any future version of DNSSEC has its own types to - allow for keys, signatures, authenticated denial, etcetera. - -2.2.2.1 Coexistence and Migration - - Both spaces can co-exist. They can be made completely orthogonal. - -2.2.2.2 Limitations - - None. - -2.2.2.3 Amendments to DNSSEC-bis - - None. - -2.2.2.4 Cons - - With this path we abandon the current DNSSEC-bis. Though it is easy - to role specific well-known and well-tested parts into the re-write, - once deployment has started this path is very expensive for - implementers, registries, registrars and registrants as well as - resolvers/users. A TCR is not to be expected to occur frequently, so - while a next generation authenticated denial may be enabled by a TCR, - it is likely that that TCR will only be agreed upon if it serves a - whole basket of changes or additions. A quick introduction of NSEC-ng - should not be expected from this path. - -2.2.2.5 Pros - - No amendments/changes to current DNSSEC-bis docset needed. It is - always there as last resort. - -2.2.3 Unknown Algorithm in RRSIG - - This proposal assumes that future extensions make use of the existing - NSEC RDATA syntax, while it may need to change the interpretation of - the RDATA or introduce an alternative denial mechanism, invoked by - the specific unknown signing algorithm. The different interpretation - would be signaled by use of different signature algorithms in the - RRSIG records covering the NSEC RRs. - - When an entire zone is signed with a single unknown algorithm, it - will cause implementations that follow current dnssec-bis documents - to treat individual RRsets as unsigned. - -2.2.3.1 Coexistence and migration - - Old and new NSEC RDATA interpretation or known and unknown Signatures - - - -Arends, et al. Expires December 7, 2004 [Page 10] - -Internet-Draft Evaluating DNSSEC Transition Mechanisms June 2004 - - - can NOT coexist in a zone since signatures cover complete (NSEC) - RRSets. - -2.2.3.2 Limitations - - Validating resolvers agnostic of new interpretation will treat the - NSEC RRset as "not signed". This affects wildcard and non-existence - proof, as well as proof for (un)secured delegations. Also, all - positive signatures (RRSIGs on RRSets other than DS, NSEC) appear - insecure/bogus to an old validator. - - The algorithm version space is split for each future version of - DNSSEC. Violation of the 'modular components' concept. We use the - 'validator' to protect the 'resolver' from unknown interpretations. - -2.2.3.3 Amendments to DNSSEC-bis - - None. - -2.2.3.4 Cons - - The algorithm field was not designed for this purpose. This is a - straightforward hack. - -2.2.3.5 Pros - - No amendments/changes to current DNSSEC-bis docset needed. - -3. Recommendation - - The authors recommend that the working group commits to and starts - work on a partial TCR, allowing gracefull transition towards a future - version of NSEC. Meanwhile, to accomodate the need for an - immediately, temporary, solution against zone-traversal, we recommend - On-Demand NSEC synthesis. - - This approach does not require any mandatory changes to DNSSEC-bis, - does not violate the protocol and fulfills the requirements. As a - side effect, it moves the cost of implementation and deployment to - the users (zone owners) of this mechanism. - - - - - - - - - - - -Arends, et al. Expires December 7, 2004 [Page 11] - -Internet-Draft Evaluating DNSSEC Transition Mechanisms June 2004 - - -Authors' Addresses - - Roy Arends - Telematica Instituut - Drienerlolaan 5 - Enschede 7522 NB - Netherlands - - Phone: +31 534850485 - EMail: roy.arends@telin.nl - - - Peter Koch - Universitaet Bielefeld - - Bielefeld 33594 - Germany - - Phone: +49 521 106 2902 - EMail: pk@TechFak.Uni-Bielefeld.DE - - - Jakob Schlyter - NIC-SE - Box 5774 - Stockholm SE-114 87 - Sweden - - EMail: jakob@nic.se - URI: http://www.nic.se/ - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires December 7, 2004 [Page 12] - -Internet-Draft Evaluating DNSSEC Transition Mechanisms June 2004 - - -Intellectual Property Statement - - The IETF takes no position regarding the validity or scope of any - intellectual property or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; neither does it represent that it - has made any effort to identify any such rights. Information on the - IETF's procedures with respect to rights in standards-track and - standards-related documentation can be found in BCP-11. Copies of - claims of rights made available for publication and any assurances of - licenses to be made available, or the result of an attempt made to - obtain a general license or permission for the use of such - proprietary rights by implementors or users of this specification can - be obtained from the IETF Secretariat. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights which may cover technology that may be required to practice - this standard. Please address the information to the IETF Executive - Director. - - -Full Copyright Statement - - Copyright (C) The Internet Society (2004). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assignees. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING - BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION - - - -Arends, et al. Expires December 7, 2004 [Page 13] - -Internet-Draft Evaluating DNSSEC Transition Mechanisms June 2004 - - - HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - -Acknowledgment - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires December 7, 2004 [Page 14] - diff --git a/doc/draft/draft-ietf-dnsext-dnssec-trans-02.txt b/doc/draft/draft-ietf-dnsext-dnssec-trans-02.txt new file mode 100644 index 0000000000..dd8cbf0682 --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-dnssec-trans-02.txt @@ -0,0 +1,839 @@ + +DNS Extensions Working Group R. Arends +Internet-Draft Telematica Instituut +Expires: August 25, 2005 P. Koch + DENIC eG + J. Schlyter + NIC-SE + February 21, 2005 + + + Evaluating DNSSEC Transition Mechanisms + draft-ietf-dnsext-dnssec-trans-02.txt + +Status of this Memo + + This document is an Internet-Draft and is subject to all provisions + of Section 3 of RFC 3667. By submitting this Internet-Draft, each + author represents that any applicable patent or other IPR claims of + which he or she is aware have been or will be disclosed, and any of + which he or she become aware will be disclosed, in accordance with + RFC 3668. + + 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 August 25, 2005. + +Copyright Notice + + Copyright (C) The Internet Society (2005). + +Abstract + + This document collects and summarizes different proposals for + alternative and additional strategies for authenticated denial in DNS + responses, evaluates these proposals and gives a recommendation for a + + + +Arends, et al. Expires August 25, 2005 [Page 1] + +Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005 + + + way forward. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Transition Mechanisms . . . . . . . . . . . . . . . . . . . . 3 + 2.1 Mechanisms With Need of Updating DNSSEC-bis . . . . . . . 4 + 2.1.1 Dynamic NSEC Synthesis . . . . . . . . . . . . . . . . 4 + 2.1.2 Add Versioning/Subtyping to Current NSEC . . . . . . . 5 + 2.1.3 Type Bit Map NSEC Indicator . . . . . . . . . . . . . 6 + 2.1.4 New Apex Type . . . . . . . . . . . . . . . . . . . . 6 + 2.1.5 NSEC White Lies . . . . . . . . . . . . . . . . . . . 7 + 2.1.6 NSEC Optional via DNSSKEY Flag . . . . . . . . . . . . 8 + 2.1.7 New Answer Pseudo RR Type . . . . . . . . . . . . . . 9 + 2.1.8 SIG(0) Based Authenticated Denial . . . . . . . . . . 9 + 2.2 Mechanisms Without Need of Updating DNSSEC-bis . . . . . . 10 + 2.2.1 Partial Type-code and Signal Rollover . . . . . . . . 10 + 2.2.2 A Complete Type-code and Signal Rollover . . . . . . . 11 + 2.2.3 Unknown Algorithm in RRSIG . . . . . . . . . . . . . . 11 + 3. Recommendation . . . . . . . . . . . . . . . . . . . . . . . . 12 + 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 + 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 + 5.1 Normative References . . . . . . . . . . . . . . . . . . . 13 + 5.2 Informative References . . . . . . . . . . . . . . . . . . 13 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14 + Intellectual Property and Copyright Statements . . . . . . . . 15 + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires August 25, 2005 [Page 2] + +Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005 + + +1. Introduction + + This report shall document the process of dealing with the NSEC + walking problem late in the Last Call for + [I-D.ietf-dnsext-dnssec-intro, I-D.ietf-dnsext-dnssec-protocol, + I-D.ietf-dnsext-dnssec-records]. It preserves some of the discussion + that took place in the DNSEXT WG during the first half of June 2004 + as well as some additional ideas that came up subsequently. + + This is an edited excerpt of the chairs' mail to the WG: + The working group consents on not including NSEC-alt in the + DNSSEC-bis documents. The working group considers to take up + "prevention of zone enumeration" as a work item. + There may be multiple mechanisms to allow for co-existence with + DNSSEC-bis. The chairs allow the working group a little over a + week (up to June 12, 2004) to come to consensus on a possible + modification to the document to enable gentle rollover. If that + consensus cannot be reached the DNSSEC-bis documents will go out + as-is. + + To ease the process of getting consensus, a summary of the proposed + solutions and analysis of the pros and cons were written during the + weekend. + + This summary includes: + + An inventory of the proposed mechanisms to make a transition to + future work on authenticated denial of existence. + List the known Pros and Cons, possibly provide new arguments, and + possible security considerations of these mechanisms. + Provide a recommendation on a way forward that is least disruptive + to the DNSSEC-bis specifications as they stand and keep an open + path to other methods for authenticated denial of existence. + + The descriptions of the proposals in this document are coarse and do + not cover every detail necessary for implementation. In any case, + documentation and further study is needed before implementaion and/or + deployment, including those which seem to be solely operational in + nature. + +2. Transition Mechanisms + + In the light of recent discussions and past proposals, we have found + several ways to allow for transition to future expansion of + authenticated denial. We tried to illuminate the paths and pitfalls + in these ways forward. Some proposals lead to a versioning of + DNSSEC, where DNSSEC-bis may co-exist with DNSSEC-ter, other + proposals are 'clean' but may cause delay, while again others may be + + + +Arends, et al. Expires August 25, 2005 [Page 3] + +Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005 + + + plain hacks. + + Some paths do not introduce versioning, and might require the current + DNSSEC-bis documents to be fully updated to allow for extensions to + authenticated denial mechanisms. Other paths introduce versioning + and do not (or minimally) require DNSSEC-bis documents to be updated, + allowing DNSSEC-bis to be deployed, while future versions can be + drafted independent from or partially depending on DNSSEC-bis. + +2.1 Mechanisms With Need of Updating DNSSEC-bis + + Mechanisms in this category demand updates to the DNSSEC-bis document + set. + +2.1.1 Dynamic NSEC Synthesis + + This proposal assumes that NSEC RRs and the authenticating RRSIG will + be generated dynamically to just cover the (non existent) query name. + The owner name is (the) one preceding the name queried for, the Next + Owner Name Field has the value of the Query Name Field + 1 (first + successor in canonical ordering). A separate key (the normal ZSK or + a separate ZSK per authoritative server) would be used for RRSIGs on + NSEC RRs. This is a defense against enumeration, though it has the + presumption of online signing. + +2.1.1.1 Coexistence and Migration + + There is no change in interpretation other then that the next owner + name might or might not exist. + +2.1.1.2 Limitations + + This introduces an unbalanced cost between query and response + generation due to dynamic generation of signatures. + +2.1.1.3 Amendments to DNSSEC-bis + + The current DNSSEC-bis documents might need to be updated to indicate + that the next owner name might not be an existing name in the zone. + This is not a real change to the spec since implementers have been + warned not to synthesize with previously cached NSEC records. A + specific bit to identify the dynamic signature generating key might + be useful as well, to prevent it from being used to fake positive + data. + +2.1.1.4 Cons + + Unbalanced cost is a ground for DDoS. Though this protects against + + + +Arends, et al. Expires August 25, 2005 [Page 4] + +Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005 + + + enumeration, it is not really a path for versioning. + +2.1.1.5 Pros + + Hardly any amendments to DNSSEC-bis. + +2.1.2 Add Versioning/Subtyping to Current NSEC + + This proposal introduces versioning for the NSEC RR type (a.k.a. + subtyping) by adding a (one octet) version field to the NSEC RDATA. + Version number 0 is assigned to the current (DNSSEC-bis) meaning, + making this an 'Must Be Zero' (MBZ) for the to be published docset. + +2.1.2.1 Coexistence and Migration + + Since the versioning is done inside the NSEC RR, different versions + may coexist. However, depending on future methods, that may or may + not be useful inside a single zone. Resolvers cannot ask for + specific NSEC versions but may be able to indicate version support by + means of a to be defined EDNS option bit. + +2.1.2.2 Limitations + + There are no technical limitations, though it will cause delay to + allow testing of the (currently unknown) new NSEC interpretation. + + Since the versioning and signaling is done inside the NSEC RR, future + methods will likely be restricted to a single RR type authenticated + denial (as opposed to e.g. NSEC-alt, which currently proposes three + RR types). + +2.1.2.3 Amendments to DNSSEC-bis + + Full Update of the current DNSSEC-bis documents to provide for new + fields in NSEC, while specifying behavior in case of unknown field + values. + +2.1.2.4 Cons + + Though this is a clean and clear path without versioning DNSSEC, it + takes some time to design, gain consensus, update the current + dnssec-bis document, test and implement a new authenticated denial + record. + +2.1.2.5 Pros + + Does not introduce an iteration to DNSSEC while providing a clear and + clean migration strategy. + + + +Arends, et al. Expires August 25, 2005 [Page 5] + +Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005 + + +2.1.3 Type Bit Map NSEC Indicator + + Bits in the type-bit-map are reused or allocated to signify the + interpretation of NSEC. + + This proposal assumes that future extensions make use of the existing + NSEC RDATA syntax, while it may need to change the interpretation of + the RDATA or introduce an alternative denial mechanism, invoked by + the specific type-bit-map-bits. + +2.1.3.1 Coexistence and migration + + Old and new NSEC meaning could coexist, depending how the signaling + would be defined. The bits for NXT, NSEC, RRSIG or other outdated RR + types are available as well as those covering meta/query types or + types to be specifically allocated. + +2.1.3.2 Limitations + + This mechanism uses an NSEC field that was not designed for that + purpose. Similar methods were discussed during the Opt-In discussion + and the Silly-State discussion. + +2.1.3.3 Amendments to DNSSEC-bis + + The specific type-bit-map-bits must be allocated and they need to be + specified as 'Must Be Zero' (MBZ) when used for standard (dnssec-bis) + interpretation. Also, behaviour of the resolver and validator must + be documented in case unknown values are encountered for the MBZ + field. Currently the protocol document specifies that the validator + MUST ignore the setting of the NSEC and the RRSIG bits, while other + bits are only used for the specific purpose of the type-bit-map field + +2.1.3.4 Cons + + The type-bit-map was not designed for this purpose. It is a + straightforward hack. Text in protocol section 5.4 was put in + specially to defend against this usage. + +2.1.3.5 Pros + + No change needed to the on-the-wire protocol as specified in the + current docset. + +2.1.4 New Apex Type + + This introduces a new Apex type (parallel to the zone's SOA) + indicating the DNSSEC version (or authenticated denial) used in or + + + +Arends, et al. Expires August 25, 2005 [Page 6] + +Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005 + + + for this zone. + +2.1.4.1 Coexistence and Migration + + Depending on the design of this new RR type multiple denial + mechanisms may coexist in a zone. Old validators will not understand + and thus ignore the new type, so interpretation of the new NSEC + scheme may fail, negative responses may appear 'bogus'. + +2.1.4.2 Limitations + + A record of this kind is likely to carry additional + feature/versioning indications unrelated to the current question of + authenticated denial. + +2.1.4.3 Amendments to DNSSEC-bis + + The current DNSSEC-bis documents need to be updated to indicate that + the absence of this type indicates dnssec-bis, and that the (mere) + presence of this type indicated unknown versions. + +2.1.4.4 Cons + + The only other 'zone' or 'apex' record is the SOA record. Though + this proposal is not new, it is yet unknown how it might fulfill + authenticated denial extensions. This new RR type would only provide + for a generalized signaling mechanism, not the new authenticated + denial scheme. Since it is likely to be general in nature, due to + this generality consensus is not to be reached soon. + +2.1.4.5 Pros + + This approach would allow for a lot of other per zone information to + be transported or signaled to both (slave) servers and resolvers. + +2.1.5 NSEC White Lies + + This proposal disables one part of NSEC (the pointer part) by means + of a special target (root, apex, owner, ...), leaving intact only the + ability to authenticate denial of existence of RR sets, not denial of + existence of domain names (NXDOMAIN). It may be necessary to have + one working NSEC to prove the absence of a wildcard. + +2.1.5.1 Coexistence and Migration + + The NSEC target can be specified per RR, so standard NSEC and 'white + lie' NSEC can coexist in a zone. There is no need for migration + because no versioning is introduced or intended. + + + +Arends, et al. Expires August 25, 2005 [Page 7] + +Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005 + + +2.1.5.2 Limitations + + This proposal breaks the protocol and is applicable to certain types + of zones only (no wildcard, no deep names, delegation only). Most of + the burden is put on the resolver side and operational consequences + are yet to be studied. + +2.1.5.3 Amendments to DNSSEC-bis + + The current DNSSEC-bis documents need to be updated to indicate that + the NXDOMAIN responses may be insecure. + +2.1.5.4 Cons + + Strictly speaking this breaks the protocol and doesn't fully fulfill + the requirements for authenticated denial of existence. Security + implications need to be carefully documented: search path problems + (forged denial of existence may lead to wrong expansion of non-FQDNs + [RFC1535]) and replay attacks to deny existence of records. + +2.1.5.5 Pros + + Hardly any amendments to DNSSEC-bis. Operational "trick" that is + available anyway. + +2.1.6 NSEC Optional via DNSSKEY Flag + + A new DNSKEY may be defined to declare NSEC optional per zone. + +2.1.6.1 Coexistence and Migration + + Current resolvers/validators will not understand the Flag bit and + will have to treat negative responses as bogus. Otherwise, no + migration path is needed since NSEC is simply turned off. + +2.1.6.2 Limitations + + NSEC can only be made completely optional at the cost of being unable + to prove unsecure delegations (absence of a DS RR [RFC3658]). A next + to this approach would just disable authenticated denial for + non-existence of nodes. + +2.1.6.3 Amendments to DNSSEC-bis + + New DNSKEY Flag to be defined. Resolver/Validator behaviour needs to + be specified in the light of absence of authenticated denial. + + + + + +Arends, et al. Expires August 25, 2005 [Page 8] + +Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005 + + +2.1.6.4 Cons + + Doesn't fully meet requirements. Operational consequences to be + studied. + +2.1.6.5 Pros + + Official version of the "trick" presented in (8). Operational + problems can be addressed during future work on validators. + +2.1.7 New Answer Pseudo RR Type + + A new pseudo RR type may be defined that will be dynamically created + (and signed) by the responding authoritative server. The RR in the + response will cover the QNAME, QCLASS and QTYPE and will authenticate + both denial of existence of name (NXDOMAIN) or RRset. + +2.1.7.1 Coexistence and Migration + + Current resolvers/validators will not understand the pseudo RR and + will thus not be able to process negative responses so testified. A + signaling or solicitation method would have to be specified. + +2.1.7.2 Limitations + + This method can only be used with online keys and online signing + capacity. + +2.1.7.3 Amendments to DNSSEC-bis + + Signaling method needs to be defined. + +2.1.7.4 Cons + + Keys have to be held and processed online with all security + implications. An additional flag for those keys identifying them as + online or negative answer only keys should be considered. + +2.1.7.5 Pros + + Expands DNSSEC authentication to the RCODE. + +2.1.8 SIG(0) Based Authenticated Denial + + +2.1.8.1 Coexistence and Migration + + + + + +Arends, et al. Expires August 25, 2005 [Page 9] + +Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005 + + +2.1.8.2 Limitations + + +2.1.8.3 Amendments to DNSSEC-bis + + +2.1.8.4 Cons + + +2.1.8.5 Pros + + +2.2 Mechanisms Without Need of Updating DNSSEC-bis + +2.2.1 Partial Type-code and Signal Rollover + + Carefully crafted type code/signal rollover to define a new + authenticated denial space that extends/replaces DNSSEC-bis + authenticated denial space. This particular path is illuminated by + Paul Vixie in a Message-Id <20040602070859.0F50913951@sa.vix.com> + posted to 2004-06-02. + +2.2.1.1 Coexistence and Migration + + To protect the current resolver for future versions, a new DNSSEC-OK + bit must be allocated to make clear it does or does not understand + the future version. Also, a new DS type needs to be allocated to + allow differentiation between a current signed delegation and a + 'future' signed delegation. Also, current NSEC needs to be rolled + into a new authenticated denial type. + +2.2.1.2 Limitations + + None. + +2.2.1.3 Amendments to DNSSEC-bis + + None. + +2.2.1.4 Cons + + It is cumbersome to carefully craft an TCR that 'just fits'. The + DNSSEC-bis protocol has many 'borderline' cases that needs special + consideration. It might be easier to do a full TCR, since a few of + the types and signals need upgrading anyway. + + + + + + +Arends, et al. Expires August 25, 2005 [Page 10] + +Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005 + + +2.2.1.5 Pros + + Graceful adoption of future versions of NSEC, while there are no + amendments to DNSSEC-bis. + +2.2.2 A Complete Type-code and Signal Rollover + + A new DNSSEC space is defined which can exist independent of current + DNSSEC-bis space. + + This proposal assumes that all current DNSSEC type-codes + (RRSIG/DNSKEY/NSEC/DS) and signals (DNSSEC-OK) are not used in any + future versions of DNSSEC. Any future version of DNSSEC has its own + types to allow for keys, signatures, authenticated denial, etcetera. + +2.2.2.1 Coexistence and Migration + + Both spaces can co-exist. They can be made completely orthogonal. + +2.2.2.2 Limitations + + None. + +2.2.2.3 Amendments to DNSSEC-bis + + None. + +2.2.2.4 Cons + + With this path we abandon the current DNSSEC-bis. Though it is easy + to role specific well-known and well-tested parts into the re-write, + once deployment has started this path is very expensive for + implementers, registries, registrars and registrants as well as + resolvers/users. A TCR is not to be expected to occur frequently, so + while a next generation authenticated denial may be enabled by a TCR, + it is likely that that TCR will only be agreed upon if it serves a + whole basket of changes or additions. A quick introduction of + NSEC-ng should not be expected from this path. + +2.2.2.5 Pros + + No amendments/changes to current DNSSEC-bis docset needed. It is + always there as last resort. + +2.2.3 Unknown Algorithm in RRSIG + + This proposal assumes that future extensions make use of the existing + NSEC RDATA syntax, while it may need to change the interpretation of + + + +Arends, et al. Expires August 25, 2005 [Page 11] + +Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005 + + + the RDATA or introduce an alternative denial mechanism, invoked by + the specific unknown signing algorithm. The different interpretation + would be signaled by use of different signature algorithms in the + RRSIG records covering the NSEC RRs. + + When an entire zone is signed with a single unknown algorithm, it + will cause implementations that follow current dnssec-bis documents + to treat individual RRsets as unsigned. + +2.2.3.1 Coexistence and migration + + Old and new NSEC RDATA interpretation or known and unknown Signatures + can NOT coexist in a zone since signatures cover complete (NSEC) + RRSets. + +2.2.3.2 Limitations + + Validating resolvers agnostic of new interpretation will treat the + NSEC RRset as "not signed". This affects wildcard and non-existence + proof, as well as proof for (un)secured delegations. Also, all + positive signatures (RRSIGs on RRSets other than DS, NSEC) appear + insecure/bogus to an old validator. + + The algorithm version space is split for each future version of + DNSSEC. Violation of the 'modular components' concept. We use the + 'validator' to protect the 'resolver' from unknown interpretations. + +2.2.3.3 Amendments to DNSSEC-bis + + None. + +2.2.3.4 Cons + + The algorithm field was not designed for this purpose. This is a + straightforward hack. + +2.2.3.5 Pros + + No amendments/changes to current DNSSEC-bis docset needed. + +3. Recommendation + + The authors recommend that the working group commits to and starts + work on a partial TCR, allowing graceful transition towards a future + version of NSEC. Meanwhile, to accomodate the need for an + immediately, temporary, solution against zone-traversal, we recommend + On-Demand NSEC synthesis. + + + + +Arends, et al. Expires August 25, 2005 [Page 12] + +Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005 + + + This approach does not require any mandatory changes to DNSSEC-bis, + does not violate the protocol and fulfills the requirements. As a + side effect, it moves the cost of implementation and deployment to + the users (zone owners) of this mechanism. + +4. Acknowledgements + + The authors would like to thank Sam Weiler and Mark Andrews for their + input and constructive comments. + +5. References + +5.1 Normative References + + [I-D.ietf-dnsext-dnssec-intro] + Arends, R., Austein, R., Massey, D., Larson, M. and S. + Rose, "DNS Security Introduction and Requirements", + Internet-Draft draft-ietf-dnsext-dnssec-intro-13, October + 2004. + + [I-D.ietf-dnsext-dnssec-protocol] + Arends, R., "Protocol Modifications for the DNS Security + Extensions", + Internet-Draft draft-ietf-dnsext-dnssec-protocol-09, + October 2004. + + [I-D.ietf-dnsext-dnssec-records] + Arends, R., "Resource Records for the DNS Security + Extensions", + Internet-Draft draft-ietf-dnsext-dnssec-records-11, + October 2004. + + [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", + STD 13, RFC 1034, November 1987. + + [RFC1035] Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, November 1987. + + [RFC2931] Eastlake, D., "DNS Request and Transaction Signatures ( + SIG(0)s)", RFC 2931, September 2000. + +5.2 Informative References + + [RFC1535] Gavron, E., "A Security Problem and Proposed Correction + With Widely Deployed DNS Software", RFC 1535, October + 1993. + + [RFC2535] Eastlake, D., "Domain Name System Security Extensions", + + + +Arends, et al. Expires August 25, 2005 [Page 13] + +Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005 + + + RFC 2535, March 1999. + + [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, + June 1999. + + [RFC3658] Gudmundsson, O., "Delegation Signer (DS) Resource Record + (RR)", RFC 3658, December 2003. + + +Authors' Addresses + + Roy Arends + Telematica Instituut + Brouwerijstraat 1 + Enschede 7523 XC + The Netherlands + + Phone: +31 53 4850485 + Email: roy.arends@telin.nl + + + Peter Koch + DENIC eG + Wiesenh"uttenplatz 26 + Frankfurt 60329 + Germany + + Phone: +49 69 27235 0 + Email: pk@DENIC.DE + + + Jakob Schlyter + NIC-SE + Box 5774 + Stockholm SE-114 87 + Sweden + + Email: jakob@nic.se + URI: http://www.nic.se/ + + + + + + + + + + + + +Arends, et al. Expires August 25, 2005 [Page 14] + +Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005 + + +Intellectual Property Statement + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + + +Disclaimer of Validity + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + +Copyright Statement + + Copyright (C) The Internet Society (2005). This document is subject + to the rights, licenses and restrictions contained in BCP 78, and + except as set forth therein, the authors retain all their rights. + + +Acknowledgment + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + +Arends, et al. Expires August 25, 2005 [Page 15] + + diff --git a/doc/draft/draft-ietf-dnsext-ecc-key-05.txt b/doc/draft/draft-ietf-dnsext-ecc-key-06.txt similarity index 71% rename from doc/draft/draft-ietf-dnsext-ecc-key-05.txt rename to doc/draft/draft-ietf-dnsext-ecc-key-06.txt index dc156530a9..6953f6e42f 100644 --- a/doc/draft/draft-ietf-dnsext-ecc-key-05.txt +++ b/doc/draft/draft-ietf-dnsext-ecc-key-06.txt @@ -1,13 +1,13 @@ - + INTERNET-DRAFT ECC Keys in the DNS -Expires: February 2005 August 2004 +Expires: June 2005 December 2004 Elliptic Curve KEYs in the DNS -------- ----- ---- -- --- --- - + Richard C. Schroeppel Donald Eastlake 3rd @@ -43,8 +43,8 @@ Status of This Document Abstract - The standard method for storing elliptic curve cryptographic keys in - the Domain Name System is specified. + The standard method for storing elliptic curve cryptographic keys and + signatures in the Domain Name System is specified. Copyright Notice @@ -81,17 +81,17 @@ Table of Contents 2. Elliptic Curve Data in Resource Records.................3 3. The Elliptic Curve Equation.............................9 4. How do I Compute Q, G, and Y?..........................10 - 5. Performance Considerations.............................11 - 6. Security Considerations................................11 - 7. IANA Considerations....................................11 - Copyright and Disclaimer..................................12 + 5. Elliptic Curve SIG Resource Records....................11 + 6. Performance Considerations.............................13 + 7. Security Considerations................................13 + 8. IANA Considerations....................................13 + Copyright and Disclaimer..................................14 - Informational References..................................13 - Normative Refrences.......................................13 - - Authors Addresses.........................................14 - Expiration and File Name..................................14 + Informational References..................................15 + Normative Refrences.......................................15 + Author's Addresses........................................16 + Expiration and File Name..................................16 @@ -128,9 +128,9 @@ INTERNET-DRAFT ECC Keys in the DNS protocol, records]. This document describes how to store elliptic curve cryptographic - (ECC) keys in the DNS so they can be used for a variety of security - purposes. A DNS elliptic curve SIG resource record is not defined. - Familiarity with ECC cryptography is assumed [Menezes]. + (ECC) keys and signatures in the DNS so they can be used for a + variety of security purposes. Familiarity with ECC cryptography is + assumed [Menezes]. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this @@ -141,11 +141,8 @@ INTERNET-DRAFT ECC Keys in the DNS 2. Elliptic Curve Data in Resource Records Elliptic curve public keys are stored in the DNS within the RDATA - portions of key RRs with the structure shown below [RFC records]. - - The period of key validity may not be in the RR with the key but - could be indicated by RR(s) with signatures that authenticates the - RR(s) containing the key. + portions of key RRs, such as RRKEY and KEY [RFC records] RRs, with + the structure shown below. The research world continues to work on the issue of which is the best elliptic curve system, which finite field to use, and how to @@ -171,6 +168,9 @@ INTERNET-DRAFT ECC Keys in the DNS + + + R. Schroeppel, et al [Page 3] @@ -373,7 +373,7 @@ INTERNET-DRAFT ECC Keys in the DNS and the constant term is least important. Coefficients are ordered by sign-magnitude: 0 < 1 < -1 < 2 < -2 < ... The first polynomial of degree D is X^D (which is not irreducible). The next is X^D+1, which - is sometimes irreducible, followed by X^D-1, which isnt. Assuming + is sometimes irreducible, followed by X^D-1, which isn't. Assuming odd P, this series continues to X^D - (P-1)/2, and then goes to X^D + X, X^D + X + 1, X^D + X - 1, etc. @@ -490,7 +490,7 @@ INTERNET-DRAFT ECC Keys in the DNS of the curve point is given explicitly; the Z-coordinate is implicit. - LY,Y is the users public signing key, another curve point of + LY,Y is the user's public signing key, another curve point of order Q. The W-coordinate is given explicitly; the Z- coordinate is implicit. The LY,Y parameter pair is always present. @@ -540,7 +540,7 @@ INTERNET-DRAFT ECC Keys in the DNS The number of points on the curve is the number of solutions to the curve equation, + 1 (for the "point at infinity"). The prime Q must divide the number of points. Usually the curve is chosen first, then - the number of points is determined with Schoofs algorithm. This + the number of points is determined with Schoof's algorithm. This number is factored, and if it has a large prime divisor, that number is taken as Q. @@ -567,7 +567,7 @@ INTERNET-DRAFT ECC Keys in the DNS smaller Z value (the one which does not contain the highest-order 1 bit of W (or C)) is used in subsequent calculations. - Y is specified by giving the W-coordinate of the users public + Y is specified by giving the W-coordinate of the user's public signature key. The Z-coordinate value is determined from the curve equation. As with G, there are two possible Z values; the same rule is followed for choosing which Z to use. @@ -598,41 +598,41 @@ INTERNET-DRAFT ECC Keys in the DNS -5. Performance Considerations +5. Elliptic Curve SIG Resource Records - Elliptic curve signatures use smaller moduli or field sizes than RSA - and DSA. Creation of a curve is slow, but not done very often. Key - generation is faster than RSA or DSA. + The signature portion of an RR RDATA area when using the EC + algorithm, for example in the RRSIG and SIG [RFC records] RRs is + shown below. - DNS implementations have been optimized for small transfers, - typically less than 512 octets including DNS overhead. Larger - transfers will perform correctly and and extensions have been - standardized to make larger transfers more efficient [RFC 2671]. - However, it is still advisable at this time to make reasonable - efforts to minimize the size of RR sets stored within the DNS - consistent with adequate security. + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | R, (length determined from LQ) .../ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | S, (length determined from LQ) .../ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + R and S are integers (mod Q). Their length is specified by the LQ + field of the corresponding KEY RR and can also be calculated from the + SIG RR's RDLENGTH. They are right justified, high-order-octet first. + The same conditional formula for calculating the length from LQ is + used as for all the other length fields above. + The data signed is determined as specified in [RFC 2535]. Then the + following steps are taken where Q, P, G, and Y are as specified in + the public key [Schneier]: -6. Security Considerations + hash = SHA-1 ( data ) - Keys retrieved from the DNS should not be trusted unless (1) they - have been securely obtained from a secure resolver or independently - verified by the user and (2) this secure resolver and secure - obtainment or independent verification conform to security policies - acceptable to the user. As with all cryptographic algorithms, - evaluating the necessary strength of the key is essential and - dependent on local policy. + Generate random [RFC 1750] K such that 0 < K < Q. (Never sign two + different messages with the same K. K should be chosen from a + very large space: If an opponent learns a K value for a single + signature, the user's signing key is compromised, and a forger + can sign arbitrary messages. There is no harm in signing the + same message multiple times with the same key or different + keys.) - Some specific key generation considerations are given in the body of - this document. - - - -7. IANA Considerations - - Assignment of meaning to the remaining ECC data flag bits or to - values of ECC fields outside the ranges for which meaning in defined + R = (the W-coordinate of ( K*G on the elliptic curve )) interpreted R. Schroeppel, et al [Page 11] @@ -641,56 +641,56 @@ R. Schroeppel, et al [Page 11] INTERNET-DRAFT ECC Keys in the DNS - in this document requires an IETF consensus as defined in [RFC 2434]. - - - -Copyright and Disclaimer - - Copyright (C) The Internet Society 2004. This document is subject to - the rights, licenses and restrictions contained in BCP 78 and except - as set forth therein, the authors retain all their rights. - - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - - - - - - - - - - - - - - - - + as an integer, and reduced (mod Q). (R must not be 0. In + this astronomically unlikely event, generate a new random K + and recalculate R.) + S = ( K^(-1) * (hash + X*R) ) mod Q. + S must not be 0. In this astronomically unlikely event, generate a + new random K and recalculate R and S. + If S > Q/2, set S = Q - S. + The pair (R,S) is the signature. + Another party verifies the signature as follows: + Check that 0 < R < Q and 0 < S < Q/2. If not, it can not be a + valid EC sigature. + hash = SHA-1 ( data ) + Sinv = S^(-1) mod Q. + U1 = (hash * Sinv) mod Q. + U2 = (R * Sinv) mod Q. + (U1 * G + U2 * Y) is computed on the elliptic curve. + V = (the W-coordinate of this point) interpreted as an integer + and reduced (mod Q). + The signature is valid if V = R. + The reason for requiring S < Q/2 is that, otherwise, both (R,S) and + (R,Q-S) would be valid signatures for the same data. Note that a + signature that is valid for hash(data) is also valid for + hash(data)+Q or hash(data)-Q, if these happen to fall in the range + [0,2^160-1]. It's believed to be computationally infeasible to + find data that hashes to an assigned value, so this is only a + cosmetic blemish. The blemish can be eliminated by using Q > + 2^160, at the cost of having slightly longer signatures, 42 octets + instead of 40. + We must specify how a field-element E ("the W-coordinate") is to be + interpreted as an integer. The field-element E is regarded as a + radix-P integer, with the digits being the coefficients in the + polynomial basis representation of E. The digits are in the ragne + [0,P-1]. In the two most common cases, this reduces to "the + obvious thing". In the (mod P) case, E is simply a residue mod P, + and is taken as an integer in the range [0,P-1]. In the GF[2^D] R. Schroeppel, et al [Page 12] @@ -699,53 +699,53 @@ R. Schroeppel, et al [Page 12] INTERNET-DRAFT ECC Keys in the DNS -Informational References - - [RFC 1034] - P. Mockapetris, "Domain names - concepts and - facilities", 11/01/1987. - - [RFC 1035] - P. Mockapetris, "Domain names - implementation and - specification", 11/01/1987. - - [RFC 1750] - D. Eastlake, S. Crocker, J. Schiller, "Randomness - Recommendations for Security", 12/29/1994. - - [RFC intro] - "DNS Security Introduction and Requirements", R. - Arends, M. Larson, R. Austein, D. Massey, S. Rose, work in progress, - draft-ietf-dnsext-dnssec-intro-*.txt. - - [RFC protocol] - "Protocol Modifications for the DNS Security - Extensions", R. Arends, M. Larson, R. Austein, D. Massey, S. Rose, - work in progress, draft-ietf-dnsext-dnssec-protocol-*.txt. - - [RFC 2671] - P. Vixie, "Extension Mechanisms for DNS (EDNS0)", August - 1999. - - [Schneier] - Bruce Schneier, "Applied Cryptography: Protocols, - Algorithms, and Source Code in C", 1996, John Wiley and Sons - - [Menezes] - Alfred Menezes, "Elliptic Curve Public Key - Cryptosystems", 1993 Kluwer. - - [Silverman] - Joseph Silverman, "The Arithmetic of Elliptic Curves", - 1986, Springer Graduate Texts in mathematics #106. + case, E is in the D-bit polynomial basis representation, and is + simply taken as an integer in the range [0,(2^D)-1]. For other + fields GF[P^D], it's necessary to do some radix conversion + arithmetic. -Normative Refrences + 6. Performance Considerations - [RFC 2119] - S. Bradner, "Key words for use in RFCs to Indicate - Requirement Levels", March 1997. + Elliptic curve signatures use smaller moduli or field sizes than + RSA and DSA. Creation of a curve is slow, but not done very often. + Key generation is faster than RSA or DSA. - [RFC 2434] - T. Narten, H. Alvestrand, "Guidelines for Writing an - IANA Considerations Section in RFCs", October 1998. - - [RFC records] - "Resource Records for the DNS Security Extensions", - R. Arends, R. Austein, M. Larson, D. Massey, S. Rose, work in - progress, draft-ietf-dnsext-dnssec-records- *.txt. + DNS implementations have been optimized for small transfers, + typically less than 512 octets including DNS overhead. Larger + transfers will perform correctly and and extensions have been + standardized to make larger transfers more efficient [RFC 2671]. + However, it is still advisable at this time to make reasonable + efforts to minimize the size of RR sets stored within the DNS + consistent with adequate security. + 7. Security Considerations + + Keys retrieved from the DNS should not be trusted unless (1) they + have been securely obtained from a secure resolver or independently + verified by the user and (2) this secure resolver and secure + obtainment or independent verification conform to security policies + acceptable to the user. As with all cryptographic algorithms, + evaluating the necessary strength of the key is essential and + dependent on local policy. + + Some specific key generation considerations are given in the body + of this document. + + + + 8. IANA Considerations + + The key and signature data structures defined herein correspond to + the value 4 in the Algorithm number field of the IANA registry + + Assignment of meaning to the remaining ECC data flag bits or to + values of ECC fields outside the ranges for which meaning in + defined in this document requires an IETF consensus as defined in + [RFC 2434]. @@ -757,33 +757,33 @@ R. Schroeppel, et al [Page 13] INTERNET-DRAFT ECC Keys in the DNS -Authors Addresses + Copyright and Disclaimer + + Copyright (C) The Internet Society 2004. This document is subject + to the rights, licenses and restrictions contained in BCP 78 and + except as set forth therein, the authors retain all their rights. + + + This document and the information contained herein are provided on + an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE + REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND + THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, + EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT + THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR + ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A + PARTICULAR PURPOSE. + + + + - Rich Schroeppel - 500 S. Maple Drive - Woodland Hills, UT 84653 USA - - Telephone: 1-801-423-7998(h) - 1-505-844-9079(w) - Email: rschroe@sandia.gov - Donald E. Eastlake 3rd - Motorola Laboratories - 155 Beaver Street - Milford, MA 01757 USA - - Telephone: +1 508-634-2066 (h) - +1 508-786-7554 (w) - EMail: Donald.Eastlake@motorola.com -Expiration and File Name - This draft expires in February 2004. - Its file name is draft-ietf-dnsext-ecc-key-05.txt. @@ -812,3 +812,119 @@ Expiration and File Name R. Schroeppel, et al [Page 14] +INTERNET-DRAFT ECC Keys in the DNS + + + Informational References + + [RFC 1034] - P. Mockapetris, "Domain names - concepts and + facilities", 11/01/1987. + + [RFC 1035] - P. Mockapetris, "Domain names - implementation and + specification", 11/01/1987. + + [RFC 1750] - D. Eastlake, S. Crocker, J. Schiller, "Randomness + Recommendations for Security", 12/29/1994. + + [RFC intro] - "DNS Security Introduction and Requirements", R. + Arends, M. Larson, R. Austein, D. Massey, S. Rose, work in + progress, draft-ietf-dnsext-dnssec-intro-*.txt. + + [RFC protocol] - "Protocol Modifications for the DNS Security + Extensions", R. Arends, M. Larson, R. Austein, D. Massey, S. Rose, + work in progress, draft-ietf-dnsext-dnssec-protocol-*.txt. + + [RFC 2671] - P. Vixie, "Extension Mechanisms for DNS (EDNS0)", + August 1999. + + [Schneier] - Bruce Schneier, "Applied Cryptography: Protocols, + Algorithms, and Source Code in C", 1996, John Wiley and Sons + + [Menezes] - Alfred Menezes, "Elliptic Curve Public Key + Cryptosystems", 1993 Kluwer. + + [Silverman] - Joseph Silverman, "The Arithmetic of Elliptic + Curves", 1986, Springer Graduate Texts in mathematics #106. + + + + Normative Refrences + + [RFC 2119] - S. Bradner, "Key words for use in RFCs to Indicate + Requirement Levels", March 1997. + + [RFC 2434] - T. Narten, H. Alvestrand, "Guidelines for Writing an + IANA Considerations Section in RFCs", October 1998. + + [RFC records] - "Resource Records for the DNS Security Extensions", + R. Arends, R. Austein, M. Larson, D. Massey, S. Rose, work in + progress, draft-ietf-dnsext-dnssec-records- *.txt. + + + + + + + + +R. Schroeppel, et al [Page 15] + + +INTERNET-DRAFT ECC Keys in the DNS + + + Author's Addresses + + Rich Schroeppel + 500 S. Maple Drive + Woodland Hills, UT 84653 USA + + Telephone: +1-505-844-9079(w) + +1-801-423-7998(h) + Email: rschroe@sandia.gov + + + Donald E. Eastlake 3rd + Motorola Laboratories + 155 Beaver Street + Milford, MA 01757 USA + + Telephone: +1 508-786-7554 (w) + +1 508-634-2066 (h) + EMail: Donald.Eastlake@motorola.com + + + + Expiration and File Name + + This draft expires in June 2004. + + Its file name is draft-ietf-dnsext-ecc-key-06.txt. + + + + + + + + + + + + + + + + + + + + + + + + + +R. Schroeppel, et al [Page 16] + + diff --git a/doc/draft/draft-ietf-dnsext-insensitive-04.txt b/doc/draft/draft-ietf-dnsext-insensitive-05.txt similarity index 83% rename from doc/draft/draft-ietf-dnsext-insensitive-04.txt rename to doc/draft/draft-ietf-dnsext-insensitive-05.txt index 4cfd417804..41fbee7a4a 100644 --- a/doc/draft/draft-ietf-dnsext-insensitive-04.txt +++ b/doc/draft/draft-ietf-dnsext-insensitive-05.txt @@ -1,639 +1,697 @@ - -INTERNET-DRAFT Donald E. Eastlake 3rd -Clarifies STD0013 Motorola Laboratories -Expires December 2004 July 2004 - - - - Domain Name System (DNS) Case Insensitivity Clarification - ------ ---- ------ ----- ---- ------------- ------------- - - - Donald E. Eastlake 3rd - - - -Status of This Document - - By submitting this Internet-Draft, I certify that any applicable - patent or other IPR claims of which I am aware have been disclosed, - and any of which I become aware will be disclosed, in accordance with - RFC 3668. - - Distribution of this document is unlimited. Comments should be sent - to the DNSEXT working group at namedroppers@ops.ietf.org. - - This document is an Internet-Draft and is in full conformance with - all provisions of Section 10 of RFC 2026. 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. - - - -Abstract - - Domain Name System (DNS) names are "case insensitive". This document - explains exactly what that means and provides a clear specification - of the rules. This clarification should not have any interoperability - consequences. - - - - - - - -D. Eastlake 3rd [Page 1] - - -INTERNET-DRAFT DNS Case Insensitivity - - -Acknowledgements - - The contributions to this document of Rob Austein, Olafur - Gudmundsson, Daniel J. Anderson, Alan Barrett, Marc Blanchet, Dana, - Andreas Gustafsson, Andrew Main, and Scott Seligman are gratefully - acknowledged. - - - -Table of Contents - - Status of This Document....................................1 - Abstract...................................................1 - - Acknowledgements...........................................2 - Table of Contents..........................................2 - - 1. Introduction............................................3 - 2. Case Insensitivity of DNS Labels........................3 - 2.1 Escaping Unusual DNS Label Octets......................3 - 2.2 Example Labels with Escapes............................4 - 3. Name Lookup, Label Types, and CLASS.....................4 - 3.1 Original DNS Label Types...............................5 - 3.2 Extended Label Type Case Insensitivity Considerations..5 - 3.3 CLASS Case Insensitivity Considerations................5 - 4. Case on Input and Output................................6 - 4.1 DNS Output Case Preservation...........................6 - 4.2 DNS Input Case Preservation............................6 - 5. Internationalized Domain Names..........................7 - 6. Security Considerations.................................7 - - Copyright and Disclaimer...................................9 - Normative References.......................................9 - Informative References....................................10 - -02 to -03 Changes........................................10 - -03 to -04 Changes........................................11 - Author's Address..........................................11 - Expiration and File Name..................................11 - - - - - - - - - - - - - - -D. Eastlake 3rd [Page 2] - - -INTERNET-DRAFT DNS Case Insensitivity - - -1. Introduction - - The Domain Name System (DNS) is the global hierarchical replicated - distributed database system for Internet addressing, mail proxy, and - other information. Each node in the DNS tree has a name consisting of - zero or more labels [STD 13][RFC 1591, 2606] that are treated in a - case insensitive fashion. This document clarifies the meaning of - "case insensitive" for the DNS. - - 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]. - - - -2. Case Insensitivity of DNS Labels - - DNS was specified in the era of [ASCII]. DNS names were expected to - look like most host names or Internet email address right halves (the - part after the at-sign, "@") or be numeric as in the in-addr.arpa - part of the DNS name space. For example, - - foo.example.net. - aol.com. - www.gnu.ai.mit.edu. - or 69.2.0.192.in-addr.arpa. - - Case varied alternatives to the above would be DNS names like - - Foo.ExamplE.net. - AOL.COM. - WWW.gnu.AI.mit.EDU. - or 69.2.0.192.in-ADDR.ARPA. - - However, the individual octets of which DNS names consist are not - limited to valid ASCII character codes. They are 8-bit bytes and all - values are allowed. Many applications, however, interpret them as - ASCII characters. - - - -2.1 Escaping Unusual DNS Label Octets - - In Master Files [STD 13] and other human readable and writable ASCII - contexts, an escape is needed for the byte value for period (0x2E, - ".") and all octet values outside of the inclusive range of 0x21 - ("!") to 0x7E ("~"). That is to say, 0x2E and all octet values in - the two inclusive ranges 0x00 to 0x20 and 0x7F to 0xFF. - - One typographic convention for octets that do not correspond to an - - -D. Eastlake 3rd [Page 3] - - -INTERNET-DRAFT DNS Case Insensitivity - - - ASCII printing graphic is to use a back-slash followed by the value - of the octet as an unsigned integer represented by exactly three - decimal digits. - - The same convention can be used for printing ASCII characters so that - they will be treated as a normal label character. This includes the - back-slash character used in this convention itself which can be - expressed as \092 or \\ and the special label separator period (".") - which can be expressed as and \046 or \. respectively. It is - advisable to avoid using a backslash to quote an immediately - following non-printing ASCII character code to avoid implementation - difficulties. - - A back-slash followed by only one or two decimal digits is undefined. - A back-slash followed by four decimal digits produces two octets, the - first octet having the value of the first three digits considered as - a decimal number and the second octet being the character code for - the fourth decimal digit. - - - -2.2 Example Labels with Escapes - - The first example below shows embedded spaces and a period (".") - within a label. The second one show a 5 octet label where the second - octet has all bits zero, the third is a backslash, and the fourth - octet has all bits one. - - Donald\032E\.\032Eastlake\0323rd.example. - and a\000\\\255z.example. - - - -3. Name Lookup, Label Types, and CLASS - - The design decision was made that comparisons on name lookup for DNS - queries should be case insensitive [STD 13]. That is to say, a lookup - string octet with a value in the inclusive range of 0x41 to 0x5A, the - upper case ASCII letters, MUST match the identical value and also - match the corresponding value in the inclusive range 0x61 to 0x7A, - the lower case ASCII letters. And a lookup string octet with a lower - case ASCII letter value MUST similarly match the identical value and - also match the corresponding value in the upper case ASCII letter - range. - - (Historical Note: the terms "upper case" and "lower case" were - invented after movable type. The terms originally referred to the - two font trays for storing, in partitioned areas, the different - physical type elements. Before movable type, the nearest equivalent - terms were "majuscule" and "minuscule".) - - -D. Eastlake 3rd [Page 4] - - -INTERNET-DRAFT DNS Case Insensitivity - - - One way to implement this rule would be, when comparing octets, to - subtract 0x20 from all octets in the inclusive range 0x61 to 0x7A - before the comparison. Such an operation is commonly known as "case - folding" but implementation via case folding is not required. Note - that the DNS case insensitivity does NOT correspond to the case - folding specified in iso-8859-1 or iso-8859-2. For example, the - octets 0xDD (\221) and 0xFD (\253) do NOT match although in other - contexts, where they are interpreted as the upper and lower case - version of "Y" with an acute accent, they might. - - - -3.1 Original DNS Label Types - - DNS labels in wire encoded names have a type associated with them. - The original DNS standard [RFC 1035] had only two types. ASCII - labels, with a length of from zero to 63 octets, and indirect labels - which consist of an offset pointer to a name location elsewhere in - the wire encoding on a DNS message. (The ASCII label of length zero - is reserved for use as the name of the root node of the name tree.) - ASCII labels follow the ASCII case conventions described herein and, - as stated above, can actually contain arbitrary byte values. Indirect - labels are, in effect, replaced by the name to which they point which - is then treated with the case insensitivity rules in this document. - - - -3.2 Extended Label Type Case Insensitivity Considerations - - DNS was extended by [RFC 2671] to have additional label type numbers - available. (The only such type defined so far is the BINARY type [RFC - 2673].) - - The ASCII case insensitivity conventions only apply to ASCII labels, - that is to say, label type 0x0, whether appearing directly or invoked - by indirect labels. - - - -3.3 CLASS Case Insensitivity Considerations - - As described in [STD 13] and [RFC 2929], DNS has an additional axis - for data location called CLASS. The only CLASS in global use at this - time is the "IN" or Internet CLASS. - - The handling of DNS label case is not CLASS dependent. - - - - - - -D. Eastlake 3rd [Page 5] - - -INTERNET-DRAFT DNS Case Insensitivity - - -4. Case on Input and Output - - While ASCII label comparisons are case insensitive, [STD 13] says - case MUST be preserved on output, and preserved when convenient on - input. However, this means less than it would appear since the - preservation of case on output is NOT required when output is - optimized by the use of indirect labels, as explained below. - - - -4.1 DNS Output Case Preservation - - [STD 13] views the DNS namespace as a node tree. ASCII output is as - if a name was marshaled by taking the label on the node whose name is - to be output, converting it to a typographically encoded ASCII - string, walking up the tree outputting each label encountered, and - preceding all labels but the first with a period ("."). Wire output - follows the same sequence but each label is wire encoded and no - periods inserted. No "case conversion" or "case folding" is done - during such output operations, thus "preserving" case. However, to - optimize output, indirect labels may be used to point to names - elsewhere in the DNS answer. In determining whether the name to be - pointed to, for example the QNAME, is the "same" as the remainder of - the name being optimized, the case insensitive comparison specified - above is done. Thus such optimization MAY easily destroy the output - preservation of case. This type of optimization is commonly called - "name compression". - - - -4.2 DNS Input Case Preservation - - Originally, DNS input came from an ASCII Master File as defined in - [STD 13] or a zone transfer. DNS Dynamic update and incremental zone - transfers [RFC 1995] have been added as a source of DNS data [RFC - 2136, 3007]. When a node in the DNS name tree is created by any of - such inputs, no case conversion is done. Thus the case of ASCII - labels is preserved if they are for nodes being created. However, - when a name label is input for a node that already exist in DNS data - being held, the situation is more complex. Implementations may retain - the case first input for such a label or allow new input to override - the old case or even maintain separate copies preserving the input - case. - - For example, if data with owner name "foo.bar.example" is input and - then later data with owner name "xyz.BAR.example" is input, the name - of the label on the "bar.example" node, i.e. "bar", might or might - not be changed to "BAR" or the actual input case could be preserved. - Thus later retrieval of data stored under "xyz.bar.example" in this - case can easily return data with "xyz.BAR.example". The same - - -D. Eastlake 3rd [Page 6] - - -INTERNET-DRAFT DNS Case Insensitivity - - - considerations apply when inputting multiple data records with owner - names differing only in case. For example, if an "A" record is stored - as the first resourced record under owner name "xyz.BAR.example" and - then a second "A" record is stored under "XYZ.BAR.example", the - second MAY be stored with the first (lower case initial label) name - or the second MAY override the first so that only an upper case - initial label is retained or both capitalizations MAY be kept. - - Note that the order of insertion into a server database of the DNS - name tree nodes that appear in a Master File is not defined so that - the results of inconsistent capitalization in a Master File are - unpredictable output capitalization. - - - -5. Internationalized Domain Names - - A scheme has been adopted for "internationalized domain names" and - "internationalized labels" as described in [RFC 3490, 3454, 3491, and - 3492]. It makes most of [UNICODE] available through a separate - application level transformation from internationalized domain name - to DNS domain name and from DNS domain name to internationalized - domain name. Any case insensitivity that internationalized domain - names and labels have varies depending on the script and is handled - entirely as part of the transformation described in [RFC 3454] and - [RFC 3491] which should be seen for further details. This is not a - part of the DNS as standardized in STD 13. - - - -6. Security Considerations - - The equivalence of certain DNS label types with case differences, as - clarified in this document, can lead to security problems. For - example, a user could be confused by believing two domain names - differing only in case were actually different names. - - Furthermore, a domain name may be used in contexts other than the - DNS. It could be used as a case sensitive index into some data base - system. Or it could be interpreted as binary data by some integrity - or authentication code system. These problems can usually be handled - by using a standardized or "canonical" form of the DNS ASCII type - labels, that is, always mapping the ASCII letter value octets in - ASCII labels to some specific pre-chosen case, either upper case or - lower case. An example of a canonical form for domain names (and also - a canonical ordering for them) appears in Section 8 of [RFC 2535]. - See also [RFC 3597]. - - Finally, a non-DNS name may be stored into DNS with the false - expectation that case will always be preserved. For example, although - - -D. Eastlake 3rd [Page 7] - - -INTERNET-DRAFT DNS Case Insensitivity - - - this would be quite rare, on a system with case sensitive email - address local parts, an attempt to store two "RP" records that - differed only in case would probably produce unexpected results that - might have security implications. That is because the entire email - address, including the possibly case sensitive local or left hand - part, is encoded into a DNS name in a readable fashion where the case - of some letters might be changed on output as described above. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -D. Eastlake 3rd [Page 8] - - -INTERNET-DRAFT DNS Case Insensitivity - - -Copyright and Disclaimer - - Copyright (C) The Internet Society 2004. This document is subject to - the rights, licenses and restrictions contained in BCP 78, and except - as set forth therein, the authors retain all their rights. - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - - -Normative References - - [ASCII] - ANSI, "USA Standard Code for Information Interchange", - X3.4, American National Standards Institute: New York, 1968. - - [RFC 1034, 1035] - See [STD 13]. - - [RFC 1995] - M. Ohta, "Incremental Zone Transfer in DNS", August - 1996. - - [RFC 2119] - S. Bradner, "Key words for use in RFCs to Indicate - Requirement Levels", March 1997. - - [RFC 2136] - P. Vixie, Ed., S. Thomson, Y. Rekhter, J. Bound, - "Dynamic Updates in the Domain Name System (DNS UPDATE)", April 1997. - - [RFC 2535] - D. Eastlake, "Domain Name System Security Extensions", - March 1999. - - [RFC 3007] - B. Wellington, "Secure Domain Name System (DNS) Dynamic - Update", November 2000. - - [RFC 3597] - Andreas Gustafsson, "Handling of Unknown DNS RR Types", - draft-ietf-dnsext-unknown-rrs-05.txt, March 2003. - - [STD 13] - - P. Mockapetris, "Domain names - concepts and facilities", RFC - 1034, November 1987. - - P. Mockapetris, "Domain names - implementation and - specification", RFC 1035, November 1987. - - - - - - -D. Eastlake 3rd [Page 9] - - -INTERNET-DRAFT DNS Case Insensitivity - - -Informative References - - [RFC 1591] - J. Postel, "Domain Name System Structure and - Delegation", March 1994. - - [RFC 2606] - D. Eastlake, A. Panitz, "Reserved Top Level DNS Names", - June 1999. - - [RFC 2929] - D. Eastlake, E. Brunner-Williams, B. Manning, "Domain - Name System (DNS) IANA Considerations", September 2000. - - [RFC 2671] - P. Vixie, "Extension mechanisms for DNS (EDNS0)", August - 1999. - - [RFC 2673] - M. Crawford, "Binary Labels in the Domain Name System", - August 1999. - - [RFC 3092] - D. Eastlake 3rd, C. Manros, E. Raymond, "Etymology of - Foo", 1 April 2001. - - [RFC 3454] - P. Hoffman, M. Blanchet, "Preparation of - Internationalized String ("stringprep")", December 2002. - - [RFC 3490] - P. Faltstrom, P. Hoffman, A. Costello, - "Internationalizing Domain Names in Applications (IDNA)", March 2003. - - [RFC 3491] - P. Hoffman, M. Blanchet, "Nameprep: A Stringprep Profile - for Internationalized Domain Names (IDN)", March 2003. - - [RFC 3492] - A. Costello, "Punycode: A Bootstring encoding of Unicode - for Internationalized Domain Names in Applications (IDNA)", March - 2003. - - [UNICODE] - The Unicode Consortium, "The Unicode Standard", - . - - - --02 to -03 Changes - - The following changes were made between draft version -02 and -03: - - 1. Add internationalized domain name section and references. - - 2. Change to indicate that later input of a label for an existing DNS - name tree node may or may not be normalized to the earlier input or - override it or both may be preserved. - - 3. Numerous minor wording changes. - - - -D. Eastlake 3rd [Page 10] - - -INTERNET-DRAFT DNS Case Insensitivity - - --03 to -04 Changes - - The following changes were made between draft version -03 and -04: - - 1. Change to conform to the new IPR, Copyright, etc., notice - requirements. - - 2. Change in some section headers for clarity. - - 3. Drop section on wildcards. - - 4. Add emphasis on loss of case preservation due to name compression. - - 5. Add references to RFCs 1995 and 3092. - - - -Author's Address - - Donald E. Eastlake 3rd - Motorola Laboratories - 155 Beaver Street - Milford, MA 01757 USA - - Telephone: +1 508-786-7554 (w) - +1 508-634-2066 (h) - EMail: Donald.Eastlake@motorola.com - - - -Expiration and File Name - - This draft expires December 2004. - - Its file name is draft-ietf-dnsext-insensitive-04.txt. - - - - - - - - - - - - - - - - - -D. Eastlake 3rd [Page 11] - - + +INTERNET-DRAFT Donald E. Eastlake 3rd +Updates RFC 1034, 1035 Motorola Laboratories +Expires July 2005 January 2005 + + + + Domain Name System (DNS) Case Insensitivity Clarification + ------ ---- ------ ----- ---- ------------- ------------- + + + Donald E. Eastlake 3rd + + + +Status of This Document + + By submitting this Internet-Draft, I certify that any applicable + patent or other IPR claims of which I am aware have been disclosed, + or will be disclosed, and any of which I become aware will be + disclosed, in accordance with RFC 3668. + + Distribution of this document is unlimited. Comments should be sent + to the DNSEXT working group at namedroppers@ops.ietf.org. + + 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 a "work in progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/1id-abstracts.html + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html + + + +Copyright Notice + + Copyright (C) The Internet Society. All Rights Reserved. + + + +Abstract + + Domain Name System (DNS) names are "case insensitive". This document + explains exactly what that means and provides a clear specification + of the rules. This clarification updates RFCs 1034 and 1035. + + +D. Eastlake 3rd [Page 1] + + +INTERNET-DRAFT DNS Case Insensitivity + + +Acknowledgements + + The contributions to this document of Rob Austein, Olafur + Gudmundsson, Daniel J. Anderson, Alan Barrett, Marc Blanchet, Dana, + Andreas Gustafsson, Andrew Main, Thomas Narten, and Scott Seligman + are gratefully acknowledged. + + + +Table of Contents + + Status of This Document....................................1 + Copyright Notice...........................................1 + Abstract...................................................1 + + Acknowledgements...........................................2 + Table of Contents..........................................2 + + 1. Introduction............................................3 + 2. Case Insensitivity of DNS Labels........................3 + 2.1 Escaping Unusual DNS Label Octets......................3 + 2.2 Example Labels with Escapes............................4 + 3. Name Lookup, Label Types, and CLASS.....................4 + 3.1 Original DNS Label Types...............................5 + 3.2 Extended Label Type Case Insensitivity Considerations..5 + 3.3 CLASS Case Insensitivity Considerations................5 + 4. Case on Input and Output................................6 + 4.1 DNS Output Case Preservation...........................6 + 4.2 DNS Input Case Preservation............................6 + 5. Internationalized Domain Names..........................7 + 6. Security Considerations.................................7 + + Full Copyright Notice and Disclaimer.......................9 + Normative References.......................................9 + Informative References....................................10 + -02 to -03 Changes........................................10 + -03 to -04 Changes........................................11 + -04 to -05 Changes........................................11 + Author's Address..........................................11 + Expiration and File Name..................................12 + + + + + + + + + + + + +D. Eastlake 3rd [Page 2] + + +INTERNET-DRAFT DNS Case Insensitivity + + +1. Introduction + + The Domain Name System (DNS) is the global hierarchical replicated + distributed database system for Internet addressing, mail proxy, and + other information. Each node in the DNS tree has a name consisting of + zero or more labels [STD 13][RFC 1591, 2606] that are treated in a + case insensitive fashion. This document clarifies the meaning of + "case insensitive" for the DNS. This clarification updates RFCs 1034 + and 1035 [STD 13]. + + 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]. + + + +2. Case Insensitivity of DNS Labels + + DNS was specified in the era of [ASCII]. DNS names were expected to + look like most host names or Internet email address right halves (the + part after the at-sign, "@") or be numeric as in the in-addr.arpa + part of the DNS name space. For example, + + foo.example.net. + aol.com. + www.gnu.ai.mit.edu. + or 69.2.0.192.in-addr.arpa. + + Case varied alternatives to the above would be DNS names like + + Foo.ExamplE.net. + AOL.COM. + WWW.gnu.AI.mit.EDU. + or 69.2.0.192.in-ADDR.ARPA. + + However, the individual octets of which DNS names consist are not + limited to valid ASCII character codes. They are 8-bit bytes and all + values are allowed. Many applications, however, interpret them as + ASCII characters. + + + +2.1 Escaping Unusual DNS Label Octets + + In Master Files [STD 13] and other human readable and writable ASCII + contexts, an escape is needed for the byte value for period (0x2E, + ".") and all octet values outside of the inclusive range of 0x21 + ("!") to 0x7E ("~"). That is to say, 0x2E and all octet values in + the two inclusive ranges 0x00 to 0x20 and 0x7F to 0xFF. + + + +D. Eastlake 3rd [Page 3] + + +INTERNET-DRAFT DNS Case Insensitivity + + + One typographic convention for octets that do not correspond to an + ASCII printing graphic is to use a back-slash followed by the value + of the octet as an unsigned integer represented by exactly three + decimal digits. + + The same convention can be used for printing ASCII characters so that + they will be treated as a normal label character. This includes the + back-slash character used in this convention itself which can be + expressed as \092 or \\ and the special label separator period (".") + which can be expressed as and \046 or \. respectively. It is + advisable to avoid using a backslash to quote an immediately + following non-printing ASCII character code to avoid implementation + difficulties. + + A back-slash followed by only one or two decimal digits is undefined. + A back-slash followed by four decimal digits produces two octets, the + first octet having the value of the first three digits considered as + a decimal number and the second octet being the character code for + the fourth decimal digit. + + + +2.2 Example Labels with Escapes + + The first example below shows embedded spaces and a period (".") + within a label. The second one show a 5-octet label where the second + octet has all bits zero, the third is a backslash, and the fourth + octet has all bits one. + + Donald\032E\.\032Eastlake\0323rd.example. + and a\000\\\255z.example. + + + +3. Name Lookup, Label Types, and CLASS + + The design decision was made that comparisons on name lookup for all + DNS queries should be case insensitive [STD 13]. That is to say, a + lookup string octet with a value in the inclusive range of 0x41 to + 0x5A, the upper case ASCII letters, MUST match the identical value + and also match the corresponding value in the inclusive range 0x61 to + 0x7A, the lower case ASCII letters. And a lookup string octet with a + lower case ASCII letter value MUST similarly match the identical + value and also match the corresponding value in the upper case ASCII + letter range. + + (Historical Note: the terms "upper case" and "lower case" were + invented after movable type. The terms originally referred to the + two font trays for storing, in partitioned areas, the different + physical type elements. Before movable type, the nearest equivalent + + +D. Eastlake 3rd [Page 4] + + +INTERNET-DRAFT DNS Case Insensitivity + + + terms were "majuscule" and "minuscule".) + + One way to implement this rule would be, when comparing octets, to + subtract 0x20 from all octets in the inclusive range 0x61 to 0x7A + before the comparison. Such an operation is commonly known as "case + folding" but implementation via case folding is not required. Note + that the DNS case insensitivity does NOT correspond to the case + folding specified in [iso-8859-1] or [iso-8859-2]. For example, the + octets 0xDD (\221) and 0xFD (\253) do NOT match although in other + contexts, where they are interpreted as the upper and lower case + version of "Y" with an acute accent, they might. + + + +3.1 Original DNS Label Types + + DNS labels in wire-encoded names have a type associated with them. + The original DNS standard [RFC 1035] had only two types. ASCII + labels, with a length of from zero to 63 octets, and indirect labels + which consist of an offset pointer to a name location elsewhere in + the wire encoding on a DNS message. (The ASCII label of length zero + is reserved for use as the name of the root node of the name tree.) + ASCII labels follow the ASCII case conventions described herein and, + as stated above, can actually contain arbitrary byte values. Indirect + labels are, in effect, replaced by the name to which they point which + is then treated with the case insensitivity rules in this document. + + + +3.2 Extended Label Type Case Insensitivity Considerations + + DNS was extended by [RFC 2671] to have additional label type numbers + available. (The only such type defined so far is the BINARY type [RFC + 2673].) + + The ASCII case insensitivity conventions only apply to ASCII labels, + that is to say, label type 0x0, whether appearing directly or invoked + by indirect labels. + + + +3.3 CLASS Case Insensitivity Considerations + + As described in [STD 13] and [RFC 2929], DNS has an additional axis + for data location called CLASS. The only CLASS in global use at this + time is the "IN" or Internet CLASS. + + The handling of DNS label case is not CLASS dependent. + + + + +D. Eastlake 3rd [Page 5] + + +INTERNET-DRAFT DNS Case Insensitivity + + +4. Case on Input and Output + + While ASCII label comparisons are case insensitive, [STD 13] says + case MUST be preserved on output, and preserved when convenient on + input. However, this means less than it would appear since the + preservation of case on output is NOT required when output is + optimized by the use of indirect labels, as explained below. + + + +4.1 DNS Output Case Preservation + + [STD 13] views the DNS namespace as a node tree. ASCII output is as + if a name was marshaled by taking the label on the node whose name is + to be output, converting it to a typographically encoded ASCII + string, walking up the tree outputting each label encountered, and + preceding all labels but the first with a period ("."). Wire output + follows the same sequence but each label is wire encoded and no + periods inserted. No "case conversion" or "case folding" is done + during such output operations, thus "preserving" case. However, to + optimize output, indirect labels may be used to point to names + elsewhere in the DNS answer. In determining whether the name to be + pointed to, for example the QNAME, is the "same" as the remainder of + the name being optimized, the case insensitive comparison specified + above is done. Thus such optimization may easily destroy the output + preservation of case. This type of optimization is commonly called + "name compression". + + + +4.2 DNS Input Case Preservation + + Originally, DNS input came from an ASCII Master File as defined in + [STD 13] or a zone transfer. DNS Dynamic update and incremental zone + transfers [RFC 1995] have been added as a source of DNS data [RFC + 2136, 3007]. When a node in the DNS name tree is created by any of + such inputs, no case conversion is done. Thus the case of ASCII + labels is preserved if they are for nodes being created. However, + when a name label is input for a node that already exist in DNS data + being held, the situation is more complex. Implementations may retain + the case first input for such a label or allow new input to override + the old case or even maintain separate copies preserving the input + case. + + For example, if data with owner name "foo.bar.example" is input and + then later data with owner name "xyz.BAR.example" is input, the name + of the label on the "bar.example" node, i.e. "bar", might or might + not be changed to "BAR" or the actual input case could be preserved. + Thus later retrieval of data stored under "xyz.bar.example" in this + case can easily return data with "xyz.BAR.example". The same + + +D. Eastlake 3rd [Page 6] + + +INTERNET-DRAFT DNS Case Insensitivity + + + considerations apply when inputting multiple data records with owner + names differing only in case. For example, if an "A" record is stored + as the first resourced record under owner name "xyz.BAR.example" and + then a second "A" record is stored under "XYZ.BAR.example", the + second MAY be stored with the first (lower case initial label) name + or the second MAY override the first so that only an upper case + initial label is retained or both capitalizations MAY be kept. + + Note that the order of insertion into a server database of the DNS + name tree nodes that appear in a Master File is not defined so that + the results of inconsistent capitalization in a Master File are + unpredictable output capitalization. + + + +5. Internationalized Domain Names + + A scheme has been adopted for "internationalized domain names" and + "internationalized labels" as described in [RFC 3490, 3454, 3491, and + 3492]. It makes most of [UNICODE] available through a separate + application level transformation from internationalized domain name + to DNS domain name and from DNS domain name to internationalized + domain name. Any case insensitivity that internationalized domain + names and labels have varies depending on the script and is handled + entirely as part of the transformation described in [RFC 3454] and + [RFC 3491] which should be seen for further details. This is not a + part of the DNS as standardized in STD 13. + + + +6. Security Considerations + + The equivalence of certain DNS label types with case differences, as + clarified in this document, can lead to security problems. For + example, a user could be confused by believing two domain names + differing only in case were actually different names. + + Furthermore, a domain name may be used in contexts other than the + DNS. It could be used as a case sensitive index into some data base + system. Or it could be interpreted as binary data by some integrity + or authentication code system. These problems can usually be handled + by using a standardized or "canonical" form of the DNS ASCII type + labels, that is, always mapping the ASCII letter value octets in + ASCII labels to some specific pre-chosen case, either upper case or + lower case. An example of a canonical form for domain names (and also + a canonical ordering for them) appears in Section 8 of [RFC 2535]. + See also [RFC 3597]. + + Finally, a non-DNS name may be stored into DNS with the false + expectation that case will always be preserved. For example, although + + +D. Eastlake 3rd [Page 7] + + +INTERNET-DRAFT DNS Case Insensitivity + + + this would be quite rare, on a system with case sensitive email + address local parts, an attempt to store two "RP" records that + differed only in case would probably produce unexpected results that + might have security implications. That is because the entire email + address, including the possibly case sensitive local or left hand + part, is encoded into a DNS name in a readable fashion where the case + of some letters might be changed on output as described above. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +D. Eastlake 3rd [Page 8] + + +INTERNET-DRAFT DNS Case Insensitivity + + +Full Copyright Notice and Disclaimer + + Copyright (C) The Internet Society 2005. This document is subject to + the rights, licenses and restrictions contained in BCP 78 and except + as set forth therein, the authors retain all their rights. + + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + + +Normative References + + [ASCII] - ANSI, "USA Standard Code for Information Interchange", + X3.4, American National Standards Institute: New York, 1968. + + [RFC 1034, 1035] - See [STD 13]. + + [RFC 1995] - M. Ohta, "Incremental Zone Transfer in DNS", August + 1996. + + [RFC 2119] - S. Bradner, "Key words for use in RFCs to Indicate + Requirement Levels", March 1997. + + [RFC 2136] - P. Vixie, Ed., S. Thomson, Y. Rekhter, J. Bound, + "Dynamic Updates in the Domain Name System (DNS UPDATE)", April 1997. + + [RFC 2535] - D. Eastlake, "Domain Name System Security Extensions", + March 1999. + + [RFC 3007] - B. Wellington, "Secure Domain Name System (DNS) Dynamic + Update", November 2000. + + [RFC 3597] - Andreas Gustafsson, "Handling of Unknown DNS RR Types", + draft-ietf-dnsext-unknown-rrs-05.txt, March 2003. + + [STD 13] + - P. Mockapetris, "Domain names - concepts and facilities", RFC + 1034, November 1987. + - P. Mockapetris, "Domain names - implementation and + specification", RFC 1035, November 1987. + + + + + +D. Eastlake 3rd [Page 9] + + +INTERNET-DRAFT DNS Case Insensitivity + + +Informative References + + [ISO 8859-1] - International Standards Organization, Standard for + Character Encodings, Latin-1. + + [ISO 8859-2] - International Standards Organization, Standard for + Character Encodings, Latin-2. + + [RFC 1591] - J. Postel, "Domain Name System Structure and + Delegation", March 1994. + + [RFC 2606] - D. Eastlake, A. Panitz, "Reserved Top Level DNS Names", + June 1999. + + [RFC 2929] - D. Eastlake, E. Brunner-Williams, B. Manning, "Domain + Name System (DNS) IANA Considerations", September 2000. + + [RFC 2671] - P. Vixie, "Extension mechanisms for DNS (EDNS0)", August + 1999. + + [RFC 2673] - M. Crawford, "Binary Labels in the Domain Name System", + August 1999. + + [RFC 3092] - D. Eastlake 3rd, C. Manros, E. Raymond, "Etymology of + Foo", 1 April 2001. + + [RFC 3454] - P. Hoffman, M. Blanchet, "Preparation of + Internationalized String ("stringprep")", December 2002. + + [RFC 3490] - P. Faltstrom, P. Hoffman, A. Costello, + "Internationalizing Domain Names in Applications (IDNA)", March 2003. + + [RFC 3491] - P. Hoffman, M. Blanchet, "Nameprep: A Stringprep Profile + for Internationalized Domain Names (IDN)", March 2003. + + [RFC 3492] - A. Costello, "Punycode: A Bootstring encoding of Unicode + for Internationalized Domain Names in Applications (IDNA)", March + 2003. + + [UNICODE] - The Unicode Consortium, "The Unicode Standard", + . + + + +-02 to -03 Changes + + The following changes were made between draft version -02 and -03: + + 1. Add internationalized domain name section and references. + + + +D. Eastlake 3rd [Page 10] + + +INTERNET-DRAFT DNS Case Insensitivity + + + 2. Change to indicate that later input of a label for an existing DNS + name tree node may or may not be normalized to the earlier input or + override it or both may be preserved. + + 3. Numerous minor wording changes. + + + +-03 to -04 Changes + + The following changes were made between draft versions -03 and -04: + + 1. Change to conform to the new IPR, Copyright, etc., notice + requirements. + + 2. Change in some section headers for clarity. + + 3. Drop section on wildcards. + + 4. Add emphasis on loss of case preservation due to name compression. + + 5. Add references to RFCs 1995 and 3092. + + + +-04 to -05 Changes + + The following changes were made between draft versions -04 and -05: + + 1. More clearly state that this draft updates RFCs 1034, 1035 [STD + 13]. + + 2. Add informative references to ISO 8859-1 and ISO 8859-2. + + 3. Fix hyphenation and capitalization nits. + + + +Author's Address + + Donald E. Eastlake 3rd + Motorola Laboratories + 155 Beaver Street + Milford, MA 01757 USA + + Telephone: +1 508-786-7554 (w) + +1 508-634-2066 (h) + EMail: Donald.Eastlake@motorola.com + + + + +D. Eastlake 3rd [Page 11] + + +INTERNET-DRAFT DNS Case Insensitivity + + +Expiration and File Name + + This draft expires July 2005. + + Its file name is draft-ietf-dnsext-insensitive-05.txt. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +D. Eastlake 3rd [Page 12] + + diff --git a/doc/draft/draft-ietf-dnsext-mdns-37.txt b/doc/draft/draft-ietf-dnsext-mdns-38.txt similarity index 84% rename from doc/draft/draft-ietf-dnsext-mdns-37.txt rename to doc/draft/draft-ietf-dnsext-mdns-38.txt index 86d7de88a9..ac51706af2 100644 --- a/doc/draft/draft-ietf-dnsext-mdns-37.txt +++ b/doc/draft/draft-ietf-dnsext-mdns-38.txt @@ -1,14 +1,9 @@ - - - - - DNSEXT Working Group Levon Esibov INTERNET-DRAFT Bernard Aboba Category: Standards Track Dave Thaler - Microsoft -20 October 2004 + Microsoft +19 February 2005 Linklocal Multicast Name Resolution (LLMNR) @@ -35,11 +30,11 @@ Status of this Memo The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on April 22, 2005. + This Internet-Draft will expire on August 22, 2005. Copyright Notice - Copyright (C) The Internet Society 2004. All rights reserved. + Copyright (C) The Internet Society 2005. All rights reserved. Abstract @@ -61,7 +56,7 @@ Esibov, Aboba & Thaler Standards Track [Page 1] -INTERNET-DRAFT LLMNR 20 October 2004 +INTERNET-DRAFT LLMNR 19 February 2005 Table of Contents @@ -74,33 +69,33 @@ Table of Contents 2.2 Sender behavior ................................. 8 2.3 Responder behavior .............................. 9 2.4 Unicast queries ................................. 11 - 2.5 Off-link detection .............................. 11 - 2.6 Responder responsibilities ...................... 12 + 2.5 Off-link detection .............................. 12 + 2.6 Responder responsibilities ...................... 13 2.7 Retransmission and jitter ....................... 13 2.8 DNS TTL ......................................... 14 2.9 Use of the authority and additional sections .... 14 -3. Usage model ........................................... 14 - 3.1 LLMNR configuration ............................. 15 +3. Usage model ........................................... 15 + 3.1 LLMNR configuration ............................. 16 4. Conflict resolution ................................... 17 - 4.1 Considerations for multiple interfaces .......... 18 - 4.2 API issues ...................................... 19 -5. Security considerations ............................... 20 - 5.1 Scope restriction ............................... 20 - 5.2 Usage restriction ............................... 21 - 5.3 Cache and port separation ....................... 22 - 5.4 Authentication .................................. 22 -6. IANA considerations ................................... 22 -7. References ............................................ 23 - 7.1 Normative References ............................ 23 - 7.2 Informative References .......................... 23 -Acknowledgments .............................................. 25 -Authors' Addresses ........................................... 25 -Intellectual Property Statement .............................. 25 -Disclaimer of Validity ....................................... 26 -Copyright Statement .......................................... 26 - - - + 4.1 Uniqueness Verification ......................... 18 + 4.2 Conflict Detection and Defense .................. 18 + 4.3 Considerations for multiple interfaces .......... 20 + 4.4 API issues ...................................... 21 +5. Security considerations ............................... 21 + 5.1 Scope restriction ............................... 22 + 5.2 Usage restriction ............................... 23 + 5.3 Cache and port separation ....................... 23 + 5.4 Authentication .................................. 24 +6. IANA considerations ................................... 24 +7. Constants ............................................. 24 +8. References ............................................ 24 + 8.1 Normative References ............................ 24 + 8.2 Informative References .......................... 25 +Acknowledgments .............................................. 26 +Authors' Addresses ........................................... 27 +Intellectual Property Statement .............................. 27 +Disclaimer of Validity ....................................... 28 +Copyright Statement .......................................... 28 @@ -121,7 +116,7 @@ Esibov, Aboba & Thaler Standards Track [Page 2] -INTERNET-DRAFT LLMNR 20 October 2004 +INTERNET-DRAFT LLMNR 19 February 2005 1. Introduction @@ -181,7 +176,7 @@ Esibov, Aboba & Thaler Standards Track [Page 3] -INTERNET-DRAFT LLMNR 20 October 2004 +INTERNET-DRAFT LLMNR 19 February 2005 and "OPTIONAL" in this document are to be interpreted as described in @@ -241,7 +236,7 @@ Esibov, Aboba & Thaler Standards Track [Page 4] -INTERNET-DRAFT LLMNR 20 October 2004 +INTERNET-DRAFT LLMNR 19 February 2005 responder. A host MAY be configured as a sender, but not a @@ -301,7 +296,7 @@ Esibov, Aboba & Thaler Standards Track [Page 5] -INTERNET-DRAFT LLMNR 20 October 2004 +INTERNET-DRAFT LLMNR 19 February 2005 [d] Upon reception of the response, the sender processes it. @@ -329,7 +324,7 @@ INTERNET-DRAFT LLMNR 20 October 2004 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ID | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - |QR| Opcode | Z|TC| Z| Z| Z| Z| Z| RCODE | + |QR| Opcode | Z|TC| U| C| Z| Z| Z| RCODE | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | QDCOUNT | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ @@ -361,7 +356,7 @@ Esibov, Aboba & Thaler Standards Track [Page 6] -INTERNET-DRAFT LLMNR 20 October 2004 +INTERNET-DRAFT LLMNR 19 February 2005 OPCODE @@ -383,6 +378,19 @@ TC TrunCation - specifies that this message was truncated due to destination address. See [RFC2181] and Section 2.4 of this specification for further discussion of the TC bit. +U UNIQUE - specifies that this message is a UNIQUEness query. The U + bit MUST NOT be set in an LLMNR response, and if set is ignored by + an LLMNR sender. If the U bit is set in an LLMNR query, this + indicates that the sender believes that it is authoritative for the + name. See Section 4.1 and 4.2 for discussion of name conflict + detection. + +C Conflict - specifies that a sender has previously received multiple + LLMNR responses to this query. The C bit MUST NOT be set in an + LLMNR response, and if set is ignored by an LLMNR sender. + Responders do not respond to LLMNR queries with the 'C' bit set; + since no response is expected, LLMNR senders do not retransmit. + Z Reserved for future use. Implementations of this specification MUST set these bits to zero in both queries and responses. If these bits are set in a LLMNR query or response, implementations of @@ -399,6 +407,18 @@ RCODE LLMNR response with a non-zero RCODE sent in response to a multicast query. + + + +Esibov, Aboba & Thaler Standards Track [Page 7] + + + + + +INTERNET-DRAFT LLMNR 19 February 2005 + + If an LLMNR responder is authoritative for the name in a multicast query, but an error is encountered, the responder SHOULD send an LLMNR response with an RCODE of zero, no RRs in the answer section, @@ -412,18 +432,6 @@ RCODE with an RCODE of 3; instead, they should not respond at all. LLMNR implementations MUST support EDNS0 [RFC2671] and extended - - - -Esibov, Aboba & Thaler Standards Track [Page 7] - - - - - -INTERNET-DRAFT LLMNR 20 October 2004 - - RCODE values. QDCOUNT @@ -459,6 +467,18 @@ ARCOUNT may be sent. The sender MUST anticipate receiving no replies to some LLMNR + + + +Esibov, Aboba & Thaler Standards Track [Page 8] + + + + + +INTERNET-DRAFT LLMNR 19 February 2005 + + queries, in the event that no responders are available within the link-scope or in the event no positive non-null responses exist for the transmitted query. If no positive response is received, a @@ -472,18 +492,6 @@ ARCOUNT The sender MUST anticipate receiving multiple replies to the same LLMNR query, in the event that several LLMNR enabled computers - - - -Esibov, Aboba & Thaler Standards Track [Page 8] - - - - - -INTERNET-DRAFT LLMNR 20 October 2004 - - receive the query and respond with valid answers. When multiple valid answers are received, they may first be concatenated, and then treated in the same manner that multiple RRs received from the same @@ -519,6 +527,18 @@ INTERNET-DRAFT LLMNR 20 October 2004 ip6.arpa IN PTR host1. (line split for formatting reasons) IN PTR host1.example.com. + + + +Esibov, Aboba & Thaler Standards Track [Page 9] + + + + + +INTERNET-DRAFT LLMNR 19 February 2005 + + An LLMNR responder might be further manually configured with the name of a local mail server with an MX RR included in the "host1." and "host1.example.com." records. @@ -532,18 +552,6 @@ INTERNET-DRAFT LLMNR 20 October 2004 [b] Responders MUST direct responses to the port from which the query was sent. When queries are received via TCP this is an inherent - - - -Esibov, Aboba & Thaler Standards Track [Page 9] - - - - - -INTERNET-DRAFT LLMNR 20 October 2004 - - part of the transport protocol. For queries received by UDP the responder MUST take note of the source port and use that as the destination port in the response. Responses MUST always be sent @@ -551,7 +559,8 @@ INTERNET-DRAFT LLMNR 20 October 2004 [c] Responders MUST respond to LLMNR queries for names and addresses they are authoritative for. This applies to both forward and - reverse lookups. + reverse lookups, with the exception of queries with the 'C' bit + set, which do not elicit a response. [d] Responders MUST NOT respond to LLMNR queries for names they are not authoritative for. @@ -579,6 +588,17 @@ INTERNET-DRAFT LLMNR 20 October 2004 query is received, the responder would respond with RCODE=0 and an empty answer section. + + +Esibov, Aboba & Thaler Standards Track [Page 10] + + + + + +INTERNET-DRAFT LLMNR 19 February 2005 + + In conventional DNS terminology a DNS server authoritative for a zone is authoritative for all the domain names under the zone apex except for the branches delegated into separate zones. Contrary to @@ -592,18 +612,6 @@ INTERNET-DRAFT LLMNR 20 October 2004 reply to an LLMNR query for "child.foo.example.com." with RCODE=3 (authoritative name error). The purpose of limiting the name authority scope of a responder is to prevent complications that could - - - -Esibov, Aboba & Thaler Standards Track [Page 10] - - - - - -INTERNET-DRAFT LLMNR 20 October 2004 - - be caused by coexistence of two or more hosts with the names representing child and parent (or grandparent) nodes in the DNS tree, for example, "foo.example.com." and "child.foo.example.com.". @@ -639,6 +647,18 @@ INTERNET-DRAFT LLMNR 20 October 2004 Unicast UDP queries MUST be silently discarded. If TCP connection setup cannot be completed in order to send a + + + +Esibov, Aboba & Thaler Standards Track [Page 11] + + + + + +INTERNET-DRAFT LLMNR 19 February 2005 + + unicast TCP query, this is treated as a response that no records of the specified type and class exist for the specified name (it is treated the same as a response with RCODE=0 and an empty answer @@ -652,18 +672,6 @@ INTERNET-DRAFT LLMNR 20 October 2004 link-local address, defined in [RFC2373], or one belonging to a prefix that a Router Advertisement indicates is on-link [RFC2461]. - - - -Esibov, Aboba & Thaler Standards Track [Page 11] - - - - - -INTERNET-DRAFT LLMNR 20 October 2004 - - A sender MUST select a source address for LLMNR queries that is "on link". The destination address of an LLMNR query MUST be a link- scope multicast address or an "on link" unicast address. @@ -700,6 +708,17 @@ INTERNET-DRAFT LLMNR 20 October 2004 received packets with recvmsg(). [RFC2292] specifies similar options for setting and retrieving the IPv6 Hop Limit. + + +Esibov, Aboba & Thaler Standards Track [Page 12] + + + + + +INTERNET-DRAFT LLMNR 19 February 2005 + + 2.6. Responder responsibilities It is the responsibility of the responder to ensure that RRs returned @@ -712,18 +731,6 @@ INTERNET-DRAFT LLMNR 20 October 2004 that address MUST be valid on the local link over which LLMNR is used. - - - -Esibov, Aboba & Thaler Standards Track [Page 12] - - - - - -INTERNET-DRAFT LLMNR 20 October 2004 - - [b] If an IPv4 address is returned, it MUST be reachable through the link over which LLMNR is used. @@ -753,12 +760,25 @@ INTERNET-DRAFT LLMNR 20 October 2004 assure that it was received by a host capable of responding to it. Retransmission of UDP queries SHOULD NOT be attempted more than 3 times. Where LLMNR queries are sent using TCP, retransmission is - handled by the transport layer. + handled by the transport layer. Queries with the 'C' bit set MUST be + sent over UDP and MUST NOT be retransmitted. Because an LLMNR sender cannot know in advance if a query sent using multicast will receive no response, one response, or more than one response, the sender SHOULD wait for LLMNR_TIMEOUT in order to collect all possible responses, rather than considering the multicast + + + +Esibov, Aboba & Thaler Standards Track [Page 13] + + + + + +INTERNET-DRAFT LLMNR 19 February 2005 + + query answered after the first response is received. A unicast query sender considers the query answered after the first response is received, so that it only waits for LLMNR_TIMEOUT if no response has @@ -771,26 +791,16 @@ INTERNET-DRAFT LLMNR 20 October 2004 for the initial RTO (discussed in Section 2 of [RFC2988], paragraph 2.1), the minimum RTO (discussed in Section 2 of [RFC2988], paragraph 2.4), and the maximum RTO (discussed in Section 2 of [RFC2988], - paragraph 2.5). Recommended values are an initial RTO of 500ms, a - - - -Esibov, Aboba & Thaler Standards Track [Page 13] - - - - - -INTERNET-DRAFT LLMNR 20 October 2004 - - - minimum RTO of 100ms, and a maximum RTO of 5 seconds. + paragraph 2.5). In order to avoid synchronization, the transmission of each LLMNR query and response SHOULD delayed by a time randomly selected from - the interval 0 to 100 ms. This delay MAY be avoided by responders - responding with RRs which they have previously determined to be - UNIQUE (see Section 4 for details). + the interval 0 to JITTER_INTERVAL. This delay MAY be avoided by + responders responding with RRs which they have previously determined + to be UNIQUE (see Section 4 for details). + + Recommended values for constants (including LLMNR_TIMEOUT if it is + set statically) are given in Section 7. 2.8. DNS TTL @@ -817,10 +827,29 @@ INTERNET-DRAFT LLMNR 20 October 2004 [RFC2308]. The owner name of this SOA record MUST be equal to the query name. - In LLMNR, the additional section is only intended for use by EDNS0, - TSIG and SIG(0). As a result, senders MAY only include pseudo RR- - types in the additional section of a query; responders MUST ignore - the additional section of queries containing other RR types. + + + +Esibov, Aboba & Thaler Standards Track [Page 14] + + + + + +INTERNET-DRAFT LLMNR 19 February 2005 + + + In LLMNR, the additional section is primarily intended for use by + EDNS0, TSIG and SIG(0). As a result, unless the 'C' bit is set, + senders MAY only include pseudo RR-types in the additional section of + a query; unless the 'C' bit is set, responders MUST ignore the + additional section of queries containing other RR types. + + In queries where the 'C' bit is set, the sender SHOULD include the + conflicting RRs in the additional section. Since conflict + notifications are advisory, responders SHOULD log information from + the additional section, but otherwise MUST ignore the additional + section. Senders MUST NOT cache RRs from the authority or additional section of a response as answers, though they may be used for other purposes @@ -832,18 +861,6 @@ INTERNET-DRAFT LLMNR 20 October 2004 part determined by the behavior of DNS implementations. This document does not specify any changes to DNS resolver behavior, such as searchlist processing or retransmission/failover policy. However, - - - -Esibov, Aboba & Thaler Standards Track [Page 14] - - - - - -INTERNET-DRAFT LLMNR 20 October 2004 - - robust DNS resolver implementations are more likely to avoid unnecessary LLMNR queries. @@ -870,6 +887,18 @@ INTERNET-DRAFT LLMNR 20 October 2004 will also reduce unnecessary LLMNR queries. [RFC1536] Section 6 describes name error bugs and recommended + + + +Esibov, Aboba & Thaler Standards Track [Page 15] + + + + + +INTERNET-DRAFT LLMNR 19 February 2005 + + searchlist processing that will reduce unnecessary RCODE=3 (authoritative name) errors, thereby also reducing unnecessary LLMNR queries. @@ -892,18 +921,6 @@ INTERNET-DRAFT LLMNR 20 October 2004 IPv6. Where a DHCPv4 server is available but not a DHCPv6 server [RFC3315], - - - -Esibov, Aboba & Thaler Standards Track [Page 15] - - - - - -INTERNET-DRAFT LLMNR 20 October 2004 - - IPv6-only hosts may not be configured with a DNS server. Where there is no DNS server authoritative for the name of a host or the authoritative DNS server does not support dynamic client update over @@ -930,6 +947,18 @@ INTERNET-DRAFT LLMNR 20 October 2004 configure LLMNR on an interface. The LLMNR Enable Option, described in [LLMNREnable], can be used to explicitly enable or disable use of LLMNR on an interface. The LLMNR Enable Option does not determine + + + +Esibov, Aboba & Thaler Standards Track [Page 16] + + + + + +INTERNET-DRAFT LLMNR 19 February 2005 + + whether or in which order DNS itself is used for name resolution. The order in which various name resolution mechanisms should be used can be specified using the Name Service Search Option (NSSO) for DHCP @@ -952,18 +981,6 @@ INTERNET-DRAFT LLMNR 20 October 2004 continuing to use LLMNR even once the outage is repaired. Since LLMNR only enables linklocal name resolution, this represents a degradation in capabilities. As a result, hosts without a configured - - - -Esibov, Aboba & Thaler Standards Track [Page 16] - - - - - -INTERNET-DRAFT LLMNR 20 October 2004 - - DNS server may wish to periodically attempt to obtain DNS configuration if permitted by the configuration mechanism in use. In the absence of other guidance, a default retry interval of one (1) @@ -982,21 +999,37 @@ INTERNET-DRAFT LLMNR 20 October 2004 type record for a name. By default, a responder SHOULD be configured to behave as though all - RRs are UNIQUE on each interface on which LLMNR is enabled. Prior to - including a UNIQUE resource record in a response, for each UNIQUE - resource record in a given interface's configuration, the host MUST - verify that there is no other host within the scope of LLMNR query - propagation that can return a resource record for the same name, type - and class on that interface. Once a responder has verified the - uniqueness of a UNIQUE resource record, if it receives an LLMNR query - for that resource record, it MUST respond. + RRs are UNIQUE on each interface on which LLMNR is enabled. - To verify uniqueness, a responder MUST send an LLMNR query for each - UNIQUE resource record. If no response is received after a suitable - number of attempts (see Section 2.7), the responder can use the - UNIQUE resource record in response to LLMNR queries. If a response - is received, the responder MUST NOT use the UNIQUE resource record in - response to LLMNR queries. + When name conflicts are detected, they SHOULD be logged. To detect + duplicate use of a name, an administrator can use a name resolution + utility which employs LLMNR and lists both responses and responders. + This would allow an administrator to diagnose behavior and + potentially to intervene and reconfigure LLMNR responders who should + not be configured to respond to the same name. + + + +Esibov, Aboba & Thaler Standards Track [Page 17] + + + + + +INTERNET-DRAFT LLMNR 19 February 2005 + + +4.1. Uniqueness Verification + + Prior to including a UNIQUE resource record in a response, for each + UNIQUE resource record in a given interface's configuration, the host + MUST verify that there is no other host within the scope of LLMNR + query propagation that can return a resource record for the same + name, type and class on that interface. + + Once a responder has verified the uniqueness of a UNIQUE resource + record, if it receives an LLMNR query for that resource record, with + the 'C' bit clear, it MUST respond. Uniqueness verification is carried out when the host: @@ -1010,38 +1043,105 @@ INTERNET-DRAFT LLMNR 20 October 2004 - verifies the acquisition of a new IP address and configuration on an interface - The name conflict detection mechanism doesn't prevent name conflicts - when previously partitioned segments are connected by a bridge. It + To verify uniqueness, a responder MUST send an LLMNR query with the + 'U' bit set for each UNIQUE resource record. If no response is + received, the sender retransmits the query, as specified in Section + 2.7. If a response is received, the responder MUST NOT use the UNIQUE + resource record in response to LLMNR queries. + + Periodically carrying out uniqueness verification in an attempt to + detect name conflicts is not necessary, wastes network bandwidth, and + may actually be detrimental. For example, if network links are + joined only briefly, and are separated again before any new + communication is initiated, temporary conflicts are benign and no + forced reconfiguration is required. Triggering a reconfiguration in + this case would not serve any useful purpose. LLMNR responders + SHOULD NOT periodically attempt uniqueness verification. + +4.2. Conflict Detection and Defense + + Hosts on disjoint network links may configure the same name for use + with LLMNR. If these separate network links are later joined or + bridged together, then there may be multiple hosts which are now on + the same link, trying to use the same name. + + There are several mechanisms by which ongoing name conflicts may be + detected: -Esibov, Aboba & Thaler Standards Track [Page 17] +Esibov, Aboba & Thaler Standards Track [Page 18] -INTERNET-DRAFT LLMNR 20 October 2004 +INTERNET-DRAFT LLMNR 19 February 2005 - also does not prevent deadlocks where two hosts attempt to verify - uniqueness of the same RR, yet neither can yet respond to queries - since uniqueness has not yet been verified. +[a] Receipt of a query with the 'U' bit set. Whenever an LLMNR + responder receives an LLMNR query for a UNIQUE resource record with + the 'U' bit set, if the source IP address does not match an IP + address configured on that interface, this indicates a conflict. - In order to minimize the chance of conflicts in such situations, it - is recommended that steps be taken to ensure name uniqueness. For - example, the name could be chosen randomly from a large pool of - potential names, or the name could be assigned via a process designed - to guarantee uniqueness. +[b] Conflict notification queries. When an LLMNR sender receives + multiple LLMNR responses to a query, it MUST send another query for + the same resource record, this time with the 'C' bit set, with the + answers received included in the Additional section. - When name conflicts are detected, they SHOULD be logged. To detect - duplicate use of a name, an administrator can use a name resolution - utility which employs LLMNR and lists both responses and responders. - This would allow an administrator to diagnose behavior and - potentially to intervene and reconfigure LLMNR responders who should - not be configured to respond to the same name. + Queries with the 'C' bit set are considered advisory and responders + MUST verify the existence of a conflict by other means before + acting on it. A responder receiving a query with the 'C' bit set + MUST NOT respond. If the resource record is not UNIQUE, then the + responder MUST ignore the query. If the resource record is UNIQUE, + then the responder MUST send its own query for the same resource + record, with the 'U' bit set. If a response is received, or if a + query with the 'U' bit set is received, then a conflict has been + detected. -4.1. Considerations for Multiple Interfaces +An LLMNR responder MUST NOT ignore conflicts once detected. An LLMNR +responder MUST respond to a conflict as described in either [1] or [2] +below: + +[1] Upon detecting a conflict, an LLMNR responder MAY elect to + immediately stop using the conflicting UNIQUE resource record in + response to LLMNR queries. + + The responder MAY also elect to configure a new name. However, + since name reconfiguration may be disruptive, this is not required, + and a responder may have been configured to respond to multiple + names so that alternative names may already be available. + +[2] If a responder currently has reasons to prefer using the name, and + it has not seen any other conflicting LLMNR queries within the last + DEFEND_INTERVAL seconds, then it MAY elect to defend its name, by + recording the time that the conflicting LLMNR query was received, + and then sending multicast queries for its UNIQUE resource records, + with the 'U' bit set. + + Having done this, an LLMNR responder can then continue to use the + name normally without any further special action. However, if this + is not the first conflicting LLMNR query the responder has seen, + and the time recorded for the previous conflicting LLMNR query is + recent, within DEFEND_INTERVAL, then the LLMNR responder MUST + immediately cease using the conflicting resource records. + + This is necessary to ensure that two hosts do not get stuck in an + + + +Esibov, Aboba & Thaler Standards Track [Page 19] + + + + + +INTERNET-DRAFT LLMNR 19 February 2005 + + + endless loop with both hosts trying to defend the same name. + +4.3. Considerations for Multiple Interfaces A multi-homed host may elect to configure LLMNR on only one of its active interfaces. In many situations this will be adequate. @@ -1072,18 +1172,6 @@ INTERNET-DRAFT LLMNR 20 October 2004 Since names are only unique per-link, hosts on different links could be using the same name. If an LLMNR client sends requests over - - - -Esibov, Aboba & Thaler Standards Track [Page 18] - - - - - -INTERNET-DRAFT LLMNR 20 October 2004 - - multiple interfaces, and receives replies from more than one, the result returned to the client is defined by the implementation. The situation is illustrated in figure 2. @@ -1100,6 +1188,17 @@ INTERNET-DRAFT LLMNR 20 October 2004 query for the host RR for name "A" it will receive a response from hosts on both interfaces. + + +Esibov, Aboba & Thaler Standards Track [Page 20] + + + + + +INTERNET-DRAFT LLMNR 19 February 2005 + + Host myhost cannot distinguish between the situation shown in Figure 2, and that shown in Figure 3 where no conflict exists. @@ -1118,7 +1217,7 @@ INTERNET-DRAFT LLMNR 20 October 2004 separated name spaces. It is not the intent of this document to address the issue of uniqueness of names within DNS. -4.2. API issues +4.4. API issues [RFC2553] provides an API which can partially solve the name ambiguity problem for applications written to use this API, since the @@ -1132,18 +1231,6 @@ INTERNET-DRAFT LLMNR 20 October 2004 interfaces and the resolver library will return a list containing multiple addrinfo structures, each with an associated sockaddr_in6 structure. This list will thus contain the IPv4 and IPv6 addresses - - - -Esibov, Aboba & Thaler Standards Track [Page 19] - - - - - -INTERNET-DRAFT LLMNR 20 October 2004 - - of both hosts responding to the name 'A'. Link-local addresses will have a sin6_scope_id value that disambiguates which interface is used to reach the address. Of course, to the application, Figures 2 and 3 @@ -1160,6 +1247,18 @@ INTERNET-DRAFT LLMNR 20 October 2004 sent to a link-scope multicast address, where every host on the logical link will be made aware of it. + + + +Esibov, Aboba & Thaler Standards Track [Page 21] + + + + + +INTERNET-DRAFT LLMNR 19 February 2005 + + In order to address the security vulnerabilities, the following mechanisms are contemplated: @@ -1192,18 +1291,6 @@ INTERNET-DRAFT LLMNR 20 October 2004 While this limits the ability of off-link attackers to spoof LLMNR queries and responses, it does not eliminate it. For example, it is - - - -Esibov, Aboba & Thaler Standards Track [Page 20] - - - - - -INTERNET-DRAFT LLMNR 20 October 2004 - - possible for an attacker to spoof a response to a query (such as an A or AAAA query for a popular Internet host), and by using a TTL or Hop Limit field larger than one (1), for the forged response to reach the @@ -1220,6 +1307,18 @@ INTERNET-DRAFT LLMNR 20 October 2004 queries for which they are authoritative, and LLMNR does not provide wildcard query support, it is believed that this threat is minimal. + + + +Esibov, Aboba & Thaler Standards Track [Page 22] + + + + + +INTERNET-DRAFT LLMNR 19 February 2005 + + There also are scenarios such as public "hotspots" where attackers can be present on the same link. These threats are most serious in wireless networks such as 802.11, since attackers on a wired network @@ -1252,18 +1351,6 @@ INTERNET-DRAFT LLMNR 20 October 2004 be necessary in order to poison the LLMNR cache, since LLMNR queries would be sent even when the DNS server is available. In addition, the LLMNR cache, once poisoned, would take precedence over the DNS - - - -Esibov, Aboba & Thaler Standards Track [Page 21] - - - - - -INTERNET-DRAFT LLMNR 20 October 2004 - - cache, eliminating the benefits of cache separation. As a result, LLMNR is only used as a name resolution mechanism of last resort. @@ -1279,6 +1366,19 @@ INTERNET-DRAFT LLMNR 20 October 2004 LLMNR operates on a separate port from DNS, reducing the likelihood that a DNS server will unintentionally respond to an LLMNR query. + + + + +Esibov, Aboba & Thaler Standards Track [Page 23] + + + + + +INTERNET-DRAFT LLMNR 19 February 2005 + + 5.4. Authentication LLMNR implementations MAY support TSIG and/or SIG(0) security @@ -1307,30 +1407,38 @@ INTERNET-DRAFT LLMNR 20 October 2004 224.0.0.252, as well as link-scope multicast IPv6 address FF02:0:0:0:0:0:1:3. +7. Constants + The following timing constants are used in this protocol; they are + not intended to be user configurable. + DEFEND_INTERVAL 10 seconds (minimum interval between + defensive LLMNR queries). + JITTER_INTERVAL 100 ms + LLMNR_TIMEOUT 1 second (only if set statically) + RTOinit 500 ms (initial value of LLMNR_TIMEOUT) + RTOmax 5 seconds (maximum value of LLMNR_TIMEOUT) + RTOmin 100 ms (minimum value of LLMNR_TIMEOUT) +8. References - - - - -Esibov, Aboba & Thaler Standards Track [Page 22] - - - - - -INTERNET-DRAFT LLMNR 20 October 2004 - - -7. References - -7.1. Normative References +8.1. Normative References [RFC1035] Mockapetris, P., "Domain Names - Implementation and Specification", RFC 1035, November 1987. + + + +Esibov, Aboba & Thaler Standards Track [Page 24] + + + + + +INTERNET-DRAFT LLMNR 19 February 2005 + + [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992. @@ -1368,28 +1476,29 @@ INTERNET-DRAFT LLMNR 20 October 2004 [RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission Timer", RFC 2988, November 2000. -7.2. Informative References +8.2. Informative References [RFC1536] Kumar, A., et. al., "DNS Implementation Errors and Suggested Fixes", RFC 1536, October 1993. - - -Esibov, Aboba & Thaler Standards Track [Page 23] - - - - - -INTERNET-DRAFT LLMNR 20 October 2004 - - [RFC1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness Recommendations for Security", RFC 1750, December 1994. [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997. + + + +Esibov, Aboba & Thaler Standards Track [Page 25] + + + + + +INTERNET-DRAFT LLMNR 19 February 2005 + + [RFC2136] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April 1997. @@ -1432,24 +1541,24 @@ INTERNET-DRAFT LLMNR 20 October 2004 (work in progress), draft-ietf-ipn-gwg-icmp-name- lookups-09.txt, May 2002. - - - -Esibov, Aboba & Thaler Standards Track [Page 24] - - - - - -INTERNET-DRAFT LLMNR 20 October 2004 - - Acknowledgments This work builds upon original work done on multicast DNS by Bill Manning and Bill Woodcock. Bill Manning's work was funded under DARPA grant #F30602-99-1-0523. The authors gratefully acknowledge their contribution to the current specification. Constructive input + + + +Esibov, Aboba & Thaler Standards Track [Page 26] + + + + + +INTERNET-DRAFT LLMNR 19 February 2005 + + has also been received from Mark Andrews, Rob Austein, Randy Bush, Stuart Cheshire, Ralph Droms, Robert Elz, James Gilroy, Olafur Gudmundsson, Andreas Gustafsson, Erik Guttman, Myron Hattig, @@ -1492,24 +1601,24 @@ Intellectual Property Statement has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of - - - -Esibov, Aboba & Thaler Standards Track [Page 25] - - - - - -INTERNET-DRAFT LLMNR 20 October 2004 - - claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. + + + +Esibov, Aboba & Thaler Standards Track [Page 27] + + + + + +INTERNET-DRAFT LLMNR 19 February 2005 + + The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice @@ -1528,7 +1637,7 @@ Disclaimer of Validity Copyright Statement - Copyright (C) The Internet Society (2004). This document is subject + Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. @@ -1555,5 +1664,14 @@ Open Issues -Esibov, Aboba & Thaler Standards Track [Page 26] + + + + + + +Esibov, Aboba & Thaler Standards Track [Page 28] + + + diff --git a/doc/draft/draft-ietf-dnsext-nsec3-00.txt b/doc/draft/draft-ietf-dnsext-nsec3-01.txt similarity index 79% rename from doc/draft/draft-ietf-dnsext-nsec3-00.txt rename to doc/draft/draft-ietf-dnsext-nsec3-01.txt index 2b4ac79ec2..10d8118412 100644 --- a/doc/draft/draft-ietf-dnsext-nsec3-00.txt +++ b/doc/draft/draft-ietf-dnsext-nsec3-01.txt @@ -1,13 +1,15 @@ + Network Working Group B. Laurie Internet-Draft G. Sisson -Expires: July 2, 2005 Nominet +Expires: August 2, 2005 Nominet R. Arends Telematica Instituut - january 2005 + february 2005 + DNSSEC Hash Authenticated Denial of Existence - draft-ietf-dnsext-nsec3-00 + draft-ietf-dnsext-nsec3-01 Status of this Memo @@ -34,7 +36,7 @@ Status of this Memo The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on July 2, 2005. + This Internet-Draft will expire on August 2, 2005. Copyright Notice @@ -48,8 +50,12 @@ Abstract a listing of all ownernames. -Laurie, et al. Expires July 2, 2005 [Page 1] -Internet-Draft nsec3 january 2005 + + +Laurie, et al. Expires August 2, 2005 [Page 1] + +Internet-Draft nsec3 february 2005 + A complete zone file can be used either directly as a source of probable e-mail addresses for spam, or indirectly as a key for @@ -64,28 +70,6 @@ Internet-Draft nsec3 january 2005 names. Non-authoritative delegation point NS RR types may be excluded. - - - - - - - - - - - - - - - - - - - -Laurie, et al. Expires July 2, 2005 [Page 2] -Internet-Draft nsec3 january 2005 - Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 @@ -104,26 +88,35 @@ Table of Contents 2.2 The NSEC3 RR Presentation Format . . . . . . . . . . . . . 8 3. Creating Additional NSEC3 RR for Empty Non Terminals . . . . . 9 4. Calculation of the Hash . . . . . . . . . . . . . . . . . . . 9 - 5. Special Considerations . . . . . . . . . . . . . . . . . . . . 9 - 5.1 delegation points . . . . . . . . . . . . . . . . . . . . 10 - 5.1.1 Unsigned Delegations . . . . . . . . . . . . . . . . . 10 - 5.2 Additional Complexity Caused by Wildcards . . . . . . . . 11 - 5.3 Salting . . . . . . . . . . . . . . . . . . . . . . . . . 11 - 5.4 Hash Collision . . . . . . . . . . . . . . . . . . . . . . 11 - 5.4.1 Avoiding Hash Collisions during generation . . . . . . 11 - 5.4.2 Second Preimage Requirement Analysis . . . . . . . . . 11 - 5.4.3 Possible Hash Value Truncation Method . . . . . . . . 12 - 6. Performance Considerations . . . . . . . . . . . . . . . . . . 12 - 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 - 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 - 9. Requirements notation . . . . . . . . . . . . . . . . . . . . 13 - 10. Security Considerations . . . . . . . . . . . . . . . . . . 13 - A. Example Zone . . . . . . . . . . . . . . . . . . . . . . . . . 13 - 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 - 11.1 Normative References . . . . . . . . . . . . . . . . . . . . 14 - 11.2 Informative References . . . . . . . . . . . . . . . . . . . 15 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 15 - Intellectual Property and Copyright Statements . . . . . . . . 17 + 5. Including NSEC3 RRs in a Zone . . . . . . . . . . . . . . . . 9 + 6. Special Considerations . . . . . . . . . . . . . . . . . . . . 10 + 6.1 delegation points . . . . . . . . . . . . . . . . . . . . 10 + 6.1.1 Unsigned Delegations . . . . . . . . . . . . . . . . . 11 + 6.2 Additional Complexity Caused by Wildcards . . . . . . . . 11 + 6.3 Salting . . . . . . . . . . . . . . . . . . . . . . . . . 12 + 6.4 Hash Collision . . . . . . . . . . . . . . . . . . . . . . 12 + 6.4.1 Avoiding Hash Collisions during generation . . . . . . 12 + 6.4.2 Second Preimage Requirement Analysis . . . . . . . . . 12 + 6.4.3 Possible Hash Value Truncation Method . . . . . . . . 13 + 7. Performance Considerations . . . . . . . . . . . . . . . . . . 13 + 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 + 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 + 10. Requirements notation . . . . . . . . . . . . . . . . . . . 14 + 11. Security Considerations . . . . . . . . . . . . . . . . . . 14 + A. Example Zone . . . . . . . . . . . . . . . . . . . . . . . . . 14 + 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 + + + +Laurie, et al. Expires August 2, 2005 [Page 2] + +Internet-Draft nsec3 february 2005 + + + 12.1 Normative References . . . . . . . . . . . . . . . . . . . . 15 + 12.2 Informative References . . . . . . . . . . . . . . . . . . . 16 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 16 + Intellectual Property and Copyright Statements . . . . . . . . 18 @@ -131,8 +124,50 @@ Table of Contents -Laurie, et al. Expires July 2, 2005 [Page 3] -Internet-Draft nsec3 january 2005 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Laurie, et al. Expires August 2, 2005 [Page 3] + +Internet-Draft nsec3 february 2005 + 1. Introduction @@ -184,10 +219,13 @@ Internet-Draft nsec3 january 2005 ownername. Because this proposal uses the result of a hash function -Laurie, et al. Expires July 2, 2005 [Page 4] -Internet-Draft nsec3 january 2005 - over the original (unmodified) ownername, this result is refered to +Laurie, et al. Expires August 2, 2005 [Page 4] + +Internet-Draft nsec3 february 2005 + + + over the original (unmodified) ownername, this result is referred to as "hashed ownername". 2. The NSEC3 Resource Record @@ -235,8 +273,13 @@ Internet-Draft nsec3 january 2005 -Laurie, et al. Expires July 2, 2005 [Page 5] -Internet-Draft nsec3 january 2005 + + + +Laurie, et al. Expires August 2, 2005 [Page 5] + +Internet-Draft nsec3 february 2005 + 2.1.1 The Authoritative Only Flag Field @@ -258,7 +301,7 @@ Internet-Draft nsec3 january 2005 ownername MUST be set if the NSEC3 covers a delegation, even though the NS RR itself is not authoritative. This implies that all delegations, signed or unsigned, have an NSEC3 record associated. - This behavior is identical to NSEC behavior. + This behaviour is identical to NSEC behaviour. 2.1.2 The Hash Function Field @@ -288,8 +331,11 @@ Internet-Draft nsec3 january 2005 of 0. -Laurie, et al. Expires July 2, 2005 [Page 6] -Internet-Draft nsec3 january 2005 + +Laurie, et al. Expires August 2, 2005 [Page 6] + +Internet-Draft nsec3 february 2005 + The salt field is prepended to the original ownername before hashing in order to defend against precalculated dictionary attacks. @@ -340,8 +386,12 @@ Internet-Draft nsec3 january 2005 Type Bit Map(s) Field = ( Window Block # | Bitmap Length | Bitmap ) + -Laurie, et al. Expires July 2, 2005 [Page 7] -Internet-Draft nsec3 january 2005 + + +Laurie, et al. Expires August 2, 2005 [Page 7] + +Internet-Draft nsec3 february 2005 + Each bitmap encodes the low-order 8 bits of RR types within the window block, in network bit order. The first bit is bit 0. For @@ -373,7 +423,7 @@ Internet-Draft nsec3 january 2005 bitmap is determined by the type code with the largest numerical value, within that block, among the set of RR types present at the NSEC3 RR's actual ownername. Trailing zero octets not specified MUST - be interpretted as zero octets. + be interpreted as zero octets. 2.2 The NSEC3 RR Presentation Format @@ -393,8 +443,11 @@ Internet-Draft nsec3 january 2005 hexadecimal digits. Whitespace is not allowed within the sequence. -Laurie, et al. Expires July 2, 2005 [Page 8] -Internet-Draft nsec3 january 2005 + +Laurie, et al. Expires August 2, 2005 [Page 8] + +Internet-Draft nsec3 february 2005 + The Salt Field is represented as 00 when the Salt Length field has value 0. @@ -409,7 +462,7 @@ Internet-Draft nsec3 january 2005 3. Creating Additional NSEC3 RR for Empty Non Terminals - In order to prove the nonexistence of a record that might be covered + In order to prove the non-existence of a record that might be covered by a wildcard, it is necessary to prove the existence of its closest encloser. A closest encloser might be an Empty Non Terminal. @@ -441,27 +494,82 @@ Internet-Draft nsec3 january 2005 original unexpanded form, including the "*" label (no wildcard substitution); -5. Special Considerations +5. Including NSEC3 RRs in a Zone - The following paragraphs clarify specific behavior explain special + Each owner name in the zone which has authoritative data or a secured -Laurie, et al. Expires July 2, 2005 [Page 9] -Internet-Draft nsec3 january 2005 +Laurie, et al. Expires August 2, 2005 [Page 9] + +Internet-Draft nsec3 february 2005 + + + delegation point NS RRset MUST have an NSEC3 resource record. + + An unsecured delegation point NS RRset MAY have an NSEC3 resource + record. This is different from NSEC records where an unsecured + delegation point NS RRset MUST have an NSEC record. + + The TTL value for any NSEC3 RR SHOULD be the same as the minimum TTL + value field in the zone SOA RR. + + The type bitmap of every NSEC3 resource record in a signed zone MUST + indicate the presence of both the NSEC3 record itself and its + corresponding RRSIG record. + + The bitmap for the NSEC3 RR at a delegation point requires special + attention. Bits corresponding to the delegation NS RRset and any + RRsets for which the parent zone has authoritative data MUST be set; + bits corresponding to any non-NS RRset for which the parent is not + authoritative MUST be clear. + + The following steps describe the proper construction of NSEC3 + records. + 1. Sort the zone in canonical order. + 2. For each unique original owner name, add a NSEC3 RRset, where the + ownername of the NSEC3 RR is the hashed equivalent of the + original owner name, prepended to the zone name. + 3. For each RRset at the original owner, set the corresponding bit + in the type bit map. If the RRset signifies an unsecured + delegation point, and the policy is to have Authoritative Only + RRsets, mark this NSEC3 RR. + 4. If the difference in labels between the apex and the original + ownername is greater then 1, additional NSEC3 need to be added + for every intermediate label level between the apex and the + original ownername. + 5. sort the set of NSEC3 RRs. + 6. In each NSEC3 RR, insert the Next Hashed Ownername. If the next + hashed ownername is a marked NSEC3 (from step 3), delete the + marked NSEC3 from the zone, set the Authoritative Only bit in the + current NSEC3 RRs, and repeat this step. The last NSEC3 in the + zone will contain the value of the first NSEC3 in the zone. + +6. Special Considerations + + The following paragraphs clarify specific behaviour explain special considerations for implementations. -5.1 delegation points +6.1 delegation points This proposal introduces the Authoritative Only Flag which indicates + + + +Laurie, et al. Expires August 2, 2005 [Page 10] + +Internet-Draft nsec3 february 2005 + + whether non authoritative delegation point NS records are included in the type bit Maps. As discussed in paragraph 2.1.1, a flag value of 0 indicates that the interpretation of the type bit maps is identical to NSEC records. - The following subsections describe behavior when the flag value is 1. + The following subsections describe behaviour when the flag value is + 1. -5.1.1 Unsigned Delegations +6.1.1 Unsigned Delegations Delegation point NS records are not authoritative. They are authoritative in the delegated zone. No other data exists at the @@ -498,13 +606,17 @@ Internet-Draft nsec3 january 2005 The only possible mitigation is to either not use this method, hence proving absence of unsigned delegations. - -Laurie, et al. Expires July 2, 2005 [Page 10] -Internet-Draft nsec3 january 2005 - -5.2 Additional Complexity Caused by Wildcards +6.2 Additional Complexity Caused by Wildcards If a wildcard ownername appears in a zone, the wildcard label ("*") + + + +Laurie, et al. Expires August 2, 2005 [Page 11] + +Internet-Draft nsec3 february 2005 + + is treated as a literal symbol and is treated in the same way as any other ownername for purposes of generating NSEC3 RRs. RFC 2535 [RFC2525] describes the impact of wildcards on authenticated denial @@ -512,10 +624,10 @@ Internet-Draft nsec3 january 2005 In order to prove there are no wildcards for a domain, as well as no RRs that match directly, an RR must be shown for the closest - encloser, and nonexistence must be shown for all enclosers that could - be closer. + encloser, and non-existence must be shown for all enclosers that + could be closer. -5.3 Salting +6.3 Salting Augmenting original ownernames with salt before hashing increases the cost of a dictionary of pre-generated hash-values. For every bit of @@ -525,7 +637,7 @@ Internet-Draft nsec3 january 2005 The salt value for each NSEC3 RR MUST be equal for a single version of the zone. -5.4 Hash Collision +6.4 Hash Collision Hash collisions occur when different messages have the same hash value. The expected number of domain names needed to give a 1 in 2 @@ -534,30 +646,33 @@ Internet-Draft nsec3 january 2005 collisions and assessing possible damage in the event of an attack using Hash collisions. -5.4.1 Avoiding Hash Collisions during generation +6.4.1 Avoiding Hash Collisions during generation During generation of NSEC3 RRs, hash values are supposedly unique. - In the (academic) case of a collision occuring, an alternative salt + In the (academic) case of a collision occurring, an alternative salt SHOULD be chosen and all hash values SHOULD be regenerated. If hash values are not regenerated on collision, the NSEC3 RR MUST list all authoritative RR types that exist for both owners, to avoid a replay attack, spoofing an existing type as non-existent. -5.4.2 Second Preimage Requirement Analysis +6.4.2 Second Preimage Requirement Analysis A collision resistant hash function has a second-preimage resistance property. The second-preimage resistance property means that it is computationally infeasible to find another message with the same hash value as a given message, i.e. given preimage X, to find a second - - -Laurie, et al. Expires July 2, 2005 [Page 11] -Internet-Draft nsec3 january 2005 - preimage X' <> X such that hash(X) = hash(X'). The probability of finding a second preimage is 1 in 2^160 for SHA-1 on average. To mount an attack using an existing NSEC3 RR, an adversary needs to + + + +Laurie, et al. Expires August 2, 2005 [Page 12] + +Internet-Draft nsec3 february 2005 + + find a second preimage. Assuming an adversary is capable of mounting such an extreme attack, @@ -569,7 +684,7 @@ Internet-Draft nsec3 january 2005 adversary can't mount this attack on an existing name but only on a name that the adversary can't choose and does not yet exist. -5.4.3 Possible Hash Value Truncation Method +6.4.3 Possible Hash Value Truncation Method The previous sections outlined the low probability and low impact of a second-preimage attack. When impact and probability are low, while @@ -593,25 +708,28 @@ Internet-Draft nsec3 january 2005 and limited space in DNS messages, the balance between truncation profit and collision damage may be determined by local policy. -6. Performance Considerations +7. Performance Considerations Iterated hashes will obviously impose a performance penalty on both authoritative servers and resolvers. Therefore, the number of iterations should be carefully chosen. -7. IANA Considerations +8. IANA Considerations IANA has to create a new registry for NSEC3 Hash Functions. The range for this registry is 0-127. Value 1 is marked as SHA-1. - - -Laurie, et al. Expires July 2, 2005 [Page 12] -Internet-Draft nsec3 january 2005 - Values 0, 2-126 are marked as Reserved For Future Use. Value 127 is marked as Experimental. -8. Security Considerations + + + +Laurie, et al. Expires August 2, 2005 [Page 13] + +Internet-Draft nsec3 february 2005 + + +9. Security Considerations The NSEC3 records are still susceptible to dictionary attacks (i.e. the attacker retrieves all the NSEC3 records, then calculates the @@ -635,17 +753,17 @@ Internet-Draft nsec3 january 2005 found. Hash collisions may occur. If they do, it will be impossible to - prove the nonexistence of the colliding domain - however, this is + prove the non-existence of the colliding domain - however, this is fantastically unlikely, and, in any case, DNSSEC already relies on SHA-1 to not collide. -9. Requirements notation +10. Requirements notation 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]. -10. Security Considerations +11. Security Considerations Appendix A. Example Zone @@ -655,48 +773,58 @@ Appendix A. Example Zone -Laurie, et al. Expires July 2, 2005 [Page 13] -Internet-Draft nsec3 january 2005 - example.com. 1000 IN SOA localhost. - postmaster.localhost.example.com. ( - 1 ; serial - 3600 ; refresh (1 hour) - 1800 ; retry (30 minutes) - 604800 ; expire (1 week) - 3600 ; minimum (1 hour) - ) - 1000 NS ns1.example.com. - 1000 NS ns2.example.com. + + + + + + +Laurie, et al. Expires August 2, 2005 [Page 14] + +Internet-Draft nsec3 february 2005 + + + example.com. 1000 IN SOA localhost. + postmaster.localhost.example.com. ( + 1 ; serial + 3600 ; refresh (1 hour) + 1800 ; retry (30 minutes) + 604800 ; expire (1 week) + 3600 ; minimum (1 hour) + ) + 1000 NS ns1.example.com. + 1000 NS ns2.example.com. f519593e82969842a136e0f47814c881fa163833.example.com. 3600 IN NSEC3 \ SHA-1 200 31323334 4EF8239D95C18403A509D7C336A5D0FA48FD1107 \ NS SOA RRSIG DNSKEY NSEC3 - a.example.com. 1000 IN A 1.2.3.4 - 1000 IN A 1.2.3.5 - 1000 TXT "An example" + a.example.com. 1000 IN A 1.2.3.4 + 1000 IN A 1.2.3.5 + 1000 TXT "An example" bfe6ea21dee9d228889ae11fa58c4bd551d15801.example.com. 3600 IN NSEC3 \ SHA-1 200 31323334 F519593E82969842A136E0F47814C881FA163833 \ A TXT RRSIG NSEC3 - b.example.com. 1000 IN A 1.2.3.7 + b.example.com. 1000 IN A 1.2.3.7 83c06d3b7d01fbc9576c71af2bec1a1163435153.example.com. 3600 IN NSEC3 \ SHA-1 200 31323334 A33559360EECB02F36B5C1B72C109126CA4F5A0D \ A RRSIG NSEC3 - a.b.c.example.com. 1000 IN A 1.2.3.6 + a.b.c.example.com. 1000 IN A 1.2.3.6 a33559360eecb02f36b5c1b72c109126ca4f5a0d.example.com. 3600 IN NSEC3 \ SHA-1 200 31323334 BFE6EA21DEE9D228889AE11FA58C4BD551D15801 \ A RRSIG NSEC3 - ns1.example.com. 1000 IN A 1.2.3.8 + ns1.example.com. 1000 IN A 1.2.3.8 4ef8239d95c18403a509d7c336a5d0fa48fd1107.example.com. 3600 IN NSEC3 \ SHA-1 200 31323334 50016B56FD2F0FFC7B563C50FAF0E34259763BBB \ A RRSIG NSEC3 - ns2.example.com. 1000 IN A 1.2.3.9 + ns2.example.com. 1000 IN A 1.2.3.9 50016b56fd2f0ffc7b563c50faf0e34259763bbb.example.com. 3600 IN NSEC3 \ SHA-1 200 31323334 83C06D3B7D01FBC9576C71AF2BEC1A1163435153 \ A RRSIG NSEC3 -11. References -11.1 Normative References +12. References + +12.1 Normative References [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987. @@ -707,8 +835,11 @@ Internet-Draft nsec3 january 2005 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate -Laurie, et al. Expires July 2, 2005 [Page 14] -Internet-Draft nsec3 january 2005 + +Laurie, et al. Expires August 2, 2005 [Page 15] + +Internet-Draft nsec3 february 2005 + Requirement Levels", BCP 14, RFC 2119, March 1997. @@ -725,7 +856,7 @@ Internet-Draft nsec3 january 2005 [RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC 2535, March 1999. -11.2 Informative References +12.2 Informative References [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. @@ -738,6 +869,7 @@ Internet-Draft nsec3 january 2005 Rollover Algorithm and a Out-Of-Band Priming Method for DNS Trust Anchors.", July 2004. + Authors' Addresses Ben Laurie @@ -749,14 +881,21 @@ Authors' Addresses Phone: +44 (20) 8735 0686 EMail: ben@algroup.co.uk + Geoffrey Sisson Nominet -Laurie, et al. Expires July 2, 2005 [Page 15] -Internet-Draft nsec3 january 2005 + + + + +Laurie, et al. Expires August 2, 2005 [Page 16] + +Internet-Draft nsec3 february 2005 + Roy Arends Telematica Instituut @@ -788,8 +927,31 @@ Internet-Draft nsec3 january 2005 -Laurie, et al. Expires July 2, 2005 [Page 16] -Internet-Draft nsec3 january 2005 + + + + + + + + + + + + + + + + + + + + + +Laurie, et al. Expires August 2, 2005 [Page 17] + +Internet-Draft nsec3 february 2005 + Intellectual Property Statement @@ -815,6 +977,7 @@ Intellectual Property Statement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. + Disclaimer of Validity This document and the information contained herein are provided on an @@ -825,16 +988,22 @@ Disclaimer of Validity INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. + Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. -Laurie, et al. Expires July 2, 2005 [Page 17] + + +Laurie, et al. Expires August 2, 2005 [Page 18] + + diff --git a/doc/draft/draft-ietf-dnsext-rfc2538bis-00.txt b/doc/draft/draft-ietf-dnsext-rfc2538bis-01.txt similarity index 87% rename from doc/draft/draft-ietf-dnsext-rfc2538bis-00.txt rename to doc/draft/draft-ietf-dnsext-rfc2538bis-01.txt index 8cd32e316b..0d0451ace1 100644 --- a/doc/draft/draft-ietf-dnsext-rfc2538bis-00.txt +++ b/doc/draft/draft-ietf-dnsext-rfc2538bis-01.txt @@ -1,11 +1,12 @@ + Network Working Group S. Josefsson -Internet-Draft January 24, 2005 -Expires: July 25, 2005 +Internet-Draft January 2005 +Expires: July 2, 2005 Storing Certificates in the Domain Name System (DNS) - draft-ietf-dnsext-rfc2538bis-00 + draft-ietf-dnsext-rfc2538bis-01 Status of this Memo @@ -32,7 +33,7 @@ Status of this Memo The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on July 25, 2005. + This Internet-Draft will expire on July 2, 2005. Copyright Notice @@ -51,7 +52,7 @@ Abstract -Josefsson Expires July 25, 2005 [Page 1] +Josefsson Expires July 2, 2005 [Page 1] Internet-Draft Storing Certificates in the DNS January 2005 @@ -62,23 +63,24 @@ Table of Contents 2. The CERT Resource Record . . . . . . . . . . . . . . . . . . . 3 2.1 Certificate Type Values . . . . . . . . . . . . . . . . . 4 2.2 Text Representation of CERT RRs . . . . . . . . . . . . . 5 - 2.3 X.509 OIDs . . . . . . . . . . . . . . . . . . . . . . . . 5 + 2.3 X.509 OIDs . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Appropriate Owner Names for CERT RRs . . . . . . . . . . . . . 6 3.1 Content-based X.509 CERT RR Names . . . . . . . . . . . . 7 3.2 Purpose-based X.509 CERT RR Names . . . . . . . . . . . . 8 3.3 Content-based OpenPGP CERT RR Names . . . . . . . . . . . 8 3.4 Purpose-based OpenPGP CERT RR Names . . . . . . . . . . . 9 + 3.5 Owner names for IPKIX, ISPKI, and IPGP . . . . . . . . . . 9 4. Performance Considerations . . . . . . . . . . . . . . . . . . 9 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 - 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 + 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 8. Changes since RFC 2538 . . . . . . . . . . . . . . . . . . . . 11 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 12 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 9.1 Normative References . . . . . . . . . . . . . . . . . . . . 11 9.2 Informative References . . . . . . . . . . . . . . . . . . . 12 A. Copying conditions . . . . . . . . . . . . . . . . . . . . . . 12 - Intellectual Property and Copyright Statements . . . . . . . . 13 + Intellectual Property and Copyright Statements . . . . . . . . 14 @@ -106,8 +108,7 @@ Table of Contents - -Josefsson Expires July 25, 2005 [Page 2] +Josefsson Expires July 2, 2005 [Page 2] Internet-Draft Storing Certificates in the DNS January 2005 @@ -163,7 +164,7 @@ Internet-Draft Storing Certificates in the DNS January 2005 -Josefsson Expires July 25, 2005 [Page 3] +Josefsson Expires July 2, 2005 [Page 3] Internet-Draft Storing Certificates in the DNS January 2005 @@ -190,7 +191,10 @@ Internet-Draft Storing Certificates in the DNS January 2005 1 PKIX X.509 as per PKIX 2 SPKI SPKI certificate 3 PGP OpenPGP packet - 4-252 available for IANA assignment + 4 IPKIX The URL of an X.509 data object + 5 ISPKI The URL of an SPKI certificate + 6 IPGP The URL of an OpenPGP packet + 7-252 available for IANA assignment 253 URI URI private 254 OID OID private 255-65534 available for IANA assignment @@ -213,17 +217,25 @@ Internet-Draft Storing Certificates in the DNS January 2005 transferable public keys as described in section 10.1 of [5], but it MAY handle additional OpenPGP packets. - The URI private type indicates a certificate format defined by an - absolute URI. The certificate portion of the CERT RR MUST begin with - a null terminated URI [4] and the data after the null is the private -Josefsson Expires July 25, 2005 [Page 4] +Josefsson Expires July 2, 2005 [Page 4] Internet-Draft Storing Certificates in the DNS January 2005 + The IPKIX, ISPKI and IPGP types indicate a URL which will serve the + content that would have been in the "certificate, CRL or URL" field + of the corresponding (PKIX, SPKI or PGP) packet types. These types + are known as "indirect". These packet types MUST be used when the + content is too large to fit in the CERT RR, and MAY be used at the + implementations discretion. They SHOULD NOT be used where the entire + UDP packet would have fit in 512 bytes. + + The URI private type indicates a certificate format defined by an + absolute URI. The certificate portion of the CERT RR MUST begin with + a null terminated URI [4] and the data after the null is the private format certificate itself. The URI SHOULD be such that a retrieval from it will lead to documentation on the format of the certificate. Recognition of private certificate types need not be based on URI @@ -261,6 +273,14 @@ Internet-Draft Storing Certificates in the DNS January 2005 Note that the certificate / CRL portion may have internal sub-fields but these do not appear in the master file representation. For example, with type 254, there will be an OID size, an OID, and then + + + +Josefsson Expires July 2, 2005 [Page 5] + +Internet-Draft Storing Certificates in the DNS January 2005 + + the certificate / CRL proper. But only a single logical base 64 string will appear in the text representation. @@ -272,14 +292,6 @@ Internet-Draft Storing Certificates in the DNS January 2005 The following table lists the OIDs, their BER encoding, and their length prefixed hex format for use in CERT RRs: - - - -Josefsson Expires July 25, 2005 [Page 5] - -Internet-Draft Storing Certificates in the DNS January 2005 - - id-at-userCertificate = { joint-iso-ccitt(2) ds(5) at(4) 36 } == 0x 03 55 04 24 @@ -315,8 +327,16 @@ Internet-Draft Storing Certificates in the DNS January 2005 key. Further, the client might only know the hostname of a service that uses X.509 certificates or the Key ID of an OpenPGP key. - This motivate describing two different owner name guidelines. We + This motivates describing two different owner name guidelines. We call the two rules content-based owner names and purpose-based owner + + + +Josefsson Expires July 2, 2005 [Page 6] + +Internet-Draft Storing Certificates in the DNS January 2005 + + names. A content-based owner name is derived from the content of the CERT RR data; for example the Subject field in an X.509 certificate or the User ID field in OpenPGP keys. A purpose-based owner name is @@ -328,14 +348,6 @@ Internet-Draft Storing Certificates in the DNS January 2005 incoming e-mail. Implementations SHOULD use the purpose-based owner name guidelines - - - -Josefsson Expires July 25, 2005 [Page 6] - -Internet-Draft Storing Certificates in the DNS January 2005 - - described in this document, and MAY use CNAMEs at content-based owner names (or other names), pointing to the purpose-based owner name. @@ -368,11 +380,19 @@ Internet-Draft Storing Certificates in the DNS January 2005 3. If neither of the above it used but a URI containing a domain name is present, that domain name should be used. 4. If none of the above is included but a character string name is - included, then it should be treated as described for PGP names - below. + included, then it should be treated as described for OpenPGP + names below. 5. If none of the above apply, then the distinguished name (DN) should be mapped into a domain name as specified in [3]. + + + +Josefsson Expires July 2, 2005 [Page 7] + +Internet-Draft Storing Certificates in the DNS January 2005 + + Example 1: Assume that an X.509v3 certificate is issued to /CN=John Doe/DC=Doe/DC=com/DC=xy/O=Doe Inc/C=XY/ with Subject Alternative names of (a) string "John (the Man) Doe", (b) domain name john- @@ -384,14 +404,6 @@ Internet-Draft Storing Certificates in the DNS January 2005 Example 2: Assume that an X.509v3 certificate is issued to /CN=James Hacker/L=Basingstoke/O=Widget Inc/C=GB/ with Subject Alternate names - - - -Josefsson Expires July 25, 2005 [Page 7] - -Internet-Draft Storing Certificates in the DNS January 2005 - - of (a) domain name widget.foo.example, (b) IPv4 address 10.251.13.201, and (c) string "James Hacker ". Then the storage locations @@ -424,12 +436,19 @@ Internet-Draft Storing Certificates in the DNS January 2005 IPSEC Certificate Hostname of the IPSEC machine, and/or for the in-addr.arpa reverse lookup IP address. - CRLs Hostname of the issuing CA. - + An alternative approach for IPSEC is to store raw public keys [12]. 3.3 Content-based OpenPGP CERT RR Names OpenPGP signed keys (certificates) use a general character string + + + +Josefsson Expires July 2, 2005 [Page 8] + +Internet-Draft Storing Certificates in the DNS January 2005 + + User ID [5]. However, it is recommended by OpenPGP that such names include the RFC 2822 [7] email address of the party, as in "Leslie Example ". If such a format is used, the CERT @@ -441,13 +460,6 @@ Internet-Draft Storing Certificates in the DNS January 2005 If a user has more than one email address, the CNAME type can be used to reduce the amount of data stored in the DNS. For example: - - -Josefsson Expires July 25, 2005 [Page 8] - -Internet-Draft Storing Certificates in the DNS January 2005 - - $ORIGIN example.org. smith IN CERT PGP 0 0 john.smith IN CNAME smith @@ -456,15 +468,15 @@ Internet-Draft Storing Certificates in the DNS January 2005 3.4 Purpose-based OpenPGP CERT RR Names - Applications that receive an OpenPGP packet but do not know the email - address of the sender will have difficulties constructing the correct - owner name, and cannot use the content-based owner name guidelines. - However, these clients commonly know the key fingerprint or the Key - ID. The key ID is found in OpenPGP packets, and the key fingerprint - is commonly found in auxilliary data that may be available. For - these situations, it is recommended to use an owner name identical to - the key fingerprint and key ID expressed in hexadecimal [11]. For - example: + Applications that receive an OpenPGP packet containing encrypted or + signed data but do not know the email address of the sender will have + difficulties constructing the correct owner name and cannot use the + content-based owner name guidelines. However, these clients commonly + know the key fingerprint or the Key ID. The key ID is found in + OpenPGP packets, and the key fingerprint is commonly found in + auxilliary data that may be available. For these situations, it is + recommended to use an owner name identical to the key fingerprint and + key ID expressed in hexadecimal [11]. For example: $ORIGIN example.org. 0424D4EE81A0E3D119C6F835EDA21E94B565716F IN CERT PGP ... @@ -477,9 +489,22 @@ Internet-Draft Storing Certificates in the DNS January 2005 purposes, and this may be sub-optimal when two keys with the same Key ID are stored. +3.5 Owner names for IPKIX, ISPKI, and IPGP + + These types are stored under the same owner names, both purpose- and + content-based, as the PKIX, SPKI and PGP types, respectively. + 4. Performance Considerations Current Domain Name System (DNS) implementations are optimized for + + + +Josefsson Expires July 2, 2005 [Page 9] + +Internet-Draft Storing Certificates in the DNS January 2005 + + small transfers, typically not more than 512 bytes including overhead. While larger transfers will perform correctly and work is underway to make larger transfers more efficient, it is still @@ -493,16 +518,7 @@ Internet-Draft Storing Certificates in the DNS January 2005 octets (64kb) or less. This means that each CERT RR cannot contain more than 64kb worth of payload, even if the corresponding certificate or certificate revocation list is larger. This document - do not address this limitation. - - - - - -Josefsson Expires July 25, 2005 [Page 9] - -Internet-Draft Storing Certificates in the DNS January 2005 - + address this by defining "indirect" data types for each normal type. 5. Acknowledgements @@ -513,10 +529,9 @@ Internet-Draft Storing Certificates in the DNS January 2005 contributions to the earlier work that motivated this revised document. - Florian Weimer suggested to clarify wording regarding what data can - be stored in RRDATA portion of OpenPGP CERT RRs, and that the URI - type may include hashes to secure the indirection. Olivier Dubuisson - confirmed that the X.509 OID were indeed correct. + This document was improved by suggestions and comments from Olivier + Dubuisson, Ben Laurie, Samuel Weiler, and Florian Weimer. No doubt + the list is incomplete. We apologize to anyone we left out. 6. Security Considerations @@ -533,33 +548,36 @@ Internet-Draft Storing Certificates in the DNS January 2005 verifying the certificate chain if this conforms with the user's security policy. - When the URI type is used, it should be understood that is introduce + When the URI type is used, it should be understood that it introduces an additional indirection that may allow for a new attack vector. One method to secure that indirection is to include a hash of the certificate in the URI itself. - CERT RRs are not used in connection with securing the DNS security - additions so there are no security considerations related to CERT RRs - and securing the DNS itself. + + + +Josefsson Expires July 2, 2005 [Page 10] + +Internet-Draft Storing Certificates in the DNS January 2005 + + + CERT RRs are not used by DNSSEC [8] so there are no security + considerations related to CERT RRs and securing the DNS itself. + + If DNSSEC [8] is used then the non-existence of a CERT RR, and + consequently certificates or revocation lists, can be securely + asserted. Without DNSSEC, this is not possible. 7. IANA Considerations Certificate types 0x0000 through 0x00FF and 0xFF00 through 0xFFFF can only be assigned by an IETF standards action [6]. This document - assigns 0x0001 through 0x0003 and 0x00FD and 0x00FE. Certificate + assigns 0x0001 through 0x0006 and 0x00FD and 0x00FE. Certificate types 0x0100 through 0xFEFF are assigned through IETF Consensus [6] based on RFC documentation of the certificate type. The availability of private types under 0x00FD and 0x00FE should satisfy most requirements for proprietary or private types. - - - -Josefsson Expires July 25, 2005 [Page 10] - -Internet-Draft Storing Certificates in the DNS January 2005 - - 8. Changes since RFC 2538 1. Editorial changes to conform with new document requirements, @@ -582,6 +600,7 @@ Internet-Draft Storing Certificates in the DNS January 2005 for purpose-based X.509 CERT owner names, and section 3.4 for purpose-based OpenPGP CERT owner names. 8. Added size considerations. + 9. Added indirect types IPKIX, ISPKI, and IPGP. 9. References @@ -590,6 +609,14 @@ Internet-Draft Storing Certificates in the DNS January 2005 [1] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987. + + + +Josefsson Expires July 2, 2005 [Page 11] + +Internet-Draft Storing Certificates in the DNS January 2005 + + [2] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. @@ -608,14 +635,6 @@ Internet-Draft Storing Certificates in the DNS January 2005 [7] Resnick, P., "Internet Message Format", RFC 2822, April 2001. - - - -Josefsson Expires July 25, 2005 [Page 11] - -Internet-Draft Storing Certificates in the DNS January 2005 - - [8] Arends, R., Austein, R., Massey, D., Larson, M. and S. Rose, "DNS Security Introduction and Requirements", draft-ietf-dnsext-dnssec-intro-13 (work in progress), October @@ -633,6 +652,9 @@ Internet-Draft Storing Certificates in the DNS January 2005 [11] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 3548, July 2003. + [12] Richardson, M., "A method for storing IPsec keying material in + DNS", draft-ietf-ipseckey-rr-11 (work in progress), July 2004. + Author's Address @@ -643,6 +665,14 @@ Author's Address Appendix A. Copying conditions Regarding the portion of this document that was written by Simon + + + +Josefsson Expires July 2, 2005 [Page 12] + +Internet-Draft Storing Certificates in the DNS January 2005 + + Josefsson ("the author", for the remainder of this section), the author makes no guarantees and is not responsible for any damage resulting from its use. The author grants irrevocable permission to @@ -667,7 +697,34 @@ Appendix A. Copying conditions -Josefsson Expires July 25, 2005 [Page 12] + + + + + + + + + + + + + + + + + + + + + + + + + + + +Josefsson Expires July 2, 2005 [Page 13] Internet-Draft Storing Certificates in the DNS January 2005 @@ -723,6 +780,6 @@ Acknowledgment -Josefsson Expires July 25, 2005 [Page 13] +Josefsson Expires July 2, 2005 [Page 14] diff --git a/doc/draft/draft-ietf-dnsext-trustupdate-timers-00.txt b/doc/draft/draft-ietf-dnsext-trustupdate-timers-00.txt new file mode 100644 index 0000000000..32460b89b4 --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-trustupdate-timers-00.txt @@ -0,0 +1,729 @@ + + +Network Working Group M. StJohns +Internet-Draft Nominum, Inc. +Expires: April 14, 2005 October 14, 2004 + + + Automated Updates of DNSSEC Trust Anchors + draft-ietf-dnsext-trustupdate-timers-00 + +Status of this Memo + + This document is an Internet-Draft and is subject to all provisions + of section 3 of RFC 3667. By submitting this Internet-Draft, each + author represents that any applicable patent or other IPR claims of + which he or she is aware have been or will be disclosed, and any of + which he or she become aware will be disclosed, in accordance with + RFC 3668. + + 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 April 14, 2005. + +Copyright Notice + + Copyright (C) The Internet Society (2004). + +Abstract + + This document describes a means for automated, authenticated and + authorized updating of DNSSEC "trust anchors". The method provides + protection against single key compromise of a key in the trust point + key set. Based on the trust established by the presence of a current + anchor, other anchors may be added at the same place in the + hierarchy, and, ultimately, supplant the existing anchor. + + This mechanism, if adopted, will require changes to resolver + + + +StJohns Expires April 14, 2005 [Page 1] + +Internet-Draft trustanchor-update October 2004 + + + management behavior (but not resolver resolution behavior), and the + addition of a single flag bit to the DNSKEY record. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.1 Compliance Nomenclature . . . . . . . . . . . . . . . . . 3 + 1.2 Changes since -00 . . . . . . . . . . . . . . . . . . . . 3 + 2. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 4 + 2.1 Revocation . . . . . . . . . . . . . . . . . . . . . . . . 4 + 2.2 Add Hold-Down . . . . . . . . . . . . . . . . . . . . . . 5 + 2.3 Remove Hold-down . . . . . . . . . . . . . . . . . . . . . 5 + 2.4 Active Refresh . . . . . . . . . . . . . . . . . . . . . . 6 + 2.5 Resolver Parameters . . . . . . . . . . . . . . . . . . . 6 + 2.5.1 Add Hold-Down Time . . . . . . . . . . . . . . . . . . 6 + 2.5.2 Remove Hold-Down Time . . . . . . . . . . . . . . . . 6 + 2.5.3 Minimum Trust Anchors per Trust Point . . . . . . . . 6 + 3. Changes to DNSKEY RDATA Wire Format . . . . . . . . . . . . . 6 + 4. State Table . . . . . . . . . . . . . . . . . . . . . . . . . 6 + 4.1 Events . . . . . . . . . . . . . . . . . . . . . . . . . . 7 + 4.2 States . . . . . . . . . . . . . . . . . . . . . . . . . . 7 + 5. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 8 + 5.1 Adding A Trust Anchor . . . . . . . . . . . . . . . . . . 8 + 5.2 Deleting a Trust Anchor . . . . . . . . . . . . . . . . . 9 + 5.3 Key Roll-Over . . . . . . . . . . . . . . . . . . . . . . 9 + 5.4 Active Key Compromised . . . . . . . . . . . . . . . . . . 9 + 5.5 Stand-by Key Compromised . . . . . . . . . . . . . . . . . 9 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 + 6.1 Key Ownership vs Acceptance Policy . . . . . . . . . . . . 10 + 6.2 Multiple Key Compromise . . . . . . . . . . . . . . . . . 10 + 6.3 Dynamic Updates . . . . . . . . . . . . . . . . . . . . . 10 + 7. Normative References . . . . . . . . . . . . . . . . . . . . . 10 + Editorial Comments . . . . . . . . . . . . . . . . . . . . . . 11 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . 11 + Intellectual Property and Copyright Statements . . . . . . . . 12 + + + + + + + + + + + + + + + + +StJohns Expires April 14, 2005 [Page 2] + +Internet-Draft trustanchor-update October 2004 + + +1. Introduction + + As part of the reality of fielding DNSSEC (Domain Name System + Security Extensions) [RFC2535][DSINTRO][DSPROT][DSREC], the community + has come to the realization that there will not be one signed name + space, but rather islands of signed name space each originating from + specific points (i.e. 'trust points') in the DNS tree. Each of + those islands will be identified by the trust point name, and + validated by at least one associated public key. For the purpose of + this document we'll call the association of that name and a + particular key a 'trust anchor'. A particular trust point can have + more than one key designated as a trust anchor. + + For a DNSSEC-aware resolver to validate information in a DNSSEC + protected branch of the hierarchy, it must have knowledge of a trust + anchor applicable to that branch. It may also have more than one + trust anchor for any given trust point. Under current rules, a chain + of trust for DNSSEC-protected data that chains its way back to ANY + known trust anchor is considered 'secure'. + + Because of the probable balkanization of the DNSSEC tree due to + signing voids at key locations, a resolver may need to know literally + thousands of trust anchors to perform its duties. (e.g. Consider an + unsigned ".COM".) Requiring the owner of the resolver to manually + manage this many relationships is problematic. It's even more + problematic when considering the eventual requirement for key + replacement/update for a given trust anchor. The mechanism described + herein won't help with the initial configuration of the trust anchors + in the resolvers, but should make trust point key + replacement/rollover more viable. + + As mentioned above, this document describes a mechanism whereby a + resolver can update the trust anchors for a given trust point, mainly + without human intervention at the resolver. There are some corner + cases discussed (e.g. multiple key compromise) that may require + manual intervention, but they should be few and far between. This + document DOES NOT discuss the general problem of the initial + configuration of trust anchors for the resolver. + +1.1 Compliance Nomenclature + + 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, [RFC2119]. + +1.2 Changes since -00 + + Resubmitted draft-stjohns-dnssec-trustupdate as a working group + + + +StJohns Expires April 14, 2005 [Page 3] + +Internet-Draft trustanchor-update October 2004 + + + draft. + + Added the concept of timer triggered resolver queries to refresh the + resolvers view of the trust anchor key RRSet. + +2. Theory of Operation + + The general concept of this mechanism is that existing trust anchors + can be used to authenticate new trust anchors at the same point in + the DNS hierarchy. When a new SEP key is added to a trust point + DNSKEY RRSet, and when that RRSet is validated by an existing trust + anchor, then the new key can be added to the set of trust anchors. + + There are some issues with this approach which need to be mitigated. + For example, a compromise of one of the existing keys could allow an + attacker to add their own 'valid' data. This implies a need for a + method to revoke an existing key regardless of whether or not that + key is compromised. As another example assuming a single key + compromise, an attacker could add a new key and revoke all the other + old keys. + +2.1 Revocation + + Assume two trust anchor keys A and B. Assume that B has been + compromised. Without a specific revocation bit, B could invalidate A + simply by sending out a signed trust point key set which didn't + contain A. To fix this, we add a mechanism which requires knowledge + of the private key of a DNSKEY to revoke that DNSKEY. + + A key is considered revoked when the resolver sees the key in a + self-signed RRSet and the key has the REVOKE bit set to '1'. Once + the resolver sees the REVOKE bit, it MUST NOT use this key as a trust + anchor or for any other purposes except validating the RRSIG over the + DNSKEY RRSet specifically for the purpose of validating the + revocation. Unlike the 'Add' operation below, revocation is + immediate and permanent upon receipt of a valid revocation at the + resolver. + + N.B. A DNSKEY with the REVOKE bit set has a different fingerprint + than one without the bit set. This affects the matching of a DNSKEY + to DS records in the parent, or the fingerprint stored at a resolver + used to configure a trust point. [msj3] + + In the given example, the attacker could revoke B because it has + knowledge of B's private key, but could not revoke A. + + + + + + +StJohns Expires April 14, 2005 [Page 4] + +Internet-Draft trustanchor-update October 2004 + + +2.2 Add Hold-Down + + Assume two trust point keys A and B. Assume that B has been + compromised. An attacker could generate and add a new trust anchor + key - C (by adding C to the DNSKEY RRSet and signing it with B), and + then invalidate the compromised key. This would result in the both + the attacker and owner being able to sign data in the zone and have + it accepted as valid by resolvers. + + To mitigate, but not completely solve, this problem, we add a + hold-down time to the addition of the trust anchor. When the + resolver sees a new SEP key in a validated trust point DNSKEY RRSet, + the resolver starts an acceptance timer, and remembers all the keys + that validated the RRSet. If the resolver ever sees the DNSKEY RRSet + without the new key but validly signed, it stops the acceptance + process and resets the acceptance timer. If all of the keys which + were originally used to validate this key are revoked prior to the + timer expiring, the resolver stops the acceptance process and resets + the timer. + + Once the timer expires, the new key will be added as a trust anchor + the next time the validated RRSet with the new key is seen at the + resolver. The resolver MUST NOT treat the new key as a trust anchor + until the hold down time expires AND it has retrieved and validated a + DNSKEY RRSet after the hold down time which contains the new key. + + N.B.: Once the resolver has accepted a key as a trust anchor, the key + MUST be considered a valid trust anchor by that resolver until + explictly revoked as described above. + + In the given example, the zone owner can recover from a compromise by + revoking B and adding a new key D and signing the DNSKEY RRSet with + both A and B. + + The reason this does not completely solve the problem has to do with + the distributed nature of DNS. The resolver only knows what it sees. + A determined attacker who holds one compromised key could keep a + single resolver from realizing that key had been compromised by + intercepting 'real' data from the originating zone and substituting + their own (e.g. using the example, signed only by B). This is no + worse than the current situation assuming a compromised key. + +2.3 Remove Hold-down + + A new key which has been seen by the resolver, but hasn't reached + it's add hold-down time, MAY be removed from the DNSKEY RRSet by the + zone owner. If the resolver sees a validated DNSKEY RRSet without + this key, it waits for the remove hold-down time and then, if the key + + + +StJohns Expires April 14, 2005 [Page 5] + +Internet-Draft trustanchor-update October 2004 + + + hasn't reappeared, SHOULD discard any information about the key. + +2.4 Active Refresh + + A resolver which has been configured for automatic update of keys + from a particular trust point MUST query that trust point (e.g. do a + lookup for the DNSKEY RRSet and related RRSIG records) no less often + than the lesser of 15 days or half the original TTL for the DNSKEY + RRSet or half the RRSIG expiration interval. The expiration interval + is the amount of time from when the RRSIG was last retrieved until + the expiration time in the RRSIG. + + If the query fails, the resolver MUST repeat the query until + satisfied no more often than once an hour and no less often than the + lesser of 1 day or 10% of the original TTL or 10% of the original + expiration interval. + +2.5 Resolver Parameters + +2.5.1 Add Hold-Down Time + + The add hold-down time is 30 days or the expiration time of the TTL + of the first trust point DNSKEY RRSet which contained the key, + whichever is greater. This ensures that at least two validated + DNSKEY RRSets which contain the new key MUST be seen by the resolver + prior to the key's acceptance. + +2.5.2 Remove Hold-Down Time + + The remove hold-down time is 30 days. + +2.5.3 Minimum Trust Anchors per Trust Point + + A compliant resolver MUST be able to manage at least five SEP keys + per trust point. + +3. Changes to DNSKEY RDATA Wire Format + + Bit n [msj2] of the DNSKEY Flags field is designated as the 'REVOKE' + flag. If this bit is set to '1', AND the resolver sees an + RRSIG(DNSKEY) signed by the associated key, then the resolver MUST + consider this key permanently invalid for all purposes except for + validing the revocation. + +4. State Table + + The most important thing to understand is the resolver's view of any + key at a trust point. The following state table describes that view + + + +StJohns Expires April 14, 2005 [Page 6] + +Internet-Draft trustanchor-update October 2004 + + + at various points in the key's lifetime. The table is a normative + part of this specification. The initial state of the key is 'Start'. + The resolver's view of the state of the key changes as various events + occur. + + [msj1] This is the state of a trust point key as seen from the + resolver. The column on the left indicates the current state. The + header at the top shows the next state. The intersection of the two + shows the event that will cause the state to transition from the + current state to the next. + + NEXT STATE + -------------------------------------------------- + FROM |Start |AddPend |Valid |Missing|Revoked|Removed| + ---------------------------------------------------------- + Start | |NewKey | | | | | + ---------------------------------------------------------- + AddPend |KeyRem | |AddTime| | | + ---------------------------------------------------------- + Valid | | | |KeyRem |Revbit | | + ---------------------------------------------------------- + Missing | | |KeyPres| |Revbit | | + ---------------------------------------------------------- + Revoked | | | | | |RemTime| + ---------------------------------------------------------- + Removed | | | | | | | + ---------------------------------------------------------- + + +4.1 Events + NewKey The resolver sees a valid DNSKEY RRSet with a new SEP key. + That key will become a new trust anchor for the named trust point + after its been present in the RRSet for at least 'add time'. + KeyPres The key has returned to the valid DNSKEY RRSet. + KeyRem The resolver sees a valid DNSKEY RRSet that does not contain + this key. + AddTime The key has been in every valid DNSKEY RRSet seen for at + least the 'add time'. + RemTime A revoked key has been missing from the trust point DNSKEY + RRSet for sufficient time to be removed from the trust set. + RevBit The key has appeared in the trust anchor DNSKEY RRSet with its + "REVOKED" bit set, and there is an RRSig over the DNSKEY RRSet + signed by this key. + +4.2 States + + + + + + +StJohns Expires April 14, 2005 [Page 7] + +Internet-Draft trustanchor-update October 2004 + + + Start The key doesn't yet exist as a trust anchor at the resolver. + It may or may not exist at the zone server, but hasn't yet been + seen at the resolver. + AddPend The key has been seen at the resolver, has its 'SEP' bit set, + and has been included in a validated DNSKEY RRSet. There is a + hold-down time for the key before it can be used as a trust + anchor. + Valid The key has been seen at the resolver and has been included in + all validated DNSKEY RRSets from the time it was first seen up + through the hold-down time. It is now valid for verifying RRSets + that arrive after the hold down time. Clarification: The DNSKEY + RRSet does not need to be continuously present at the resolver + (e.g. its TTL might expire). If the RRSet is seen, and is + validated (i.e. verifies against an existing trust anchor), this + key MUST be in the RRSet otherwise a 'KeyRem' event is triggered. + Missing This is an abnormal state. The key remains as a valid trust + point key, but was not seen at the resolver in the last validated + DNSKEY RRSet. This is an abnormal state because the zone operator + should be using the REVOKE bit prior to removal. [Discussion + item: Should a missing key be considered revoked after some + period of time?] + Revoked This is the state a key moves to once the resolver sees an + RRSIG(DNSKEY) signed by this key where that DNSKEY RRSet contains + this key with its REVOKE bit set to '1'. Once in this state, this + key MUST permanently be considered invalid as a trust anchor. + Removed After a fairly long hold-down time, information about this + key may be purged from the resolver. A key in the removed state + MUST NOT be considered a valid trust anchor. + +5. Scenarios + + The suggested model for operation is to have one active key and one + stand-by key at each trust point. The active key will be used to + sign the DNSKEY RRSet. The stand-by key will not normally sign this + RRSet, but the resolver will accept it as a trust anchor if/when it + sees the signature on the trust point DNSKEY RRSet. + + Since the stand-by key is not in active signing use, the associated + private key may (and SHOULD) be provided with additional protections + not normally available to a key that must be used frequently. E.g. + locked in a safe, split among many parties, etc. Notionally, the + stand-by key should be less subject to compromise than an active key, + but that will be dependent on operational concerns not addressed + here. + +5.1 Adding A Trust Anchor + + Assume an existing trust anchor key 'A'. + + + +StJohns Expires April 14, 2005 [Page 8] + +Internet-Draft trustanchor-update October 2004 + + + 1. Generate a new key pair. + 2. Create a DNSKEY record from the key pair and set the SEP and Zone + Key bits. + 3. Add the DNSKEY to the RRSet. + 4. Sign the DNSKEY RRSet ONLY with the existing trust anchor key - + 'A'. + 5. Wait a while. + +5.2 Deleting a Trust Anchor + + Assume existing trust anchors 'A' and 'B' and that you want to revoke + and delete 'A'. + 1. Set the revolcation bit on key 'A'. + 2. Sign the DNSKEY RRSet with both 'A' and 'B'. + 'A' is now revoked. The operator SHOULD include the revoked 'A' in + the RRSet for at least the remove hold-down time, but then may remove + it from the DNSKEY RRSet. + +5.3 Key Roll-Over + + Assume existing keys A and B. 'A' is actively in use (i.e. has been + signing the DNSKEY RRSet.) 'B' was the stand-by key. (i.e. has + been in the DNSKEY RRSet and is a valid trust anchor, but wasn't + being used to sign the RRSet.) + 1. Generate a new key pair 'C'. + 2. Add 'C' to the DNSKEY RRSet. + 3. Set the revocation bit on key 'A'. + 4. Sign the RRSet with 'A' and 'B'. + 'A' is now revoked, 'B' is now the active key, and 'C' will be the + stand-by key once the hold-down expires. The operator SHOULD include + the revoked 'A' in the RRSet for at least the remove hold-down time, + but may then remove it from the DNSKEY RRSet. + +5.4 Active Key Compromised + + This is the same as the mechanism for Key Roll-Over (Section 5.3) + above assuming 'A' is the active key. + +5.5 Stand-by Key Compromised + + Using the same assumptions and naming conventions as Key Roll-Over + (Section 5.3) above: + 1. Generate a new key pair 'C'. + 2. Add 'C' to the DNSKEY RRSet. + 3. Set the revocation bit on key 'B'. + 4. Sign the RRSet with 'A' and 'B'. + 'B' is now revoked, 'A' remains the active key, and 'C' will be the + stand-by key once the hold-down expires. 'B' SHOULD continue to be + + + +StJohns Expires April 14, 2005 [Page 9] + +Internet-Draft trustanchor-update October 2004 + + + included in the RRSet for the remove hold-down time. + +6. Security Considerations + +6.1 Key Ownership vs Acceptance Policy + + The reader should note that, while the zone owner is responsible + creating and distributing keys, it's wholly the decision of the + resolver owner as to whether to accept such keys for the + authentication of the zone information. This implies the decision + update trust anchor keys based on trust for a current trust anchor + key is also the resolver owner's decision. + + The resolver owner (and resolver implementers) MAY choose to permit + or prevent key status updates based on this mechanism for specific + trust points. If they choose to prevent the automated updates, they + will need to establish a mechanism for manual or other out-of-band + updates outside the scope of this document. + +6.2 Multiple Key Compromise + + This scheme permits recovery as long as at least one valid trust + anchor key remains uncompromised. E.g. if there are three keys, you + can recover if two of them are compromised. The zone owner should + determine their own level of comfort with respect to the number of + active valid trust anchors in a zone and should be prepared to + implement recovery procedures once they detect a compromise. A + manual or other out-of-band update of all resolvers will be required + if all trust anchor keys at a trust point are compromised. + +6.3 Dynamic Updates + + Allowing a resolver to update its trust anchor set based in-band key + information is potentially less secure than a manual process. + However, given the nature of the DNS, the number of resolvers that + would require update if a trust anchor key were compromised, and the + lack of a standard management framework for DNS, this approach is no + worse than the existing situation. + +7 Normative References + + [DSINTRO] Arends, R., "DNS Security Introduction and Requirements", + ID draft-ietf-dnsext-dnssec-intro-09.txt, October 2004, + . + + [DSPROT] Arends, R., "Protocol Modifications for the DNS Security + Extensions", ID draft-ietf-dnsext-dnssec-protocol-05.txt, + + + +StJohns Expires April 14, 2005 [Page 10] + +Internet-Draft trustanchor-update October 2004 + + + October 2004, + . + + [DSREC] Arends, R., "Resource Records for the DNS Security + Extensions", ID draft-ietf-dnsext-dnssec-records-07.txt, + October 2004, + . + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2535] Eastlake, D., "Domain Name System Security Extensions", + RFC 2535, March 1999. + +Editorial Comments + + [msj1] msj: N.B. This table is preliminary and will be revised to + match implementation experience. For example, should there + be a state for "Add hold-down expired, but haven't seen the + new RRSet"? + + [msj2] msj: To be assigned. + + [msj3] msj: For discussion: What's the implementation guidance for + resolvers currently with respect to the non-assigned flag + bits? If they consider the flag bit when doing key matching + at the trust anchor, they won't be able to match. + + +Author's Address + + Michael StJohns + Nominum, Inc. + 2385 Bay Road + Redwood City, CA 94063 + USA + + Phone: +1-301-528-4729 + EMail: Mike.StJohns@nominum.com + URI: www.nominum.com + + + + + + + + + +StJohns Expires April 14, 2005 [Page 11] + +Internet-Draft trustanchor-update October 2004 + + +Intellectual Property Statement + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + + The IETF has been notified of intellectual property rights claimed in + regard to some or all of the specification contained in this + document. For more information consult the online list of claimed + rights. + + +Disclaimer of Validity + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + +Copyright Statement + + Copyright (C) The Internet Society (2004). This document is subject + to the rights, licenses and restrictions contained in BCP 78, and + except as set forth therein, the authors retain all their rights. + + + + + +StJohns Expires April 14, 2005 [Page 12] + +Internet-Draft trustanchor-update October 2004 + + +Acknowledgment + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +StJohns Expires April 14, 2005 [Page 13] + + diff --git a/doc/draft/draft-ietf-dnsext-tsig-sha-00.txt b/doc/draft/draft-ietf-dnsext-tsig-sha-01.txt similarity index 83% rename from doc/draft/draft-ietf-dnsext-tsig-sha-00.txt rename to doc/draft/draft-ietf-dnsext-tsig-sha-01.txt index 1133b0c87d..dbc94fe322 100644 --- a/doc/draft/draft-ietf-dnsext-tsig-sha-00.txt +++ b/doc/draft/draft-ietf-dnsext-tsig-sha-01.txt @@ -1,13 +1,12 @@ - INTERNET-DRAFT Donald E. Eastlake 3rd UPDATES RFC 2845 Motorola Laboratories -Expires: February 2005 August 2004 +Expires: August 2005 February 2005 HMAC SHA TSIG Algorithm Identifiers ---- --- ---- --------- ----------- - + Status of This Document @@ -43,14 +42,14 @@ Abstract Use of the TSIG DNS resource record requires specification of a cryptographic message authentication code. Currently identifiers have been specified only for the HMAC-MD5 and GSS TSIG algorithms. - This document standardizes identifiers for additional HMAC SHA TSIG - algorithms and standardizes how to specify the truncation of HMAC - values. + This document standardizes identifiers and implementation + requirements for additional HMAC SHA TSIG algorithms and standardizes + how to specify the truncation of HMAC values. Copyright Notice - Copyright (C) The Internet Society 2004. All Rights Reserved. + Copyright (C) The Internet Society 2005. All Rights Reserved. @@ -82,7 +81,7 @@ Table of Contents 7. Normative References....................................7 8. Informative References..................................7 - Authors Address............................................8 + Author's Address...........................................8 Expiration and File Name...................................8 @@ -131,7 +130,8 @@ INTERNET-DRAFT HMAC-SHA TSIG Identifiers are delegated to GSS [RFC 3645]. In section 2, this document specifies additional names for TSIG - authentication algorithms based on US NIST SHA algorithms and HMAC. + authentication algorithms based on US NIST SHA algorithms and HMAC + and specifies the implementation requirements for those algorithms. In section 3, this document specifies the meaning of inequality between the normal output size of the specified hash function and the @@ -168,7 +168,6 @@ INTERNET-DRAFT HMAC-SHA TSIG Identifiers - D. Eastlake 3rd [Page 3] @@ -190,21 +189,23 @@ INTERNET-DRAFT HMAC-SHA TSIG Identifiers The use of SHA-1 [FIPS 180-1, RFC 3174], which is a 160 bit hash, as compared with the 128 bits for MD5, and additional hash algorithms in - the SHA family [FIPS 180-2, RFC sha224] with 224, 256, 384, and 512 - bits, may be preferred in some case. Use of TSIG between a DNS - resolver and server is by mutual agreement. That agreement can - include the support of additional algorithms. + the SHA family [FIPS 180-2, RFC 3874] with 224, 256, 384, and 512 + bits, may be preferred in some case particularly since increasingly + successful cryptanalytic attacks are being made on the shorter + hashes. Use of TSIG between a DNS resolver and server is by mutual + agreement. That agreement can include the support of additional + algorithms and may specify policies as to which algorithms are + acceptable. - For completeness in relation to HMAC based algorithms, the current - HMAC-MD5.SIG-ALG.REG.INT identifier is included in the table below. - Implementations which support TSIG MUST implement HMAC MD5, SHOULD - implement HMAC SHA-1, and MAY implement gss-tsig and the other - algorithms listed below. + The current HMAC-MD5.SIG-ALG.REG.INT identifier is included in the + table below for convenience. Implementations which support TSIG MUST + also implement HMAC SHA1 and HMAC SHA256 and MAY implement gss-tsig + and the other algorithms listed below. Mandatory HMAC-MD5.SIG-ALG.REG.INT - Recommended hmac-sha1 + Mandatory hmac-sha1 Optional hmac-sha224 - Optional hmac-sha256 + Mandatory hmac-sha256 Optional hamc-sha384 Optional hmac-sha512 @@ -225,8 +226,6 @@ INTERNET-DRAFT HMAC-SHA TSIG Identifiers - - D. Eastlake 3rd [Page 4] @@ -309,16 +308,21 @@ INTERNET-DRAFT HMAC-SHA TSIG Identifiers MAC by reducing the information available to an attacker, excessive truncation clearly weakens authentication by reducing the number of bits an attacker has to try to force. See [RFC 2104] which recommends - that ah HMAC never be truncated to less than half its length nor to + that an HMAC never be truncated to less than half its length nor to less than 80 bits (10 octets). + Significant progress has been made recently in cryptanalysis of hash + function of the type used herein. While the results so far should not + effect HMAC, the stronger SHA-1 and SHA-256 algorithms are being made + mandatory due to caution. + See also the Security Considerations section of [RFC 2845]. 6. Copyright and Disclaimer - Copyright (C) The Internet Society 2004. This document is subject to + Copyright (C) The Internet Society 2005. This document is subject to the rights, licenses and restrictions contained in BCP 78 and except as set forth therein, the authors retain all their rights. @@ -340,11 +344,6 @@ INTERNET-DRAFT HMAC-SHA TSIG Identifiers - - - - - D. Eastlake 3rd [Page 6] @@ -353,8 +352,9 @@ INTERNET-DRAFT HMAC-SHA TSIG Identifiers 7. Normative References - [FIPS 180-2] - "Secure Hash Standard", (SHA-1/256/384/512) US Federal - Information Processing Standard, Draft, 1 August 2002. + [FIPS 180-2] - "Secure Hash Standard", (SHA-1/224/256/384/512) US + Federal Information Processing Standard, with Change Notice 1, + February 2004. [RFC 1321] - Rivest, R., "The MD5 Message-Digest Algorithm ", RFC 1321, April 1992. @@ -369,17 +369,10 @@ INTERNET-DRAFT HMAC-SHA TSIG Identifiers Wellington, "Secret Key Transaction Authentication for DNS (TSIG)", RFC 2845, May 2000. - [RFC sha224] - "A 224-bit One-way Hash Function: SHA-224", R. - Housley, December 2003, work in progress, draft-ietf-pkix- - sha224-*.txt. - 8. Informative References. - [FIPS 180-1] - Secure Hash Standard, (SHA-1) US Federal Information - Processing Standard, 17 April 1995. - [RFC 2931] - Eastlake 3rd, D., "DNS Request and Transaction Signatures ( SIG(0)s )", RFC 2931, September 2000. @@ -391,6 +384,12 @@ INTERNET-DRAFT HMAC-SHA TSIG Identifiers Transaction Authentication for DNS (GSS-TSIG)", RFC 3645, October 2003. + [RFC 3874] - "A 224-bit One-way Hash Function: SHA-224", R. Housley, + September 2004, + + + + @@ -409,7 +408,7 @@ D. Eastlake 3rd [Page 7] INTERNET-DRAFT HMAC-SHA TSIG Identifiers -Authors Address +Author's Address Donald E. Eastlake 3rd Motorola Laboratories @@ -424,9 +423,9 @@ Authors Address Expiration and File Name - This draft expires in February 2005. + This draft expires in August 2005. - Its file name is draft-ietf-dnsext-tsig-sha-00.txt + Its file name is draft-ietf-dnsext-tsig-sha-01.txt diff --git a/doc/draft/draft-ietf-dnsext-wcard-clarify-03.txt b/doc/draft/draft-ietf-dnsext-wcard-clarify-03.txt deleted file mode 100644 index 8033c0c1c0..0000000000 --- a/doc/draft/draft-ietf-dnsext-wcard-clarify-03.txt +++ /dev/null @@ -1,818 +0,0 @@ - -DNSEXT Working Group E. Lewis -INTERNET DRAFT NeuStar -Expiration Date: April 2005 October 2004 - - Clarifying the Role of Wild Card Domains - in the Domain Name System - - draft-ietf-dnsext-wcard-clarify-03.txt - -Status of this Memo - - By submitting this Internet-Draft, each author represents that any - applicable patent or other IPR claims of which he or she is aware - have been or will be disclosed, and any of which he or she becomes - aware will be disclosed, in accordance with Section 6 of RFC 3668. - - 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 April 11, 2005. - - -Copyright Notice - - Copyright (C) The Internet Society (2004). - - -Abstract - - The definition of wild cards is recast from the original in RFC 1034, - in words that are more specific and in line with RFC 2119. This - document is meant to supplement the definition in RFC 1034 and not to - significantly alter the spirit or intent of that definition. - -1 Introduction - - In RFC 1034 [RFC1034], sections 4.3.2 and 4.3.3 describe the synthesis - of answers from special records called wildcards. The original - definitions are incomplete. This document clarifies and describes - the wildcard synthesis by adding to the discussion and making - limited modifications. Modifications are made only where necessary - to close inconsistencies that have led to interoperability issues. - -1.1 Motivation - - Over time many implementations have diverged in different ways from - the original definition, or at least what had been intended. Although - there is clearly a need to clarify the original documents in light - of this, the impetus for this document lay in the engineering of - the DNS security extensions [RFC TBD]. With an unclear definition - of wildcards the design of authenticated denial became entangled. - - Although this document is motivated by DNSSEC and the need to - have a separate document passed for the sake of DNSSEC, other - motivations have risen. The renewed understanding of wildcards gained - is worthy of being documented. - -1.2 The Original Definition - - This document is intended to not make changes. To reinforce - this, sections of RFC 1034 are repeated verbatim for convenience - of the reader, to help in comparison of old and new text. - - There are a few passages which are changed. This may seem to - contradict the goal of not changing the original specification, - but the changes herein are required because of inconsistencies - with the wording in RFC 1034. - - The beginning of the discussion ought to start with the definition - of the term "wildcard" as it appears in RFC 1034, section 4.3.3. - -# In the previous algorithm, special treatment was given to RRs with owner -# names starting with the label "*". Such RRs are called wildcards. -# Wildcard RRs can be thought of as instructions for synthesizing RRs. -# When the appropriate conditions are met, the name server creates RRs -# with an owner name equal to the query name and contents taken from the -# wildcard RRs. - - - This passage appears after the algorithm in which they are used is - presented. The terminology is not consistent, the word "wildcard" - is clearly defined to be a resource record. In the next sentence - the term is shifted to be an adjective, the first step on the - path to overloading the term. Wildcard has also been used to - refer to domain names that begin with a "*". - -1.3 The Clarification - - The clarification effort can be divided into three sections. One - is the use of new terminology to better describe wildcards. Changes - to words in RFC 1034 that have resulted by discovering conflicting - concepts are presented. Descriptions of special type records in the - context of being wildcards is discussed. - -1.3.1 New Terms - - The term "wildcard" has become so overloaded it is virtually useless - as a description. A few new terms will be introduced to be more - descriptive. The new terms that will be introduced are: - - Asterisk Label - a label consisting of an asterisk ("*") and no - other characters. - - Wild Card Domain Name - a domain name whose least significant - label (first when reading left to right) is an asterisk label. - Other labels might also be asterisk labels. - - Source of Synthesis - a Wild Card Domain Name when it is consulted in - the final paragraph of step 3, part c of RFC 1034's 4.3.2 algorithm. - - Closest Encloser - in RFC 1034's 4.3.2 algorithm, the name at which - the last match was possible in step 3, part c. This is the longest - sequence of exactly matching labels from the root downward in both the - sought name (QNAME) and in the zone being examined. - - - Label Match - two labels are equivalent if the label type and label - length are the same bit sequence and if the name is the label is - equivalent bit wise after down casing all of the ASCII characters. - [Ed note: do we still call them ASCII?] - - These terms will be more fully described as needed later. These - terms will be used to describe a few changes to the words in RFC - 1034. A summary of the changes appear next and will be fully - covered in later sections. - -1.3.2 Changed Text - - The definition of "existence" is changed, superficially, to exclude - empty domains that have no subdomains with resource records. This - change will not be apparent to implementations, it is needed to - make descriptions more concise. - - In RFC 1034, there is text that seems to bar having two Asterisk - Labels in a Wild Card Domain Name. There is no further discussion, - no prescribed error handling, nor enforcement described. In this - document, the use of such names will be discouraged, but implementations - will have to account for the possibility of such a name's use. - - The actions when a Source of Synthesis owns a CNAME RR are changed to - mirror the actions if an exact match name owns a CNAME RR. This - is an addition to the words in RFC 1034, section 4.3.2, step 3, - part c. - -1.3.3 Considerations with Special Types - - This clarification will describe in some detail the semantics of - wildcard CNAME RRs, wildcard NS RRs, wildcard SOA RR's, - wildcard DNAME RRs [RFC wxyz], and empty, non-terminal wildcards. - Understanding these types in the context of wildcards has been - clouded because these types incur special processing if they - are the result of an exact match. - - By the definition in RFC 1034, there can be no empty, non-terminal - "wildcards", but in the algorithm, it is possible that an empty - non-terminal is sought as the potential owner of a "wildcard." This - is one example of why the ordering of the discussion in RFC 1034 is - confusing. - - -1.4 Standards Terminology - - 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 the document entitled - "Key words for use in RFCs to Indicate Requirement Levels." [RFC2119] - - Quotations of RFC 1034 (as has already been done once above) are - denoted by a '#' in the leftmost column. - - -2 "Wildcard" - - The context of the wildcard concept involves the algorithm by which - a name server prepares a response (in RFC 1034's section 4.3.2) and - the way in which a resource record (set) is identified as being a - source of synthetic data (section 4.3.3). - - Tackling the latter first, there are two objectives in defining a - means to identify a resource record set as a source of synthesis. - First is the desire to maintain all DNS data in a consistent manner. - Avoiding the need for implementations to have many internal data - structures is a good thing. Not that this means limiting quantity, - but rather types of data. The second objective impacts interoperability, - that is a master server of one implementation has to be able to - send the synthesis instructions to the slaves. Although there are - alternatives to the use of zone transfers via port 53, a truly - interoperable record synthesis approach has to be able to insert the - synthesis instructions into a zone transfer. - - The objectives in describing the synthesis of records in the context - of the name server algorithm include knowing when to employ the - process of synthesis and how the synthesis is carried out. - -2.1 Identifying a wildcard - - To provide a more accurate description of "wildcards", the definition - has to start with a discussion of the domain names that appear as - owners. - -2.1.1 Wild Card Domain Name and Asterisk Label - - A "Wild Card Domain Name" is defined by having its initial label be: - - 0000 0001 0010 1010 (binary) = 0x01 0x2a (hexadecimal) - - - The first octet is the normal label type and length for a 1 octet - long label, the second octet is the ASCII representation [RFC 20] for - the '*' character. In RFC 1034, ASCII encoding is assumed to be the - character encoding. - - A descriptive name of a label equaling that value is an "Asterisk - Label." - - RFC 1034's definition of wildcard would be "a resource record owned - by a Wild Card Domain Name." This is mentioned to help maintain some - orientation between this clarification and RFC 1034. Keep in mind, - that in "Clarifications to the DNS Specification" [RFC 2181] the name - of the basic unit of DNS data became the resource record set (RRSet) and - not the resource record. - -2.1.2 Variations on Wild Card Domain Names - - RFC 1034 and RFC 1035 do not explicitly mention the case in which a - domain name might be something like "the*.example.com." The - interpretation is that this domain name in a zone would only match - queries for "the*.example.com" and not have any other role. An - asterisk ('*') occurring other than as the sole character in - a label is simply a character forming part of the label and has no - special meaning. This is not an Asterisk Label, simply a label - an asterisk in it. The same is true for "**.example.com." and - "*the.example.com." - - [Ed note: the above paragraph reads too strong. The intent ought to - be that such names do not fall under the rules of wildcards. The - intent is not to bar any future attempts to define other forms of - synthesis - nor is the intent to encourage them.] - - The interpretation of a wild card domain specification which is not a - leaf domain is not clearly defined in RFC 1034. E.g., sub.*.example., - is not discussed, not barred. In wanting to minimize changes from - the original specification, such names are permitted. Although - "sub.*.example." is not a Wild Card Domain Name, "*.example." is. - - RRSets used to synthesize records can be owned by a Wild Card Domain - Name that has subdomains. - -2.1.3 Non-terminal Wild Card Domain Names - - In section 4.3.3, the following is stated: - -# .......................... The owner name of the wildcard RRs is of -# the form "*.", where is any domain name. -# should not contain other * labels...................... - - This covers names like "*.foo.*.example." The pre-RFC2119 wording uses - "should not" which has an ambiguous meaning. The specification does not - proscribe actions upon seeing such a name, such as whether or not a - zone containing the name should fail to be served. What if a dynamic - update (RFC2136) requested to add the name to the zone? The failure - semantics are not defined. - - The recommendation is that implementations ought to anticipate the - appearance of such names but generally discourage their use in - operations. No standards statement, such as "MAY NOT" or "SHOULD NOT" - is made here. - - The interpretation of this is, when seeking a Wild Card Domain Name - for the purposes of record synthesis, an implementation ought not to - check the domain name for subdomains. - - It is possible that a Wild Card Domain Name is an empty non-terminal. - (See the upcoming sections on empty non-terminals.) In this case, - the lookup will terminate as would any empty non-terminal match. - -2.2 Existence Rules - - The notion that a domain name 'exists' arises numerous times in - discussions about the wildcard concept. RFC 1034 raises the issue - of existence in a number of places, usually in reference to - non-existence and in reference to processing involving wildcards. - RFC 1034 contains algorithms that describe how domain names impact - the preparation of an answer and does define wildcards as a means of - synthesizing answers. Because of this a discussion on wildcards - needs to cover a definition of existence. - - - To help clarify the topic of wild cards, a positive definition of - existence is needed. Complicating matters, though, is the - realization that existence is relative. To an authoritative server, - a domain name exists if the domain name plays a role following the - algorithms of preparing a response. To a resolver, a domain name - exists if there is any data available corresponding to the name. The - difference between the two is the synthesis of records according to a - wildcard. - - For the purposes of this document, the point of view of an - authoritative server is more interesting. A domain name is said to - exist if it plays a role in the execution of the algorithms in RFC 1034. - -2.2.1. An Example - - To illustrate what is meant by existence consider this complete zone: - - - $ORIGIN example. - example. 3600 IN SOA - example. 3600 NS ns.example.com. - example. 3600 NS ns.example.net. - *.example. 3600 TXT "this is a wild card" - *.example. 3600 MX 10 host1.example. - host1.example. 3600 A 192.0.4.1 - _ssh._tcp.host1.example. 3600 SRV - _ssh._tcp.host2.example. 3600 SRV - subdel.example. 3600 NS ns.example.com. - subdel.example. 3600 NS ns.example.net. - - - A look at the domain names in a tree structure is helpful: - - | - -------------example------------ - / / \ \ - / / \ \ - / / \ \ - * host1 host2 subdel - | | - | | - _tcp _tcp - | | - | | - _ssh _ssh - - The following queries would be synthesized from the wild card: - - QNAME=host3.example. QTYPE=MX, QCLASS=IN - the answer will be a "host3.example. IN MX ..." - - - QNAME=host3.example. QTYPE=A, QCLASS=IN - the answer will reflect "no error, but no data" - because there is no A RR set at '*.example.' - - - QNAME=foo.bar.example. QTYPE=TXT, QCLASS=IN - the answer will be "foo.bar.example. IN TXT ..." - because bar.example. does not exist, but the wildcard does. - - The following queries would not be synthesized from the wild card: - - QNAME=host1.example., QTYPE=MX, QCLASS=IN - because host1.example. exists - - QNAME=ghost.*.example., QTYPE=MX, QCLASS=IN - because *.example. exists - - QNAME=_telnet._tcp.host1.example., QTYPE=SRV, QCLASS=IN - because _tcp.host1.example. exists (without data) - - - QNAME=_telnet._tcp.host2.example., QTYPE=SRV, QCLASS=IN - because host2.example. exists (without data) - - - QNAME=host.subdel.example., QTYPE=A, QCLASS=IN - because subdel.example. exists (and is a zone cut) - - To the server, all of the domains in the tree exist. The resolver will - get answers to some names off the tree, thanks to synthesis. - -2.2.2 Empty Non-terminals - - Empty non-terminals are domain names that own no resource records but - have subdomains which do. This is defined in section 3.1 of RFC 1034: - -# The domain name space is a tree structure. Each node and leaf on the -# tree corresponds to a resource set (which may be empty). The domain -# system makes no distinctions between the uses of the interior nodes and -# leaves, and this memo uses the term "node" to refer to both. - - The parenthesized "which may be empty" specifies that empty non- - terminals are explicitly recognized. According to the definition of - existence in this document, empty non-terminals do exist at the - server. - - Pedantically reading the above paragraph can lead to an - interpretation that all possible domains exist - up to the suggested - limit of 255 octets for a domain name [RFC 1035]. For example, - www.example. may have an A RR, and as far as is practically - concerned, is a leaf of the domain tree. But the definition can be - taken to mean that sub.www.example. also exists, albeit with no data. - By extension, all possible domains exist, from the root on down. As - RFC 1034 also defines "an authoritative name error indicating that - the name does not exist" in section 4.3.1, this is not the intent of - the original document. - -2.2.3 Yet Another Definition of Existence - - RFC1034's wording is clarified by the following paragraph: - - A node is considered to have an impact on the algorithms of - 4.3.2 if it is a leaf node with any resource sets or an interior - node (with or without a resource set) that has a subdomain that - is a leaf node with a resource set. A QNAME and QCLASS matching - an existing node never results in a response code of - authoritative name error (RCODE==3). - - The terminology in the above paragraph is chosen to remain as close - to that in the original document. The term "with" is a alternate - form for "owning" in this case, hence "a leaf node owning resources - sets, or an interior node, owning or not owning any resource set, - that has a leaf node owning a resource set as a subdomain," is the - proper interpretation of the middle sentence. - - As an aside, an "authoritative name error", response code (RCODE) 3, - has been called NXDOMAIN in some RFCs, such as RFC 2136 [RFC 2136]. - NXDOMAIN is the mnemonic assigned to such an error by at least one - implementation of DNS. - - Summarizing the discussion on existence in non-RFC1034 words: - - An authoritative server is to treat a domain name as existing - during the execution of the algorithms in RFC 1034 when the - domain name conforms to the following definition. A domain name - is defined to exist if the domain name owns data or has a - subdomain that exists, or both. - - Note that at a zone boundary, the domain name owns data, including - the NS RR set. At the delegating server, the NS RR set is not - authoritative, but that is of no consequence here. The domain name - owns data, therefore, it exists. - - -2.3 When does a Wild Card Domain Name not own a wildcard (record) - - When a Wild Card Domain Name appears in a message's query section, - no special processing occurs. Asterisk Labels in such a context - only Label Matches other Asterisk Labels in the existing zone tree - when the 4.3.2 algorithm is being followed. - - When a Wild Card Domain Name appears in the resource data of a - record, no special processing occurs. An Asterisk Label in that - context literally means just an asterisk. - - -3. Impact of a Wild Card Domain On a Response - - The description of how wild cards impact response generation is in - RFC 1034, section 4.3.2. That passage contains the algorithm - followed by a server in constructing a response. Within that - algorithm, step 3, part 'c' defines the behavior of the wild card. - The algorithm is directly quoted in lines that begin with a '#' sign. - Commentary is interleaved. - - There is a documentation issue deserving some explanation. The - algorithm in RFC 1034, section 4.3.2. is not intended to be pseudo - code, i.e., it's steps are not intended to be followed in strict - order. The "algorithm" is a suggestion. As such, in step 3, parts - a, b, and c, do not have to be implemented in that order. - - Another issue needing explanation is that RFC 1034 is a full - standard. There is another RFC, RFC 2672, which makes, or proposes - an adjustment to RFC 1034's section 4.3.2 for the sake of the DNAME - RR. RFC 2672 is a proposed standard. The dilemma in writing these - clarifications is knowing which document is the one being clarified. - Fortunately, the difference between RFC 1034 and RFC 2672 is not - significant with respect to wild card synthesis, so this document - will continue to state that it is clarifying RFC 1034. If RFC 2672 - progresses along the standards track, it will need to refer to - modifying RFC 1034's algorithm as amended here. - - -3.1 Step 2 - - Step 2 of the RFC 1034's section 4.3.2 reads: - -# 2. Search the available zones for the zone which is the nearest -# ancestor to QNAME. If such a zone is found, go to step 3, -# otherwise step 4. - - In this step, the most appropriate zone for the response is chosen. - There are two reasons to repeat this. One is that this means all - of step 3 is done within the context of a zone, which will constrain - the discussion. The other is the though behind synthesizing entire - zones and the use of Wild Card Domain Names to do so. - -3.2 Step 3 - - Step 3 is dominated by three parts, labelled a, b, and c. But the - beginning of the Step is important and needs explanation. - -# 3. Start matching down, label by label, in the zone. The -# matching process can terminate several ways: - - The word matching in this care refers to Label Matching. The concept - is based in the view of the zone as the tree of existing names. The - Query Name is considered to be an ordered sequence of labels - as - if the name were a path from the root to the owner of the desired - data. - - The process of Label Matching ends in one of three choices, the parts - a, b, and c. Once one of the parts is chosen, the other parts are - not considered. (E.g., do not execute part c and then change the - execution path to finish in part b.) The process of Label Matching - is also done independent of the Query Type. - - Parts a and b are not an issue for this clarification as they do not - relate to record synthesis. Part a generally covers a situation in - which all of the labels in the search (query) name have been matched - down the tree, e.g., the sought name exists as an exact Label Match. - Part b generally covers a situation in which any label in the sought - name Label Matches a tree label and the tree label has a NS RRSet. - -3.3 Part 'c' - - The context of part 'c' is that the process of Label Matching the - labels in the sought name has resulted in a situation in which there - is nothing corresponding in the tree. It is as if the lookup has - "fallen off the tree." - -# c. If at some label, a match is impossible (i.e., the -# corresponding label does not exist), look to see if a -# the "*" label exists. - - - To help describe the process of looking "to see is a the [sic] - label exists" a term has been coined to describe the last label - matched. The term is "Closest Encloser." - -3.3.1 Closest Encloser and the Source of Synthesis - - The "Closest Encloser" is the node in the zone's tree of existing - domain names that is has the most matching labels with the sought - name. Each match is a "Label Match" and the order of the labels - is also the same. The Closest Encloser is an existing name in the - zone, it may be an empty non-terminal, it may even be a Wild Card - Domain Name itself. In no circumstances is the Closest Encloser - the used to synthesize records though. - - A "Source of Synthesis" is defined in the context of a lookup - process as the Wild Card Domain Name immediately descending from - the Closest Encloser provided the Wild Card Domain Name exists. - A Source of Synthesis does not guarantee having a RRSet to use - for synthesis, a Source of Synthesis may even be an empty - non-terminal. - - If a Source of Synthesis exists, it will be the Wild Card Domain Name - that is identified by an Asterisk Label below the Closest Encloser. - E.g., ". or "*.." - If the Source of Synthesis does not exist (not on the domain tree), - there will be no wildcard synthesis - - The important concept is that for any given lookup process, there - is at most one place at which wildcard synthetic records can be - obtained. If the Source of Synthesis does not exist, the lookup - terminates, the lookup does not look for other wildcard records. - - Other terms have been coined on the mailing list in the past. E.g., - it has been said that existing names block the application of - wildcard records. This is still an appropriate viewpoint, but - replacing this notion with the Closest Encloser and Source of - Synthesis the depiction of the wildcard process is clearer. - -3.3.2 Closest Encloser and Source of Synthesis Examples - - - To illustrate, using the example zone in section 2.2.1 of this document, - the following chart shows QNAMEs and the closest enclosers. - - QNAME Closest Encloser Source of Synthesis - host3.example. example. *.example. - _telnet._tcp.host1.example. _tcp.host1.example. no source - _telnet._tcp.host2.example. host2.example. no source - _telnet._tcp.host3.example. example. *.example. - _chat._udp.host3.example. example. *.example. - - - - The fact that a closest encloser will be the only superdomain that - can have a candidate wild card will have an impact when it comes to - designing pre-calculated authenticated denial of existence proofs. - - -3.3.3 Non-existent Source of Synthesis - - In RFC 1034: - -# If the "*" label does not exist, check whether the name -# we are looking for is the original QNAME in the query -# or a name we have followed due to a CNAME. If the name -# is original, set an authoritative name error in the -# response and exit. Otherwise just exit. - - - The above passage is clear, evidenced by the lack of discussion and - mis-implementation of it over the years. It is included for - completeness only. (No attempt is made to re-interpret it lest - a mistake in editing leads to confusion.) - -3.3.4 Type Matching - - RFC 1034 concludes part c with this: - -# If the "*" label does exist, match RRs at that node -# against QTYPE. If any match, copy them into the answer -# section, but set the owner of the RR to be QNAME, and -# not the node with the "*" label. Go to step 6. - - - This final paragraph covers the role of the QTYPE in the lookup process. - - Based on implementation feedback and similarities between step a and - step c a change to this passage a change has been made. - - The change is to add the following text: - - If the data at the source of synthesis is a CNAME, and - QTYPE doesn't match CNAME, copy the CNAME RR into the - answer section of the response changing the owner name - to the QNAME, change QNAME to the canonical name in the - CNAME RR, and go back to step 1. - - This is essentially the same text in step a covering the processing of - CNAME RRSets. - -4. Considerations with Special Types - - - Five types of RRSets owned by a Wild Card Domain Name have caused - confusion. Four explicit types causing confusion are SOA, NS, CNAME, - DNAME, and the fifth type - "none." - -4.1. SOA RR's at a Wild Card Domain Name - - - A Wild Card Domain Name owning an SOA RRSet means that the domain - is at the root of the zone (apex). The domain can not be a Source of - Synthesis because that is, but definition, a descendent node (of - the Closest Encloser) and a zone apex is at the top of the zone. - - Although a Wild Card Domain Name can not be a Source of Synthesis, - there is no reason to forbid the ownership of an SOA RRSet. This - means that zones with names like "*..", and even - "*..." - - Step 2 (section 3.1) does not provide a means to specify a means to - synthesize a zone. Therefore, according to the rules there, the - only way in which a zone that has a name which is a Wild Card - Domain Name is if the QNAME is in a domain below the zone's name. - - E.g., if *.example. has an SOA record, then only a query like - QNAME=*.example., QTYPE=A, QCLASS=IN would see it. As another - example, a QNAME of www.*.example. would also result in passing - through the zone. - -4.2. NS RR's at a Wild Card Domain Name - - - The semantics of a Wild Card Domain Name ownership of a NS RRSet - has been unclear. Looking through RFC 1034, the recommendation - is to have the NS RRSet act the same a any non-special type, e.g., - like an A RR. - - If the NS RRSet in question is at the top of the zone, i.e., the - name also owns an SOA RRSet, the QNAME equals the zone name. This - would trigger part 'a' of Step 3. - - In any other case, the Wild Card Domain Name owned NS RRSet would - be the only RRSet (prior to changes instituted by DNSSEC) at the - node by DNS rules. If the QNAME equals the Wild Card Domain Name - or is a subdomain of it, then the node would be considered in part - 'b' of Step 3. - - Note that there is no synthesis of records in the authority section - because part 'b' does not account for synthesis. The referral - returned would have the Wild Card Domain Name in the authority section, - unchanged. - - If the QNAME is not the same as the Wild Card Domain Name nor a - subdomain of it, then part 'c' of Step 3 has been triggered. Once - part 'c' is entered, there is no reverting to part 'b' - i.e., - once an NS RRSet is synthesized it does not mean that the server has - to consider the name delegated away. I.e., the server is not - synthesizing a record (the NS RRSet) that means the server does not - have the right to synthesize. - -4.3. CNAME RR's at a Wild Card Domain Name - - The issue of CNAME RR's owned by wild card domain names has prompted - a suggested change to the last paragraph of step 3c of the algorithm - in 4.3.2. The changed text appears in section 3.3.4 of this document. - -4.4. DNAME RR's at a Wild Card Domain Name - - The specification of the DNAME RR, which is at the proposed level of - standardization, is not as mature as the full standard in RFC 1034. - Because of this, or the reason for this is, there appears to be a - a number of issues with that definition and it's rewrite of the algorithm - in 4.3.2. For the time being, when it comes to wild card processing - issues, a DNAME can be considered to be a CNAME synthesizer. A DNAME - at a wild card domain name is effectively the same as a CNAME at a - wild card domain name. - -4.5 Empty Non-terminal Wild Card Domain Name - - - If a Source of Synthesis is an empty non-terminal, then the response - will be one of no error in the return code and no RRSet in the answer - section. - -5. Security Considerations - - This document is refining the specifications to make it more likely - that security can be added to DNS. No functional additions are being - made, just refining what is considered proper to allow the DNS, - security of the DNS, and extending the DNS to be more predictable. - -6. References - - Normative References - - [RFC 20] ASCII Format for Network Interchange, V.G. Cerf, Oct-16-1969 - - [RFC 1034] Domain Names - Concepts and Facilities, P.V. Mockapetris, - Nov-01-1987 - - [RFC 1035] Domain Names - Implementation and Specification, P.V - Mockapetris, Nov-01-1987 - - [RFC 2119] Key Words for Use in RFCs to Indicate Requirement Levels, S - Bradner, March 1997 - - Informative References - - [RFC 2136] Dynamic Updates in the Domain Name System (DNS UPDATE), P. - Vixie, Ed., S. Thomson, Y. Rekhter, J. Bound, April 1997 - - [RFC 2535] Domain Name System Security Extensions, D. Eastlake, March 1999 - - [RFC 2672] Non-Terminal DNS Name Redirection, M. Crawford, August 1999 - -7. Others Contributing to This Document - - Others who have been editors of this document: Bob Halley and Robert Elz. - Others who have directly caused text to appear in the document: Paul - Vixie and Olaf Kolkman. Many others have indirect influences on the - content. - -8. Editor - - Name: Edward Lewis - Affiliation: NeuStar - Address: tbd - Phone: tbd - Email: tbd (please send comments to namedroppers) - - Comments on this document can be sent to the editors or the mailing - list for the DNSEXT WG, namedroppers@ops.ietf.org. - -9. Trailing Boilerplate - - Copyright (C) The Internet Society (2004). This document is subject - to the rights, licenses and restrictions contained in BCP 78 and - except as set forth therein, the authors retain all their rights. - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Intellectual Property - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. The IETF invites any interested party to - bring to its attention any copyrights, patents or patent - applications, or other proprietary rights that may cover technology - that may be required to implement this standard. Please address the - information to the IETF at ietf-ipr@ietf.org. - -Acknowledgement - - Funding for the RFC Editor function is currently provided by the - Internet Society. - -Expiration - - This document expires on or about 11 April 2005. diff --git a/doc/draft/draft-ietf-dnsext-wcard-clarify-05.txt b/doc/draft/draft-ietf-dnsext-wcard-clarify-05.txt new file mode 100644 index 0000000000..d7ca44db0f --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-wcard-clarify-05.txt @@ -0,0 +1,842 @@ + +DNSEXT Working Group E. Lewis +INTERNET DRAFT NeuStar +Expiration Date: August 10, 2005 February 2005 + + The Role of Wildcard Domains + in the Domain Name System + + draft-ietf-dnsext-wcard-clarify-05.txt + +Status of this Memo + + By submitting this Internet-Draft, each author represents that any + applicable patent or other IPR claims of which he or she is aware + have been or will be disclosed, and any of which he or she becomes + aware will be disclosed, in accordance with Section 6 of RFC 3668. + + 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 August 10, 2005. + +Copyright Notice + + Copyright (C) The Internet Society (2005). + +Abstract + + This is an update to the wildcard definition of RFC 1034. The + interaction with wildcards and CNAME is changed, an error + condition removed, and the words defining some concepts central to + wildcards are changed. The overall goal is not to change wildcards, + but to refine the definition of RFC 1034. + +1 Introduction + + In RFC 1034 [RFC1034], sections 4.3.2 and 4.3.3 describe the synthesis + of answers from special resource records called wildcards. The definition + in RFC 1034 is incomplete and has proven to be confusing. This document + describes the wildcard synthesis by adding to the discussion and making + limited modifications. Modifications are made to close inconsistencies + that have led to interoperability issues. This description does not + expand the service intended by the original definition. + + Staying within the spirit and style of the original documents, this + document avoids specifying rules for DNS implementations regarding + wildcards. The intention is to only describe what is needed for + interoperability, not restrict implementation choices. In addition, + consideration has been given to minimize any backwards compatibility + with implementations that have complied with RFC 1034's definition. + + This document is focused on the concept of wildcards as defined in RFC + 1034. Nothing is implied regarding alternative approaches, nor are + alternatives discussed. + + [Note to the WG - this draft is not complete, it is presented as fodder + for the upcoming meeting. Sections 4.2.3, 4.6, 3.7, and 4.8 are + particularly incomplete. I wanted to make sure there was something + recent in the draft repository before setting out on more travel. + + For 4.2.3, refer to the threads for the most recent discussions... + http://ops.ietf.org/lists/namedroppers/namedroppers.2004/msg01601.html + http://ops.ietf.org/lists/namedroppers/namedroppers.2004/msg01603.html + + And you might want to check out the minutes from the last IETF meeting + as well as http://www.ietf.org/proceedings/03nov/131.htm.] + +1.1 Motivation + + Many DNS implementations have diverged with respect to wildcards in + different ways from the original definition, or at from least what + had been intended. Although there is clearly a need to clarify the + original documents in light of this alone, the impetus for this document + lay in the engineering of the DNS security extensions [RFC TBD]. With + an unclear definition of wildcards the design of authenticated denial + became entangled. + + This document is intended to limit changes, only those based on + implementation experience, and to remain as close to the original + document as possible. To reinforce this, relevant sections of RFC + 1034 are repeated verbatim to help compare the old and new text. + +1.2 The Original Definition + + The context of the wildcard concept involves the algorithm by which + a name server prepares a response (in RFC 1034's section 4.3.2) and + the way in which a resource record (set) is identified as being a + source of synthetic data (section 4.3.3). + + The beginning of the discussion ought to start with the definition + of the term "wildcard" as it appears in RFC 1034, section 4.3.3. + +# In the previous algorithm, special treatment was given to RRs with owner +# names starting with the label "*". Such RRs are called wildcards. +# Wildcard RRs can be thought of as instructions for synthesizing RRs. +# When the appropriate conditions are met, the name server creates RRs +# with an owner name equal to the query name and contents taken from the +# wildcard RRs. + + This passage appears after the algorithm in which the term wildcard + is first used. In this definition, wildcard refers to resource + records. In other usage, wildcard has referred to domain names, and + it has been used to describe the operational practice of relying on + wildcards to generate answers. It is clear from this that there is + a need to define clear and unambiguous terminology in the process of + discussing wildcards. + + The mention of the use of wildcards in the preparation of a response + is contained in step 3c of RFC 1034's section 4.3.2 entitled "Algorithm." + Note that "wildcard" does not appear in the algorithm, instead references + are made to the "*" label. The portion of the algorithm relating to + wildcards is deconstructed in detail in section 3 of this document, + this is the beginning of the passage. + +# c. If at some label, a match is impossible (i.e., the +# corresponding label does not exist), look to see if a +# the "*" label exists. + + The scope of this document is the RFC 1034 definition of wildcards and + the implications of updates to those documents, such as DNSSEC. Alternate + schemes for synthesizing answers are not considered. (Note that there + is no reference listed. No document is known to describe any alternate + schemes, although there has been some mention of them in mailing lists.) + +1.3 This Document + + This document accomplishes these three items. + o Defines new terms + o Makes minor changes to avoid conflicting concepts + o Describe the actions of certain resource records as wildcards + +1.3.1 New Terms + + To help in discussing what resource records are wildcards, two terms + will be defined - "asterisk label" and "wild card domain name". These + are defined in section 2.1.1. + + To assist in clarifying the role of wildcards in the name server algorithm + in RFC 1034, 4.3.2, "source of synthesis" and "closest encloser" are + defined. These definitions are in section 3.3.2. "Label match" is + defined in section 3.2. + + The introduction of new terms ought not have an impact on any existing + implementations. The new terms are used only to make discussions of + wildcards clearer. + +1.3.2 Changed Text + + The definition of "existence" is changed, superficially. This + change will not be apparent to implementations; it is needed to + make descriptions more precise. The change appears in section 2.2.3. + + RFC 1034, section 4.3.3., seems to prohibit having two asterisk + labels in a wildcard owner name. With this document the restriction + is removed entirely. This change and its implications are in + section 2.1.3. + + The actions when a source of synthesis owns a CNAME RR are changed to + mirror the actions if an exact match name owns a CNAME RR. This + is an addition to the words in RFC 1034, section 4.3.2, step 3, + part c. The discussion of this is in section 3.3.3. + + Only the latter change represents an impact to implementations. The + definition of existence is not a protocol impact. The change to the + restriction on names is unlikely to have an impact, as there was no + discussion of how to enforce the restriction. + +1.3.3 Considerations with Special Types + + This document describes semantics of wildcard CNAME RRSets [RFC2181], + wildcard NS RRSets, wildcard SOA RRSets, wildcard DNAME RRSets + [RFC2672], wildcard DS RRSets [RFC TBD], and empty non-terminal + wildcards. Understanding these types in the context of wildcards + has been clouded because these types incur special processing if they + are the result of an exact match. This discussion is in section 4. + + These discussions do not have an implementation impact, they cover + existing knowledge of the types, but to a greater level of detail. + +1.4 Standards Terminology + + This document does not use terms as defined in "Key words for use in + RFCs to Indicate Requirement Levels." [RFC2119] + + Quotations of RFC 1034 are denoted by a '#' in the leftmost column. + +2 Wildcard Syntax + + The syntax of a wildcard is the same as any other DNS resource record, + across all classes and types. The only significant feature is the + owner name. + + Because wildcards are encoded as resource records with special names, + they are included in zone transfers and incremental zone transfers. + [RFC1995]. This feature has been underappreciated until discussions + on alternative approaches to wildcards appeared on mailing lists. + +2.1 Identifying a wildcard + + To provide a more accurate description of "wildcards", the definition + has to start with a discussion of the domain names that appear as + owners. Two new terms are needed, "Asterisk Label" and "Wild Card + Domain Name." + +2.1.1 Wild Card Domain Name and Asterisk Label + + A "wild card domain name" is defined by having its initial + (i.e., left-most or least significant) label be, in binary format: + + 0000 0001 0010 1010 (binary) = 0x01 0x2a (hexadecimal) + + The first octet is the normal label type and length for a 1 octet + long label, the second octet is the ASCII representation [RFC20] for + the '*' character. + + A descriptive name of a label equaling that value is an "asterisk + label." + + RFC 1034's definition of wildcard would be "a resource record owned + by a wild card domain name." + +2.1.2 Asterisks and Other Characters + + No label values other than that in section 2.1.1 are asterisk labels, + hence names beginning with other labels are never wild card domain + names. Labels such as 'the*' and '**' are not asterisk labels, + they do not start wild card domain names. + +2.1.3 Non-terminal Wild Card Domain Names + + In section 4.3.3, the following is stated: + +# .......................... The owner name of the wildcard RRs is of +# the form "*.", where is any domain name. +# should not contain other * labels...................... + + This restriction is lifted because the original documentation of it + is incomplete and the restriction does not serve any purpose given + years of operational experience. + + Indirectly, the above passage raises questions about wild card domain + names having subdomains and possibly being an empty non-terminal. By + thinking of domain names such as "*.example.*.example." and + "*.*.example." and focusing on the right-most asterisk label in each, + the issues become apparent. + + Although those example names have been restricted per RFC 1034, a name + such as "example.*.example." illustrates the same problems. The + sticky issue of subdomains and empty non-terminals is not removed by + the restriction. With that conclusion, the restriction appears to + be meaningless, worse yet, it implies that an implementation would have + to perform checks that do little more than waste CPU cycles. + + A wild card domain name can have subdomains. There is no need to + inspect the subdomains to see if there is another asterisk label in + any subdomain. + + A wild card domain name can be an empty non-terminal. (See the upcoming + sections on empty non-terminals.) In this case, any lookup encountering + it will terminate as would any empty non-terminal match. + +2.2 Existence Rules + + The notion that a domain name 'exists' is mentioned in the definition + of wildcards. In section 4.3.3 of RFC 1034: + +# Wildcard RRs do not apply: +# +... +# - When the query name or a name between the wildcard domain and +# the query name is know[n] to exist. For example, if a wildcard + + RFC 1034 also refers to non-existence in the process of generating + a response that results in a return code of "name error." NXDOMAIN + is introduced in RFC 2308, section 2.1 says "In this case the domain + ... does not exist." The overloading of the term "existence" is + confusing. + + For the purposes of this document, a domain name is said to exist if + it plays a role in the execution of the algorithms in RFC 1034. This + document avoids discussion determining when an authoritative name + error has occurred. + +2.2.1 An Example + + To illustrate what is meant by existence consider this complete zone: + + $ORIGIN example. + example. 3600 IN SOA + example. 3600 NS ns.example.com. + example. 3600 NS ns.example.net. + *.example. 3600 TXT "this is a wild card" + *.example. 3600 MX 10 host1.example. + sub.*.example. 3600 TXT "this is not a wild card" + host1.example. 3600 A 192.0.4.1 + _ssh._tcp.host1.example. 3600 SRV + _ssh._tcp.host2.example. 3600 SRV + subdel.example. 3600 NS ns.example.com. + subdel.example. 3600 NS ns.example.net. + + A look at the domain names in a tree structure is helpful: + + | + -------------example------------ + / / \ \ + / / \ \ + / / \ \ + * host1 host2 subdel + | | | + | | | + sub _tcp _tcp + | | + | | + _ssh _ssh + + The following queries would be synthesized from one of the wildcards: + + QNAME=host3.example. QTYPE=MX, QCLASS=IN + the answer will be a "host3.example. IN MX ..." + + QNAME=host3.example. QTYPE=A, QCLASS=IN + the answer will reflect "no error, but no data" + because there is no A RR set at '*.example.' + + QNAME=foo.bar.example. QTYPE=TXT, QCLASS=IN + the answer will be "foo.bar.example. IN TXT ..." + because bar.example. does not exist, but the wildcard does. + + The following queries would not be synthesized from any of the wildcards: + + QNAME=host1.example., QTYPE=MX, QCLASS=IN + because host1.example. exists + + QNAME=ghost.*.example., QTYPE=MX, QCLASS=IN + because *.example. exists + + QNAME=sub.*.example., QTYPE=MX, QCLASS=IN + because sub.*.example. exists + + QNAME=_telnet._tcp.host1.example., QTYPE=SRV, QCLASS=IN + because _tcp.host1.example. exists (without data) + + QNAME=host.subdel.example., QTYPE=A, QCLASS=IN + because subdel.example. exists (and is a zone cut) + +2.2.2 Empty Non-terminals + + Empty non-terminals [RFC2136, Section 7.16] are domain names that own + no resource records but have subdomains that do. In section 2.2.1, + "_tcp.host1.example." is an example of a empty non-terminal name. + Empty non-terminals are introduced by this text in section 3.1 of RFC + 1034: + +# The domain name space is a tree structure. Each node and leaf on the +# tree corresponds to a resource set (which may be empty). The domain +# system makes no distinctions between the uses of the interior nodes and +# leaves, and this memo uses the term "node" to refer to both. + + The parenthesized "which may be empty" specifies that empty non- + terminals are explicitly recognized, and that empty non-terminals + "exist." + + Pedantically reading the above paragraph can lead to an + interpretation that all possible domains exist - up to the suggested + limit of 255 octets for a domain name [RFC1035]. For example, + www.example. may have an A RR, and as far as is practically + concerned, is a leaf of the domain tree. But the definition can be + taken to mean that sub.www.example. also exists, albeit with no data. + By extension, all possible domains exist, from the root on down. As + RFC 1034 also defines "an authoritative name error indicating that + the name does not exist" in section 4.3.1, this is not the intent of + the original document. + +2.2.3 Yet Another Definition of Existence + + RFC1034's wording is fixed by the following paragraph: + + The domain name space is a tree structure. Nodes in the tree either + own at least one RRSet and/or have descendants that collectively own at + least on RRSet. A node may have no RRSets if it has descendents that + do, this node is a empty non-terminal. A node may have its own RRSets + and have descendants with RRSets too. + + A node with no descendants is a leaf node. Empty leaf nodes do not + exist. + + Note that at a zone boundary, the domain name owns data, including + the NS RR set. At the delegating server, the NS RR set is not + authoritative, but that is of no consequence here. The domain name + owns data, therefore, it exists. + +2.3 When does a Wild Card Domain Name is not Special + + When a wild card domain name appears in a message's query section, + no special processing occurs. An asterisk label in a query name + only (label) matches an asterisk label in the existing zone tree + when the 4.3.2 algorithm is being followed. + + When a wild card domain name appears in the resource data of a + record, no special processing occurs. An asterisk label in that + context literally means just an asterisk. + +3. Impact of a Wild Card Domain Name On a Response + + The description of how wildcards impact response generation is in + RFC 1034, section 4.3.2. That passage contains the algorithm + followed by a server in constructing a response. Within that + algorithm, step 3, part 'c' defines the behavior of the wild card. + + The algorithm in RFC 1034, section 4.3.2. is not intended to be pseudo + code, i.e., its steps are not intended to be followed in strict + order. The "algorithm" is a suggestion. As such, in step 3, parts + a, b, and c, do not have to be implemented in that order. + +3.1 Step 2 + + Step 2 of the RFC 1034's section 4.3.2 reads: + +# 2. Search the available zones for the zone which is the nearest +# ancestor to QNAME. If such a zone is found, go to step 3, +# otherwise step 4. + + In this step, the most appropriate zone for the response is chosen. + The significance of this step is that it means all of step 3 is being + performed within one zone. This has significance when considering + whether or not an SOA RR can be ever be used for synthesis. + +3.2 Step 3 + + Step 3 is dominated by three parts, labelled 'a', 'b', and 'c'. But the + beginning of the step is important and needs explanation. + +# 3. Start matching down, label by label, in the zone. The +# matching process can terminate several ways: + + The word 'matching' refers to label matching. The concept + is based in the view of the zone as the tree of existing names. The + query name is considered to be an ordered sequence of labels - as + if the name were a path from the root to the owner of the desired + data. (Which it is - 3rd paragraph of RFC 1034, section 3.1.) + + The process of label matching a query name ends in exactly one of three + choices, the parts 'a', 'b', and 'c'. Either the name is found, the + name is below a cut point, or the name is not found. + + Once one of the parts is chosen, the other parts are not considered. + (E.g., do not execute part 'c' and then change the execution path to + finish in part 'b'.) The process of label matching is also done + independent of the query type (QTYPE). + + Parts 'a' and 'b' are not an issue for this clarification as they do not + relate to record synthesis. Part 'a' is an exact match that results in + an answer, part 'b' is a referral. It is possible, from the description + given, that a query might fit into both part a and part b, this is + not within the scope of this document. + +3.3 Part 'c' + + The context of part 'c' is that the process of label matching the + labels of the query name has resulted in a situation in which there + is no corresponding label in the tree. It is as if the lookup has + "fallen off the tree." + +# c. If at some label, a match is impossible (i.e., the +# corresponding label does not exist), look to see if a +# the "*" label exists. + + + To help describe the process of looking 'to see if a [sic] the "*" + label exists' a term has been coined to describe the last label + matched. The term is "closest encloser." + +3.3.1 Closest Encloser and the Source of Synthesis + + The closest encloser is the node in the zone's tree of existing + domain names that has the most labels matching the query name + (consecutively, counting from the root label downward). Each match + is a "label match" and the order of the labels is the same. + + The closest encloser is, by definition, an existing name in the zone. The + closest encloser might be an empty non-terminal or even be a wild card + domain name itself. In no circumstances is the closest encloser + the used to synthesize records for the current query. + + The source of synthesis is defined in the context of a query process + as that wild card domain name immediately descending from the + closest encloser, provided that this wild card domain name exists. + "Immediately descending" means that the source of synthesis has a name + of the form .. A source of synthesis + does not guarantee having a RRSet to use for synthesis. The source of + synthesis could be an empty non-terminal. + + If the source of synthesis does not exist (not on the domain tree), + there will be no wildcard synthesis. There is no search for an alternate. + + The important concept is that for any given lookup process, there + is at most one place at which wildcard synthetic records can be + obtained. If the source of synthesis does not exist, the lookup + terminates, the lookup does not look for other wildcard records. + +3.3.2 Closest Encloser and Source of Synthesis Examples + + To illustrate, using the example zone in section 2.2.1 of this document, + the following chart shows QNAMEs and the closest enclosers. + + QNAME Closest Encloser Source of Synthesis + host3.example. example. *.example. + _telnet._tcp.host1.example. _tcp.host1.example. no source + _telnet._tcp.host2.example. host2.example. no source + _telnet._tcp.host3.example. example. *.example. + _chat._udp.host3.example. example. *.example. + foobar.*.example. *.example. no source + +3.3.3 Type Matching + + RFC 1034 concludes part 'c' with this: + +# If the "*" label does not exist, check whether the name +# we are looking for is the original QNAME in the query +# or a name we have followed due to a CNAME. If the name +# is original, set an authoritative name error in the +# response and exit. Otherwise just exit. +# +# If the "*" label does exist, match RRs at that node +# against QTYPE. If any match, copy them into the answer +# section, but set the owner of the RR to be QNAME, and +# not the node with the "*" label. Go to step 6. + + The final paragraph covers the role of the QTYPE in the lookup process. + + Based on implementation feedback and similarities between step 'a' and + step 'c' a change to this passage a change has been made. + + The change is to add the following text to step 'c': + + If the data at the source of synthesis is a CNAME, and + QTYPE doesn't match CNAME, copy the CNAME RR into the + answer section of the response changing the owner name + to the QNAME, change QNAME to the canonical name in the + CNAME RR, and go back to step 1. + + This is essentially the same text in step a covering the processing of + CNAME RRSets. + +4. Considerations with Special Types + + Sections 2 and 3 of this document discuss wildcard synthesis with + respect to names in the domain tree and ignore the impact of types. + In this section, the implication of wildcards of specific types are + discussed. The types covered are those that have proven to be the + most difficult to understand. The types are SOA, NS, CNAME, DNAME, + SRV, DS, NSEC, RRSIG and "none," i.e., empty non-terminal wild card + domain names. + +4.1 SOA RRSet at a Wild Card Domain Name + + A wild card domain name owning an SOA RRSet means that the domain + is at the root of the zone (apex). The domain can not be a source of + synthesis because that is, by definition, a descendent node (of + the closest encloser) and a zone apex is at the top of the zone. + + Although a wild card domain name owning an SOA RRSet can never be a + source of synthesis, there is no reason to forbid the ownership of + an SOA RRSet. + + E.g., given this zone: + $ORIGIN *.example. + @ 3600 IN SOA + 3600 NS ns1.example.com. + 3600 NS ns1.example.net. + www 3600 TXT "the www txt record" + + A query for www.*.example.'s TXT record would still find the "the www txt + record" answer. The reason is that the asterisk label only becomes + significant when RFC 1034's 4.3.2, step 3 part 'c' in in effect. + + Of course, there would need to be a delegation in the parent zone, + "example." for this to work too. This is covered in the next section. + +4.2 NS RRSet at a Wild Card Domain Name + + The semantics of a wild card domain name's ownership of a NS RRSet + has been unclear. There are three considerations to cover. One is + is that if the query processing lands in part 'a' or part 'b' of + RFC 1034's 4.3.2, step 3, the incidence of the wild card domain name + owning an NS RRset has no special meaning. Second, synthesized + records never appear in the authority section of a response, meaning + that referrals are never synthesized. And finally, DNSSEC validators + will have to be aware of a quirk in ownership rules. + +4.2.1 NS, *, and answers + + If the NS RRSet in question is at the top of the zone, i.e., the + name also owns an SOA RRSet, the QNAME equals the zone name. This + would trigger part 'a' of step 3. + +4.2.2 NS, *, and referrals + + If the NS RRset is not at the top of the zone and part 'b' is triggered, + this implies that the labels being matched are an asterisk label in + the QNAME and the asterisk label owning the NS RRset. In either case, + what is copied to the response will have the asterisk label in it - no + synthesis, no name substitution. + + E.g., consider the parent zone for the example in section 4.1. + $ORIGIN example. + @ 3600 IN SOA + 3600 NS ns0.example.com. + 3600 NS ns0.example.net. + * 3600 NS ns1.example.com. + 3600 NS ns1.example.net. + + If the query for www.*.example.'s TXT set arrived here, the response + would be a referral as in part 'b'. + + Response, non-authoritative, no error rcode + ANSWER: (empty) + AUTHORITY: + * 3600 NS ns1.example.com. + 3600 NS ns1.example.net. + ADDITIIONAL: (empty, or with OPT RR) + + The same response message would be sent to a query for *.example.'s NS + set. Note that the NS records in the response are not expanded, simply + copied verbatim. (Compare this the case where "*" is "star".) + + There is no synthesis of records in the authority section because part + 'b' does not specify synthesis. The referral returned would have the + wild card domain name in the authority section unchanged. + +4.2.3 NS, *, and synthesis + + If the QNAME is not the same as the wild card domain name nor a + subdomain of it, then part 'c' of step 3 has been triggered. Assuming + that "a match is impossible" a source of synthesis is sought. If + the source of synthesis owns an NS RRset and the QTYPE is NS, then + a NS RRset is synthesized and put into the answer section and marked + as an authoritative answer. If the QTYPE is not NS, then the NS RRset + is ignored, as it would have been if it were an A RR and the QTYPE was + AAAA. An NS RRSet at a wild card domain name will not result in + the generation of referral messages for non-existent domains because + part 'c' does not write anything into the authority section. + + (If we choose this, then we have to have a section 4.2.4 on DNSSEC + implications.) + +OR + + If the QNAME is not the same as the wild card domain name nor a + subdomain of it, then part 'c' of step 3 has been triggered. Assuming + that "a match is impossible" a source of synthesis is sought. If + the source of synthesis owns an NS RRset and the QTYPE is NS, then + no synthesis happens. A NS RRset is never synthesized. The proper + response is, what, no error/no data? Name error? + +OR + + If the QNAME is not the same as the wild card domain name nor a + subdomain of it, then part 'c' of step 3 has been triggered. Assuming + that "a match is impossible" a source of synthesis is sought. If + the source of synthesis owns an NS RRset then no synthesis happens. + A cut point is never a source of synthesis. The proper response is, + what, no error/no data? Name error? + +4.3 CNAME RRSet at a Wild Card Domain Name + + The issue of a CNAME RRSet owned by wild card domain names has prompted + a suggested change to the last paragraph of step 3c of the algorithm + in 4.3.2. The changed text appears in section 3.3.3 of this document. + +4.4 DNAME RRSet at a Wild Card Domain Name + + A DNAME RRset at a wild card domain name is effectively the same + as a CNAME at a wild card domain name. + +4.5 SRV RRSet at a Wild Card Domain Name + + The definition of the SRV RRset is RFC 2782 [RFC2782]. In the + definition of the record, there is some confusion over the term + "Name." The definition reads as follows: + +# The format of the SRV RR +... +# _Service._Proto.Name TTL Class SRV Priority Weight Port Target +... +# Name +# The domain this RR refers to. The SRV RR is unique in that the +# name one searches for is not this name; the example near the end +# shows this clearly. + + Do not confuse the definition "Name" with a domain name. I.e., once + removing the _Service and _Proto labels from the owner name of the + SRV RRSet, what remains could be a wild card domain name but this is + immaterial to the SRV RRSet. + + E.g., If an SRV record is: + _foo._udp.*.example. 10800 IN SRV 0 1 9 old-slow-box.example. + + *.example is a wild card domain name and although it it the Name of + the SRV RR, it is not the owner (domain name). The owner domain name + is "_foo._udp.*.example." which is not a wild card domain name. + + The confusion is likely based on the mixture of the specification of + the SRV RR and the description of a "use case." + +4.6 DS RRSet at a Wild Card Domain Name + +...probably harmless... + +4.7 NSEC RRSet at a Wild Card Domain Name + +...will be present, don't know if it should be synthesized... + +4.8 RRSIG at a Wild Card Domain Name + +...need to cross check with DNSSECbis to see what is said about querying +for RRSIG... + +4.9 Empty Non-terminal Wild Card Domain Name + + If a source of synthesis is an empty non-terminal, then the response + will be one of no error in the return code and no RRSet in the answer + section. + +5. Security Considerations + + This document is refining the specifications to make it more likely + that security can be added to DNS. No functional additions are being + made, just refining what is considered proper to allow the DNS, + security of the DNS, and extending the DNS to be more predictable. + +6. References + + Normative References + + [RFC20] ASCII Format for Network Interchange, V.G. Cerf, Oct-16-1969 + + [RFC1034] Domain Names - Concepts and Facilities, P.V. Mockapetris, + Nov-01-1987 + + [RFC1035] Domain Names - Implementation and Specification, P.V + Mockapetris, Nov-01-1987 + + [RFC1995] IXFR ... Ohta + + [RFC2119] Key Words for Use in RFCs to Indicate Requirement Levels, S + Bradner, March 1997 + + [RFC2181] Clarifications to the DNS Specification, R. Elz and R. Bush, + July 1997. + + [RFC2782] A DNS RR for specifying the location of services (DNS SRV), + A. Gulbrandsen, et.al., February 2000. + + Informative References + + [RFC2136] Dynamic Updates in the Domain Name System (DNS UPDATE), P. + Vixie, Ed., S. Thomson, Y. Rekhter, J. Bound, April 1997 + + [RFC2535] Domain Name System Security Extensions, D. Eastlake, March 1999 + + [RFC2672] Non-Terminal DNS Name Redirection, M. Crawford, August 1999 + +7. Others Contributing to This Document + + Others who have been editors of this document: Bob Halley. + Others who have directly caused text to appear in the document: Alex + Bligh, Robert Elz, Paul Vixie, David Blacka and Olaf Kolkman. + Many others have indirect influences on the content. + +8. Editor + + Name: Edward Lewis + Affiliation: NeuStar + Address: 46000 Center Oak Plaza, Sterling, VA, 20166, US + Phone: +1-571-434-5468 + Email: ed.lewis@neustar.biz + + Comments on this document can be sent to the editor or the mailing + list for the DNSEXT WG, namedroppers@ops.ietf.org. + +9. Trailing Boilerplate + + Copyright (C) The Internet Society (2004). This document is subject + to the rights, licenses and restrictions contained in BCP 78 and + except as set forth therein, the authors retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. The IETF invites any interested party to + bring to its attention any copyrights, patents or patent + applications, or other proprietary rights that may cover technology + that may be required to implement this standard. Please address the + information to the IETF at ietf-ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + +Expiration + + This document expires on or about August 10, 2005. + + + + diff --git a/doc/draft/draft-ietf-dnsop-bad-dns-res-02.txt b/doc/draft/draft-ietf-dnsop-bad-dns-res-02.txt deleted file mode 100644 index e9943015e4..0000000000 --- a/doc/draft/draft-ietf-dnsop-bad-dns-res-02.txt +++ /dev/null @@ -1,1120 +0,0 @@ - - -DNS Operations M. Larson -Internet-Draft P. Barber -Expires: August 16, 2004 VeriSign - February 16, 2004 - - - Observed DNS Resolution Misbehavior - draft-ietf-dnsop-bad-dns-res-02 - -Status of this Memo - - This document is an Internet-Draft and is in full conformance with - all provisions of Section 10 of RFC2026. - - 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 August 16, 2004. - -Copyright Notice - - Copyright (C) The Internet Society (2004). All Rights Reserved. - -Abstract - - This Internet-Draft describes DNS name server and resolver behavior - that results in a significant query volume sent to the root and - top-level domain (TLD) name servers. In some cases we recommend - minor additions to the DNS protocol specification and corresponding - changes in name server implementations to alleviate these unnecessary - queries. The recommendations made in this document are a direct - byproduct of observation and analysis of abnormal query traffic - patterns seen at two of the thirteen root name servers and all - thirteen com/net TLD name servers. - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - - - -Larson & Barber Expires August 16, 2004 [Page 1] - -Internet-Draft Observed DNS Resolution Misbehavior February 2004 - - - document are to be interpreted as described in RFC 2119 [1]. - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3 - 2. Observed name server misbehavior . . . . . . . . . . . . . 4 - 2.1 Aggressive requerying for delegation information . . . . . 4 - 2.1.1 Recommendation . . . . . . . . . . . . . . . . . . . . . . 5 - 2.2 Repeated queries to lame servers . . . . . . . . . . . . . 5 - 2.2.1 Recommendation . . . . . . . . . . . . . . . . . . . . . . 6 - 2.3 Inability to follow multiple levels of out-of-zone glue . 6 - 2.3.1 Recommendation . . . . . . . . . . . . . . . . . . . . . . 7 - 2.4 Aggressive retransmission when fetching glue . . . . . . . 7 - 2.4.1 Recommendation . . . . . . . . . . . . . . . . . . . . . . 8 - 2.5 Aggressive retransmission behind firewalls . . . . . . . . 8 - 2.5.1 Recommendation . . . . . . . . . . . . . . . . . . . . . . 8 - 2.6 Misconfigured NS records . . . . . . . . . . . . . . . . . 9 - 2.6.1 Recommendation . . . . . . . . . . . . . . . . . . . . . . 10 - 2.7 Name server records with zero TTL . . . . . . . . . . . . 10 - 2.7.1 Recommendation . . . . . . . . . . . . . . . . . . . . . . 11 - 2.8 Unnecessary dynamic update messages . . . . . . . . . . . 11 - 2.8.1 Recommendation . . . . . . . . . . . . . . . . . . . . . . 11 - 2.9 Queries for domain names resembling IP addresses . . . . . 12 - 2.9.1 Recommendation . . . . . . . . . . . . . . . . . . . . . . 12 - 2.10 Misdirected recursive queries . . . . . . . . . . . . . . 12 - 2.10.1 Recommendation . . . . . . . . . . . . . . . . . . . . . . 13 - 2.11 Suboptimal name server selection algorithm . . . . . . . . 13 - 2.11.1 Recommendation . . . . . . . . . . . . . . . . . . . . . . 13 - 3. IANA considerations . . . . . . . . . . . . . . . . . . . 15 - 4. Security considerations . . . . . . . . . . . . . . . . . 16 - 5. Internationalization considerations . . . . . . . . . . . 17 - Normative References . . . . . . . . . . . . . . . . . . . 18 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . 18 - Intellectual Property and Copyright Statements . . . . . . 19 - - - - - - - - - - - - - - - - - -Larson & Barber Expires August 16, 2004 [Page 2] - -Internet-Draft Observed DNS Resolution Misbehavior February 2004 - - -1. Introduction - - Observation of query traffic received by two root name servers and - the thirteen com/net TLD name servers has revealed that a large - proportion of the total traffic often consists of "requeries". A - requery is the same question () asked - repeatedly at an unexpectedly high rate. We have observed requeries - from both a single IP address and multiple IP addresses. - - By analyzing requery events we have found that the cause of the - duplicate traffic is almost always a deficient name server, stub - resolver and/or application implementation combined with an - operational anomaly. The implementation deficiencies we have - identified to date include well-intentioned recovery attempts gone - awry, insufficient caching of failures, early abort when multiple - levels of glue records must be followed, and aggressive retry by stub - resolvers and/or applications. Anomalies that we have seen trigger - requery events include lame delegations, unusual glue records, and - anything that makes all authoritative name servers for a zone - unreachable (DoS attacks, crashes, maintenance, routing failures, - congestion, etc.). - - In the following sections, we provide a detailed explanation of the - observed behavior and recommend changes that will reduce the requery - rate. Some of the changes recommended affect the core DNS protocol - specification, described principally in RFC 1034 [2], RFC 1035 [3] - and RFC 2181 [4]. - - - - - - - - - - - - - - - - - - - - - - - - -Larson & Barber Expires August 16, 2004 [Page 3] - -Internet-Draft Observed DNS Resolution Misbehavior February 2004 - - -2. Observed name server misbehavior - -2.1 Aggressive requerying for delegation information - - There can be times when every name server in a zone's NS RRset is - unreachable (e.g., during a network outage), unavailable (e.g., the - name server process is not running on the server host) or - misconfigured (e.g., the name server is not authoritative for the - given zone, also known as "lame"). Consider a recursive name server - that attempts to resolve a query for a domain name in such a zone and - discovers that none of the zone's name servers can provide an answer. - We have observed a recursive name server implementation that then - verifies the zone's NS RRset in its cache by querying for the zone's - delegation information: it sends a query for the zone's NS RRset to - one of the parent zone's name servers. - - For example, suppose that "example.com" has the following NS RRset: - - example.com. IN NS ns1.example.com. - example.com. IN NS ns2.example.com. - - Upon receipt of a query for "www.example.com" and assuming that - neither "ns1.example.com" nor "ns2.example.com" can provide an - answer, this recursive name server implementation immediately queries - a "com" zone name server for the "example.com" NS RRset to verify it - has the proper delegation information. This name server - implementation performs this query to a zone's parent zone for each - recursive query it receives that fails because of a completely - unresponsive set of name servers for the target zone. Consider the - effect when a popular zone experiences a catastrophic failure of all - its name servers: now every recursive query for domain names in that - zone sent to this name server implementation results in a query to - the failed zone's parent name servers. On one occasion when several - dozen popular zones became unreachable, the query load on the com/net - name servers increased by 50%. - - We believe this verification query is not reasonable. Consider the - circumstances: When a recursive name server is resolving a query for - a domain name in a zone it has not previously searched, it uses the - list of name servers in the referral from the target zone's parent. - If on its first attempt to search the target zone, none of the name - servers in the referral is reachable, a verification query to the - parent is pointless: this query to the parent would come so quickly - on the heels of the referral that it would be almost certain to - contain the same list of name servers. The chance of discovering any - new information is slim. - - The other possibility is that the recursive name server successfully - - - -Larson & Barber Expires August 16, 2004 [Page 4] - -Internet-Draft Observed DNS Resolution Misbehavior February 2004 - - - contacts one of the target zone's name servers and then caches the NS - RRset from the authority section of a response, the proper behavior - according to section 5.4.1 of RFC 2181 [4], because the NS RRset from - the target zone is more trustworthy than delegation information from - the parent zone. If, while processing a subsequent recursive query, - the recursing name server discovers that none of the name servers - specified in the cached NS RRset is available or authoritative, - querying the parent would be wrong. An NS RRset from the parent zone - would now be less trustworthy than data already in the cache. - - For this query of the parent zone to be useful, the target zone's - entire set of name servers would have to change AND the former set of - name servers would have to be deconfigured and/or decommissioned AND - the delegation information in the parent zone would have to be - updated with the new set of name servers, all within the TTL of the - target zone's NS RRset. We believe this scenario is uncommon: - administrative best practices dictate that changes to a zone's set of - name servers happen gradually, with servers that are removed from the - NS RRset left authoritative for the zone as long as possible. The - scenarios that we can envision that would benefit from the parent - requery behavior do not outweigh its damaging effects. - -2.1.1 Recommendation - - Name servers offering recursion MUST NOT send a query for the NS - RRset of a non-responsive zone to any of the name servers for that - zone's parent zone. For the purposes of this injunction, a - non-responsive zone is defined as a zone for which every name server - listed in the zone's NS RRset: - - 1. is not authoritative for the zone (i.e., lame), or, - - 2. returns a server failure response (RCODE=2), or, - - 3. is dead or unreachable according to section 7.2 of RFC 2308 [5]. - - -2.2 Repeated queries to lame servers - - Section 2.1 describes a catastrophic failure: when every name server - for a zone is unable to provide an answer for one reason or another. - A more common occurrence is a subset of a zone's name servers being - unavailable or misconfigured. Different failure modes have different - expected durations. Some symptoms indicate problems that are - potentially transient: various types of ICMP unreachable messages - because a name server process is not running or a host or network is - unreachable, or a complete lack of a response to a query. Such - responses could be the result of a host rebooting or temporary - - - -Larson & Barber Expires August 16, 2004 [Page 5] - -Internet-Draft Observed DNS Resolution Misbehavior February 2004 - - - outages; these events don't necessarily require any human - intervention and can be reasonably expected to be temporary. - - Other symptoms clearly indicate a condition requiring human - intervention, such as lame server: if a name server is misconfigured - and not authoritative for a zone delegated to it, it is reasonable to - assume that this condition has potential to last longer than - unreachability or unresponsiveness. Consequently, repeated queries - to known lame servers are not useful. In this case of a condition - with potential to persist for a long time, a better practice would be - to maintain a list of known lame servers and avoid querying them - repeatedly in a short interval. - -2.2.1 Recommendation - - Recursive name servers SHOULD cache name servers that they discover - are not authoritative for zones delegated to them (i.e. lame - servers). Lame servers MUST be cached against the specific query - tuple . Zone name can be - derived from the owner name of the NS record that was referenced to - query the name server that was discovered to be lame. - Implementations that perform lame server caching MUST refrain from - sending queries to known lame servers based on a time interval from - when the server is discovered to be lame. A minimum interval of - thirty minutes is RECOMMENDED. - -2.3 Inability to follow multiple levels of out-of-zone glue - - Some recursive name server implementations are unable to follow more - than one level of out-of-zone glue. For example, consider the - following delegations: - - foo.example. IN NS ns1.example.com. - foo.example. IN NS ns2.example.com. - - example.com. IN NS ns1.test.example.net. - example.com. IN NS ns2.test.example.net. - - test.example.net. IN NS ns1.test.example.net. - test.example.net. IN NS ns2.test.example.net. - - A name server processing a recursive query for "www.foo.example" must - follow two levels of indirection, first obtaining address records for - "ns1.test.example.net" and/or "ns2.test.example.net" in order to - obtain address records for "ns1.example.com" and/or "ns2.example.com" - in order to query those name servers for the address records of - "www.foo.example". While this situation may appear contrived, we - have seen multiple similar occurrences and expect more as new generic - - - -Larson & Barber Expires August 16, 2004 [Page 6] - -Internet-Draft Observed DNS Resolution Misbehavior February 2004 - - - top-level domains (gTLDs) become active. We anticipate many zones in - the new gTLDs will use name servers in other gTLDs, increasing the - amount of inter-zone glue. - -2.3.1 Recommendation - - Clearly constructing a delegation that relies on multiple levels of - out-of-zone glue is not a good administrative practice. This issue - could be mitigated with an operational injunction in an RFC to - refrain from construction of such delegations. In our opinion the - practice is widespread enough to merit clarifications to the DNS - protocol specification to permit it on a limited basis. - - Name servers offering recursion SHOULD be able to handle at least - three levels of indirection resulting from out-of-zone glue. - -2.4 Aggressive retransmission when fetching glue - - When an authoritative name server responds with a referral, it - includes NS records in the authority section of the response. - According to the algorithm in section 4.3.2 of RFC 1034 [2], the name - server should also "put whatever addresses are available into the - additional section, using glue RRs if the addresses are not available - from authoritative data or the cache." Some name server - implementations take this address inclusion a step further with a - feature called "glue fetching". A name server that implements glue - fetching attempts to include A records for every NS record in the - authority section. If necessary, the name server issues multiple - queries of its own to obtain any missing A records. - - Problems with glue fetching can arise in the context of - "authoritative-only" name servers, which only serve authoritative - data and ignore requests for recursion. Such a server will not - generate any queries of its own. Instead it answers non-recursive - queries from resolvers looking for information in zones it serves. - With glue fetching enabled, however, an authoritative server will - generate queries whenever it needs to look up an unknown address - record to complete the additional section of a response. - - We have observed situations where a glue-fetching name server can - send queries that reach other name servers, but apparently is - prevented from receiving the responses. For example, perhaps the - name server is authoritative-only and therefore its administrators - expect it to receive only queries. Perhaps unaware of glue fetching - and presuming that the name server will generate no queries, its - administrators place the name server behind a network device that - prevents it from receiving responses. If this is the case, all - glue-fetching queries will go answered. - - - -Larson & Barber Expires August 16, 2004 [Page 7] - -Internet-Draft Observed DNS Resolution Misbehavior February 2004 - - - We have observed name server implementations that retry excessively - when glue-fetching queries are unanswered. A single com/net name - server has received hundreds of queries per second from a single name - server. Judging from the specific queries received and based on - additional analysis, we believe these queries result from overly - aggressive glue fetching. - -2.4.1 Recommendation - - Implementers whose name servers support glue fetching should take - care to avoid sending queries at excessive rates. Implementations - should support throttling logic to detect when queries are sent but - no responses are received. - -2.5 Aggressive retransmission behind firewalls - - A common occurrence and one of the largest sources of repeated - queries at the com/net and root name servers appears to result from - resolvers behind misconfigured firewalls. In this situation, a - recursive name server is apparently allowed to send queries through a - firewall to other name servers, but not receive the responses. The - result is more queries than necessary because of retransmission, all - of which are useless because the responses are never received. Just - as with the glue-fetching scenario described in Section 2.4, the - queries are sometimes sent at excessive rates. To make matters - worse, sometimes the responses, sent in reply to legitimate queries, - trigger an alarm on the originator's intrusion detection system. We - are frequently contacted by administrators responding to such alarms - who believe our name servers are attacking their systems. - - Not only do some resolvers in this situation retransmit queries at an - excessive rate, but they continue to do so for days or even weeks. - This scenario could result from an organization with multiple - recursive name servers, only a subset of whose traffic is improperly - filtered in this manner. Stub resolvers in the organization could be - configured to query multiple name servers. Consider the case where a - stub resolver queries a filtered name server first. This name server - sends one or more queries whose replies are filtered, so it can't - respond to the stub resolver, which times out. The resolver - retransmits to a name server that is able to provide an answer. - Since resolution ultimately succeeds the underlying problem might not - be recognized or corrected. A popular stub resolver has a very - aggressive retransmission schedule, including simultaneous queries to - multiple name servers, which could explain how such a situation could - persist without being detected. - -2.5.1 Recommendation - - - - -Larson & Barber Expires August 16, 2004 [Page 8] - -Internet-Draft Observed DNS Resolution Misbehavior February 2004 - - - The most obvious recommendation is that administrators should take - care not to place recursive name servers behind a firewall that - prohibits queries to pass through but not the resulting replies. - - Name servers should take care to avoid sending queries at excessive - rates. Implementations should support throttling logic to detect - when queries are sent but no responses are received. - -2.6 Misconfigured NS records - - Sometimes a zone administrator forgets to add the trailing dot on the - domain names in the RDATA of a zone's NS records. Consider this - fragment of the zone file for "example.com": - - $ORIGIN example.com. - example.com. 3600 IN NS ns1.example.com ; Note missing - example.com. 3600 IN NS ns2.example.com ; trailing dots - - The zone's authoritative servers will parse the NS RDATA as - "ns1.example.com.example.com" and "ns2.example.com.example.com" and - return NS records with this incorrect RDATA in responses, including - typically the authority section of every response containing records - from the "example.com" zone. - - Now consider a typical sequence of queries. A recursive name server - attempting to resolve A records for "www.example.com" with no cached - information for this zone will query a "com" authoritative server. - The "com" server responds with a referral to the "example.com" zone, - consisting of NS records with valid RDATA and associated glue - records. (This example assumes that the "example.com" zone - information is correct in the "com" zone.) The recursive name server - caches the NS RRset from the "com" server and follows the referral by - querying one of the "example.com" authoritative servers. This server - responds with the "www.example.com" A record in the answer section - and, typically, the "example.com" NS records in the authority section - and, if space in the message remains, glue A records in the - additional section. According to Section 5.4 of RFC 2181 [4], NS - records in the authority section of an authoritative answer are more - trustworthy than NS records from the authority section of a - non-authoritative answer. Thus the "example.com" NS RRset just - received from the "example.com" authoritative server displaces the - "example.com" NS RRset received moments ago from the "com" - authoritative server. - - But the "example.com" zone contains the erroneous NS RRset as shown - in the example above. Subsequent queries for names in "example.com" - will cause the server to attempt to use the incorrect NS records and - so the server will try to resolve the nonexistent names - - - -Larson & Barber Expires August 16, 2004 [Page 9] - -Internet-Draft Observed DNS Resolution Misbehavior February 2004 - - - "ns1.example.com.example.com" and "ns2.example.com.example.com". In - this example, since all of the zone's name servers are named in the - zone itself (i.e., "ns1.example.com.example.com" and - "ns2.example.com.example.com" both end in "example.com") and all are - bogus, the recursive server cannot reach any "example.com" name - servers. Therefore attempts to resolve these names result in A - record queries to the "com' authoritative servers. Queries for such - obviously bogus glue A records occur frequently at the com/net name - servers. - -2.6.1 Recommendation - - An authoritative server can detect this situation. A trailing dot - missing from an NS record's RDATA always results by definition in a - name server name that is in the zone. But any in-zone name server - should have a corresponding glue A record also in the zone. An - authoritative name server should report an error when a zone's NS - record references an in-zone name server without a corresponding glue - A record. - -2.7 Name server records with zero TTL - - Sometimes a popular com/net subdomain's zone is configured with a TTL - of zero on the zone's NS records, which prohibits these records from - being cached and will result in a higher query volume to the zone's - authoritative servers. The zone's administrator should understand - the consequences of such a configuration and provision resources - accordingly. A zero TTL on the zone's NS RRset, however, carries - additional consequences beyond the zone itself: if a recursive name - server cannot cache a zone's NS records because of a zero TTL, it - will be forced to query that zone's parent's name servers each time - it resolves a name in the zone. The com/net authoritative servers do - see an increased query load when a popular com/net subdomain's zone - is configured with a TTL of zero on the zone's NS records. - - A zero TTL on an RRset expected to change frequently is extreme but - permissible. A zone's NS RRset is a special case, however, because - changes to it must be coordinated with the zone's parent. In most - zone parent/child relationships we are aware of, there is typically - some delay involved in effecting changes. Further, changes to the - set of a zone's authoritative name servers (and therefore to the - zone's NS RRset) are typically relatively rare: providing reliable - authoritative service requires a reasonably stable set of servers. - Therefore an extremely low or zero TTL on a zone's NS RRset rarely - makes sense, except in anticipation of an upcoming change. In this - case, when the zone's administrator has planned a change and does not - want recursive name servers throughout the Internet to cache the NS - RRset for a long period of time, a low TTL is reasonable. - - - -Larson & Barber Expires August 16, 2004 [Page 10] - -Internet-Draft Observed DNS Resolution Misbehavior February 2004 - - -2.7.1 Recommendation - - Because of the additional load placed on a zone's parent's - authoritative servers imposed by a zero TTL on a zone's NS RRset, - under such circumstances authoritative name servers should issue a - warning when loading a zone or refuse to load the zone altogether. - -2.8 Unnecessary dynamic update messages - - The UPDATE message specified in RFC 2136 [6] allows an authorized - agent to update a zone's data on an authoritative name server using a - DNS message sent over the network. Consider the case of an agent - desiring to add a particular resource record. Because of zone cuts, - the agent does not necessarily know the proper zone to which the - record should be added. The dynamic update process requires that the - agent determine the appropriate zone so the UPDATE message can be - sent to one of the zone's authoritative servers (typically the - primary master as specified in the zone's SOA MNAME field). - - The appropriate zone to update is the closest enclosing zone, which - is the lowest zone in the name space. The closest enclosing zone - cannot be determined only by inspecting the domain name of the record - to be updated, since zone cuts can occur anywhere. One way to - determine the closest enclosing zone involves working up the name - space tree and sending repeated UPDATE messages until success. For - example, consider an agent attempting to add an A record with the - name "foo.bar.example.com". The agent could first attempt to update - the "foo.bar.example.com" zone. If the attempt failed, the update - could be directed to the "bar.example.com" zone, then the - "example.com" zone, then the "com" zone, and finally the root zone. - - A popular dynamic agent follows this algorithm. The result is many - UPDATE messages received by the root name servers, the com/net - authoritative servers, and presumably other TLD authoritative - servers. A reasonable question is why the algorithm proceeds with - sending updates all the way to TLD and root name servers. In - enterprise DNS architectures with an "internal root" design, there - could conceivably be private, non-public TLD or root zones that would - be the appropriate target for a dynamic update. However, we question - if designing an algorithm to accommodate these limited cases is worth - the load it places on the public DNS in the form of unnecessary - UPDATE messages. - -2.8.1 Recommendation - - Dynamic update agents should not attempt to send UPDATE messages to - authoritative servers for TLD zones or the root zone by default. If - this functionality is supported, it should be require specific action - - - -Larson & Barber Expires August 16, 2004 [Page 11] - -Internet-Draft Observed DNS Resolution Misbehavior February 2004 - - - by a user to be enabled. - -2.9 Queries for domain names resembling IP addresses - - The root name servers receive a significant number of A record - queries where the qname is an IP address. The source of these - queries is unknown. It could be attributed to situations where a - user believes an application will accept either a domain name or an - IP address in a given configuration option. The user enters an IP - address, but the application assumes any input is a domain name and - attempts to resolve it, resulting in an A record lookup. There could - also be applications that produce such queries in a misguided attempt - to reverse map IP addresses. - - These queries result in Name Error (RCODE=3) responses. A recursive - name server can negatively cache such responses, but each response - requires a separate cache entry, i.e., a negative cache entry for the - domain name "192.0.2.1" does not prevent a subsequent query for the - domain name "192.0.2.2". - -2.9.1 Recommendation - - It would be desirable for the root name servers not to have to answer - these queries: they unnecessarily consume CPU resources and network - bandwidth. One possibility is for recursive name server - implementations to produce the Name Error response directly. We - suggest that implementors consider the option of synthesizing Name - Error responses at the recursive name server. The server could claim - authority for synthesized TLD zones corresponding to the first octet - of every possible IP address, e.g. 1., 2., through 255. This - behavior could be configurable in the (probably unlikely) event that - numeric TLDs are ever put into use. - - Another option is to delegate these numeric TLDs from the root zone - to a separate set of servers to absorb the traffic. The "blackhole - servers" used by the the AS 112 Project [8], which are currently - delegated the in-addr.arpa zones corresponding to RFC 1918 [7] - private use address space, would be a possible choice to receive - these delegations. - -2.10 Misdirected recursive queries - - The root name servers receive a significant number of recursive - queries (i.e., queries with the RD bit set in the header). Since - none of the root servers offer recursion, the servers' response in - such a situation ignores the request for recursion and the response - probably does not contain the data the querier anticipated. Some of - these queries result from users configuring stub resolvers to query a - - - -Larson & Barber Expires August 16, 2004 [Page 12] - -Internet-Draft Observed DNS Resolution Misbehavior February 2004 - - - root server. (This situation is not hypothetical: we have received - complaints from users when this configuration does not work as - hoped.) Of course, users should not direct stub resolvers to use name - servers that do not offer recursion, but we are not aware of any stub - resolver implementation that offers any feedback to the user when so - configured, aside from simply "not working". - -2.10.1 Recommendation - - When the IP address of a (supposedly) recursive name server is - configured in a stub resolver using an interactive user interface, - the resolver could send a test query to verify that the server - supports recursion (i.e., the response has the RA bit set in the - header). The user could be immediately notified if the server is - non-recursive. - - The stub resolver could also report an error, either through a user - interface or in a log file, if the queried server does not support - recursion. Error reporting should be throttled to avoid a - notification or log message for every response from a non-recursive - server. - -2.11 Suboptimal name server selection algorithm - - An entire document could be devoted to the topic of problems with - different implementations of the recursive resolution algorithm. The - entire process of recursion is woefully underspecified, requiring - each implementor to design an algorithm. Sometimes implementors make - poor design choices that could be avoided if a suggested algorithm - and best practices were documented, but that is a topic for another - document. - - Some deficiencies cause significant operational impact and are - therefore worth mentioning here. One of these is name server - selection by a recursive name server. When a recursive name server - wants to contact one of a zone's authoritative name servers, how does - it choose from the NS records listed in the zone's NS RRset? If the - selection mechanism is suboptimal, queries are not spread evenly - among a zone's authoritative servers. The details of the selection - mechanism are up to the implementor, but we offer some suggestions. - -2.11.1 Recommendation - - This list is not conclusive, but reflects the changes that would - produce the most impact in terms of reducing disproportionate query - load among a zone's authoritative servers. I.e., these changes would - help spread the query load evenly. - - - - -Larson & Barber Expires August 16, 2004 [Page 13] - -Internet-Draft Observed DNS Resolution Misbehavior February 2004 - - - o Do not make assumptions based on NS RRset order: all NS RRs should - be treated equally. (In the case of the "com" zone, for example, - most of the root servers return the NS record for - "a.gtld-servers.net" first in the authority section of referrals. - As a result, this server receives disproportionately more traffic - than the other 12 authoritative servers for "com".) - - o Use all NS records in an RRset. (For example, we are aware of - implementations that hard-coded information for a subset of the - root servers.) - - o Maintain state and favor the best-performing of a zone's - authoritative servers. A good definition of performance is - response time. Non-responsive servers can be penalized with an - extremely high response time. - - o Do not lock onto the best-performing of a zone's name servers. A - recursive name server should periodically check the performance of - all of a zone's name servers to adjust its determination of the - best-performing one. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Larson & Barber Expires August 16, 2004 [Page 14] - -Internet-Draft Observed DNS Resolution Misbehavior February 2004 - - -3. IANA considerations - - There are no new IANA considerations introduced by this - Internet-Draft. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Larson & Barber Expires August 16, 2004 [Page 15] - -Internet-Draft Observed DNS Resolution Misbehavior February 2004 - - -4. Security considerations - - Name server and resolver misbehaviors identical or similar to those - discussed in this document expose the root and TLD name servers to - increased risk of both intentional and unintentional denial of - service. - - We believe that implementation of the recommendations offered in this - document will reduce the amount of unnecessary traffic seen at root - and TLD name servers, thus reducing the opportunity for an attacker - to use such queries to his or her advantage. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Larson & Barber Expires August 16, 2004 [Page 16] - -Internet-Draft Observed DNS Resolution Misbehavior February 2004 - - -5. Internationalization considerations - - We do not believe this document introduces any new - internationalization considerations to the DNS protocol - specification. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Larson & Barber Expires August 16, 2004 [Page 17] - -Internet-Draft Observed DNS Resolution Misbehavior February 2004 - - -Normative References - - [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement - Levels", BCP 14, RFC 2119, March 1997. - - [2] Mockapetris, P., "Domain names - concepts and facilities", STD - 13, RFC 1034, November 1987. - - [3] Mockapetris, P., "Domain names - implementation and - specification", STD 13, RFC 1035, November 1987. - - [4] Elz, R. and R. Bush, "Clarifications to the DNS Specification", - RFC 2181, July 1997. - - [5] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", RFC - 2308, March 1998. - - [6] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic - Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April - 1997. - - [7] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G. and E. - Lear, "Address Allocation for Private Internets", BCP 5, RFC - 1918, February 1996. - - [8] - - -Authors' Addresses - - Matt Larson - VeriSign, Inc. - 21345 Ridgetop Circle - Dulles, VA 20166-6503 - USA - - EMail: mlarson@verisign.com - - - Piet Barber - VeriSign, Inc. - 21345 Ridgetop Circle - Dulles, VA 20166-6503 - USA - - EMail: pbarber@verisign.com - - - - - -Larson & Barber Expires August 16, 2004 [Page 18] - -Internet-Draft Observed DNS Resolution Misbehavior February 2004 - - -Intellectual Property Statement - - The IETF takes no position regarding the validity or scope of any - intellectual property or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; neither does it represent that it - has made any effort to identify any such rights. Information on the - IETF's procedures with respect to rights in standards-track and - standards-related documentation can be found in BCP-11. Copies of - claims of rights made available for publication and any assurances of - licenses to be made available, or the result of an attempt made to - obtain a general license or permission for the use of such - proprietary rights by implementors or users of this specification can - be obtained from the IETF Secretariat. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights which may cover technology that may be required to practice - this standard. Please address the information to the IETF Executive - Director. - - -Full Copyright Statement - - Copyright (C) The Internet Society (2004). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assignees. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING - BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION - - - -Larson & Barber Expires August 16, 2004 [Page 19] - -Internet-Draft Observed DNS Resolution Misbehavior February 2004 - - - HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - -Acknowledgement - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Larson & Barber Expires August 16, 2004 [Page 20] - diff --git a/doc/draft/draft-ietf-dnsop-bad-dns-res-03.txt b/doc/draft/draft-ietf-dnsop-bad-dns-res-03.txt new file mode 100644 index 0000000000..9537af6534 --- /dev/null +++ b/doc/draft/draft-ietf-dnsop-bad-dns-res-03.txt @@ -0,0 +1,1123 @@ + + + +DNS Operations M. Larson +Internet-Draft P. Barber +Expires: April 27, 2005 VeriSign + October 27, 2004 + + + Observed DNS Resolution Misbehavior + draft-ietf-dnsop-bad-dns-res-03 + +Status of this Memo + + This document is an Internet-Draft and is subject to all provisions + of section 3 of RFC 3667. By submitting this Internet-Draft, each + author represents that any applicable patent or other IPR claims of + which he or she is aware have been or will be disclosed, and any of + which he or she become aware will be disclosed, in accordance with + RFC 3668. + + 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 April 27, 2005. + +Copyright Notice + + Copyright (C) The Internet Society (2004). + +Abstract + + This memo describes DNS name server and resolver behavior that + results in a significant query volume sent to the root and top-level + domain (TLD) name servers. In some cases we recommend minor + additions to the DNS protocol specification and corresponding changes + in iterative resolver implementations to alleviate these unnecessary + queries. The recommendations made in this document are a direct + byproduct of observation and analysis of abnormal query traffic + + + +Larson & Barber Expires April 27, 2005 [Page 1] + +Internet-Draft Observed DNS Resolution Misbehavior October 2004 + + + patterns seen at two of the thirteen root name servers and all + thirteen com/net TLD name servers. + + 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 [1]. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.1 A note about terminology in this memo . . . . . . . . . . 3 + 2. Observed iterative resolver misbehavior . . . . . . . . . . 5 + 2.1 Aggressive requerying for delegation information . . . . . 5 + 2.1.1 Recommendation . . . . . . . . . . . . . . . . . . . . 6 + 2.2 Repeated queries to lame servers . . . . . . . . . . . . . 6 + 2.2.1 Recommendation . . . . . . . . . . . . . . . . . . . . 7 + 2.3 Inability to follow multiple levels of out-of-zone glue . 7 + 2.3.1 Recommendation . . . . . . . . . . . . . . . . . . . . 8 + 2.4 Aggressive retransmission when fetching glue . . . . . . . 8 + 2.4.1 Recommendation . . . . . . . . . . . . . . . . . . . . 9 + 2.5 Aggressive retransmission behind firewalls . . . . . . . . 9 + 2.5.1 Recommendation . . . . . . . . . . . . . . . . . . . . 10 + 2.6 Misconfigured NS records . . . . . . . . . . . . . . . . . 10 + 2.6.1 Recommendation . . . . . . . . . . . . . . . . . . . . 11 + 2.7 Name server records with zero TTL . . . . . . . . . . . . 11 + 2.7.1 Recommendation . . . . . . . . . . . . . . . . . . . . 12 + 2.8 Unnecessary dynamic update messages . . . . . . . . . . . 12 + 2.8.1 Recommendation . . . . . . . . . . . . . . . . . . . . 13 + 2.9 Queries for domain names resembling IP addresses . . . . . 13 + 2.9.1 Recommendation . . . . . . . . . . . . . . . . . . . . 13 + 2.10 Misdirected recursive queries . . . . . . . . . . . . . 14 + 2.10.1 Recommendation . . . . . . . . . . . . . . . . . . . 14 + 2.11 Suboptimal name server selection algorithm . . . . . . . 14 + 2.11.1 Recommendation . . . . . . . . . . . . . . . . . . . 15 + 3. IANA considerations . . . . . . . . . . . . . . . . . . . . 16 + 4. Security considerations . . . . . . . . . . . . . . . . . . 17 + 5. Internationalization considerations . . . . . . . . . . . . 18 + 6. Normative References . . . . . . . . . . . . . . . . . . . . 18 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 18 + Intellectual Property and Copyright Statements . . . . . . . 20 + + + + + + + + + + + +Larson & Barber Expires April 27, 2005 [Page 2] + +Internet-Draft Observed DNS Resolution Misbehavior October 2004 + + +1. Introduction + + Observation of query traffic received by two root name servers and + the thirteen com/net TLD name servers has revealed that a large + proportion of the total traffic often consists of "requeries". A + requery is the same question () asked + repeatedly at an unexpectedly high rate. We have observed requeries + from both a single IP address and multiple IP addresses (i.e., the + same query received simultaneously from multiple IP addresses). + + By analyzing requery events we have found that the cause of the + duplicate traffic is almost always a deficient iterative resolver, + stub resolver or application implementation combined with an + operational anomaly. The implementation deficiencies we have + identified to date include well-intentioned recovery attempts gone + awry, insufficient caching of failures, early abort when multiple + levels of glue records must be followed, and aggressive retry by stub + resolvers or applications. Anomalies that we have seen trigger + requery events include lame delegations, unusual glue records, and + anything that makes all authoritative name servers for a zone + unreachable (DoS attacks, crashes, maintenance, routing failures, + congestion, etc.). + + In the following sections, we provide a detailed explanation of the + observed behavior and recommend changes that will reduce the requery + rate. Some of the changes recommended affect the core DNS protocol + specification, described principally in RFC 1034 [2], RFC 1035 [3] + and RFC 2181 [4]. + +1.1 A note about terminology in this memo + + To recast an old saying about standards, the nice thing about DNS + terms is that there are so many of them to choose from. Writing or + talking about DNS can be difficult and cause confusion resulting from + a lack of agreed-upon terms for its various components. Further + complicating matters are implementations that combine multiple roles + into one piece of software, which makes naming the result + problematic. An example is the entity that accepts recursive + queries, issues iterative queries as necessary to resolve the initial + recursive query, caches responses it receives, and which is also able + answer questions about certain zones authoritatively. Often called a + "recursive name server" or a "caching name server", it is in fact an + iterative resolver combined with an authoritative name server. + + This memo is concerned principally with the behavior of iterative + resolvers, which are typically found as part of a recursive name + server. This memo uses the more precise term "iterative resolver", + because the focus is usually on that component. In instances where + + + +Larson & Barber Expires April 27, 2005 [Page 3] + +Internet-Draft Observed DNS Resolution Misbehavior October 2004 + + + the name server role of this entity requires mentioning, this memo + uses the term "recursive name server". For example, the name server + component of a recursive name server receives DNS queries and the + iterative resolver component sends queries. + + The advent of IPv6 requires mentioning AAAA records as well as A + records when discussing glue. To avoid continuous repetition and + qualification, this memo uses the general term "address records" to + encompass both A and AAAA records when a particular situation is + relevant to both types. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Larson & Barber Expires April 27, 2005 [Page 4] + +Internet-Draft Observed DNS Resolution Misbehavior October 2004 + + +2. Observed iterative resolver misbehavior + +2.1 Aggressive requerying for delegation information + + There can be times when every name server in a zone's NS RRset is + unreachable (e.g., during a network outage), unavailable (e.g., the + name server process is not running on the server host) or + misconfigured (e.g., the name server is not authoritative for the + given zone, also known as "lame"). Consider an iterative resolver + that attempts to resolve a query for a domain name in such a zone and + discovers that none of the zone's name servers can provide an answer. + We have observed a recursive name server implementation whose + iterative resolver then verifies the zone's NS RRset in its cache by + querying for the zone's delegation information: it sends a query for + the zone's NS RRset to one of the parent zone's name servers. + + For example, suppose that "example.com" has the following NS RRset: + + example.com. IN NS ns1.example.com. + example.com. IN NS ns2.example.com. + + Upon receipt of a query for "www.example.com" and assuming that + neither "ns1.example.com" nor "ns2.example.com" can provide an + answer, this iterative resolver implementation immediately queries a + "com" zone name server for the "example.com" NS RRset to verify it + has the proper delegation information. This implementation performs + this query to a zone's parent zone for each recursive query it + receives that fails because of a completely unresponsive set of name + servers for the target zone. Consider the effect when a popular zone + experiences a catastrophic failure of all its name servers: now every + recursive query for domain names in that zone sent to this recursive + name server implementation results in a query to the failed zone's + parent name servers. On one occasion when several dozen popular + zones became unreachable, the query load on the com/net name servers + increased by 50%. + + We believe this verification query is not reasonable. Consider the + circumstances: When an iterative resolver is resolving a query for a + domain name in a zone it has not previously searched, it uses the + list of name servers in the referral from the target zone's parent. + If on its first attempt to search the target zone, none of the name + servers in the referral is reachable, a verification query to the + parent is pointless: this query to the parent would come so quickly + on the heels of the referral that it would be almost certain to + contain the same list of name servers. The chance of discovering any + new information is slim. + + The other possibility is that the iterative resolver successfully + + + +Larson & Barber Expires April 27, 2005 [Page 5] + +Internet-Draft Observed DNS Resolution Misbehavior October 2004 + + + contacts one of the target zone's name servers and then caches the NS + RRset from the authority section of a response, the proper behavior + according to section 5.4.1 of RFC 2181 [4], because the NS RRset from + the target zone is more trustworthy than delegation information from + the parent zone. If, while processing a subsequent recursive query, + the iterative resolver discovers that none of the name servers + specified in the cached NS RRset is available or authoritative, + querying the parent would be wrong. An NS RRset from the parent zone + would now be less trustworthy than data already in the cache. + + For this query of the parent zone to be useful, the target zone's + entire set of name servers would have to change AND the former set of + name servers would have to be deconfigured or decommissioned AND the + delegation information in the parent zone would have to be updated + with the new set of name servers, all within the TTL of the target + zone's NS RRset. We believe this scenario is uncommon: + administrative best practices dictate that changes to a zone's set of + name servers happen gradually when at all possible, with servers + removed from the NS RRset left authoritative for the zone as long as + possible. The scenarios that we can envision that would benefit from + the parent requery behavior do not outweigh its damaging effects. + +2.1.1 Recommendation + + An iterative resolver MUST NOT send a query for the NS RRset of a + non-responsive zone to any of the name servers for that zone's parent + zone. For the purposes of this injunction, a non-responsive zone is + defined as a zone for which every name server listed in the zone's NS + RRset: + 1. is not authoritative for the zone (i.e., lame), or, + 2. returns a server failure response (RCODE=2), or, + 3. is dead or unreachable according to section 7.2 of RFC 2308 [5]. + +2.2 Repeated queries to lame servers + + Section 2.1 describes a catastrophic failure: when every name server + for a zone is unable to provide an answer for one reason or another. + A more common occurrence is when a subset of a zone's name servers + are unavailable or misconfigured. Different failure modes have + different expected durations. Some symptoms indicate problems that + are potentially transient; for example, various types of ICMP + unreachable messages because a name server process is not running or + a host or network is unreachable, or a complete lack of a response to + a query. Such responses could be the result of a host rebooting or + temporary outages; these events don't necessarily require any human + intervention and can be reasonably expected to be temporary. + + Other symptoms clearly indicate a condition requiring human + + + +Larson & Barber Expires April 27, 2005 [Page 6] + +Internet-Draft Observed DNS Resolution Misbehavior October 2004 + + + intervention, such as lame server: if a name server is misconfigured + and not authoritative for a zone delegated to it, it is reasonable to + assume that this condition has potential to last longer than + unreachability or unresponsiveness. Consequently, repeated queries + to known lame servers are not useful. In this case of a condition + with potential to persist for a long time, a better practice would be + to maintain a list of known lame servers and avoid querying them + repeatedly in a short interval. + +2.2.1 Recommendation + + Iterative resolvers SHOULD cache name servers that they discover are + not authoritative for zones delegated to them (i.e. lame servers). + Lame servers MUST be cached against the specific query tuple . Zone name can be derived from the + owner name of the NS record that was referenced to query the name + server that was discovered to be lame. Implementations that perform + lame server caching MUST refrain from sending queries to known lame + servers based on a time interval from when the server is discovered + to be lame. A minimum interval of thirty minutes is RECOMMENDED. + +2.3 Inability to follow multiple levels of out-of-zone glue + + Some iterative resolver implementations are unable to follow more + than one level of out-of-zone glue. For example, consider the + following delegations: + + foo.example. IN NS ns1.example.com. + foo.example. IN NS ns2.example.com. + + example.com. IN NS ns1.test.example.net. + example.com. IN NS ns2.test.example.net. + + test.example.net. IN NS ns1.test.example.net. + test.example.net. IN NS ns2.test.example.net. + + An iterative resolver resolving the name "www.foo.example" must + follow two levels of indirection, first obtaining address records for + "ns1.test.example.net" or "ns2.test.example.net" in order to obtain + address records for "ns1.example.com" or "ns2.example.com" in order + to query those name servers for the address records of + "www.foo.example". While this situation may appear contrived, we + have seen multiple similar occurrences and expect more as new generic + top-level domains (gTLDs) become active. We anticipate many zones in + new gTLDs will use name servers in other gTLDs, increasing the amount + of inter-zone glue. + + + + + +Larson & Barber Expires April 27, 2005 [Page 7] + +Internet-Draft Observed DNS Resolution Misbehavior October 2004 + + +2.3.1 Recommendation + + Clearly constructing a delegation that relies on multiple levels of + out-of-zone glue is not a good administrative practice. This issue + could be mitigated with an operational injunction in an RFC to + refrain from construction of such delegations. In our opinion the + practice is widespread enough to merit clarifications to the DNS + protocol specification to permit it on a limited basis. + + Iterative resolvers SHOULD be able to handle at least three levels of + indirection resulting from out-of-zone glue. + +2.4 Aggressive retransmission when fetching glue + + When an authoritative name server responds with a referral, it + includes NS records in the authority section of the response. + According to the algorithm in section 4.3.2 of RFC 1034 [2], the name + server should also "put whatever addresses are available into the + additional section, using glue RRs if the addresses are not available + from authoritative data or the cache." Some name server + implementations take this address inclusion a step further with a + feature called "glue fetching". A name server that implements glue + fetching attempts to include address records for every NS record in + the authority section. If necessary, the name server issues multiple + queries of its own to obtain any missing address records. + + Problems with glue fetching can arise in the context of + "authoritative-only" name servers, which only serve authoritative + data and ignore requests for recursion. Such an entity will not + normally generate any queries of its own. Instead it answers + non-recursive queries from iterative resolvers looking for + information in zones it serves. With glue fetching enabled, however, + an authoritative server invokes an iterative resolver to look up an + unknown address record to complete the additional section of a + response. + + We have observed situations where the iterative resolver of a + glue-fetching name server can send queries that reach other name + servers, but is apparently prevented from receiving the responses. + For example, perhaps the name server is authoritative-only and + therefore its administrators expect it to receive only queries and + not responses. Perhaps unaware of glue fetching and presuming that + the name server's iterative resolver will generate no queries, its + administrators place the name server behind a network device that + prevents it from receiving responses. If this is the case, all + glue-fetching queries will go answered. + + We have observed name server implementations whose iterative + + + +Larson & Barber Expires April 27, 2005 [Page 8] + +Internet-Draft Observed DNS Resolution Misbehavior October 2004 + + + resolvers retry excessively when glue-fetching queries are + unanswered. A single com/net name server has received hundreds of + queries per second from a single such source. Judging from the + specific queries received and based on additional analysis, we + believe these queries result from overly aggressive glue fetching. + +2.4.1 Recommendation + + Implementers whose name servers support glue fetching SHOULD take + care to avoid sending queries at excessive rates. Implementations + SHOULD support throttling logic to detect when queries are sent but + no responses are received. + +2.5 Aggressive retransmission behind firewalls + + A common occurrence and one of the largest sources of repeated + queries at the com/net and root name servers appears to result from + resolvers behind misconfigured firewalls. In this situation, an + iterative resolver is apparently allowed to send queries through a + firewall to other name servers, but not receive the responses. The + result is more queries than necessary because of retransmission, all + of which are useless because the responses are never received. Just + as with the glue-fetching scenario described in Section 2.4, the + queries are sometimes sent at excessive rates. To make matters + worse, sometimes the responses, sent in reply to legitimate queries, + trigger an alarm on the originator's intrusion detection system. We + are frequently contacted by administrators responding to such alarms + who believe our name servers are attacking their systems. + + Not only do some resolvers in this situation retransmit queries at an + excessive rate, but they continue to do so for days or even weeks. + This scenario could result from an organization with multiple + recursive name servers, only a subset of whose iterative resolvers' + traffic is improperly filtered in this manner. Stub resolvers in the + organization could be configured to query multiple recursive name + servers. Consider the case where a stub resolver queries a filtered + recursive name server first. The iterative resolver of this + recursive name server sends one or more queries whose replies are + filtered, so it can't respond to the stub resolver, which times out. + Then the stub resolver retransmits to a recursive name server that is + able to provide an answer. Since resolution ultimately succeeds the + underlying problem might not be recognized or corrected. A popular + stub resolver implementation has a very aggressive retransmission + schedule, including simultaneous queries to multiple recursive name + servers, which could explain how such a situation could persist + without being detected. + + + + + +Larson & Barber Expires April 27, 2005 [Page 9] + +Internet-Draft Observed DNS Resolution Misbehavior October 2004 + + +2.5.1 Recommendation + + The most obvious recommendation is that administrators SHOULD take + care not to place iterative resolvers behind a firewall that allows + queries to pass through but not the resulting replies. + + Iterative resolvers SHOULD take care to avoid sending queries at + excessive rates. Implementations SHOULD support throttling logic to + detect when queries are sent but no responses are received. + +2.6 Misconfigured NS records + + Sometimes a zone administrator forgets to add the trailing dot on the + domain names in the RDATA of a zone's NS records. Consider this + fragment of the zone file for "example.com": + + $ORIGIN example.com. + example.com. 3600 IN NS ns1.example.com ; Note missing + example.com. 3600 IN NS ns2.example.com ; trailing dots + + The zone's authoritative servers will parse the NS RDATA as + "ns1.example.com.example.com" and "ns2.example.com.example.com" and + return NS records with this incorrect RDATA in responses, including + typically the authority section of every response containing records + from the "example.com" zone. + + Now consider a typical sequence of queries. An iterative resolver + attempting to resolve address records for "www.example.com" with no + cached information for this zone will query a "com" authoritative + server. The "com" server responds with a referral to the + "example.com" zone, consisting of NS records with valid RDATA and + associated glue records. (This example assumes that the + "example.com" zone delegation information is correct in the "com" + zone.) The iterative resolver caches the NS RRset from the "com" + server and follows the referral by querying one of the "example.com" + authoritative servers. This server responds with the + "www.example.com" address record in the answer section and, + typically, the "example.com" NS records in the authority section and, + if space in the message remains, glue address records in the + additional section. According to Section 5.4 of RFC 2181 [4], NS + records in the authority section of an authoritative answer are more + trustworthy than NS records from the authority section of a + non-authoritative answer. Thus the "example.com" NS RRset just + received from the "example.com" authoritative server overrides the + "example.com" NS RRset received moments ago from the "com" + authoritative server. + + But the "example.com" zone contains the erroneous NS RRset as shown + + + +Larson & Barber Expires April 27, 2005 [Page 10] + +Internet-Draft Observed DNS Resolution Misbehavior October 2004 + + + in the example above. Subsequent queries for names in "example.com" + will cause the iterative resolver to attempt to use the incorrect NS + records and so it will try to resolve the nonexistent names + "ns1.example.com.example.com" and "ns2.example.com.example.com". In + this example, since all of the zone's name servers are named in the + zone itself (i.e., "ns1.example.com.example.com" and + "ns2.example.com.example.com" both end in "example.com") and all are + bogus, the iterative resolver cannot reach any "example.com" name + servers. Therefore attempts to resolve these names result in address + record queries to the "com" authoritative servers. Queries for such + obviously bogus glue address records occur frequently at the com/net + name servers. + +2.6.1 Recommendation + + An authoritative server can detect this situation. A trailing dot + missing from an NS record's RDATA always results by definition in a + name server name that exists somewhere under the SOA of the zone the + NS record appears in. Note that further levels of delegation are + possible, so a missing trailing dot could inadvertently create a name + server name that actually exists in a subzone. But in any case, the + address record must still be present in this zone, either as + authoritative data or glue. + + An authoritative name server SHOULD report an error when one of a + zone's NS records references a name server below the zone's SOA when + a corresponding address record does not exist in the zone. + +2.7 Name server records with zero TTL + + Sometimes a popular com/net subdomain's zone is configured with a TTL + of zero on the zone's NS records, which prohibits these records from + being cached and will result in a higher query volume to the zone's + authoritative servers. The zone's administrator should understand + the consequences of such a configuration and provision resources + accordingly. A zero TTL on the zone's NS RRset, however, carries + additional consequences beyond the zone itself: if an iterative + resolver cannot cache a zone's NS records because of a zero TTL, it + will be forced to query that zone's parent's name servers each time + it resolves a name in the zone. The com/net authoritative servers do + see an increased query load when a popular com/net subdomain's zone + is configured with a TTL of zero on the zone's NS records. + + A zero TTL on an RRset expected to change frequently is extreme but + permissible. A zone's NS RRset is a special case, however, because + changes to it must be coordinated with the zone's parent. In most + zone parent/child relationships we are aware of, there is typically + some delay involved in effecting changes. Further, changes to the + + + +Larson & Barber Expires April 27, 2005 [Page 11] + +Internet-Draft Observed DNS Resolution Misbehavior October 2004 + + + set of a zone's authoritative name servers (and therefore to the + zone's NS RRset) are typically relatively rare: providing reliable + authoritative service requires a reasonably stable set of servers. + Therefore an extremely low or zero TTL on a zone's NS RRset rarely + makes sense, except in anticipation of an upcoming change. In this + case, when the zone's administrator has planned a change and does not + want iterative resolvers throughout the Internet to cache the NS + RRset for a long period of time, a low TTL is reasonable. + +2.7.1 Recommendation + + Because of the additional load placed on a zone's parent's + authoritative servers resulting from a zero TTL on a zone's NS RRset, + under such circumstances authoritative name servers SHOULD issue a + warning when loading a zone or refuse to load the zone altogether. + +2.8 Unnecessary dynamic update messages + + The UPDATE message specified in RFC 2136 [6] allows an authorized + agent to update a zone's data on an authoritative name server using a + DNS message sent over the network. Consider the case of an agent + desiring to add a particular resource record. Because of zone cuts, + the agent does not necessarily know the proper zone to which the + record should be added. The dynamic update process requires that the + agent determine the appropriate zone so the UPDATE message can be + sent to one of the zone's authoritative servers (typically the + primary master as specified in the zone's SOA MNAME field). + + The appropriate zone to update is the closest enclosing zone, which + cannot be determined only by inspecting the domain name of the record + to be updated, since zone cuts can occur anywhere. One way to + determine the closest enclosing zone entails walking up the name + space tree by sending repeated UPDATE messages until success. For + example, consider an agent attempting to add an address record with + the name "foo.bar.example.com". The agent could first attempt to + update the "foo.bar.example.com" zone. If the attempt failed, the + update could be directed to the "bar.example.com" zone, then the + "example.com" zone, then the "com" zone, and finally the root zone. + + A popular dynamic agent follows this algorithm. The result is many + UPDATE messages received by the root name servers, the com/net + authoritative servers, and presumably other TLD authoritative + servers. A valid question is why the algorithm proceeds to send + updates all the way to TLD and root name servers. This behavior is + not entirely unreasonable: in enterprise DNS architectures with an + "internal root" design, there could conceivably be private, + non-public TLD or root zones that would be the appropriate targets + for a dynamic update. + + + +Larson & Barber Expires April 27, 2005 [Page 12] + +Internet-Draft Observed DNS Resolution Misbehavior October 2004 + + + A significant deficiency with this algorithm is that knowledge of a + given UPDATE message's failure is not helpful in directing future + UPDATE messages to the appropriate servers. A better algorithm would + be to find the closest enclosing zone by walking up the name space + with queries for SOA or NS rather than "probing" with UPDATE + messages. Once the appropriate zone is found, an UPDATE message can + be sent. In addition, the results of these queries can be cached to + aid in determining closest enclosing zones for future updates. Once + the closest enclosing zone is determined with this method, the update + will either succeed or fail and there is no need to send further + updates to higher-level zones. The important point is that walking + up the tree with queries yields cacheable information, whereas + walking up the tree by sending UPDATE messages does not. + +2.8.1 Recommendation + + Dynamic update agents SHOULD send SOA or NS queries to progressively + higher-level zones to find the closest enclosing zone for a given + name to update. Only after the appropriate zone is found should the + client send an UPDATE message to one of the zone's authoritative + servers. Update clients SHOULD NOT "probe" using UPDATE messages by + walking up the tree to progressively higher-level zones. + +2.9 Queries for domain names resembling IP addresses + + The root name servers receive a significant number of A record + queries where the qname is an IP address. The source of these + queries is unknown. It could be attributed to situations where a + user believes an application will accept either a domain name or an + IP address in a given configuration option. The user enters an IP + address, but the application assumes any input is a domain name and + attempts to resolve it, resulting in an A record lookup. There could + also be applications that produce such queries in a misguided attempt + to reverse map IP addresses. + + These queries result in Name Error (RCODE=3) responses. An iterative + resolver can negatively cache such responses, but each response + requires a separate cache entry, i.e., a negative cache entry for the + domain name "192.0.2.1" does not prevent a subsequent query for the + domain name "192.0.2.2". + +2.9.1 Recommendation + + It would be desirable for the root name servers not to have to answer + these queries: they unnecessarily consume CPU resources and network + bandwidth. One possibility is for iterative resolver implementations + to produce the Name Error response directly. We suggest that + implementors consider the option of synthesizing Name Error responses + + + +Larson & Barber Expires April 27, 2005 [Page 13] + +Internet-Draft Observed DNS Resolution Misbehavior October 2004 + + + at the iterative resolver. The server could claim authority for + synthesized TLD zones corresponding to the first octet of every + possible IP address, e.g. 1., 2., through 255. This behavior could + be configurable in the (probably unlikely) event that numeric TLDs + are ever put into use. + + Another option is to delegate these numeric TLDs from the root zone + to a separate set of servers to absorb the traffic. The "black hole + servers" used by the the AS 112 +Project [8], which are currently + delegated the in-addr.arpa zones corresponding to RFC 1918 [7] + private use address space, would be a possible choice to receive + these delegations. + +2.10 Misdirected recursive queries + + The root name servers receive a significant number of recursive + queries (i.e., queries with the RD bit set in the header). Since + none of the root servers offers recursion, the servers' response in + such a situation ignores the request for recursion and the response + probably does not contain the data the querier anticipated. Some of + these queries result from users configuring stub resolvers to query a + root server. (This situation is not hypothetical: we have received + complaints from users when this configuration does not work as + hoped.) Of course, users should not direct stub resolvers to use name + servers that do not offer recursion, but we are not aware of any stub + resolver implementation that offers any feedback to the user when so + configured, aside from simply "not working". + +2.10.1 Recommendation + + When the IP address of a name server that supposedly offers recursion + is configured in a stub resolver using an interactive user interface, + the resolver could send a test query to verify that the server indeed + supports recursion (i.e., verify that the response has the RA bit set + in the header). The user could be immediately notified if the server + is non-recursive. + + The stub resolver could also report an error, either through a user + interface or in a log file, if the queried server does not support + recursion. Error reporting SHOULD be throttled to avoid a + notification or log message for every response from a non-recursive + server. + +2.11 Suboptimal name server selection algorithm + + An entire document could be devoted to the topic of problems with + different implementations of the recursive resolution algorithm. The + entire process of recursion is woefully under specified, requiring + + + +Larson & Barber Expires April 27, 2005 [Page 14] + +Internet-Draft Observed DNS Resolution Misbehavior October 2004 + + + each implementor to design an algorithm. Sometimes implementors make + poor design choices that could be avoided if a suggested algorithm + and best practices were documented, but that is a topic for another + document. + + Some deficiencies cause significant operational impact and are + therefore worth mentioning here. One of these is name server + selection by an iterative resolver. When an iterative resolver wants + to contact one of a zone's authoritative name servers, how does it + choose from the NS records listed in the zone's NS RRset? If the + selection mechanism is suboptimal, queries are not spread evenly + among a zone's authoritative servers. The details of the selection + mechanism are up to the implementor, but we offer some suggestions. + +2.11.1 Recommendation + + This list is not conclusive, but reflects the changes that would + produce the most impact in terms of reducing disproportionate query + load among a zone's authoritative servers. I.e., these changes would + help spread the query load evenly. + o Do not make assumptions based on NS RRset order: all NS RRs SHOULD + be treated equally. (In the case of the "com" zone, for example, + most of the root servers return the NS record for + "a.gtld-servers.net" first in the authority section of referrals. + Apparently as a result, this server receives disproportionately + more traffic than the other 12 authoritative servers for "com".) + o Use all NS records in an RRset. (For example, we are aware of + implementations that hard-coded information for a subset of the + root servers.) + o Maintain state and favor the best-performing of a zone's + authoritative servers. A good definition of performance is + response time. Non-responsive servers can be penalized with an + extremely high response time. + o Do not lock onto the best-performing of a zone's name servers. An + iterative resolver SHOULD periodically check the performance of + all of a zone's name servers to adjust its determination of the + best-performing one. + + + + + + + + + + + + + + +Larson & Barber Expires April 27, 2005 [Page 15] + +Internet-Draft Observed DNS Resolution Misbehavior October 2004 + + +3. IANA considerations + + There are no new IANA considerations introduced by this memo. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Larson & Barber Expires April 27, 2005 [Page 16] + +Internet-Draft Observed DNS Resolution Misbehavior October 2004 + + +4. Security considerations + + Name server and resolver misbehaviors identical or similar to those + discussed in this document expose the root and TLD name servers to + increased risk of both intentional and unintentional denial of + service. + + We believe that implementation of the recommendations offered in this + document will reduce the amount of unnecessary traffic seen at root + and TLD name servers, thus reducing the opportunity for an attacker + to use such queries to his or her advantage. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Larson & Barber Expires April 27, 2005 [Page 17] + +Internet-Draft Observed DNS Resolution Misbehavior October 2004 + + +5. Internationalization considerations + + We do not believe this document introduces any new + internationalization considerations to the DNS protocol + specification. + +6 Normative References + + [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + [2] Mockapetris, P., "Domain names - concepts and facilities", STD + 13, RFC 1034, November 1987. + + [3] Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, November 1987. + + [4] Elz, R. and R. Bush, "Clarifications to the DNS Specification", + RFC 2181, July 1997. + + [5] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", RFC + 2308, March 1998. + + [6] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic + Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April + 1997. + + [7] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G. and E. + Lear, "Address Allocation for Private Internets", BCP 5, RFC + 1918, February 1996. + + [8] + + +Authors' Addresses + + Matt Larson + VeriSign, Inc. + 21345 Ridgetop Circle + Dulles, VA 20166-6503 + USA + + EMail: mlarson@verisign.com + + + + + + + + +Larson & Barber Expires April 27, 2005 [Page 18] + +Internet-Draft Observed DNS Resolution Misbehavior October 2004 + + + Piet Barber + VeriSign, Inc. + 21345 Ridgetop Circle + Dulles, VA 20166-6503 + USA + + EMail: pbarber@verisign.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Larson & Barber Expires April 27, 2005 [Page 19] + +Internet-Draft Observed DNS Resolution Misbehavior October 2004 + + +Intellectual Property Statement + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + + +Disclaimer of Validity + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + +Copyright Statement + + Copyright (C) The Internet Society (2004). This document is subject + to the rights, licenses and restrictions contained in BCP 78, and + except as set forth therein, the authors retain all their rights. + + +Acknowledgment + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + +Larson & Barber Expires April 27, 2005 [Page 20] + + diff --git a/doc/draft/draft-ietf-dnsop-dnssec-operational-practices-02.txt b/doc/draft/draft-ietf-dnsop-dnssec-operational-practices-03.txt similarity index 68% rename from doc/draft/draft-ietf-dnsop-dnssec-operational-practices-02.txt rename to doc/draft/draft-ietf-dnsop-dnssec-operational-practices-03.txt index c8006c2c49..0f713dd77d 100644 --- a/doc/draft/draft-ietf-dnsop-dnssec-operational-practices-02.txt +++ b/doc/draft/draft-ietf-dnsop-dnssec-operational-practices-03.txt @@ -1,21 +1,20 @@ + DNSOP O. Kolkman Internet-Draft RIPE NCC -Expires: April 11, 2005 R. Gieben +Expires: June 23, 2005 R. Gieben NLnet Labs - October 11, 2004 + December 23, 2004 DNSSEC Operational Practices - draft-ietf-dnsop-dnssec-operational-practices-02.txt + draft-ietf-dnsop-dnssec-operational-practices-03.txt Status of this Memo - This document is an Internet-Draft and is subject to all provisions - of section 3 of RFC 3667. By submitting this Internet-Draft, each - author represents that any applicable patent or other IPR claims of - which he or she is aware have been or will be disclosed, and any of - which he or she become aware will be disclosed, in accordance with + By submitting this Internet-Draft, I certify that any applicable + patent or other IPR claims of which I am aware have been disclosed, + and any of which I become aware will be disclosed, in accordance with RFC 3668. Internet-Drafts are working documents of the Internet Engineering @@ -34,109 +33,120 @@ Status of this Memo The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on April 11, 2005. + This Internet-Draft will expire on June 23, 2005. Copyright Notice - Copyright (C) The Internet Society (2004). + Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract - This document describes a set of practices for operating a DNSSEC - aware environment. The target audience is zone administrators - deploying DNSSEC that need a guide to help them chose appropriate - values for DNSSEC parameters. It also discusses operational matters - such as key rollovers, KSK and ZSK considerations and related - matters. + This document describes a set of practices for operating the DNS with + security extensions (DNSSEC). The target audience is zone + administrators deploying DNSSEC. + + The document discusses operational aspects of using keys and + signatures in the DNS. It discusses issues as key generation, key + storage, signature generation, key rollover and related policies. -Kolkman & Gieben Expires April 11, 2005 [Page 1] + +Kolkman & Gieben Expires June 23, 2005 [Page 1] -Internet-Draft DNSSEC Operational Practices October 2004 +Internet-Draft DNSSEC Operational Practices December 2004 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 The Use of the Term 'key' . . . . . . . . . . . . . . . . 3 - 1.2 Keeping the Chain of Trust Intact . . . . . . . . . . . . 3 - 2. Time in DNSSEC . . . . . . . . . . . . . . . . . . . . . . . . 4 - 2.1 Time Definitions . . . . . . . . . . . . . . . . . . . . . 4 - 2.2 Time Considerations . . . . . . . . . . . . . . . . . . . 5 - 3. Keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 - 3.1 Motivations for the KSK and ZSK Separation . . . . . . . . 7 - 3.2 Key Security Considerations . . . . . . . . . . . . . . . 8 - 3.2.1 Key Validity Period . . . . . . . . . . . . . . . . . 8 - 3.2.2 Key Algorithm . . . . . . . . . . . . . . . . . . . . 8 - 3.2.3 Key Sizes . . . . . . . . . . . . . . . . . . . . . . 9 - 3.3 Key Rollovers . . . . . . . . . . . . . . . . . . . . . . 9 - 3.3.1 Difference Between ZSK and KSK Rollovers . . . . . . . 10 - 3.3.2 Zone-signing Key Rollovers . . . . . . . . . . . . . . 10 - 3.3.3 Key-signing Key Rollovers . . . . . . . . . . . . . . 14 - 3.3.4 Automated Key Rollovers . . . . . . . . . . . . . . . 15 - 4. Planning for Emergency Key Rollover . . . . . . . . . . . . . 15 - 4.1 KSK Compromise . . . . . . . . . . . . . . . . . . . . . . 16 - 4.2 ZSK Compromise . . . . . . . . . . . . . . . . . . . . . . 16 - 4.3 Compromises of Keys Anchored in Resolvers . . . . . . . . 16 - 5. Parental Policies . . . . . . . . . . . . . . . . . . . . . . 17 - 5.1 Initial Key Exchanges and Parental Policies - Considerations . . . . . . . . . . . . . . . . . . . . . . 17 - 5.2 Storing Keys So Hashes Can Be Regenerated . . . . . . . . 17 - 5.3 Security Lameness Checks . . . . . . . . . . . . . . . . . 18 - 5.4 DS Signature Validity Period . . . . . . . . . . . . . . . 18 - 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 - 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 - 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 - 8.1 Normative References . . . . . . . . . . . . . . . . . . . . 19 - 8.2 Informative References . . . . . . . . . . . . . . . . . . . 19 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 20 - A. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 20 - B. Zone-signing Key Rollover Howto . . . . . . . . . . . . . . . 21 - C. Typographic Conventions . . . . . . . . . . . . . . . . . . . 22 - D. Document Details and Changes . . . . . . . . . . . . . . . . . 23 - D.1 draft-ietf-dnsop-dnssec-operational-practices-00 . . . . . 23 - D.2 draft-ietf-dnsop-dnssec-operational-practices-01 . . . . . 23 - Intellectual Property and Copyright Statements . . . . . . . . 25 + 1.2 Time Definitions . . . . . . . . . . . . . . . . . . . . . 4 + 2. Keeping the Chain of Trust Intact . . . . . . . . . . . . . . 4 + 3. Keys Generation and Storage . . . . . . . . . . . . . . . . . 5 + 3.1 Zone and Key Signing Keys . . . . . . . . . . . . . . . . 5 + 3.1.1 Motivations for the KSK and ZSK Separation . . . . . . 5 + 3.1.2 KSKs for high level zones . . . . . . . . . . . . . . 6 + 3.2 Randomness . . . . . . . . . . . . . . . . . . . . . . . . 7 + 3.3 Key Effectivity Period . . . . . . . . . . . . . . . . . . 7 + 3.4 Key Algorithm . . . . . . . . . . . . . . . . . . . . . . 8 + 3.5 Key Sizes . . . . . . . . . . . . . . . . . . . . . . . . 8 + 3.6 Private Key Storage . . . . . . . . . . . . . . . . . . . 9 + 4. Signature generation, Key Rollover and Related Policies . . . 10 + 4.1 Time in DNSSEC . . . . . . . . . . . . . . . . . . . . . . 10 + 4.1.1 Time Considerations . . . . . . . . . . . . . . . . . 10 + 4.2 Key Rollovers . . . . . . . . . . . . . . . . . . . . . . 12 + 4.2.1 Difference Between ZSK and KSK Rollovers . . . . . . . 12 + 4.2.2 Zone-signing Key Rollovers . . . . . . . . . . . . . . 13 + 4.2.3 Key-signing Key Rollovers . . . . . . . . . . . . . . 17 + 4.2.4 Automated Key Rollovers . . . . . . . . . . . . . . . 18 + 4.3 Planning for Emergency Key Rollover . . . . . . . . . . . 18 + 4.3.1 KSK Compromise . . . . . . . . . . . . . . . . . . . . 19 + 4.3.2 ZSK Compromise . . . . . . . . . . . . . . . . . . . . 19 + 4.3.3 Compromises of Keys Anchored in Resolvers . . . . . . 19 + 4.4 Parental Policies . . . . . . . . . . . . . . . . . . . . 20 + 4.4.1 Initial Key Exchanges and Parental Policies + Considerations . . . . . . . . . . . . . . . . . . . . 20 + 4.4.2 Storing Keys So Hashes Can Be Regenerated . . . . . . 20 + 4.4.3 Security Lameness . . . . . . . . . . . . . . . . . . 21 + 4.4.4 DS Signature Validity Period . . . . . . . . . . . . . 21 + 5. Security Considerations . . . . . . . . . . . . . . . . . . . 21 + 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 + 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 + 7.1 Normative References . . . . . . . . . . . . . . . . . . . . 22 + 7.2 Informative References . . . . . . . . . . . . . . . . . . . 23 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 23 + A. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 24 + B. Zone-signing Key Rollover Howto . . . . . . . . . . . . . . . 24 + C. Typographic Conventions . . . . . . . . . . . . . . . . . . . 25 + D. Document Details and Changes . . . . . . . . . . . . . . . . . 26 + D.1 draft-ietf-dnsop-dnssec-operational-practices-00 . . . . . 27 + D.2 draft-ietf-dnsop-dnssec-operational-practices-01 . . . . . 27 + D.3 draft-ietf-dnsop-dnssec-operational-practices-02 . . . . . 27 + D.4 draft-ietf-dnsop-dnssec-operational-practices-03 . . . . . 27 + Intellectual Property and Copyright Statements . . . . . . . . 28 - - - - - - -Kolkman & Gieben Expires April 11, 2005 [Page 2] +Kolkman & Gieben Expires June 23, 2005 [Page 2] -Internet-Draft DNSSEC Operational Practices October 2004 +Internet-Draft DNSSEC Operational Practices December 2004 1. Introduction During workshops and early operational deployment tests, operators - and system administrators gained experience about operating DNSSEC - aware DNS services. This document translates these experiences into - a set of practices for zone administrators. At the time of writing, - there exists very little experience with DNSSEC in production - environments, this document should therefore explicitly not be seen - as representing 'Best Current Practices'. + and system administrators gained experience about operating the DNS + with security extensions (DNSSEC). This document translates these + experiences into a set of practices for zone administrators. At the + time of writing, there exists very little experience with DNSSEC in + production environments, this document should therefore explicitly + not be seen as representing 'Best Current Practices'. The procedures herein are focused on the maintenance of signed zones (i.e. signing and publishing zones on authoritative servers). It is intended that maintenance of zones such as resigning or key rollovers be transparent to any verifying clients on the Internet. - The structure of this document is as follows: It begins with - discussing some of the considerations with respect to timing - parameters of DNS in relation to DNSSEC (Section 2). Aspects of key - management such as key rollover schemes are described in Section 3. - Emergency rollover considerations are addressed in Section 4. The - typographic conventions used in this document are explained in + The structure of this document is as follows. In Section 2 we + discuss the importance of keeping the "chain of trust" intact. + Aspects of key generation and storage of private keys are discussed + in Section 3, the focus in this section is mainly on the private part + of the key(s). Section 4 describes considerations concerning the + public part of the keys. Since these public keys appear in the DNS + one has to take into account all kinds of timing issues, these are + discussed in Section 4.1. Section 4.2 and Section 4.3 deal with the + rollover, or supersession, of keys. Finally Section 4.4 discusses + considerations on how parents deal with their children's public keys + in order to maintain chains of trust. + + The typographic conventions used in this document are explained in Appendix C. Since this is a document with operational suggestions and there are - no protocol specifications, the RFC2119 [7] language does not apply. + no protocol specifications, the RFC2119 [6] language does not apply. + + This document obsoletes RFC2541 [1] 1.1 The Use of the Term 'key' @@ -150,7 +160,43 @@ Internet-Draft DNSSEC Operational Practices October 2004 in the DNSKEY resource record and that it is the public part that is used in key-exchanges. -1.2 Keeping the Chain of Trust Intact + + + + +Kolkman & Gieben Expires June 23, 2005 [Page 3] + +Internet-Draft DNSSEC Operational Practices December 2004 + + +1.2 Time Definitions + + In this document we will be using a number of time related terms. + The following definitions apply: + o "Signature validity period" + The period that a signature is valid. It starts at the time + specified in the signature inception field of the RRSIG RR and + ends at the time specified in the expiration field of the RRSIG + RR. + o "Signature publication period" + Time after which a signature (made with a specific key) is + replaced with a new signature (made with the same key). This + replacement takes place by publishing the relevant RRSIG in the + master zone file. + After one stopped publishing an RRSIG in a zone file it will + take a while before the RRSIG has actually been removed from + the DNS. + o "Key effectivity period" + The period during a key pair is effective. This period is + defined as the time between the first inception time stamp and + the last expiration date of any signature made with this key. + The key effectivity period can span multiple signature validity + intervals. + o "Maximum/Minimum Zone TTL" + The maximum or minimum value of the TTLs from the complete set + of RRs in a zone. + +2. Keeping the Chain of Trust Intact Maintaining a valid chain of trust is important because broken chains of trust will result in data being marked as bogus, which may cause @@ -160,14 +206,6 @@ Internet-Draft DNSSEC Operational Practices October 2004 As mentioned in the introduction, the procedures herein are intended to ensure maintenance of zones, such as resigning or key rollovers, - - - -Kolkman & Gieben Expires April 11, 2005 [Page 3] - -Internet-Draft DNSSEC Operational Practices October 2004 - - be transparent to the verifying clients on the Internet. Administrators of secured zones will have to keep in mind that data @@ -179,6 +217,14 @@ Internet-Draft DNSSEC Operational Practices October 2004 For the verifying clients it is important that data from secured zones can be used to build chains of trust regardless of whether the + + + +Kolkman & Gieben Expires June 23, 2005 [Page 4] + +Internet-Draft DNSSEC Operational Practices December 2004 + + data came directly from an authoritative server, a caching nameserver or some middle box. Only by carefully using the available timing parameters can a zone administrator assure that the data necessary @@ -188,59 +234,308 @@ Internet-Draft DNSSEC Operational Practices October 2004 administrators of secured zones in the chain of trust. This is most obvious in the case of a 'key compromise' when a trade off between maintaining a valid chain of trust and replacing the compromised keys - as soon as possible, must be made. + as soon as possible, must be made. Then zone administrators will + have to make a trade off between keeping the chain of trust intact - + thereby allowing for attacks with the compromised key - or to + deliberately break the chain of trust and making secured sub domains + invisible to security aware resolvers. Also see Section 4.3. - The zone administrator will have to make a trade off between keeping - the chain of trust intact - thereby allowing for attacks with the - compromised key - or to deliberately break the chain of trust and - making secured sub domains invisible to security aware resolvers. - Also see Section 4. +3. Keys Generation and Storage -2. Time in DNSSEC + This section describes a number of considerations with respect to the + security of keys. It deals with the generation, effectivity period, + size and storage of private keys. - Without DNSSEC all times in DNS are relative. The SOA's refresh, +3.1 Zone and Key Signing Keys + + The DNSSEC validation protocol does not distinguish between DNSKEYs. + All DNSKEYs can be used during the validation. In practice operators + use Key Singing and Zone Signing Keys and use the so called SEP flag + to distinguish between them during operations. The dynamics and + considerations are discussed below. + + To make zone re-signing and key rollovers procedures easier to + implement, it is possible to use one or more keys as Key Signing Keys + (KSK) these keys will only sign the apex DNSKEY RR set in a zone. + Other keys can be used to sign all the RRsets in a zone and are + referred to as Zone Signing Keys (ZSK). In this document we assume + that KSKs are the subset of keys that are used for key exchanges with + the parent and potentially for configuration as trusted anchors - the + so called Secure Entry Point keys (SEP). In this document we assume + a one-to-one mapping between KSK and SEP keys and we assume the SEP + flag [2] to be set on KSKs. + +3.1.1 Motivations for the KSK and ZSK Separation + + Differentiating between the KSK to ZSK functions has several + advantages: + + o The KSK can be made stronger (i.e. using more bits in the key + material). This has little operational impact since it is only + used to sign a small fraction of the zone data. + + + +Kolkman & Gieben Expires June 23, 2005 [Page 5] + +Internet-Draft DNSSEC Operational Practices December 2004 + + + o As the KSK is only used to sign a key set, which is most probably + updated less frequently than other data in the zone, it can be + stored separately from and in a safer location than the ZSK. + o A KSK can have a longer key effectivity period. + o No parent/child interaction is required when ZSKs are updated. + + The KSK is used less than ZSK, once a key set is signed with the KSK + all the keys in the key set can be used as ZSK. If a ZSK is + compromised, it can be simply dropped from the key set. The new key + set is then resigned with the KSK. + + Given the assumption that for KSKs the SEP flag is set, the KSK can + be distinguished from a ZSK by examining the flag field in the DNSKEY + RR. If the flag field is an odd number it is a KSK if it is an even + number it is a ZSK. + + The zone-signing key can be used to sign all the data in a zone on a + regular basis. When a zone-signing key is to be rolled, no + interaction with the parent is needed. This allows for "Signature + Validity Periods" in the order of days. + + The key-signing key is only to be used to sign the DNSKEY RRs in a + zone. If a key-signing key is to be rolled over, there will be + interactions with parties other than the zone administrator. These + can include the registry of the parent zone or administrators of + verifying resolvers that have the particular key configured as + trusted entry points. Hence, the key effectivity period of these + keys can and should be made much longer. Although, given a long + enough key, the Key Usage Time can be on the order of years we + suggest to plan for a key effectivity of the order of a few months so + that a key rollover remains an operational routine. + +3.1.2 KSKs for high level zones + + Higher level zones are generally more sensitive than lower level + zones. Anyone controlling or breaking the security of a zone thereby + obtains authority over all of its sub domains (except in the case of + resolvers that have locally configured the public key of a sub + domain). Therefore, extra care should be taken with high level zones + and strong keys used. + + The root zone is the most critical of all zones. Someone controlling + or compromising the security of the root zone would control the + entire DNS name space of all resolvers using that root zone (except + in the case of resolvers that have locally configured the public key + of a sub domain). Therefore, the utmost care must be taken in the + securing of the root zone. The strongest and most carefully handled + keys should be used. The root zone private key should always be kept + + + +Kolkman & Gieben Expires June 23, 2005 [Page 6] + +Internet-Draft DNSSEC Operational Practices December 2004 + + + off line. + + Many resolvers will start at a root server for their access to and + authentication of DNS data. Securely updating the trust anchors an + enormous population of resolvers around the world will be extremely + difficult. + +3.2 Randomness + + Careful generation of all keys is a sometimes overlooked but + absolutely essential element in any cryptographically secure system. + The strongest algorithms used with the longest keys are still of no + use if an adversary can guess enough to lower the size of the likely + key space so that it can be exhaustively searched. Technical + suggestions for the generation of random keys will be found in + RFC1750 [5]. One should carefully assess if the random number + generator used during key generation adheres to these suggestions. + + Keys with a long effectivity period are particularly sensitive as + they will represent a more valuable target and be subject to attack + for a longer time than short period keys. It is strongly recommended + that long term key generation occur off-line in a manner isolated + from the network via an air gap or, at a minimum, high level secure + hardware. + +3.3 Key Effectivity Period + + For various reasons keys in DNSSEC need to be changed once in a + while. The longer a key is in use, the greater the probability that + it will have been compromised through carelessness, accident, + espionage, or cryptanalysis. Furthermore when key rollovers are too + rare an event, they will not become part of the operational habit and + there is risk that no body on-site will remember the procedure for + rollover when the need is there. + + For Key Signing Keys a reasonable key effectivity period is 13 + months, with the intent to replace them after 12 months. An intended + key effectivity period of a month is reasonable for Zone Signing + Keys. + + Using these recommendations will lead to rollovers occurring + frequently enough to become part of 'operational habits'; the + procedure does not have to be reinvented every time a key is + replaced. + + Key effectivity periods can be made very short, as in the order of a + few minutes. But when replacing keys one has to take the + considerations from Section 4.1 and Section 4.2 into account. + + + +Kolkman & Gieben Expires June 23, 2005 [Page 7] + +Internet-Draft DNSSEC Operational Practices December 2004 + + +3.4 Key Algorithm + + There are currently three different types of algorithms that can be + used in DNSSEC: RSA, DSA and elliptic curve cryptography. The latter + is fairly new and still needs to be standardized for usage in DNSSEC. + + RSA has been developed in an open and transparent manner. As the + patent on RSA expired in 2000, its use is now also free. + + DSA has been developed by NIST. The creation of signatures creation + is roughly the same speed as with RSA, but is 10 to 40 times as slow + for verification [11]. + + We suggest the use of RSA/SHA-1 as the preferred algorithm for the + key. The current known attacks on RSA can be defeated by making your + key longer. As the MD5 hashing algorithm is showing (theoretical) + cracks, we recommend the usage of SHA1. + +3.5 Key Sizes + + When choosing key sizes, zone administrators will need to take into + account how long a key will be used and how much data will be signed + during the key publication period. It is hard to give precise + recommendations but Lenstra and Verheul [10] supplied the following + table with lower bound estimates for cryptographic key sizes. Their + recommendations are based on a set of explicitly formulated parameter + settings, combined with existing data points about cryptographic + systems. For details we refer to the original paper. + + + + + + + + + + + + + + + + + + + + + + + +Kolkman & Gieben Expires June 23, 2005 [Page 8] + +Internet-Draft DNSSEC Operational Practices December 2004 + + + Year RSA Key Sizes Year RSA Key Sizes + + 2000 952 2015 1613 + 2001 990 2016 1664 + 2002 1028 2017 1717 + 2003 1068 2018 1771 + 2004 1108 2019 1825 + + + 2005 1149 2020 1881 + 2006 1191 2021 1937 + 2007 1235 2022 1995 + 2008 1279 2023 2054 + 2009 1323 2024 2113 + + + 2026 2236 2025 2174 + 2010 1369 2027 2299 + 2011 1416 2028 2362 + 2012 1464 2029 2427 + 2013 1513 + 2014 1562 + + For example, should you wish your key to last three years from 2003, + check the RSA key size values for 2006 in this table. In this case + it should be at least 1191 bits. + + When determining a key size one should take into account that a large + key will be slower during generation and verification. For RSA, + verification, the most common operation, will vary roughly with the + square of the key size signing will vary with the cube of the key + size length, and key generation will vary with the fourth power of + the modulus length. Besides larger keys will increase the sizes of + the RRSIG and DNSKEY records and will therefore increase the chance + of DNS UDP packet overflow. Also see Section 3.1.1. + +3.6 Private Key Storage + + It is recommended that, where possible, zone private keys and the + zone file master copy be kept and used in off-line, non-network + connected, physically secure machines only. Periodically an + application can be run to add authentication to a zone by adding + RRSIG and NSEC RRs. Then the augmented file can be transferred, + perhaps by sneaker-net, to the networked zone primary server machine. + + The ideal situation is to have a one way information flow to the + network to avoid the possibility of tampering from the network. + Keeping the zone master file on-line on the network and simply + + + +Kolkman & Gieben Expires June 23, 2005 [Page 9] + +Internet-Draft DNSSEC Operational Practices December 2004 + + + cycling it through an off-line signer does not do this. The on-line + version could still be tampered with if the host it resides on is + compromised. For maximum security, the master copy of the zone file + should be off net and should not be updated based on an unsecured + network mediated communication. + + In general keeping a zone-file off-line will not be practical and the + machines on which zone files are maintained will be connected to a + network. Operators are advised to take security measures to shield + unauthorized access to the master copy. + + For dynamically updated secured zones RFC2137 [7] both the master + copy and the private key that is used to update signatures on updated + RRs will need to be on line. + +4. Signature generation, Key Rollover and Related Policies + +4.1 Time in DNSSEC + + Without DNSSEC all times in DNS are relative. The SOA RR's refresh, retry and expiration timers are counters that are used to determine the time elapsed after a slave server synchronized (or tried to synchronize) with a master server. The Time to Live (TTL) value and - the SOA minimum TTL parameter [8] are used to determine how long a + the SOA RR minimum TTL parameter [8] are used to determine how long a forwarder should cache data after it has been fetched from an authoritative server. By using a signature validity period, DNSSEC introduces the notion of an absolute time in the DNS. Signatures in DNSSEC have an expiration date after which the signature is marked as invalid and the signed data is to be considered bogus. -2.1 Time Definitions - - In this document we will be using a number of time related terms. - The following definitions apply: - o "Signature validity period" - - - - - -Kolkman & Gieben Expires April 11, 2005 [Page 4] - -Internet-Draft DNSSEC Operational Practices October 2004 - - - The period that a signature is valid. It starts at the time - specified in the signature inception field of the RRSIG RR and - ends at the time specified in the expiration field of the RRSIG - RR. - o "Signature publication period" - Time after which a signature (made with a specific key) is - replaced with a new signature (made with the same key). This - replacement takes place by publishing the relevant RRSIG in the - master zone file. - If all signatures are refreshed at zone (re)signing then the - signature publication period is equal to the signature validity - period. - o "Maximum/Minimum Zone TTL" - The maximum or minimum value of the TTLs from the complete set - of RRs in a zone. - -2.2 Time Considerations +4.1.1 Time Considerations Because of the expiration of signatures, one should consider the following. @@ -249,12 +544,23 @@ Internet-Draft DNSSEC Operational Practices October 2004 If the TTL would be of similar order as the signature validity period, then all RRsets fetched during the validity period would be cached until the signature expiration time. Section - 7.1 [5] suggests that "the resolver may use the time remaining - before expiration of the signature validity period of a signed - RRset as an upper bound for the TTL". As a result query load - on authoritative servers would peak at signature expiration - time, as this is also the time at which records simultaneously - expire from caches. + 7.1 of [3] suggests that "the resolver may use the time + remaining before expiration of the signature validity period of + a signed RRset as an upper bound for the TTL". As a result + query load on authoritative servers would peak at signature + expiration time, as this is also the time at which records + simultaneously expire from caches. + + + + + + +Kolkman & Gieben Expires June 23, 2005 [Page 10] + +Internet-Draft DNSSEC Operational Practices December 2004 + + To avoid query load peaks we suggest the TTL on all the RRs in your zone to be at least a few times smaller than your signature validity period. @@ -265,21 +571,13 @@ Internet-Draft DNSSEC Operational Practices October 2004 caches. This in turn may lead to peaks in the load on authoritative servers. o We suggest the minimum zone TTL to be long enough to both fetch - and verify all the RRs in the authentication chain. A low TTL can - cause two problems: + and verify all the RRs in the authentication chain. A low TTL + could cause two problems: 1. During validation, some data may expire before the validation is complete. The validator should be able to keep all data, until is completed. This applies to all RRs needed to complete the chain of trust: DSs, DNSKEYs, RRSIGs, and the final answers i.e. the RR set that is returned for the initial - - - -Kolkman & Gieben Expires April 11, 2005 [Page 5] - -Internet-Draft DNSSEC Operational Practices October 2004 - - query. 2. Frequent verification causes load on recursive nameservers. Data at delegation points, DSs, DNSKEYs and RRSIGs benefit from @@ -309,6 +607,16 @@ Internet-Draft DNSSEC Operational Practices October 2004 data served by the particular slave servers while security aware resolvers will experience problems because of answers being marked as bogus. + + + + + +Kolkman & Gieben Expires June 23, 2005 [Page 11] + +Internet-Draft DNSSEC Operational Practices December 2004 + + We suggest the SOA expiration timer being approximately one third or one fourth of the signature validity period. It will allow problems with transfers from the master server to be @@ -323,186 +631,16 @@ Internet-Draft DNSSEC Operational Practices October 2004 not DNSSEC specific but may influence the choice of your signature validity intervals. -3. Keys - - The DNSSEC validation protocol does not distinguish between DNSKEYs. - All DNSKEYs can be used during the validation. In practice operators - use Key Singing and Zone Signing Keys and use the so called SEP flag - - - -Kolkman & Gieben Expires April 11, 2005 [Page 6] - -Internet-Draft DNSSEC Operational Practices October 2004 - - - to distinguish between them during operations. The dynamics and - considerations are discussed below. - - To make zone re-signing and key rollovers procedures easier to - implement, it is possible to use one or more keys as Key Signing Keys - (KSK) these keys will only sign the apex DNSKEY RR set in a zone. - Other keys can be used to sign all the RRsets in a zone and are - referred to as Zone Signing Keys (ZSK). In this document we assume - that KSKs are the subset of keys that are used for key exchanges with - the parent and potentially for configuration as trusted anchors - the - so called Secure Entry Point keys (SEP). In this document we assume - a one-to-one mapping between KSK and SEP keys and we assume the SEP - flag [4] to be set on KSKs. - -3.1 Motivations for the KSK and ZSK Separation - - Differentiating between the KSK to ZSK functions has several - advantages: - - o The KSK can be made stronger (i.e. using more bits in the key - material). This has little operational impact since it is only - used to sign a small fraction of the zone data. - o As the KSK is only used to sign a key set, which is most probably - updated less frequently than other data in the zone, it can be - stored separately from and in a safer location than the ZSK. - o A KSK can be used for longer periods. - o No parent/child interaction is required when ZSKs are updated. - - The KSK is used less than ZSK, once a key set is signed with the KSK - all the keys in the key set can be used as ZSK. If a ZSK is - compromised, it can be simply dropped from the key set. The new key - set is then resigned with the KSK. - - Given the assumption that for KSKs the SEP flag is set, the KSK can - be distinguished from a ZSK by examining the flag field in the DNSKEY - RR. If the flag field is an odd number it is a KSK if it is an even - number it is a ZSK. - - The zone-signing key can be used to sign all the data in a zone on a - regular basis. When a zone-signing key is to be rolled, no - interaction with the parent is needed. This allows for "Signature - Validity Periods" in the order of days. - - The key-signing key is only to be used to sign the DNSKEY RRs in a - zone. If a key-signing key is to be rolled over, there will be - interactions with parties other than the zone administrator. These - can include the registry of the parent zone or administrators of - verifying resolvers that have the particular key configured as - - - -Kolkman & Gieben Expires April 11, 2005 [Page 7] - -Internet-Draft DNSSEC Operational Practices October 2004 - - - trusted entry points. Hence, the "Key Usage Time" of these keys can - and should be made much longer. Although, given a long enough key, - the "Key Usage Time" can be on the order of years we suggest to plan - for a "Key Usage Time" of the order of a few months so that a key - rollover remains an operational routine. - -3.2 Key Security Considerations - - Keys in DNSSEC have a number of parameters which should all be chosen - with care, the most important once are: size, algorithm and the key - validity period (its lifetime). - -3.2.1 Key Validity Period - - RFC2541 [2] describes a number of considerations with respect to the - security of keys. The document deals with the generation, lifetime, - size and storage of private keys. - - In Section 3 of RFC2541 [2] there are some suggestions for a key - validity period: 13 months for long-lived keys and 36 days for - transaction keys but suggestions for key sizes are not made. - - If we say long-lived keys are key-signing keys and transactions keys - are zone-signing keys, these recommendations will lead to rollovers - occurring frequently enough to become part of 'operational habits'; - the procedure does not have to be reinvented every time a key is - replaced. - -3.2.2 Key Algorithm - - There are currently three different types of algorithms that can be - used in DNSSEC: RSA, DSA and elliptic curve cryptography. The latter - is fairly new and still needs to be standardized for usage in DNSSEC. - - RSA has been developed in an open and transparent manner. As the - patent on RSA expired in 2000, its use is now also free. - - DSA has been developed by NIST. The creation of signatures creation - is roughly the same speed as with RSA, but is 10 to 40 times as slow - for verification [11]. - - We suggest the use of RSA/SHA-1 as the preferred algorithm for the - key. The current known attacks on RSA can be defeated by making your - key longer. As the MD5 hashing algorithm is showing (theoretical) - cracks, we recommend the usage of SHA1. - - - - - - -Kolkman & Gieben Expires April 11, 2005 [Page 8] - -Internet-Draft DNSSEC Operational Practices October 2004 - - -3.2.3 Key Sizes - - When choosing key sizes, zone administrators will need to take into - account how long a key will be used and how much data will be signed - during the key publication period. It is hard to give precise - recommendations but Lenstra and Verheul [10] supplied the following - table with lower bound estimates for cryptographic key sizes. Their - recommendations are based on a set of explicitly formulated parameter - settings, combined with existing data points about cryptographic - systems. For details we refer to the original paper. - - - Year RSA Key Sizes Year RSA Key Sizes - - 2000 952 2015 1613 - 2001 990 2016 1664 - 2002 1028 2017 1717 - 2003 1068 2018 1771 - 2004 1108 2019 1825 - - - 2005 1149 2020 1881 - 2006 1191 2021 1937 - 2007 1235 2022 1995 - 2008 1279 2023 2054 - 2009 1323 2024 2113 - - - 2026 2236 2025 2174 - 2010 1369 2027 2299 - 2011 1416 2028 2362 - 2012 1464 2029 2427 - 2013 1513 - 2014 1562 - - For example, should you wish your key to last three years from 2003, - check the RSA key size values for 2006 in this table. In this case - 1191. - -3.3 Key Rollovers - - A DNSSEC key cannot be used forever (see RFC2541 [2] and Section - 3.2). So key rollovers are a fact of life when using DNSSEC. Zone - administrators who are in the process of rolling their keys have to - take into account that data published in previous versions of their - zone still lives in caches. When deploying DNSSEC, this becomes an - important consideration; ignoring data that may be in caches may lead - to loss of service for clients. - - - -Kolkman & Gieben Expires April 11, 2005 [Page 9] - -Internet-Draft DNSSEC Operational Practices October 2004 +4.2 Key Rollovers + A DNSSEC key cannot be used forever (see Section 3.3). So key + rollovers -- or supersessions, as they are sometimes called -- are a + fact of life when using DNSSEC. Zone administrators who are in the + process of rolling their keys have to take into account that data + published in previous versions of their zone still lives in caches. + When deploying DNSSEC, this becomes an important consideration; + ignoring data that may be in caches may lead to loss of service for + clients. The most pressing example of this is when zone material signed with an old key is being validated by a resolver which does not have the @@ -512,11 +650,11 @@ Internet-Draft DNSSEC Operational Practices October 2004 signed with a new key against an old key that lives in a local cache, also resulting in data being marked bogus. -3.3.1 Difference Between ZSK and KSK Rollovers +4.2.1 Difference Between ZSK and KSK Rollovers Note that KSK rollovers and ZSK rollovers are different. A zone-key rollover can be handled in two different ways: pre-publish (Section - Section 3.3.2.1) and double signature (Section Section 3.3.2.2). + Section 4.2.2.1) and double signature (Section Section 4.2.2.2). As the KSK is used to validate the key set and because the KSK is not changed during a ZSK rollover, a cache is able to validate the new @@ -525,6 +663,16 @@ Internet-Draft DNSSEC Operational Practices October 2004 KSK from DNSKEY1 to DNSKEY2 using the NONE working pre-publish method. + + + + + +Kolkman & Gieben Expires June 23, 2005 [Page 12] + +Internet-Draft DNSSEC Operational Practices December 2004 + + normal pre-roll roll after SOA0 SOA1 SOA2 SOA3 @@ -544,25 +692,17 @@ Internet-Draft DNSSEC Operational Practices October 2004 by DNSKEY2. It will then try to validate the key set with DNSKEY1 and will fail. -3.3.2 Zone-signing Key Rollovers +4.2.2 Zone-signing Key Rollovers For zone-signing key rollovers there are two ways to make sure that during the rollover data still cached can be verified with the new key sets or newly generated signatures can be verified with the keys still in caches. One schema uses double signatures, it is described - in Section 3.3.2.2, the other uses key pre-publication (Section - 3.3.2.1). The pros, cons and recommendations are described in + in Section 4.2.2.2, the other uses key pre-publication (Section + 4.2.2.1). The pros, cons and recommendations are described in + Section 4.2.2.3. - - -Kolkman & Gieben Expires April 11, 2005 [Page 10] - -Internet-Draft DNSSEC Operational Practices October 2004 - - - Section 3.3.2.3. - -3.3.2.1 Pre-publish key set Rollover +4.2.2.1 Pre-publish key set Rollover This section shows how to perform a ZSK rollover without the need to sign all the data in a zone twice - the so called "pre-publish @@ -574,6 +714,21 @@ Internet-Draft DNSSEC Operational Practices October 2004 as is the case with the double signature ZSK rollover. A small "HOWTO" for this kind of rollover can be found in Appendix B. + + + + + + + + + + +Kolkman & Gieben Expires June 23, 2005 [Page 13] + +Internet-Draft DNSSEC Operational Practices December 2004 + + normal pre-roll roll after SOA0 SOA1 SOA2 SOA3 @@ -607,15 +762,6 @@ Internet-Draft DNSSEC Operational Practices October 2004 time it takes for this zone to propagate to all authoritative servers plus the Maximum Zone TTL value of any of the data in the previous version of the zone. - - - - -Kolkman & Gieben Expires April 11, 2005 [Page 11] - -Internet-Draft DNSSEC Operational Practices October 2004 - - after: DNSKEY 10 is removed from the zone. The key set, now only containing DNSKEY 11 is resigned with the DNSKEY 1. @@ -625,6 +771,20 @@ Internet-Draft DNSSEC Operational Practices October 2004 DNSKEY 12 and again a newer one, numbered 13, in "2nd after": + + + + + + + + + +Kolkman & Gieben Expires June 23, 2005 [Page 14] + +Internet-Draft DNSSEC Operational Practices December 2004 + + normal roll after SOA0 SOA2 SOA3 @@ -654,7 +814,7 @@ Internet-Draft DNSSEC Operational Practices October 2004 secure manner and does not need to be 'fetched' every time a zone needs to be signed. -3.3.2.2 Double Signature Zone-signing Key Rollover +4.2.2.2 Double Signature Zone-signing Key Rollover This section shows how to perform a ZSK key rollover using the double zone data signature scheme, aptly named "double sig rollover". @@ -667,9 +827,18 @@ Internet-Draft DNSSEC Operational Practices October 2004 -Kolkman & Gieben Expires April 11, 2005 [Page 12] + + + + + + + + + +Kolkman & Gieben Expires June 23, 2005 [Page 15] -Internet-Draft DNSSEC Operational Practices October 2004 +Internet-Draft DNSSEC Operational Practices December 2004 normal roll after @@ -715,7 +884,7 @@ Internet-Draft DNSSEC Operational Practices October 2004 during the rollover. New data can be introduced in the zone as long as it is signed with both keys. -3.3.2.3 Pros and Cons of the Schemes +4.2.2.3 Pros and Cons of the Schemes @@ -723,9 +892,9 @@ Internet-Draft DNSSEC Operational Practices October 2004 -Kolkman & Gieben Expires April 11, 2005 [Page 13] +Kolkman & Gieben Expires June 23, 2005 [Page 16] -Internet-Draft DNSSEC Operational Practices October 2004 +Internet-Draft DNSSEC Operational Practices December 2004 Pre-publish-key set rollover: This rollover does not involve signing @@ -733,13 +902,13 @@ Internet-Draft DNSSEC Operational Practices October 2004 the new key is published in the key set and thus available for cryptanalysis attacks. A small disadvantage is that this process requires four steps. Also the pre-publish scheme will not work - for KSKs as explained in Section 3.3. + for KSKs as explained in Section 4.2. Double signature rollover: The drawback of this signing scheme is that during the rollover the number of signatures in your zone doubles, this may be prohibitive if you have very big zones. An advantage is that it only requires three steps. -3.3.3 Key-signing Key Rollovers +4.2.3 Key-signing Key Rollovers For the rollover of a key-signing key the same considerations as for the rollover of a zone-signing key apply. However we can use a @@ -779,9 +948,9 @@ Internet-Draft DNSSEC Operational Practices October 2004 -Kolkman & Gieben Expires April 11, 2005 [Page 14] +Kolkman & Gieben Expires June 23, 2005 [Page 17] -Internet-Draft DNSSEC Operational Practices October 2004 +Internet-Draft DNSSEC Operational Practices December 2004 after: DNSKEY1 has been removed. @@ -797,10 +966,10 @@ Internet-Draft DNSSEC Operational Practices October 2004 interaction has not been developed further discussion is out of scope for this document. -3.3.4 Automated Key Rollovers +4.2.4 Automated Key Rollovers As keys must be renewed periodically, there are some motivation to - automate the rollover process (also see [12]) + automate the rollover process. Consider that: o ZSK rollovers are easy to automate as only the local zone is involved. @@ -808,10 +977,10 @@ Internet-Draft DNSSEC Operational Practices October 2004 Data exchange is needed to provide the new keys to the parent, consequently, this data must be authenticated and integrity must be guaranteed in order to avoid attacks on the rollover. - o All time and TTL considerations presented in Section 3.3 apply to + o All time and TTL considerations presented in Section 4.2 apply to an automated rollover. -4. Planning for Emergency Key Rollover +4.3 Planning for Emergency Key Rollover This section deals with preparation for a possible key compromise. Our advice is to have a documented procedure ready for when a key @@ -835,9 +1004,9 @@ Internet-Draft DNSSEC Operational Practices October 2004 -Kolkman & Gieben Expires April 11, 2005 [Page 15] +Kolkman & Gieben Expires June 23, 2005 [Page 18] -Internet-Draft DNSSEC Operational Practices October 2004 +Internet-Draft DNSSEC Operational Practices December 2004 chooses to break the authentication chain to the compromised key, @@ -849,7 +1018,7 @@ Internet-Draft DNSSEC Operational Practices October 2004 where the spoof takes place. -4.1 KSK Compromise +4.3.1 KSK Compromise When the KSK has been compromised the parent must be notified as soon as possible using secure means. The key set of the zone should be @@ -867,7 +1036,7 @@ Internet-Draft DNSSEC Operational Practices October 2004 dispute. An out of band and secure notify mechanism to contact a parent is needed in this case. -4.2 ZSK Compromise +4.3.2 ZSK Compromise Primarily because there is no parental interaction required when a ZSK is compromised, the situation is less severe than with with a KSK @@ -879,7 +1048,7 @@ Internet-Draft DNSSEC Operational Practices October 2004 compromised key may lead to verification problems. The pre-publication scheme as discussed above minimizes such problems. -4.3 Compromises of Keys Anchored in Resolvers +4.3.3 Compromises of Keys Anchored in Resolvers A key can also be pre-configured in resolvers. For instance, if DNSSEC is successfully deployed the root key will be pre-configured @@ -891,9 +1060,9 @@ Internet-Draft DNSSEC Operational Practices October 2004 -Kolkman & Gieben Expires April 11, 2005 [Page 16] +Kolkman & Gieben Expires June 23, 2005 [Page 19] -Internet-Draft DNSSEC Operational Practices October 2004 +Internet-Draft DNSSEC Operational Practices December 2004 about to be rolled over. This communication will of course need to @@ -904,9 +1073,9 @@ Internet-Draft DNSSEC Operational Practices October 2004 DNS, for example, looking them up on an x.509 secured announcement website. -5. Parental Policies +4.4 Parental Policies -5.1 Initial Key Exchanges and Parental Policies Considerations +4.4.1 Initial Key Exchanges and Parental Policies Considerations The initial key exchange is always subject to the policies set by the parent (or its registry). When designing a key exchange policy one @@ -920,7 +1089,7 @@ Internet-Draft DNSSEC Operational Practices October 2004 Using the DNS itself as the source for the actual DNSKEY material, with an off-band check on the validity of the DNSKEY, has the benefit that it reduces the chances of user error. A parental DNSKEY - download tool can make use of the SEP bit [4] to select the proper + download tool can make use of the SEP bit [2] to select the proper key from a DNSSEC key set; thereby reducing the chance that the wrong DNSKEY is sent. It can validate the self-signature over a key; thereby verifying the ownership of the private key material. @@ -932,7 +1101,7 @@ Internet-Draft DNSSEC Operational Practices October 2004 is fetched via the DNS. The parent can never be sure whether the DNSKEY RRs have been spoofed or not. -5.2 Storing Keys So Hashes Can Be Regenerated +4.4.2 Storing Keys So Hashes Can Be Regenerated When designing a registry system one should consider if the DNSKEYs and/or the corresponding DSs are stored. Storing DNSKEYs will help @@ -947,12 +1116,12 @@ Internet-Draft DNSSEC Operational Practices October 2004 -Kolkman & Gieben Expires April 11, 2005 [Page 17] +Kolkman & Gieben Expires June 23, 2005 [Page 20] -Internet-Draft DNSSEC Operational Practices October 2004 +Internet-Draft DNSSEC Operational Practices December 2004 -5.3 Security Lameness Checks +4.4.3 Security Lameness Security Lameness is defined as what happens when a parent has a DS RR pointing to a non-existing DNSKEY RR. During key exchange a @@ -966,7 +1135,7 @@ Internet-Draft DNSSEC Operational Practices October 2004 Once a zone is "security lame" a fix (e.g. by removing a DS RR) will take time to propagate through the DNS. -5.4 DS Signature Validity Period +4.4.4 DS Signature Validity Period Since the DS can be replayed as long as it has a valid signature a short signature validity period over the DS minimizes the time a @@ -976,11 +1145,11 @@ Internet-Draft DNSSEC Operational Practices October 2004 error in the signer. There may not be enough time to fix the problems before signatures expire. Something as mundane as operator unavailability during weekends shows the need for DS signature - lifetimes longer than 2 days. We recommend the minimum for a DS - signature validity period to be a few days. + validity periods longer than 2 days. We recommend the minimum for a + DS signature validity period to be a few days. - The maximum signature lifetime of the DS record depends on how long - child zones are willing to be vulnerable after a key compromise. + The maximum signature validity period of the DS record depends on how + long child zones are willing to be vulnerable after a key compromise. Other considerations, such as how often the zone is (re)signed can also be taken into account. @@ -988,81 +1157,92 @@ Internet-Draft DNSSEC Operational Practices October 2004 good compromise between the operational constraints of the parent and minimizing damage for the child. -6. Security Considerations + In addition to the signature validity period, which sets the lower + bounds on the amount of times the zone owner will need to sign the + zone data and which sets an upper bound to the time a child is + vulnerable after key compromise there is the TTL value on the DS RRs. + By lowering the TTL the authoritative servers will see more queries, + on the other hand a low TTL increases the speed with which new DS RRs + propagate through the DNS. As argued in Section 4.1.1 the TTL should + be a fraction of the signature validity period. + +5. Security Considerations DNSSEC adds data integrity to the DNS. This document tries to assess + + + +Kolkman & Gieben Expires June 23, 2005 [Page 21] + +Internet-Draft DNSSEC Operational Practices December 2004 + + considerations to operate a stable and secure DNSSEC service. Not taking into account the 'data propagation' properties in the DNS will cause validation failures and may make secured zones unavailable to security aware resolvers. -7. Acknowledgments +6. Acknowledgments - We, the folk mentioned as authors, only acted as editors. Most of - the ideas in this draft were the result of collective efforts during - - - -Kolkman & Gieben Expires April 11, 2005 [Page 18] - -Internet-Draft DNSSEC Operational Practices October 2004 - - - workshops, discussions and try outs. + Most of the ideas in this draft were the result of collective efforts + during workshops, discussions and try outs. At the risk of forgetting individuals who where the original contributors of the ideas we would like to acknowledge people who where actively involved in the compilation of this document. In - random order: Olafur Gudmundsson, Wesley Griffin, Michael Richardson, - Scott Rose, Rick van Rein, Tim McGinnis, Gilles Guette and Olivier - Courtay, Sam Weiler, Jelte Jansen. + random order: Rip Loomis, Olafur Gudmundsson, Wesley Griffin, Michael + Richardson, Scott Rose, Rick van Rein, Tim McGinnis, Gilles Guette + and Olivier Courtay, Sam Weiler, Jelte Jansen. + + Some material in this document has been shamelessly copied from + RFC2541 [1] by Donald Eastlake. Mike StJohns designed the key exchange between parent and child - mentioned in the last paragraph of Section 3.3.3 + mentioned in the last paragraph of Section 4.2.3 - Section 3.3.4 was supplied by G. Guette and O. Courtay. + Section 4.2.4 was supplied by G. Guette and O. Courtay. Emma Bretherick and Adrian Bedford corrected many of the spelling and style issues. Kolkman and Gieben take the blame for introducing all miscakes(SIC). -8. References +7. References -8.1 Normative References +7.1 Normative References - [1] Eastlake, D., "Domain Name System Security Extensions", RFC - 2535, March 1999. - - [2] Eastlake, D., "DNS Security Operational Considerations", RFC + [1] Eastlake, D., "DNS Security Operational Considerations", RFC 2541, March 1999. - [3] Lewis, E., "DNS Security Extension Clarification on Zone - Status", RFC 3090, March 2001. + [2] Kolkman, O., Schlyter, J. and E. Lewis, "Domain Name System KEY + (DNSKEY) Resource Record (RR) Secure Entry Point (SEP) Flag", + RFC 3757, May 2004. - [4] Lewis, E., Kolkman, O. and J. Schlyter, "KEY RR Key-Signing Key - (KSK) Flag", draft-ietf-dnsext-keyrr-key-signing-flag-06 (work - in progress), February 2003. - - [5] Arends, R., "DNS Security Introduction and Requirements", + [3] Arends, R., "DNS Security Introduction and Requirements", draft-ietf-dnsext-dnssec-intro-11 (work in progress), March 2003. - [6] Arends, R., "Protocol Modifications for the DNS Security + [4] Arends, R., "Protocol Modifications for the DNS Security Extensions", draft-ietf-dnsext-dnssec-protocol-07 (work in progress), March 2003. -8.2 Informative References - [7] Bradner, S., "Key words for use in RFCs to Indicate Requirement + +Kolkman & Gieben Expires June 23, 2005 [Page 22] + +Internet-Draft DNSSEC Operational Practices December 2004 + + +7.2 Informative References + + [5] Eastlake, D., Crocker, S. and J. Schiller, "Randomness + Recommendations for Security", RFC 1750, December 1994. + + [6] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. - - -Kolkman & Gieben Expires April 11, 2005 [Page 19] - -Internet-Draft DNSSEC Operational Practices October 2004 - + [7] Eastlake, D., "Secure Domain Name System Dynamic Update", RFC + 2137, April 1997. [8] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", RFC 2308, March 1998. @@ -1076,10 +1256,6 @@ Internet-Draft DNSSEC Operational Practices October 2004 [11] Schneier, B., "Applied Cryptography: Protocols, Algorithms, and Source Code in C", 1996. - [12] Guette, G., "Requirements for Automated Key Rollover in - DNSsec", draft-ietf-dnsop-key-rollover-requirements-01 (work in - progress), August 2004. - Authors' Addresses @@ -1103,6 +1279,16 @@ Authors' Addresses EMail: miek@nlnetlabs.nl URI: http://www.nlnetlabs.nl + + + + + +Kolkman & Gieben Expires June 23, 2005 [Page 23] + +Internet-Draft DNSSEC Operational Practices December 2004 + + Appendix A. Terminology In this document there is some jargon used that is defined in other @@ -1111,41 +1297,35 @@ Appendix A. Terminology of the meaning. Note that these explanations should not be seen as authoritative. - - - - -Kolkman & Gieben Expires April 11, 2005 [Page 20] - -Internet-Draft DNSSEC Operational Practices October 2004 - - + Anchored Key: A DNSKEY configured in resolvers around the globe. + This key is hard to update, hence the term anchored. + Bogus: Also see Section 5 of [3]. An RRset in DNSSEC is marked + "Bogus" when a signature of a RRset does not validate against a + DNSKEY. + Key-Signing Key or KSK: A Key-Signing Key (KSK) is a key that is used + exclusively for signing the apex key set. The fact that a key is + a KSK is only relevant to the signing tool. Private and Public Keys: DNSSEC secures the DNS through the use of public key cryptography. Public key cryptography is based on the existence of two keys, a public key and a private key. The public keys are published in the DNS by use of the DNSKEY Resource Record (DNSKEY RR). Private keys should remain private. + Key Rollover: A key rollover (also called key supersession in some + environments) is the act of replacing one key pair by another at + the end of a key effectivity period. + Secure Entry Point key or SEP Key: A KSK that has a parental DS + record pointing to it. Note: this is not enforced in the + protocol. A SEP Key with no parental DS is security lame. + Singing the Zone File: The term used for the event where an + administrator joyfully signs its zone file while producing melodic + sound patterns. Signer: The system that has access to the private key material and signs the Resource Record sets in a zone. A signer may be configured to sign only parts of the zone e.g. only those RRsets for which existing signatures are about to expire. - KSK: A Key-Signing Key (KSK) is a key that is used exclusively for - signing the apex key set. The fact that a key is a KSK is only - relevant to the signing tool. - ZSK: A Zone Signing Key (ZSK) is a key that is used for signing all - data in a zone. The fact that a key is a ZSK is only relevant to - the signing tool. - SEP Key: A KSK that has a parental DS record pointing to it. Note: - this is not enforced in the protocol. A SEP Key with no parental - DS is security lame. - Anchored Key: A DNSKEY configured in resolvers around the globe. - This key is hard to update, hence the term anchored. - Bogus: Also see Section 5 of [5]. An RRset in DNSSEC is marked - "Bogus" when a signature of a RRset does not validate against a - DNSKEY. - Singing the Zone File: The term used for the event where an - administrator joyfully signs its zone file while producing melodic - sound patterns. + Zone-Signing Key or ZSK: A Zone Signing Key (ZSK) is a key that is + used for signing all data in a zone. The fact that a key is a ZSK + is only relevant to the signing tool. Zone Administrator: The 'role' that is responsible for signing a zone and publishing it on the primary authoritative server. @@ -1154,7 +1334,17 @@ Appendix B. Zone-signing Key Rollover Howto Using the pre-published signature scheme and the most conservative method to assure oneself that data does not live in caches here follows the "HOWTO". - Key notation: + + + + + + +Kolkman & Gieben Expires June 23, 2005 [Page 24] + +Internet-Draft DNSSEC Operational Practices December 2004 + + Step 0: The preparation: Create two keys and publish both in your key set. Mark one of the keys as "active" and the other as "published". Use the "active" key for signing your zone data. @@ -1167,15 +1357,6 @@ Appendix B. Zone-signing Key Rollover Howto Step 2: Then start using the key that was marked as "published" to sign your data i.e. mark it as "active". Stop using the key that was marked as "active", mark it as "rolled". - - - - -Kolkman & Gieben Expires April 11, 2005 [Page 21] - -Internet-Draft DNSSEC Operational Practices October 2004 - - Step 3: It is safe to engage in a new rollover (Step 1) after at least one "signature validity period". @@ -1212,6 +1393,14 @@ Appendix C. Typographic Conventions cmL62SI6iAX46xGNQAdQ... ) 600 NS a.iana-servers.net. 600 NS b.iana-servers.net. + + + +Kolkman & Gieben Expires June 23, 2005 [Page 25] + +Internet-Draft DNSSEC Operational Practices December 2004 + + 600 RRSIG NS 5 2 600 20130507213204 ( 20130407213204 14 example.net. SO5epiJei19AjXoUpFnQ ... ) @@ -1224,14 +1413,6 @@ Appendix C. Typographic Conventions 3600 RRSIG DNSKEY 5 2 3600 20130522213204 ( 20130422213204 14 example.net. J4zCe8QX4tXVGjV4e1r9... ) - - - -Kolkman & Gieben Expires April 11, 2005 [Page 22] - -Internet-Draft DNSSEC Operational Practices October 2004 - - 3600 RRSIG DNSKEY 5 2 3600 20130522213204 ( 20130422213204 15 example.net. keVDCOpsSeDReyV6O... ) @@ -1269,8 +1450,15 @@ Appendix D. Document Details and Changes This section is to be removed by the RFC editor if and when the document is published. - $Id: draft-ietf-dnsop-dnssec-operational-practices.xml,v 1.29 2004/ - 10/11 11:27:10 dnssec Exp $ + + +Kolkman & Gieben Expires June 23, 2005 [Page 26] + +Internet-Draft DNSSEC Operational Practices December 2004 + + + $Id: draft-ietf-dnsop-dnssec-operational-practices.xml,v 1.31.2.7 + 2004/12/23 12:20:29 dnssec Exp $ D.1 draft-ietf-dnsop-dnssec-operational-practices-00 @@ -1280,14 +1468,6 @@ D.1 draft-ietf-dnsop-dnssec-operational-practices-00 D.2 draft-ietf-dnsop-dnssec-operational-practices-01 changed the definition of "Bogus" to reflect the one in the protocol - - - -Kolkman & Gieben Expires April 11, 2005 [Page 23] - -Internet-Draft DNSSEC Operational Practices October 2004 - - draft. Bad to Bogus @@ -1298,6 +1478,27 @@ Internet-Draft DNSSEC Operational Practices October 2004 Updates from Sam Weiler added +D.3 draft-ietf-dnsop-dnssec-operational-practices-02 + + Style and errors corrected. + + Added Automatic rollover requirements from + I-D.ietf-dnsop-key-rollover-requirements. + +D.4 draft-ietf-dnsop-dnssec-operational-practices-03 + + Added the definition of Key effectivity period and used that term + instead of Key validity period. + + Modified the order of the sections, based on a suggestion by Rip + Loomis. + + Included parts from RFC2541 [1]. Most of its ground was allready + covered. This document obsoletes RFC2541 [1]. Section 3.1.2 + deserves some review as it in contrast to RFC2541 does _not_ give + recomendations about root-zone keys. + + added a paragraph to Section 4.4.4 @@ -1307,41 +1508,9 @@ Internet-Draft DNSSEC Operational Practices October 2004 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Kolkman & Gieben Expires April 11, 2005 [Page 24] +Kolkman & Gieben Expires June 23, 2005 [Page 27] -Internet-Draft DNSSEC Operational Practices October 2004 +Internet-Draft DNSSEC Operational Practices December 2004 Intellectual Property Statement @@ -1395,6 +1564,6 @@ Acknowledgment -Kolkman & Gieben Expires April 11, 2005 [Page 25] +Kolkman & Gieben Expires June 23, 2005 [Page 28] diff --git a/doc/draft/draft-ietf-dnsop-inaddr-required-05.txt b/doc/draft/draft-ietf-dnsop-inaddr-required-05.txt deleted file mode 100644 index 8809913a00..0000000000 --- a/doc/draft/draft-ietf-dnsop-inaddr-required-05.txt +++ /dev/null @@ -1,301 +0,0 @@ - - - - - - -INTERNET-DRAFT D. Senie -Category: BCP Amaranth Networks Inc. -Expires in six months April 2004 - - Encouraging the use of DNS IN-ADDR Mapping - draft-ietf-dnsop-inaddr-required-05.txt - -Status of this Memo - - - This draft, is intended to be become a Best Current Practice RFC. - Distribution of this document is unlimited. Comments should be sent - to the Domain Name Server Operations working group mailing list - or to the author. - - This document is an Internet-Draft and is in full conformance with - all provisions of Section 10 of [RFC2026]. - - 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." - - To view the list Internet-Draft Shadow Directories, see - http://www.ietf.org/shadow.html. - -Copyright Notice - - Copyright (C) The Internet Society (2000-2002). All Rights Reserved. - -Abstract - - Mapping of addresses to names has been a feature of DNS. Many sites, - implement it, many others don’t. Some applications attempt to use it - as a part of a security strategy. The goal of this document is to - encourage proper deployment of address to name mappings, and provide - guidance for their use. - -1. Introduction - - The Domain Name Service has provision for providing mapping of IP - addresses to host names. It is common practice to ensure both name to - address, and address to name mappings are provided for networks. This - practice, while documented, has never been documented as a - requirement placed upon those who control address blocks. This - - - -Senie [Page 1] - - - - - -Internet-Draft Encouraging the use of DNS IN-ADDR Mapping April 2004 - - - document fills this gap. - - 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]. - -2. Discussion - - From the early days of the Domain Name Service [RFC 883] a special - domain has been set aside for resolving mappings of IP addresses to - domain names. This was refined in [RFC1035], describing the .IN- - ADDR.ARPA in use today. - - The assignment of blocks of IP Address space was delegated to three - regional registries. Guidelines for the registries are specified in - [RFC2050], which requires regional registries to maintain IN-ADDR - records on the large blocks of space issued to ISPs and others. - - ARIN’s policy requires ISPs to maintain IN-ADDR for /16 or larger - allocations. For smaller allocations, ARIN can provide IN-ADDR for - /24 and shorter prefixes. [ARIN]. APNIC provides methods for ISPs to - update IN-ADDR, however the present version of its policy document - for IPv4 [APNIC] dropped the IN-ADDR requirements that were in draft - copies of this document. As of this writing, it appears APNIC has no - actual policy on IN-ADDR. RIPE appears to have the strongest policy - in this area [ripe-185] indicating Local Internet Registries are - required to perform IN-ADDR services, and delegate those as - appropriate when address blocks are delegated. - - As we can see, the regional registries have their own policies for - requirements for IN-ADDR maintenance. It should be noted, however, - that many address blocks were allocated before the creation of the - regional registries, and thus it is unclear whether any of the - policies of the registries are binding on those who hold blocks from - that era. - - Registries allocate address blocks on CIDR [RFC1519] boundaries. - Unfortunately the IN-ADDR zones are based on classful allocations. - Guidelines [RFC2317] for delegating on non-octet-aligned boundaries - exist, but are not always implemented. - -3. Effects of missing IN-ADDR - - Many applications use DNS lookups for security checks. To ensure - validity of claimed names, some applications will look up IN-ADDR - records to get names, and then look up the resultant name to see if - it maps back to the address originally known. Failure to resolve - matching names is seen as a potential security concern. - - - -Senie [Page 2] - - - - - -Internet-Draft Encouraging the use of DNS IN-ADDR Mapping April 2004 - - - Some popular FTP sites will flat-out reject users, even for anonymous - FTP, if the IN-ADDR lookup fails or if the result of the IN-ADDR - lookup when itself resolved, does not match. Some Telnet servers also - implement this check. - - Web sites are in some cases using IN-ADDR checks to verify whether - the client is located within a certain geopolitical entity. This is - being employed for downloads of crypto software, for example, where - export of that software is prohibited to some locales. Credit card - anti-fraud systems also use these methods for geographic placement - purposes. - - The popular TCP Wrappers program found on most Unix and Linux systems - has options to enforce IN-ADDR checks and to reject any client that - does not resolve. - - Wider-scale implementation of IN-ADDR on dialup, CDPD and other such - client-oriented portions of the Internet would result in lower - latency for queries (due to lack of negative caching), and lower name - server load and DNS traffic. - - Some anti-spam (anti junk email) systems use IN-ADDR to verify return - addresses before accepting email. - - Many web servers look up the IN-ADDR of visitors to be used in log - analysis. This adds to the server load, but in the case of IN-ADDR - unavailability, it can lead to delayed responses for users. - - Traceroutes with descriptive IN-ADDR naming proves useful when - debugging problems spanning large areas. When this information is - missing, the traceroutes take longer, and it takes additional steps - to determine that network is the cause of problems. - -4. Requirements - - 4.1 Delegation Requirements - - Regional Registries and any Local Registries to whom they delegate - SHOULD establish and convey a policy to those to whom they delegate - blocks that IN-ADDR mappings are required. Policies SHOULD require - those receiving delegations to provide IN-ADDR service and/or - delegate to downstream customers. - - Network operators SHOULD define and implement policies and procedures - which delegate IN-ADDR to their clients who wish to run their own IN- - ADDR DNS services, and provide IN-ADDR services for those who do not - have the resources to do it themselves. Delegation mechanisms MUST - permit the downstream customer to implement and comply with IETF - - - -Senie [Page 3] - - - - - -Internet-Draft Encouraging the use of DNS IN-ADDR Mapping April 2004 - - - recommendations application of IN-ADDR to CIDR [RFC2317]. - - All IP address space assigned and in use SHOULD be resolved by IN- - ADDR records. All PTR records MUST use canonical names. - - All IP addresses in use within a block SHOULD have an IN-ADDR - mapping. Those addresses not in use, and those that are not valid for - use (zeros or ones broadcast addresses within a CIDR block) need not - have mappings. - - It should be noted that due to CIDR, many addresses that appear to be - otherwise valid host addresses may actually be zeroes or ones - broadcast addresses. As such, attempting to audit a site’s degree of - compliance can only be done with knowledge of the internal routing - structure of the site. However, any host that originates an IP packet - necessarily will have a valid host address, and must therefore have - an IN-ADDR mapping. - - 4.2 Application Requirements - - Applications SHOULD NOT rely on IN-ADDR for proper operation. The use - of IN-ADDR, sometimes in conjunction with a lookup of the name - resulting from the PTR record provides no real security, can lead to - erroneous results and generally just increases load on DNS servers. - Further, in cases where address block holders fail to properly - configure IN-ADDR, users of those blocks are penalized. - -5. Security Considerations - - This document has no negative impact on security. While it could be - argued that lack of PTR record capabilities provides a degree of - anonymity, this is really not valid. Trace routes, whois lookups and - other sources will still provide methods for discovering identity. - - By recommending applications avoid using IN-ADDR as a security - mechanism this document points out that this practice, despite its - use by many applications, is an ineffective form of security. - Applications should use better mechanisms of authentication. - -6. References - - [RFC883] P.V. Mockapetris, "Domain names: Implementation - specification," RFC883, November 1983. - - [RFC1035] P.V. Mockapetris, "Domain Names: Implementation - Specification," RFC 1035, November 1987. - - [RFC1519] V. Fuller, et. al., "Classless Inter-Domain Routing (CIDR): - - - -Senie [Page 4] - - - - - -Internet-Draft Encouraging the use of DNS IN-ADDR Mapping April 2004 - - - an Address Assignment and Aggregation Strategy," RFC 1519, September - 1993. - - [RFC2026] S. Bradner, "The Internet Standards Process -- Revision 3", - RFC 2026, BCP 9, October 1996. - - [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate - Requirement Levels", RFC 2119, BCP 14, March 1997. - - [RFC2050] K. Hubbard, et. al., "Internet Registry IP Allocation - Guidelines", RFC2050, BCP 12, Novebmer 1996. - - [RFC2317] H. Eidnes, et. al., "Classless IN-ADDR.ARPA delegation," - RFC 2317, March 1998. - - [ARIN] "ISP Guidelines for Requesting Initial IP Address Space," date - unknown, http://www.arin.net/regserv/initial-isp.html - - [APNIC] "Policies For IPv4 Address Space Management in the Asia - Pacific Region," APNIC-086, 13 January 2003. - - [RIPE185] "European Internet Registry Policies and Procedures," - ripe-185, October 26, 1998. http://www.ripe.net/docs/ripe-185.html - - -7. Acknowledgements - - Thanks to Peter Koch and Gary Miller for their input, and to many - people who encouraged me to write this document. - -8. Author’s Address - - Daniel Senie - Amaranth Networks Inc. - 324 Still River Road - Bolton, MA 01740 - - Phone: (978) 779-5100 - - EMail: dts@senie.com - - - - - - - - - - - -Senie [Page 5] - - diff --git a/doc/draft/draft-ietf-dnsop-inaddr-required-06.txt b/doc/draft/draft-ietf-dnsop-inaddr-required-06.txt new file mode 100644 index 0000000000..812440c783 --- /dev/null +++ b/doc/draft/draft-ietf-dnsop-inaddr-required-06.txt @@ -0,0 +1,424 @@ + +draft-ietf-dnsop-inaddr-required-06.txt + +INTERNET-DRAFT D. Senie +Category: BCP Amaranth Networks Inc. +Expires in six months February 2005 + + Encouraging the use of DNS IN-ADDR Mapping + +Status of this Memo + + By submitting this Internet-Draft, each author represents that any + applicable patent or other IPR claims of which he or she is aware + have been or will be disclosed, and any of which he or she becomes + aware will be disclosed, in accordance with Section 6 of RFC 3668. + + 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 + +Abstract + + Mapping of addresses to names has been a feature of DNS. Many sites, + implement it, many others don't. Some applications attempt to use it + as a part of a security strategy. The goal of this document is to + encourage proper deployment of address to name mappings, and provide + guidance for their use. + +Copyright Notice + + Copyright (C) The Internet Society. (2005) + +1. Introduction + + The Domain Name Service has provision for providing mapping of IP + addresses to host names. It is common practice to ensure both name to + address, and address to name mappings are provided for networks. This + practice, while documented, has never been required, though it is + generally encouraged. This document both encourages the presence of + + + +Senie [Page 1] + + + + + +Internet-Draft Encouraging the use of DNS IN-ADDR Mapping February 2005 + + + these mappings and discourages reliance on such mappings for security + checks. + + 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]. + +2. Discussion + + + From the early days of the Domain Name Service [RFC883] a special + domain has been set aside for resolving mappings of IP addresses to + domain names. This was refined in [RFC1035], describing the .IN- + ADDR.ARPA in use today. For the in the IPv6 address space, .IP6.ARPA + was added [RFC3152]. This document uses IPv4 CIDR block sizes and + allocation strategy where there are differences and uses IPv4 + terminology. Aside from these differences, this document can and + should be applied to both address spaces. + + The assignment of blocks of IP address space was delegated to three + regional registries. Guidelines for the registries are specified in + [RFC2050], which requires regional registries to maintain IN-ADDR + records on the large blocks of space issued to ISPs and others. + + ARIN's policy requires ISPs to maintain IN-ADDR for /16 or larger + allocations. For smaller allocations, ARIN can provide IN-ADDR for + /24 and shorter prefixes. [ARIN]. APNIC provides methods for ISPs to + update IN-ADDR, however the present version of its policy document + for IPv4 [APNIC] dropped the IN-ADDR requirements that were in draft + copies of this document. As of this writing, it appears APNIC has no + actual policy on IN-ADDR. RIPE appears to have the strongest policy + in this area [RIPE302] indicating Local Internet Registries should + provide IN-ADDR services, and delegate those as appropriate when + address blocks are delegated. + + As we can see, the regional registries have their own policies for + recommendations and/or requirements for IN-ADDR maintenance. It + should be noted, however, that many address blocks were allocated + before the creation of the regional registries, and thus it is + unclear whether any of the policies of the registries are binding on + those who hold blocks from that era. + + Registries allocate address blocks on CIDR [RFC1519] boundaries. + Unfortunately the IN-ADDR zones are based on classful allocations. + Guidelines [RFC2317] for delegating on non-octet-aligned boundaries + exist, but are not always implemented. + +3. Examples of impact of missing IN-ADDR + + + +Senie [Page 2] + + + + + +Internet-Draft Encouraging the use of DNS IN-ADDR Mapping February 2005 + + + These are some examples of problems that may be introduced by + reliance on IN-ADDR. + + Some applications use DNS lookups for security checks. To ensure + validity of claimed names, some applications will look up IN-ADDR + records to get names, and then look up the resultant name to see if + it maps back to the address originally known. Failure to resolve + matching names is seen as a potential security concern. + + Some FTP sites will flat-out reject users, even for anonymous FTP, if + the IN-ADDR lookup fails or if the result of the IN-ADDR lookup when + itself resolved, does not match. Some Telnet servers also implement + this check. + + Web sites are in some cases using IN-ADDR checks to verify whether + the client is located within a certain geopolitical entity. This + approach has been employed for downloads of crypto software, for + example, where export of that software is prohibited to some locales. + Credit card anti-fraud systems also use these methods for geographic + placement purposes. + + The popular TCP Wrappers program found on most Unix and Linux systems + has options to enforce IN-ADDR checks and to reject any client that + does not resolve. This program also has a way to check to see that + the name given by a PTR record then resolves back to the same IP + address. This method provdes more comfort but no appreciable + additional security. + + Some anti-spam (anti junk email) systems use IN-ADDR to verify the + presence of a PTR record, or validate the PTR value points back to + the same address. + + Many web servers look up the IN-ADDR of visitors to be used in log + analysis. This adds to the server load, but in the case of IN-ADDR + unavailability, it can lead to delayed responses for users. + + Traceroutes with descriptive IN-ADDR naming proves useful when + debugging problems spanning large areas. When this information is + missing, the traceroutes take longer, and it takes additional steps + to determine that network is the cause of problems. + + Wider-scale implementation of IN-ADDR on dialup, wireless access and + other such client-oriented portions of the Internet would result in + lower latency for queries (due to lack of negative caching), and + lower name server load and DNS traffic. + +4. Recommendations + + + + +Senie [Page 3] + + + + + +Internet-Draft Encouraging the use of DNS IN-ADDR Mapping February 2005 + + + 4.1 Delegation Recommendations + + + Regional Registries and any Local Registries to whom they delegate + should establish and convey a policy to those to whom they delegate + blocks that IN-ADDR mappings are recommended. Policies should + recommend those receiving delegations to provide IN-ADDR service + and/or delegate to downstream customers. + + Network operators should define and implement policies and procedures + which delegate IN-ADDR to their clients who wish to run their own IN- + ADDR DNS services, and provide IN-ADDR services for those who do not + have the resources to do it themselves. Delegation mechanisms should + permit the downstream customer to implement and comply with IETF + recommendations application of IN-ADDR to CIDR [RFC2317]. + + All IP address space assigned and in use should be resolved by IN- + ADDR records. All PTR records must use canonical names. + + All IP addresses in use within a block should have an IN-ADDR + mapping. Those addresses not in use, and those that are not valid for + use (zeros or ones broadcast addresses within a CIDR block) need not + have mappings. + + It should be noted that due to CIDR, many addresses that appear to be + otherwise valid host addresses may actually be zeroes or ones + broadcast addresses. As such, attempting to audit a site's degree of + compliance may only be done with knowledge of the internal subnet + architecture of the site. It can be assumed, however, any host that + originates an IP packet necessarily will have a valid host address, + and must therefore have an IN-ADDR mapping. + +4.2 Application Recommendations + + + Applications SHOULD NOT rely on IN-ADDR for proper operation. The use + of IN-ADDR, sometimes in conjunction with a lookup of the name + resulting from the PTR record provides no real security, can lead to + erroneous results and generally just increases load on DNS servers. + Further, in cases where address block holders fail to properly + configure IN-ADDR, users of those blocks are penalized. + +5. Security Considerations + + This document has no negative impact on security. While it could be + argued that lack of PTR record capabilities provides a degree of + anonymity, this is really not valid. Trace routes, whois lookups and + other sources will still provide methods for discovering identity. + + + +Senie [Page 4] + + + + + +Internet-Draft Encouraging the use of DNS IN-ADDR Mapping February 2005 + + + By recommending applications avoid using IN-ADDR as a security + mechanism this document points out that this practice, despite its + use by many applications, is an ineffective form of security. + Applications should use better mechanisms of authentication. + +6. IANA Considerations + + There are no IANA considerations for this document. + +7. References + +7.1 Normative References + + [RFC883] P.V. Mockapetris, "Domain names: Implementation + specification," RFC883, November 1983. + + [RFC1035] P.V. Mockapetris, "Domain Names: Implementation + Specification," RFC 1035, November 1987. + + [RFC1519] V. Fuller, et. al., "Classless Inter-Domain Routing (CIDR): + an Address Assignment and Aggregation Strategy," RFC 1519, September + 1993. + + [RFC2026] S. Bradner, "The Internet Standards Process -- Revision 3", + RFC 2026, BCP 9, October 1996. + + [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate + Requirement Levels", RFC 2119, BCP 14, March 1997. + + [RFC2050] K. Hubbard, et. al., "Internet Registry IP Allocation + Guidelines", RFC2050, BCP 12, Novebmer 1996. + + [RFC2317] H. Eidnes, et. al., "Classless IN-ADDR.ARPA delegation," + RFC 2317, March 1998. + + [RFC3152] R. Bush, "Delegation of IP6.ARPA," RFC 3152, BCP 49, August + 2001. + +7.2 Informative References + + [ARIN] "ISP Guidelines for Requesting Initial IP Address Space," date + unknown, +http://www.arin.net/regserv/initial-isp.html + + [APNIC] "Policies For IPv4 Address Space Management in the Asia + Pacific Region," APNIC-086, 13 January 2003. + + [RIPE302] "Policy for Reverse Address Delegation of IPv4 and IPv6 + Address Space in the RIPE NCC Service Region", RIPE-302, April 26, + + + +Senie [Page 5] + + + + + +Internet-Draft Encouraging the use of DNS IN-ADDR Mapping February 2005 + + + 2004. +http://www.ripe.net//ripe/docs/rev-del.html + + + +8. Acknowledgements + + Thanks to Peter Koch and Gary Miller for their input, and to many + people who encouraged me to write this document. + +9. Author's Address + + Daniel Senie + Amaranth Networks Inc. + 324 Still River Road + Bolton, MA 01740 + + Phone: (978) 779-5100 + + EMail: dts@senie.com + +10. Full Copyright Statement + + Copyright (C) The Internet Society (2004). This document is + subject to the rights, licenses and restrictions contained in + BCP 78 and except as set forth therein, the authors retain + all their rights. + + This document and the information contained herein are provided + on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE + REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND + THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, + EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT + THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR + ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A + PARTICULAR PURPOSE. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed + to pertain to the implementation or use of the technology + described in this document or the extent to which any license + under such rights might or might not be available; nor does it + represent that it has made any independent effort to identify any + such rights. Information on the procedures with respect to + rights in RFC documents can be found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + + + +Senie [Page 6] + + + + + +Internet-Draft Encouraging the use of DNS IN-ADDR Mapping February 2005 + + + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use + of such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository + at http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention + any copyrights, patents or patent applications, or other + proprietary rights that may cover technology that may be required + to implement this standard. Please address the information to the + IETF at ietf-ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Senie [Page 7] + + + + + + + diff --git a/doc/draft/draft-ietf-dnsop-key-rollover-requirements-01.txt b/doc/draft/draft-ietf-dnsop-key-rollover-requirements-01.txt deleted file mode 100644 index 2311ee6c18..0000000000 --- a/doc/draft/draft-ietf-dnsop-key-rollover-requirements-01.txt +++ /dev/null @@ -1,391 +0,0 @@ - -DNSOP G. Guette -Internet-Draft IRISA / INRIA -Expires: February 5, 2005 O. Courtay - Thomson R&D - August 7, 2004 - - - Requirements for Automated Key Rollover in DNSSEC - draft-ietf-dnsop-key-rollover-requirements-01.txt - -Status of this Memo - - By submitting this Internet-Draft, I certify that any applicable - patent or other IPR claims of which I am aware have been disclosed, - and any of which I become aware will be disclosed, in accordance with - RFC 3668. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as - Internet-Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt. - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - This Internet-Draft will expire on February 5, 2005. - -Copyright Notice - - Copyright (C) The Internet Society (2004). All Rights Reserved. - -Abstract - - This document describes problems that appear during an automated - rollover and gives the requirements for the design of communication - between parent zone and child zone in an automated rollover process. - This document is essentially about key rollover, the rollover of - another Resource Record present at delegation point (NS RR) is also - discussed. - - - - - -Guette & Courtay Expires February 5, 2005 [Page 1] - -Internet-Draft Automated Rollover Requirements August 2004 - - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 2. The Key Rollover Process . . . . . . . . . . . . . . . . . . . 3 - 3. Basic Requirements . . . . . . . . . . . . . . . . . . . . . . 4 - 4. Messages authentication and information exchanged . . . . . . 4 - 5. Emergency Rollover . . . . . . . . . . . . . . . . . . . . . . 5 - 6. Other Resource Record concerned by automatic rollover . . . . 5 - 7. Security consideration . . . . . . . . . . . . . . . . . . . . 5 - 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5 - 9. Normative References . . . . . . . . . . . . . . . . . . . . . 5 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 6 - Intellectual Property and Copyright Statements . . . . . . . . 7 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Guette & Courtay Expires February 5, 2005 [Page 2] - -Internet-Draft Automated Rollover Requirements August 2004 - - -1. Introduction - - The DNS security extensions (DNSSEC) [4][8][7][9] uses public-key - cryptography and digital signatures. It stores the public part of - keys in DNSKEY Resource Records (RRs). Because old keys and - frequently used keys are vulnerable, they must be renewed - periodically. In DNSSEC, this is the case for Zone Signing Keys - (ZSKs) and Key Signing Keys (KSKs) [1][2]. Automation of key - rollover process is necessary for large zones because there are too - many changes to handle a manual administration. - - Let us consider for example a zone with 100000 secure delegations. - If the child zones change their keys once a year on average, that - implies 300 changes per day for the parent zone. This amount of - changes are hard to manage manually. - - Automated rollover is optional and resulting from an agreement - between the administrator of the parent zone and the administrator of - the child zone. Of course, key rollover can also be done manually by - administrators. - - This document describes the requirements for the design of messages - of automated key rollover process and focusses on interaction between - parent and child zone. - -2. The Key Rollover Process - - Key rollover consists in renewing the DNSSEC keys used to sign - resource records in a given DNS zone file. There are two types of - rollover, ZSK rollovers and KSK rollovers. - - In a ZSK rollover, all changes are local to the zone that renews its - key: there is no need to contact other zones (e.g., parent zone) to - propagate the performed changes because a ZSK has no associated DS - record in the parent zone. - - In a KSK rollover, new DS RR(s) must be created and stored in the - parent zone. In consequence, the child zone must contact its parent - zone and must notify it about the KSK change(s). - - Manual key rollover exists and works [3]. The key rollover is built - from two parts of different nature: - o An algorithm that generates new keys and signs the zone file. It - could be local to the zone - o The interaction between parent and child zones - - One example of manual key rollover is: - - - - -Guette & Courtay Expires February 5, 2005 [Page 3] - -Internet-Draft Automated Rollover Requirements August 2004 - - - o The child zone creates a new KSK - o The child zone waits for the creation of the DS RR in its parent - zone - o The child zone deletes the old key. - - In manual rollover, communications are managed by the zone - administrators and the security of these communications is out of - scope of DNSSEC. - - Automated key rollover should use a secure communication between - parent and child zones. This document concentrates on defining - interactions between entities present in key rollover process. - -3. Basic Requirements - - The main constraint to respect during a key rollover is that the - chain of trust MUST be preserved, even if a resolver retrieves some - RRs from recursive cache server. Every RR MUST be verifiable at any - time, every RRs exchanged during the rollover should be authenticated - and their integrity should be guaranteed. - - Two entities act during a KSK rollover: the child zone and its parent - zone. These zones are generally managed by different administrators. - These administrators should agree on some parameters like - availability of automated rollover, the maximum delay between - notification of changes in the child zone and the resigning of the - parent zone. The child zone needs to know this delay to schedule its - changes. - -4. Messages authentication and information exchanged - - Every exchanged message MUST be authenticated and the authentication - tool MUST be a DNSSEC tool such as TSIG [6], SIG(0) [5] or DNSSEC - request with verifiable SIG records. - - Once the changes related to a KSK are made in a child zone, this zone - MUST notify its parent zone in order to create the new DS RR and - store this DS RR in parent zone file. - - The parent zone MUST receive all the child keys that needs the - creation of associated DS RRs in the parent zone. - - Some errors could occur during transmission between child zone and - parent zone. Key rollover solution MUST be fault tolerant, i.e. at - any time the rollover MUST be in a consistent state and all RRs MUST - be verifiable, even if an error occurs. That is to say that it MUST - remain a valid chain of trust. - - - - -Guette & Courtay Expires February 5, 2005 [Page 4] - -Internet-Draft Automated Rollover Requirements August 2004 - - -5. Emergency Rollover - - A key of a zone might be compromised and this key MUST be changed as - soon as possible. Fast changes could break the chain of trust. The - part of DNS tree having this zone as apex can become unverifiable, - but the break of the chain of trust is necessary if we want to no one - can use the compromised key to spoof DNS data. - - In case of emergency rollover, the administrators of parent and child - zones should create new key(s) and DS RR(s) as fast as possible in - order to reduce the time the chain of trust is broken. - -6. Other Resource Record concerned by automatic rollover - - NS records are also present at delegation point, so when the child - zone renews some NS RR, the corresponding records at delegation point - in parent zone (glue) MUST be updated. NS records are concerned by - rollover and this rollover could be automated too. In this case, - when the child zone notifies its parent zone that some NS records - have been changed, the parent zone MUST verify that these NS records - are present in child zone before doing any changes in its own zone - file. This allows to avoid inconsistency between NS records at - delegation point and NS records present in the child zone. - -7. Security consideration - - This document describes requirements to design an automated key - rollover in DNSSEC based on DNSSEC security. In the same way, as - plain DNSSEC, the automatic key rollover contains no mechanism - protecting against denial of service (DoS). The security level - obtain after an automatic key rollover, is the security level - provided by DNSSEC. - -8. Acknowledgments - - The authors want to acknowledge Francis Dupont, Mohsen Souissi, - Bernard Cousin, Bertrand Lonard and members of IDsA project for - their contribution to this document. - -9 Normative References - - [1] Gudmundsson, O., "Delegation Signer (DS) Resource Record (RR)", - RFC 3658, December 2003. - - [2] Kolkman, O., Schlyter, J. and E. Lewis, "Domain Name System KEY - (DNSKEY) Resource Record (RR) Secure Entry Point (SEP) Flag", - RFC 3757, May 2004. - - - - -Guette & Courtay Expires February 5, 2005 [Page 5] - -Internet-Draft Automated Rollover Requirements August 2004 - - - [3] Kolkman, O., "DNSSEC Operational Practices", - draft-ietf-dnsop-dnssec-operational-practice-01 (work in - progress), May 2004. - - [4] Eastlake, D., "Domain Name System Security Extensions", RFC - 2535, March 1999. - - [5] Eastlake, D., "DNS Request and Transaction Signatures ( - SIG(0)s)", RFC 2931, September 2000. - - [6] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington, - "Secret Key Transaction Authentication for DNS (TSIG)", RFC - 2845, May 2000. - - [7] Arends, R., "Resource Records for the DNS Security Extensions", - draft-ietf-dnsext-dnssec-records-09 (work in progress), July - 2004. - - [8] Arends, R., Austein, R., Massey, D., Larson, M. and S. Rose, - "DNS Security Introduction and Requirements", - draft-ietf-dnsext-dnssec-intro-11 (work in progress), July 2004. - - [9] Arends, R., "Protocol Modifications for the DNS Security - Extensions", draft-ietf-dnsext-dnssec-protocol-07 (work in - progress), July 2004. - - -Authors' Addresses - - Gilles Guette - IRISA / INRIA - Campus de Beaulieu - 35042 Rennes CEDEX - FR - - EMail: gilles.guette@irisa.fr - URI: http://www.irisa.fr - - - Olivier Courtay - Thomson R&D - 1, avenue Belle Fontaine - 35510 Cesson Svign CEDEX - FR - - EMail: olivier.courtay@thomson.net - - - - - -Guette & Courtay Expires February 5, 2005 [Page 6] - -Internet-Draft Automated Rollover Requirements August 2004 - - -Intellectual Property Statement - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at - ietf-ipr@ietf.org. - - -Disclaimer of Validity - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - -Copyright Statement - - Copyright (C) The Internet Society (2004). This document is subject - to the rights, licenses and restrictions contained in BCP 78, and - except as set forth therein, the authors retain all their rights. - - -Acknowledgment - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - -Guette & Courtay Expires February 5, 2005 [Page 7] - diff --git a/doc/draft/draft-ietf-dnsop-key-rollover-requirements-02.txt b/doc/draft/draft-ietf-dnsop-key-rollover-requirements-02.txt new file mode 100644 index 0000000000..6bece56182 --- /dev/null +++ b/doc/draft/draft-ietf-dnsop-key-rollover-requirements-02.txt @@ -0,0 +1,389 @@ + +DNSOP G. Guette +Internet-Draft IRISA / INRIA +Expires: July 19, 2005 O. Courtay + Thomson R&D + January 18, 2005 + + Requirements for Automated Key Rollover in DNSSEC + draft-ietf-dnsop-key-rollover-requirements-02.txt + +Status of this Memo + + By submitting this Internet-Draft, I certify that any applicable + patent or other IPR claims of which I am aware have been disclosed, + and any of which I become aware will be disclosed, in accordance with + RFC 3668. + + 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 July 19, 2005. + +Copyright Notice + + Copyright (C) The Internet Society (2005). All Rights Reserved. + +Abstract + + This document describes problems that appear during an automated + rollover and gives the requirements for the design of communication + between parent zone and child zone during an automated rollover + process. This document is essentially about in-band key rollover. + + + + +Guette & Courtay Expires July 19, 2005 [Page 1] +Internet-Draft Automated Rollover Requirements January 2005 + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. The Key Rollover Process . . . . . . . . . . . . . . . . . . . 3 + 3. Basic Requirements . . . . . . . . . . . . . . . . . . . . . . 4 + 4. Messages authentication and information exchanged . . . . . . 5 + 5. Emergency Rollover . . . . . . . . . . . . . . . . . . . . . . 5 + 6. Security consideration . . . . . . . . . . . . . . . . . . . . 6 + 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 + 8. Normative References . . . . . . . . . . . . . . . . . . . . . 6 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 7 + A. Documents details and changes . . . . . . . . . . . . . . . . 7 + Intellectual Property and Copyright Statements . . . . . . . . 8 + + + + + + + + + + + + + + + + + + + +Guette & Courtay Expires July 19, 2005 [Page 2] +Internet-Draft Automated Rollover Requirements January 2005 + +1. Introduction + + The DNS security extensions (DNSSEC) [4][6][5][7] uses public-key + cryptography and digital signatures. It stores the public part of + keys in DNSKEY Resource Records (RRs). Because old keys and + frequently used keys are vulnerable, they must be renewed + periodically. In DNSSEC, this is the case for Zone Signing Keys + (ZSKs) and Key Signing Keys (KSKs) [1][2]. Automation of key + exchanges between parents and children is necessary for large zones + because there are too many changes to handle. + + Let us consider for example a zone with 100000 secure delegations. + If the child zones change their keys once a year on average, that + implies 300 changes per day for the parent zone. This amount of + changes is hard to manage manually. + + Automated rollover is optional and resulting from an agreement + between the administrator of the parent zone and the administrator of + the child zone. Of course, key rollover can also be done manually by + administrators. + + This document describes the requirements for a protocol to perform + the automated key rollover process and focusses on interaction + between parent and child zone. + +2. The Key Rollover Process + + Key rollover consists of renewing the DNSSEC keys used to sign + resource records in a given DNS zone file. There are two types of + rollover, ZSK rollovers and KSK rollovers. + + During a ZSK rollover, all changes are local to the zone that renews + its key: there is no need to contact other zones administrators to + propagate the performed changes because a ZSK has no associated DS + record in the parent zone. + + During a KSK rollover, new DS RR(s) must be created and stored in the + parent zone. In consequence, data must be exchanged between child + and parent zones. + + The key rollover is built from two parts of different nature: + o An algorithm that generates new keys and signs the zone file. It + can be local to the zone, + o the interaction between parent and child zones. + + One example of manual key rollover [3] is: + o The child zone creates a new KSK, + + +Guette & Courtay Expires July 19, 2005 [Page 3] +Internet-Draft Automated Rollover Requirements January 2005 + + o the child zone waits for the creation of the DS RR in its parent + zone, + o the child zone deletes the old key, + o the parent zone deletes the old DS RR. + + This document concentrates on defining interactions between entities + present in key rollover process. + +3. Basic Requirements + + This section provides the requirements for automated key rollover in + case of normal use. Exceptional case like emergency rollover is + specifically described later in this document. + + The main condition during a key rollover is that the chain of trust + must be preserved to every validating DNS client. No matter if this + client retrieves some of the RRs from recursive caching name server + or from the authoritative servers for the zone involved in the + rollover. + + Automated key rollover solution may be interrupted by a manual + intervention. This manual intervention should not compromise the + security state of the chain of trust. If the chain is safe before + the manual intervention, the chain of trust must remain safe during + and after the manual intervention + + Two entities act during a KSK rollover: the child zone and its parent + zone. These zones are generally managed by different administrators. + These administrators should agree on some parameters like + availability of automated rollover, the maximum delay between + notification of changes in the child zone and the resigning of the + parent zone. The child zone needs to know this delay to schedule its + changes and/or to verify that the changes had been taken into account + in the parent zone. Hence, the child zone can also avoid some + critical cases where all child key are changed prior to the DS RR + creation. + + By keeping some resource records during a given time, the recursive + cache servers can act on the automated rollover. The existence of + recursive cache servers must be taken into account by automated + rollover solution. + + Indeed, during an automated key rollover a name server could have to + retrieve some DNSSEC data. An automated key rollover solution must + ensure that these data are not old DNSSEC material retrieved from a + recursive name server. + + + +Guette & Courtay Expires July 19, 2005 [Page 4] +Internet-Draft Automated Rollover Requirements January 2005 + +4. Messages authentication and information exchanged + + This section addresses in-band rollover, security of out-of-band + mechanisms is out of scope of this document. + + The security provided by DNSSEC must not be compromised by the key + rollover, thus every exchanged message must be authenticated to avoid + fake rollover messages from malicious parties. + + Once the changes related to a KSK are made in a child zone, there are + two ways for the parent zone to take this changes into account: + o the child zone notify directly or not directly its parent zone in + order to create the new DS RR and store this DS RR in parent zone + file, + o or the parent zone poll the child zone. + + In both cases, the parent zone must receive all the child keys that + need the creation of associated DS RRs in the parent zone. + + Because errors could occur during the transmission of keys between + child and parent, the key exchange protocol must be fault tolerant. + Should an error occured during the automated key rollover, an + automated key rollover solution must be able to keep the zone files + in a consistent state. + +5. Emergency Rollover + + Emergency key rollover is a special case of rollover decided by the + zone administrator generally for security reasons. In consequence, + emergency key rollover can break some of the requirement described + above. + + A zone key might be compromised and an attacker can use the + compromised key to create and sign fake records. To avoid this, the + zone administrator may change the compromised key or all its keys as + soon as possible, without waiting for the creation of new DS RRs in + its parent zone. + + Fast changes may break the chain of trust. The part of DNS tree + having this zone as apex can become unverifiable, but the break of + the chain of trust is necessary if the administrator wants to prevent + the compromised key from being used (to spoof DNS data). + + Parent and child zones sharing an automated rollover mechanism, + should have an out-of-band way to re-establish a consistent state at + the delegation point (DS and DNSKEY RRs). This allows to avoid that + a malicious party uses the compromised key to roll the zone keys. + + +Guette & Courtay Expires July 19, 2005 [Page 5] +Internet-Draft Automated Rollover Requirements January 2005 + +6. Security consideration + + The automated key rollover process in DNSSEC allows automated renewal + of any kind of DNS key (ZSK or KSK). It is essential that parent + side and child side can do mutual authentication. Moreover, + integrity of the material exchanged between the parent and child zone + must be provided to ensure the right DS are created. + + As in any application using public key cryptography, in DNSSEC a key + may be compromised. What to do in such a case can be describe in the + zone local policy and can violate some requirements described in this + draft. The emergency rollover can break the chain of trust in order + to protect the zone against the use of the compromised key. + +7. Acknowledgments + + The authors want to thank members of IDsA project for their + contribution to this document. + +8 Normative References + + [1] Gudmundsson, O., "Delegation Signer (DS) Resource Record (RR)", + RFC 3658, December 2003. + + [2] Kolkman, O., Schlyter, J. and E. Lewis, "Domain Name System KEY + (DNSKEY) Resource Record (RR) Secure Entry Point (SEP) Flag", + RFC 3757, May 2004. + + [3] Kolkman, O., "DNSSEC Operational Practices", + draft-ietf-dnsop-dnssec-operational-practice-01 (work in + progress), May 2004. + + [4] Eastlake, D., "Domain Name System Security Extensions", RFC + 2535, March 1999. + + [5] Arends, R., Austein, R., Larson, M., Massey, D. and S. Rose, + "Resource Records for the DNS Security Extensions", + draft-ietf-dnsext-dnssec-records-11 (work in progress), October + 2004. + + [6] Arends, R., Austein, R., Larson, M., Massey, D. and S. Rose, + "DNS Security Introduction and Requirements", + draft-ietf-dnsext-dnssec-intro-13 (work in progress), October + 2004. + + [7] Arends, R., Austein, R., Larson, M., Massey, D. and S. Rose, + "Protocol Modifications for the DNS Security Extensions", + draft-ietf-dnsext-dnssec-protocol-09 (work in progress), October + + +Guette & Courtay Expires July 19, 2005 [Page 6] +Internet-Draft Automated Rollover Requirements January 2005 + + 2004. + +Authors' Addresses + + Gilles Guette + IRISA / INRIA + Campus de Beaulieu + 35042 Rennes CEDEX + FR + + EMail: gilles.guette@irisa.fr + URI: http://www.irisa.fr + + Olivier Courtay + Thomson R&D + 1, avenue Belle Fontaine + 35510 Cesson S?vign? CEDEX + FR + + EMail: olivier.courtay@thomson.net + +Appendix A. Documents details and changes + + This section is to be removed by the RFC editor if and when the + document is published. + + Section about NS RR rollover has been removed + + Remarks from Samuel Weiler and Rip Loomis added + + Clarification about in-band rollover and in emergency section + + Section 3, details about recursive cache servers added + + + + + + + + +Guette & Courtay Expires July 19, 2005 [Page 7] +Internet-Draft Automated Rollover Requirements January 2005 + +Intellectual Property Statement + + The IETF takes no position regarding the validity or scope of any + intellectual property or other rights that might be claimed to + pertain to the implementation or use of the technology described + in this document or the extent to which any license under such + rights might or might not be available; neither does it represent + that it has made any effort to identify any such rights. + Information on the IETF's procedures with respect to rights in + IETF Documents can be found in BCP 78 and 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use + of such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository + at http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention + any copyrights, patents or patent applications, or other + proprietary rights which may cover technology that may be required + to implement this standard. Please address the information to the + IETF at ietf-ipr.org. + + + Full Copyright Statement + + Copyright (C) The Internet Society (2005). This document is subject + to the rights, licenses and restrictions contained in BCP 78, and + except as set forth therein, the authors retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + Acknowledgment + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + +Guette & Courtay Expires July 19, 2005 [Page 8]