From: Mark Andrews Date: Fri, 2 Sep 2005 01:45:07 +0000 (+0000) Subject: new draft X-Git-Tag: v9.3.2b1~33 X-Git-Url: http://git.ipfire.org/gitweb/?a=commitdiff_plain;h=0cca8471e68b22e5c2fff689913b27e44d2953fa;p=thirdparty%2Fbind9.git new draft --- diff --git a/doc/draft/draft-ietf-dnsext-dnssec-experiments-00.txt b/doc/draft/draft-ietf-dnsext-dnssec-experiments-00.txt deleted file mode 100644 index 6c897b92b11..00000000000 --- a/doc/draft/draft-ietf-dnsext-dnssec-experiments-00.txt +++ /dev/null @@ -1,841 +0,0 @@ - - -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 deleted file mode 100644 index c4103183d5c..00000000000 --- a/doc/draft/draft-ietf-dnsext-dnssec-opt-in-06.txt +++ /dev/null @@ -1,1177 +0,0 @@ - - -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-ecc-key-06.txt b/doc/draft/draft-ietf-dnsext-ecc-key-06.txt deleted file mode 100644 index 6953f6e42f7..00000000000 --- a/doc/draft/draft-ietf-dnsext-ecc-key-06.txt +++ /dev/null @@ -1,930 +0,0 @@ - - -INTERNET-DRAFT ECC Keys in the DNS -Expires: June 2005 December 2004 - - - - Elliptic Curve KEYs in the DNS - -------- ----- ---- -- --- --- - - - Richard C. Schroeppel - Donald 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. - - This draft is intended to be become a Proposed Standard RFC. - Distribution of this document is unlimited. Comments should be sent - to the DNS mailing list . - - 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 - - -Abstract - - The standard method for storing elliptic curve cryptographic keys and - signatures in the Domain Name System is specified. - - -Copyright Notice - - Copyright (C) The Internet Society. All Rights Reserved. - - - - - -R. Schroeppel, et al [Page 1] - - -INTERNET-DRAFT ECC Keys in the DNS - - -Acknowledgement - - The assistance of Hilarie K. Orman in the production of this document - is greatfully acknowledged. - - - -Table of Contents - - Status of This Document....................................1 - Abstract...................................................1 - Copyright Notice...........................................1 - - Acknowledgement............................................2 - Table of Contents..........................................2 - - 1. Introduction............................................3 - 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. Elliptic Curve SIG Resource Records....................11 - 6. Performance Considerations.............................13 - 7. Security Considerations................................13 - 8. IANA Considerations....................................13 - Copyright and Disclaimer..................................14 - - Informational References..................................15 - Normative Refrences.......................................15 - - Author's Addresses........................................16 - Expiration and File Name..................................16 - - - - - - - - - - - - - - - - - - - - - -R. Schroeppel, et al [Page 2] - - -INTERNET-DRAFT ECC Keys in the DNS - - -1. Introduction - - The Domain Name System (DNS) is the global hierarchical replicated - distributed database system for Internet addressing, mail proxy, and - other information. The DNS has been extended to include digital - signatures and cryptographic keys as described in [RFC intro, - protocol, records]. - - This document describes how to store elliptic curve cryptographic - (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 - document are to be interpreted as described in [RFC 2119]. - - - -2. Elliptic Curve Data in Resource Records - - Elliptic curve public keys are stored in the DNS within the RDATA - 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 - best represent elements in the field. So, representations are - defined for every type of finite field, and every type of elliptic - curve. The reader should be aware that there is a unique finite - field with a particular number of elements, but many possible - representations of that field and its elements. If two different - representations of a field are given, they are interconvertible with - a tedious but practical precomputation, followed by a fast - computation for each field element to be converted. It is perfectly - reasonable for an algorithm to work internally with one field - representation, and convert to and from a different external - representation. - - - - - - - - - - - - - - -R. Schroeppel, et al [Page 3] - - -INTERNET-DRAFT ECC Keys in the DNS - - - 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 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - |S M -FMT- A B Z| - +-+-+-+-+-+-+-+-+ - | LP | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | P (length determined from LP) .../ - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | LF | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | F (length determined from LF) .../ - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | DEG | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | DEGH | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | DEGI | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | DEGJ | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | TRDV | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - |S| LH | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | H (length determined from LH) .../ - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - |S| LK | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | K (length determined from LK) .../ - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | LQ | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Q (length determined from LQ) .../ - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | LA | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | A (length determined from LA) .../ - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | ALTA | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | LB | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | B (length determined from LB) .../ - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | LC | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | C (length determined from LC) .../ - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | LG | - - -R. Schroeppel, et al [Page 4] - - -INTERNET-DRAFT ECC Keys in the DNS - - - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | G (length determined from LG) .../ - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | LY | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Y (length determined from LY) .../ - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - SMFMTABZ is a flags octet as follows: - - S = 1 indicates that the remaining 7 bits of the octet selects - one of 128 predefined choices of finite field, element - representation, elliptic curve, and signature parameters. - MFMTABZ are omitted, as are all parameters from LP through G. - LY and Y are retained. - - If S = 0, the remaining parameters are as in the picture and - described below. - - M determines the type of field underlying the elliptic curve. - - M = 0 if the field is a GF[2^N] field; - - M = 1 if the field is a (mod P) or GF[P^D] field with P>2. - - FMT is a three bit field describing the format of the field - representation. - - FMT = 0 for a (mod P) field. - > 0 for an extension field, either GF[2^D] or GF[P^D]. - The degree D of the extension, and the field polynomial - must be specified. The field polynomial is always monic - (leading coefficient 1.) - - FMT = 1 The field polynomial is given explicitly; D is implied. - - If FMT >=2, the degree D is given explicitly. - - = 2 The field polynomial is implicit. - = 3 The field polynomial is a binomial. P>2. - = 4 The field polynomial is a trinomial. - = 5 The field polynomial is the quotient of a trinomial by a - short polynomial. P=2. - = 6 The field polynomial is a pentanomial. P=2. - - Flags A and B apply to the elliptic curve parameters. - - - - - - -R. Schroeppel, et al [Page 5] - - -INTERNET-DRAFT ECC Keys in the DNS - - - A = 1 When P>=5, the curve parameter A is negated. If P=2, then - A=1 indicates that the A parameter is special. See the - ALTA parameter below, following A. The combination A=1, - P=3 is forbidden. - - B = 1 When P>=5, the curve parameter B is negated. If P=2 or 3, - then B=1 indicates an alternate elliptic curve equation is - used. When P=2 and B=1, an additional curve parameter C - is present. - - The Z bit SHOULD be set to zero on creation of an RR and MUST be - ignored when processing an RR (when S=0). - - Most of the remaining parameters are present in some formats and - absent in others. The presence or absence of a parameter is - determined entirely by the flags. When a parameter occurs, it is in - the order defined by the picture. - - Of the remaining parameters, PFHKQABCGY are variable length. When - present, each is preceded by a one-octet length field as shown in the - diagram above. The length field does not include itself. The length - field may have values from 0 through 110. The parameter length in - octets is determined by a conditional formula: If LL<=64, the - parameter length is LL. If LL>64, the parameter length is 16 times - (LL-60). In some cases, a parameter value of 0 is sensible, and MAY - be represented by an LL value of 0, with the data field omitted. A - length value of 0 represents a parameter value of 0, not an absent - parameter. (The data portion occupies 0 space.) There is no - requirement that a parameter be represented in the minimum number of - octets; high-order 0 octets are allowed at the front end. Parameters - are always right adjusted, in a field of length defined by LL. The - octet-order is always most-significant first, least-significant last. - The parameters H and K may have an optional sign bit stored in the - unused high-order bit of their length fields. - - LP defines the length of the prime P. P must be an odd prime. The - parameters LP,P are present if and only if the flag M=1. If M=0, the - prime is 2. - - LF,F define an explicit field polynomial. This parameter pair is - present only when FMT = 1. The length of a polynomial coefficient is - ceiling(log2 P) bits. Coefficients are in the numerical range - [0,P-1]. The coefficients are packed into fixed-width fields, from - higher order to lower order. All coefficients must be present, - including any 0s and also the leading coefficient (which is required - to be 1). The coefficients are right justified into the octet string - of length specified by LF, with the low-order "constant" coefficient - at the right end. As a concession to storage efficiency, the higher - order bits of the leading coefficient may be elided, discarding high- - order 0 octets and reducing LF. The degree is calculated by - - -R. Schroeppel, et al [Page 6] - - -INTERNET-DRAFT ECC Keys in the DNS - - - determining the bit position of the left most 1-bit in the F data - (counting the right most bit as position 0), and dividing by - ceiling(log2 P). The division must be exact, with no remainder. In - this format, all of the other degree and field parameters are - omitted. The next parameters will be LQ,Q. - - If FMT>=2, the degree of the field extension is specified explicitly, - usually along with other parameters to define the field polynomial. - - DEG is a two octet field that defines the degree of the field - extension. The finite field will have P^DEG elements. DEG is - present when FMT>=2. - - When FMT=2, the field polynomial is specified implicitly. No other - parameters are required to define the field; the next parameters - present will be the LQ,Q pair. The implicit field poynomial is the - lexicographically smallest irreducible (mod P) polynomial of the - correct degree. The ordering of polynomials is by highest-degree - coefficients first -- the leading coefficient 1 is most important, - 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 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. - - When FMT=3, the field polynomial is a binomial, X^DEG + K. P must be - odd. The polynomial is determined by the degree and the low order - term K. Of all the field parameters, only the LK,K parameters are - present. The high-order bit of the LK octet stores on optional sign - for K; if the sign bit is present, the field polynomial is X^DEG - K. - - When FMT=4, the field polynomial is a trinomial, X^DEG + H*X^DEGH + - K. When P=2, the H and K parameters are implicitly 1, and are - omitted from the representation. Only DEG and DEGH are present; the - next parameters are LQ,Q. When P>2, then LH,H and LK,K are - specified. Either or both of LH, LK may contain a sign bit for its - parameter. - - When FMT=5, then P=2 (only). The field polynomial is the exact - quotient of a trinomial divided by a small polynomial, the trinomial - divisor. The small polynomial is right-adjusted in the two octet - field TRDV. DEG specifies the degree of the field. The degree of - TRDV is calculated from the position of the high-order 1 bit. The - trinomial to be divided is X^(DEG+degree(TRDV)) + X^DEGH + 1. If - DEGH is 0, the middle term is omitted from the trinomial. The - quotient must be exact, with no remainder. - - When FMT=6, then P=2 (only). The field polynomial is a pentanomial, - with the degrees of the middle terms given by the three 2-octet - - -R. Schroeppel, et al [Page 7] - - -INTERNET-DRAFT ECC Keys in the DNS - - - values DEGH, DEGI, DEGJ. The polynomial is X^DEG + X^DEGH + X^DEGI + - X^DEGJ + 1. The values must satisfy the inequality DEG > DEGH > DEGI - > DEGJ > 0. - - DEGH, DEGI, DEGJ are two-octet fields that define the degree of - a term in a field polynomial. DEGH is present when FMT = 4, - 5, or 6. DEGI and DEGJ are present only when FMT = 6. - - TRDV is a two-octet right-adjusted binary polynomial of degree < - 16. It is present only for FMT=5. - - LH and H define the H parameter, present only when FMT=4 and P - is odd. The high bit of LH is an optional sign bit for H. - - LK and K define the K parameter, present when FMT = 3 or 4, and - P is odd. The high bit of LK is an optional sign bit for K. - - The remaining parameters are concerned with the elliptic curve and - the signature algorithm. - - LQ defines the length of the prime Q. Q is a prime > 2^159. - - In all 5 of the parameter pairs LA+A,LB+B,LC+C,LG+G,LY+Y, the data - member of the pair is an element from the finite field defined - earlier. The length field defines a long octet string. Field - elements are represented as (mod P) polynomials of degree < DEG, with - DEG or fewer coefficients. The coefficients are stored from left to - right, higher degree to lower, with the constant term last. The - coefficients are represented as integers in the range [0,P-1]. Each - coefficient is allocated an area of ceiling(log2 P) bits. The field - representation is right-justified; the "constant term" of the field - element ends at the right most bit. The coefficients are fitted - adjacently without regard for octet boundaries. (Example: if P=5, - three bits are used for each coefficient. If the field is GF[5^75], - then 225 bits are required for the coefficients, and as many as 29 - octets may be needed in the data area. Fewer octets may be used if - some high-order coefficients are 0.) If a flag requires a field - element to be negated, each non-zero coefficient K is replaced with - P-K. To save space, 0 bits may be removed from the left end of the - element representation, and the length field reduced appropriately. - This would normally only happen with A,B,C, because the designer - chose curve parameters with some high-order 0 coefficients or bits. - - If the finite field is simply (mod P), then the field elements are - simply numbers (mod P), in the usual right-justified notation. If - the finite field is GF[2^D], the field elements are the usual right- - justified polynomial basis representation. - - - - - -R. Schroeppel, et al [Page 8] - - -INTERNET-DRAFT ECC Keys in the DNS - - - LA,A is the first parameter of the elliptic curve equation. - When P>=5, the flag A = 1 indicates A should be negated (mod - P). When P=2 (indicated by the flag M=0), the flag A = 1 - indicates that the parameter pair LA,A is replaced by the two - octet parameter ALTA. In this case, the parameter A in the - curve equation is x^ALTA, where x is the field generator. - Parameter A often has the value 0, which may be indicated by - LA=0 (with no A data field), and sometimes A is 1, which may - be represented with LA=1 and a data field of 1, or by setting - the A flag and using an ALTA value of 0. - - LB,B is the second parameter of the elliptic curve equation. - When P>=5, the flag B = 1 indicates B should be negated (mod - P). When P=2 or 3, the flag B selects an alternate curve - equation. - - LC,C is the third parameter of the elliptic curve equation, - present only when P=2 (indicated by flag M=0) and flag B=1. - - LG,G defines a point on the curve, of order Q. The W-coordinate - of the curve point is given explicitly; the Z-coordinate is - implicit. - - 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. - - - -3. The Elliptic Curve Equation - - (The coordinates of an elliptic curve point are named W,Z instead of - the more usual X,Y to avoid confusion with the Y parameter of the - signing key.) - - The elliptic curve equation is determined by the flag octet, together - with information about the prime P. The primes 2 and 3 are special; - all other primes are treated identically. - - If M=1, the (mod P) or GF[P^D] case, the curve equation is Z^2 = W^3 - + A*W + B. Z,W,A,B are all numbers (mod P) or elements of GF[P^D]. - If A and/or B is negative (i.e., in the range from P/2 to P), and - P>=5, space may be saved by putting the sign bit(s) in the A and B - bits of the flags octet, and the magnitude(s) in the parameter - fields. - - If M=1 and P=3, the B flag has a different meaning: it specifies an - alternate curve equation, Z^2 = W^3 + A*W^2 + B. The middle term of - the right-hand-side is different. When P=3, this equation is more - - -R. Schroeppel, et al [Page 9] - - -INTERNET-DRAFT ECC Keys in the DNS - - - commonly used. - - If M=0, the GF[2^N] case, the curve equation is Z^2 + W*Z = W^3 + - A*W^2 + B. Z,W,A,B are all elements of the field GF[2^N]. The A - parameter can often be 0 or 1, or be chosen as a single-1-bit value. - The flag B is used to select an alternate curve equation, Z^2 + C*Z = - W^3 + A*W + B. This is the only time that the C parameter is used. - - - -4. How do I Compute Q, G, and Y? - - 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 Schoof's algorithm. This - number is factored, and if it has a large prime divisor, that number - is taken as Q. - - G must be a point of order Q on the curve, satisfying the equation - - Q * G = the point at infinity (on the elliptic curve) - - G may be chosen by selecting a random [RFC 1750] curve point, and - multiplying it by (number-of-points-on-curve/Q). G must not itself - be the "point at infinity"; in this astronomically unlikely event, a - new random curve point is recalculated. - - G is specified by giving its W-coordinate. The Z-coordinate is - calculated from the curve equation. In general, there will be two - possible Z values. The rule is to choose the "positive" value. - - In the (mod P) case, the two possible Z values sum to P. The smaller - value is less than P/2; it is used in subsequent calculations. In - GF[P^D] fields, the highest-degree non-zero coefficient of the field - element Z is used; it is chosen to be less than P/2. - - In the GF[2^N] case, the two possible Z values xor to W (or to the - parameter C with the alternate curve equation). The numerically - 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 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. - - - - - - -R. Schroeppel, et al [Page 10] - - -INTERNET-DRAFT ECC Keys in the DNS - - - During the key generation process, a random [RFC 1750] number X must - be generated such that 1 <= X <= Q-1. X is the private key and is - used in the final step of public key generation where Y is computed - as - - Y = X * G (as points on the elliptic curve) - - If the Z-coordinate of the computed point Y is wrong (i.e., Z > P/2 - in the (mod P) case, or the high-order non-zero coefficient of Z > - P/2 in the GF[P^D] case, or Z sharing a high bit with W(C) in the - GF[2^N] case), then X must be replaced with Q-X. This will - correspond to the correct Z-coordinate. - - - -5. Elliptic Curve SIG Resource Records - - 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. - - 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]: - - hash = SHA-1 ( data ) - - 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.) - - R = (the W-coordinate of ( K*G on the elliptic curve )) interpreted - - -R. Schroeppel, et al [Page 11] - - -INTERNET-DRAFT ECC Keys in the DNS - - - 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] - - -INTERNET-DRAFT ECC Keys in the DNS - - - 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. - - - - 6. Performance Considerations - - 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. - - 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]. - - - - - -R. Schroeppel, et al [Page 13] - - -INTERNET-DRAFT ECC Keys in the DNS - - - 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. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -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-05.txt b/doc/draft/draft-ietf-dnsext-insensitive-05.txt deleted file mode 100644 index 41fbee7a4a5..00000000000 --- a/doc/draft/draft-ietf-dnsext-insensitive-05.txt +++ /dev/null @@ -1,697 +0,0 @@ - -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-interop3597-01.txt b/doc/draft/draft-ietf-dnsext-interop3597-01.txt deleted file mode 100644 index 123d3cc0961..00000000000 --- a/doc/draft/draft-ietf-dnsext-interop3597-01.txt +++ /dev/null @@ -1,335 +0,0 @@ - -DNS Extensions Working Group J. Schlyter -Internet-Draft August 24, 2004 -Expires: February 22, 2005 - - - RFC 3597 Interoperability Report - draft-ietf-dnsext-interop3597-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 3667. - - 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 22, 2005. - -Copyright Notice - - Copyright (C) The Internet Society (2004). All Rights Reserved. - -Abstract - - This memo documents the result from the RFC 3597 (Handling of Unknown - DNS Resource Record Types) interoperability testing. - - - - - - - - - - - - -Schlyter Expires February 22, 2005 [Page 1] - -Internet-Draft RFC 3597 Interoperability Report August 2004 - - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 2. Implementations . . . . . . . . . . . . . . . . . . . . . . . 3 - 3. Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 3.1 Authoritative Primary Name Server . . . . . . . . . . . . . . 3 - 3.2 Authoritative Secondary Name Server . . . . . . . . . . . . . 3 - 3.3 Full Recursive Resolver . . . . . . . . . . . . . . . . . . . 3 - 3.4 Stub Resolver . . . . . . . . . . . . . . . . . . . . . . . . 3 - 3.5 DNSSEC Signer . . . . . . . . . . . . . . . . . . . . . . . . 4 - 4. Problems found . . . . . . . . . . . . . . . . . . . . . . . . 4 - 5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 - Normative References . . . . . . . . . . . . . . . . . . . . . 4 - Author's Address . . . . . . . . . . . . . . . . . . . . . . . 4 - A. Test zone data . . . . . . . . . . . . . . . . . . . . . . . . 5 - Intellectual Property and Copyright Statements . . . . . . . . 6 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Schlyter Expires February 22, 2005 [Page 2] - -Internet-Draft RFC 3597 Interoperability Report August 2004 - - -1. Introduction - - This memo documents the result from the RFC 3597 (Handling of Unknown - DNS Resource Record Types) interoperability testing. The test was - performed during June and July 2004 by request of the IETF DNS - Extensions Working Group. - -2. Implementations - - The following is a list, in alphabetic order, of implementations for - compliance of RFC 3597: - - DNSJava 1.6.4 - ISC BIND 8.4.5rc4 - ISC BIND 9.3.0rc2 - NSD 2.1.1 - Net::DNS 0.47 patchlevel 1 - Nominum ANS 2.2.1.0.d - - These implementations covers the following functions (number of - implementations tested for each function in paranthesis): - - Authoritative Name Servers (4) - Full Recursive Resolver (2) - Stub Resolver (4) - DNSSEC Zone Signers (2) - -3. Tests - -3.1 Authoritative Primary Name Server - - The test zone data (Appendix A) was loaded into the name server - implementation and the server was queried for the loaded information. - -3.2 Authoritative Secondary Name Server - - The test zone data (Appendix A) was transferred using AXFR from - another name server implementation and the server was queried for the - transferred information. - -3.3 Full Recursive Resolver - - A recursive resolver was queried for resource records from a domain - with the test zone data (Appendix A). - -3.4 Stub Resolver - - A stub resolver was used to query resource records from a domain with - - - -Schlyter Expires February 22, 2005 [Page 3] - -Internet-Draft RFC 3597 Interoperability Report August 2004 - - - the test zone data (Appendix A). - -3.5 DNSSEC Signer - - A DNSSEC signer was used to sign a zone with test zone data (Appendix - A). - -4. Problems found - - Two implementations had problems with text presentation of zero - length RDATA. - - One implementation had problems with text presentation of RR type - code and classes >= 4096. - - Bug reports were filed for problems found. - -5. Summary - - Unknown type codes works in the tested authoritative servers, - recursive resolvers and stub clients. - - No changes are needed to advance RFC 3597 to draft standard. - -Normative References - - [1] Gustafsson, A., "Handling of Unknown DNS Resource Record (RR) - Types", RFC 3597, September 2003. - - -Author's Address - - Jakob Schlyter - - EMail: jakob@rfc.se - - - - - - - - - - - - - - - - -Schlyter Expires February 22, 2005 [Page 4] - -Internet-Draft RFC 3597 Interoperability Report August 2004 - - -Appendix A. Test zone data - - ; A-record encoded as TYPE1 - a TYPE1 \# 4 7f000001 - a TYPE1 192.0.2.1 - a A \# 4 7f000002 - - ; draft-ietf-secsh-dns-05.txt - sshfp TYPE44 \# 22 01 01 c691e90714a1629d167de8e5ee0021f12a7eaa1e - - ; bogus test record (from RFC 3597) - type731 TYPE731 \# 6 abcd ( - ef 01 23 45 ) - - ; zero length RDATA (from RFC 3597) - type62347 TYPE62347 \# 0 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Schlyter Expires February 22, 2005 [Page 5] - -Internet-Draft RFC 3597 Interoperability Report 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 IETF's procedures with respect to rights in IETF 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. - - - - -Schlyter Expires February 22, 2005 [Page 6] - diff --git a/doc/draft/draft-ietf-dnsext-mdns-38.txt b/doc/draft/draft-ietf-dnsext-mdns-38.txt deleted file mode 100644 index ac51706af27..00000000000 --- a/doc/draft/draft-ietf-dnsext-mdns-38.txt +++ /dev/null @@ -1,1677 +0,0 @@ - -DNSEXT Working Group Levon Esibov -INTERNET-DRAFT Bernard Aboba -Category: Standards Track Dave Thaler - Microsoft -19 February 2005 - - Linklocal Multicast Name Resolution (LLMNR) - -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 August 22, 2005. - -Copyright Notice - - Copyright (C) The Internet Society 2005. All rights reserved. - -Abstract - - Today, with the rise of home networking, there are an increasing - number of ad-hoc networks operating without a Domain Name System - (DNS) server. The goal of Link-Local Multicast Name Resolution - (LLMNR) is to enable name resolution in scenarios in which - conventional DNS name resolution is not possible. LLMNR supports all - current and future DNS formats, types and classes, while operating on - a separate port from DNS, and with a distinct resolver cache. Since - LLMNR only operates on the local link, it cannot be considered a - substitute for DNS. - - - -Esibov, Aboba & Thaler Standards Track [Page 1] - - - - - -INTERNET-DRAFT LLMNR 19 February 2005 - - -Table of Contents - -1. Introduction .......................................... 3 - 1.1 Requirements .................................... 3 - 1.2 Terminology ..................................... 4 -2. Name resolution using LLMNR ........................... 4 - 2.1 LLMNR packet format ............................. 6 - 2.2 Sender behavior ................................. 8 - 2.3 Responder behavior .............................. 9 - 2.4 Unicast queries ................................. 11 - 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 ........................................... 15 - 3.1 LLMNR configuration ............................. 16 -4. Conflict resolution ................................... 17 - 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 - - - - - - - - - - - - - - -Esibov, Aboba & Thaler Standards Track [Page 2] - - - - - -INTERNET-DRAFT LLMNR 19 February 2005 - - -1. Introduction - - This document discusses Link Local Multicast Name Resolution (LLMNR), - which utilizes the DNS packet format and supports all current and - future DNS formats, types and classes. LLMNR operates on a separate - port from the Domain Name System (DNS), with a distinct resolver - cache. - - The goal of LLMNR is to enable name resolution in scenarios in which - conventional DNS name resolution is not possible. These include - scenarios in which hosts are not configured with the address of a DNS - server, where configured DNS servers do not reply to a query, or - where they respond with errors, as described in Section 2. Since - LLMNR only operates on the local link, it cannot be considered a - substitute for DNS. - - Link-scope multicast addresses are used to prevent propagation of - LLMNR traffic across routers, potentially flooding the network. - LLMNR queries can also be sent to a unicast address, as described in - Section 2.4. - - Propagation of LLMNR packets on the local link is considered - sufficient to enable name resolution in small networks. The - assumption is that if a network has a gateway, then the network is - able to provide DNS server configuration. Configuration issues are - discussed in Section 3.1. - - In the future, it may be desirable to consider use of multicast name - resolution with multicast scopes beyond the link-scope. This could - occur if LLMNR deployment is successful, the need arises for - multicast name resolution beyond the link-scope, or multicast routing - becomes ubiquitous. For example, expanded support for multicast name - resolution might be required for mobile ad-hoc networks. - - Once we have experience in LLMNR deployment in terms of - administrative issues, usability and impact on the network, it will - be possible to reevaluate which multicast scopes are appropriate for - use with multicast name resolution. - - Service discovery in general, as well as discovery of DNS servers - using LLMNR in particular, is outside of the scope of this document, - as is name resolution over non-multicast capable media. - -1.1. Requirements - - In this document, several words are used to signify the requirements - of the specification. The key words "MUST", "MUST NOT", "REQUIRED", - "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", - - - -Esibov, Aboba & Thaler Standards Track [Page 3] - - - - - -INTERNET-DRAFT LLMNR 19 February 2005 - - - and "OPTIONAL" in this document are to be interpreted as described in - [RFC2119]. - -1.2. Terminology - - This document assumes familiarity with DNS terminology defined in - [RFC1035]. Other terminology used in this document includes: - -Positively Resolved - Responses with RCODE set to zero are referred to in this document - as "positively resolved". - -Routable Address - An address other than a Link-Local address. This includes globally - routable addresses, as well as private addresses. - -Reachable - An LLMNR responder considers one of its addresses reachable over a - link if it will respond to an ARP or Neighbor Discovery query for - that address sent over the link. - -Responder - A host that listens to LLMNR queries, and responds to those for - which it is authoritative. - -Sender - A host that sends an LLMNR query. - -UNIQUE - There are some scenarios when multiple responders may respond to - the same query. There are other scenarios when only one responder - may respond to a query. Resource records for which only a single - responder is anticipated are referred to as UNIQUE. Resource - record uniqueness is configured on the responder, and therefore - uniqueness verification is the responder's responsibility. - -2. Name resolution using LLMNR - - LLMNR is a peer-to-peer name resolution protocol that is not intended - as a replacement for DNS. LLMNR queries are sent to and received on - port 5355. IPv4 administratively scoped multicast usage is specified - in "Administratively Scoped IP Multicast" [RFC2365]. The IPv4 link- - scope multicast address a given responder listens to, and to which a - sender sends queries, is 224.0.0.252. The IPv6 link-scope multicast - address a given responder listens to, and to which a sender sends all - queries, is FF02:0:0:0:0:0:1:3. - - Typically a host is configured as both an LLMNR sender and a - - - -Esibov, Aboba & Thaler Standards Track [Page 4] - - - - - -INTERNET-DRAFT LLMNR 19 February 2005 - - - responder. A host MAY be configured as a sender, but not a - responder. However, a host configured as a responder MUST act as a - sender to verify the uniqueness of names as described in Section 4. - This document does not specify how names are chosen or configured. - This may occur via any mechanism, including DHCPv4 [RFC2131] or - DHCPv6 [RFC3315]. - - LLMNR usage MAY be configured manually or automatically on a per - interface basis. By default, LLMNR responders SHOULD be enabled on - all interfaces, at all times. Enabling LLMNR for use in situations - where a DNS server has been configured will result in a change in - default behavior without a simultaneous update to configuration - information. Where this is considered undesirable, LLMNR SHOULD NOT - be enabled by default, so that hosts will neither listen on the link- - scope multicast address, nor will they send queries to that address. - - An LLMNR sender may send a request for any name. However, by - default, LLMNR requests SHOULD be sent only when one of the following - conditions are met: - - [1] No manual or automatic DNS configuration has been - performed. If DNS server address(es) have been - configured, then LLMNR SHOULD NOT be used as the - primary name resolution mechanism, although it MAY - be used as a secondary name resolution mechanism. - - [2] DNS servers do not respond. - - [3] DNS servers respond to a DNS query with RCODE=3 - (Authoritative Name Error) or RCODE=0, and an empty - answer section. - - A typical sequence of events for LLMNR usage is as follows: - - [a] DNS servers are not configured or do not respond to a - DNS query, or respond with RCODE=3, or RCODE=0 and an - empty answer section. - - [b] An LLMNR sender sends an LLMNR query to the link-scope - multicast address(es) defined in Section 2, unless a - unicast query is indicated. A sender SHOULD send LLMNR - queries for PTR RRs via unicast, as specified in Section 2.4. - - [c] A responder responds to this query only if it is authoritative - for the domain name in the query. A responder responds to a - multicast query by sending a unicast UDP response to the sender. - Unicast queries are responded to as indicated in Section 2.4. - - - - -Esibov, Aboba & Thaler Standards Track [Page 5] - - - - - -INTERNET-DRAFT LLMNR 19 February 2005 - - - [d] Upon reception of the response, the sender processes it. - - Further details of sender and responder behavior are provided in the - sections that follow. - -2.1. LLMNR packet format - - LLMNR utilizes the DNS packet format defined in [RFC1035] Section 4 - for both queries and responses. LLMNR implementations SHOULD send - UDP queries and responses only as large as are known to be - permissible without causing fragmentation. When in doubt a maximum - packet size of 512 octets SHOULD be used. LLMNR implementations MUST - accept UDP queries and responses as large as the smaller of the link - MTU or 8192 octets. - -2.1.1. LLMNR header format - - LLMNR queries and responses utilize the DNS header format defined in - [RFC1035] with exceptions noted below: - - 1 1 1 1 1 1 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - | ID | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - |QR| Opcode | Z|TC| U| C| Z| Z| Z| RCODE | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - | QDCOUNT | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - | ANCOUNT | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - | NSCOUNT | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - | ARCOUNT | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - - where: - -ID A 16 bit identifier assigned by the program that generates any kind - of query. This identifier is copied from the query to the response - and can be used by the sender to match responses to outstanding - queries. The ID field in a query SHOULD be set to a pseudo-random - value. For advice on generation of pseudo-random values, please - consult [RFC1750]. - -QR A one bit field that specifies whether this message is an LLMNR - query (0), or an LLMNR response (1). - - - - -Esibov, Aboba & Thaler Standards Track [Page 6] - - - - - -INTERNET-DRAFT LLMNR 19 February 2005 - - -OPCODE - A four bit field that specifies the kind of query in this message. - This value is set by the originator of a query and copied into the - response. This specification defines the behavior of standard - queries and responses (opcode value of zero). Future - specifications may define the use of other opcodes with LLMNR. - LLMNR senders and responders MUST support standard queries (opcode - value of zero). LLMNR queries with unsupported OPCODE values MUST - be silently discarded by responders. - -TC TrunCation - specifies that this message was truncated due to - length greater than that permitted on the transmission channel. - The TC bit MUST NOT be set in an LLMNR query and if set is ignored - by an LLMNR responder. If the TC bit is set in an LLMNR response, - then the sender SHOULD discard the response and resend the LLMNR - query over TCP using the unicast address of the responder as the - 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 - this specification MUST ignore them. Since reserved bits could - conceivably be used for different purposes than in DNS, - implementors are advised not to enable processing of these bits in - an LLMNR implementation starting from a DNS code base. - -RCODE - Response code -- this 4 bit field is set as part of LLMNR - responses. In an LLMNR query, the RCODE MUST be zero, and is - ignored by the responder. The response to a multicast LLMNR query - MUST have RCODE set to zero. A sender MUST silently discard an - 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, - and the TC bit set. This will cause the query to be resent using - TCP, and allow the inclusion of a non-zero RCODE in the response to - the TCP query. Responding with the TC bit set is preferable to not - sending a response, since it enables errors to be diagnosed. - - Since LLMNR responders only respond to LLMNR queries for names for - which they are authoritative, LLMNR responders MUST NOT respond - with an RCODE of 3; instead, they should not respond at all. - - LLMNR implementations MUST support EDNS0 [RFC2671] and extended - RCODE values. - -QDCOUNT - An unsigned 16 bit integer specifying the number of entries in the - question section. A sender MUST place only one question into the - question section of an LLMNR query. LLMNR responders MUST silently - discard LLMNR queries with QDCOUNT not equal to one. LLMNR senders - MUST silently discard LLMNR responses with QDCOUNT not equal to - one. - -ANCOUNT - An unsigned 16 bit integer specifying the number of resource - records in the answer section. LLMNR responders MUST silently - discard LLMNR queries with ANCOUNT not equal to zero. - -NSCOUNT - An unsigned 16 bit integer specifying the number of name server - resource records in the authority records section. Authority - record section processing is described in Section 2.9. - -ARCOUNT - An unsigned 16 bit integer specifying the number of resource - records in the additional records section. Additional record - section processing is described in Section 2.9. - -2.2. Sender behavior - - A sender may send an LLMNR query for any legal resource record type - (e.g., A, AAAA, SRV, etc.) to the link-scope multicast address. - - As described in Section 2.4, a sender may also send a unicast query. - Sections 2 and 3 describe the circumstances in which LLMNR queries - 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 - resolver treats it 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 section). - - Since the responder may order the RRs in the response so as to - indicate preference, the sender SHOULD preserve ordering in the - response to the querying application. - - The sender MUST anticipate receiving multiple replies to the same - LLMNR query, in the event that several LLMNR enabled computers - 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 - DNS server would; the sender perceives no inherent conflict in the - receipt of multiple responses. - -2.3. Responder behavior - - An LLMNR response MUST be sent to the sender via unicast. - - Upon configuring an IP address, responders typically will synthesize - corresponding A, AAAA and PTR RRs so as to be able to respond to - LLMNR queries for these RRs. An SOA RR is synthesized only when a - responder has another RR as well; the SOA RR MUST NOT be the only RR - that a responder has. However, in general whether RRs are manually - or automatically created is an implementation decision. - - For example, a host configured to have computer name "host1" and to - be a member of the "example.com" domain, and with IPv4 address - 192.0.2.1 and IPv6 address 2001:0DB8::1:2:3:FF:FE:4:5:6 might be - authoritative for the following records: - - host1. IN A 192.0.2.1 - IN AAAA 2001:0DB8::1:2:3:FF:FE:4:5:6 - - host1.example.com. IN A 192.0.2.1 - IN AAAA 2001:0DB8::1:2:3:FF:FE:4:5:6 - - 1.2.0.192.in-addr.arpa. IN PTR host1. - IN PTR host1.example.com. - - 6.0.5.0.4.0.E.F.F.F.3.0.2.0.1.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2. - 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. - - In responding to queries: - -[a] Responders MUST listen on UDP port 5355 on the link-scope multicast - address(es) defined in Section 2, and on UDP and TCP port 5355 on - the unicast address(es) that could be set as the source address(es) - when the responder responds to the LLMNR query. - -[b] Responders MUST direct responses to the port from which the query - was sent. When queries are received via TCP this is an inherent - 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 - from the port to which they were directed. - -[c] Responders MUST respond to LLMNR queries for names and addresses - they are authoritative for. This applies to both forward and - 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. - -[e] Responders MUST NOT respond using data from the LLMNR or DNS - resolver cache. - -[f] If a DNS server is running on a host that supports LLMNR, the DNS - server MUST respond to LLMNR queries only for the RRSets relating - to the host on which the server is running, but MUST NOT respond - for other records for which the server is authoritative. DNS - servers also MUST NOT send LLMNR queries in order to resolve DNS - queries. - -[g] If a responder is authoritative for a name, it SHOULD respond with - RCODE=0 and an empty answer section, if the type of query does not - match a RR that the responder has. - - As an example, a host configured to respond to LLMNR queries for the - name "foo.example.com." is authoritative for the name - "foo.example.com.". On receiving an LLMNR query for an A RR with the - name "foo.example.com." the host authoritatively responds with A - RR(s) that contain IP address(es) in the RDATA of the resource - record. If the responder has a AAAA RR, but no A RR, and an A RR - 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 - conventional DNS terminology, an LLMNR responder is authoritative - only for the zone apex. - - For example the host "foo.example.com." is not authoritative for the - name "child.foo.example.com." unless the host is configured with - multiple names, including "foo.example.com." and - "child.foo.example.com.". As a result, "foo.example.com." cannot - 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 - 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.". - - In this example (unless this limitation is introduced) an LLMNR query - for an A resource record for the name "child.foo.example.com." would - result in two authoritative responses: RCODE=3 (authoritative name - error) received from "foo.example.com.", and a requested A record - - from "child.foo.example.com.". To prevent this ambiguity, LLMNR - enabled hosts could perform a dynamic update of the parent (or - grandparent) zone with a delegation to a child zone. In this example - a host "child.foo.example.com." would send a dynamic update for the - NS and glue A record to "foo.example.com.", but this approach - significantly complicates implementation of LLMNR and would not be - acceptable for lightweight hosts. - -2.4. Unicast queries and responses - - Unicast queries SHOULD be sent when: - - [a] A sender repeats a query after it received a response - with the TC bit set to the previous LLMNR multicast query, or - - [b] The sender queries for a PTR RR of a fully formed IP address - within the "in-addr.arpa" or "ip6.arpa" zones. - - Unicast LLMNR queries MUST be done using TCP and the responses MUST - be sent using the same TCP connection as the query. Senders MUST - support sending TCP queries, and responders MUST support listening - for TCP queries. If the sender of a TCP query receives a response to - that query not using TCP, the response MUST be silently discarded. - - 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 - section). - -2.5. "Off link" detection - - For IPv4, an "on link" address is defined as a link-local address - [IPv4Link] or an address whose prefix belongs to a subnet on the - local link. For IPv6 [RFC2460] an "on link" address is either a - link-local address, defined in [RFC2373], or one belonging to a - prefix that a Router Advertisement indicates is on-link [RFC2461]. - - 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. - - A responder MUST select a source address for responses that is "on - link". The destination address of an LLMNR response MUST be an "on - link" unicast address. - - On receiving an LLMNR query, the responder MUST check whether it was - sent to a LLMNR multicast addresses defined in Section 2. If it was - sent to another multicast address, then the query MUST be silently - discarded. - - Section 2.4 discusses use of TCP for LLMNR queries and responses. In - composing an LLMNR query using TCP, the sender MUST set the Hop Limit - field in the IPv6 header and the TTL field in the IPv4 header of the - response to one (1). The responder SHOULD set the TTL or Hop Limit - settings on the TCP listen socket to one (1) so that SYN-ACK packets - will have TTL (IPv4) or Hop Limit (IPv6) set to one (1). This - prevents an incoming connection from off-link since the sender will - not receive a SYN-ACK from the responder. - - For UDP queries and responses, the Hop Limit field in the IPv6 header - and the TTL field in the IPV4 header MAY be set to any value. - However, it is RECOMMENDED that the value 255 be used for - compatibility with Apple Rendezvous. - - Implementation note: - - In the sockets API for IPv4 [POSIX], the IP_TTL and - IP_MULTICAST_TTL socket options are used to set the TTL of - outgoing unicast and multicast packets. The IP_RECVTTL socket - option is available on some platforms to retrieve the IPv4 TTL of - 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 - in LLMNR responses MUST only include values that are valid on the - local interface, such as IPv4 or IPv6 addresses valid on the local - link or names defended using the mechanism described in Section 4. - In particular: - - [a] If a link-scope IPv6 address is returned in a AAAA RR, - that address MUST be valid on the local link over which - LLMNR is used. - - [b] If an IPv4 address is returned, it MUST be reachable - through the link over which LLMNR is used. - - [c] If a name is returned (for example in a CNAME, MX - or SRV RR), the name MUST be resolvable on the local - link over which LLMNR is used. - - Where multiple addresses represent valid responses to a query, the - order in which the addresses are returned is as follows: - - [d] If the source address of the query is a link-scope address, - then the responder SHOULD include a link-scope address first - in the response, if available. - - [e] If the source address of the query is a routable address, - then the responder MUST include a routable address first - in the response, if available. - -2.7. Retransmission and jitter - - An LLMNR sender uses the timeout interval LLMNR_TIMEOUT to determine - when to retransmit an LLMNR query and how long to collect responses - to an LLMNR query. - - If an LLMNR query sent over UDP is not resolved within LLMNR_TIMEOUT, - then a sender SHOULD repeat the transmission of the query in order to - 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. 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 - been received. - - An LLMNR sender SHOULD dynamically compute the value of LLMNR_TIMEOUT - for each transmission. For example, the algorithms described in RFC - 2988 [RFC2988] (including exponential backoff) compute an RTO, which - is used as the value of LLMNR_TIMEOUT. Smaller values MAY be used - 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). - - 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 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 - - The responder should insert a pre-configured TTL value in the records - returned in an LLMNR response. A default value of 30 seconds is - RECOMMENDED. In highly dynamic environments (such as mobile ad-hoc - networks), the TTL value may need to be reduced. - - Due to the TTL minimalization necessary when caching an RRset, all - TTLs in an RRset MUST be set to the same value. - -2.9. Use of the authority and additional sections - - Unlike the DNS, LLMNR is a peer-to-peer protocol and does not have a - concept of delegation. In LLMNR, the NS resource record type may be - stored and queried for like any other type, but it has no special - delegation semantics as it does in the DNS. Responders MAY have NS - records associated with the names for which they are authoritative, - but they SHOULD NOT include these NS records in the authority - sections of responses. - - Responders SHOULD insert an SOA record into the authority section of - a negative response, to facilitate negative caching as specified in - [RFC2308]. The owner name of this SOA record MUST be equal to the - query name. - - - - -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 - such as negative caching. - -3. Usage model - - Since LLMNR is a secondary name resolution mechanism, its usage is in - 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, - robust DNS resolver implementations are more likely to avoid - unnecessary LLMNR queries. - - As noted in [DNSPerf], even when DNS servers are configured, a - significant fraction of DNS queries do not receive a response, or - result in negative responses due to missing inverse mappings or NS - records that point to nonexistent or inappropriate hosts. This has - the potential to result in a large number of unnecessary LLMNR - queries. - - [RFC1536] describes common DNS implementation errors and fixes. If - the proposed fixes are implemented, unnecessary LLMNR queries will be - reduced substantially, and so implementation of [RFC1536] is - recommended. - - For example, [RFC1536] Section 1 describes issues with retransmission - and recommends implementation of a retransmission policy based on - round trip estimates, with exponential backoff. [RFC1536] Section 4 - describes issues with failover, and recommends that resolvers try - another server when they don't receive a response to a query. These - policies are likely to avoid unnecessary LLMNR queries. - - [RFC1536] Section 3 describes zero answer bugs, which if addressed - 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. - -3.1. LLMNR configuration - - Since IPv4 and IPv6 utilize distinct configuration mechanisms, it is - possible for a dual stack host to be configured with the address of a - DNS server over IPv4, while remaining unconfigured with a DNS server - suitable for use over IPv6. - - In these situations, a dual stack host will send AAAA queries to the - configured DNS server over IPv4. However, an IPv6-only host - unconfigured with a DNS server suitable for use over IPv6 will be - unable to resolve names using DNS. Automatic IPv6 DNS configuration - mechanisms (such as [RFC3315] and [DNSDisc]) are not yet widely - deployed, and not all DNS servers support IPv6. Therefore lack of - IPv6 DNS configuration may be a common problem in the short term, and - LLMNR may prove useful in enabling linklocal name resolution over - IPv6. - - Where a DHCPv4 server is available but not a DHCPv6 server [RFC3315], - 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 - IPv6 or DHCPv6-based dynamic update, then an IPv6-only host will not - be able to do DNS dynamic update, and other hosts will not be able to - resolve its name. - - For example, if the configured DNS server responds to a AAAA RR query - sent over IPv4 or IPv6 with an authoritative name error (RCODE=3) or - RCODE=0 and an empty answer section, then a AAAA RR query sent using - LLMNR over IPv6 may be successful in resolving the name of an - IPv6-only host on the local link. - - Similarly, if a DHCPv4 server is available providing DNS server - configuration, and DNS server(s) exist which are authoritative for - the A RRs of local hosts and support either dynamic client update - over IPv4 or DHCPv4-based dynamic update, then the names of local - IPv4 hosts can be resolved over IPv4 without LLMNR. However, if no - DNS server is authoritative for the names of local hosts, or the - authoritative DNS server(s) do not support dynamic update, then LLMNR - enables linklocal name resolution over IPv4. - - Where DHCPv4 or DHCPv6 is implemented, DHCP options can be used to - 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 - [RFC2937], using the LLMNR Enable Option code carried in the NSSO - data. - - It is possible that DNS configuration mechanisms will go in and out - of service. In these circumstances, it is possible for hosts within - an administrative domain to be inconsistent in their DNS - configuration. - - For example, where DHCP is used for configuring DNS servers, one or - more DHCP servers can fail. As a result, hosts configured prior to - the outage will be configured with a DNS server, while hosts - configured after the outage will not. Alternatively, it is possible - for the DNS configuration mechanism to continue functioning while - configured DNS servers fail. - - An outage in the DNS configuration mechanism may result in hosts - 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 - 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) - minute is RECOMMENDED. - -4. Conflict resolution - - The uniqueness of a resource record depends on the nature of the name - in the query and type of the query. For example it is expected that: - - - multiple hosts may respond to a query for an SRV type record - - multiple hosts may respond to a query for an A or AAAA type - record for a cluster name (assigned to multiple hosts in - the cluster) - - only a single host may respond to a query for an A or AAAA - 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. - - 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: - - - starts up or is rebooted - - wakes from sleep (if the network interface was inactive - during sleep) - - is configured to respond to LLMNR queries on an interface - enabled for transmission and reception of IP traffic - - is configured to respond to LLMNR queries using additional - UNIQUE resource records - - verifies the acquisition of a new IP address and configuration - on an interface - - 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 18] - - - - - -INTERNET-DRAFT LLMNR 19 February 2005 - - -[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. - -[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. - - 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. - -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. - However, should a host need to configure LLMNR on more than one of - its active interfaces, there are some additional precautions it MUST - take. Implementers who are not planning to support LLMNR on multiple - interfaces simultaneously may skip this section. - - Where a host is configured to issue LLMNR queries on more than one - interface, each interface maintains its own independent LLMNR - resolver cache, containing the responses to LLMNR queries. - - A multi-homed host checks the uniqueness of UNIQUE records as - described in Section 4. The situation is illustrated in figure 1. - - ---------- ---------- - | | | | - [A] [myhost] [myhost] - - Figure 1. Link-scope name conflict - - In this situation, the multi-homed myhost will probe for, and defend, - its host name on both interfaces. A conflict will be detected on one - interface, but not the other. The multi-homed myhost will not be - able to respond with a host RR for "myhost" on the interface on the - right (see Figure 1). The multi-homed host may, however, be - configured to use the "myhost" name on the interface on the left. - - Since names are only unique per-link, hosts on different links could - be using the same name. If an LLMNR client sends requests over - 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. - - ---------- ---------- - | | | | - [A] [myhost] [A] - - - Figure 2. Off-segment name conflict - - If host myhost is configured to use LLMNR on both interfaces, it will - send LLMNR queries on both interfaces. When host myhost sends a - 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. - - [A] - | | - ----- ----- - | | - [myhost] - - Figure 3. Multiple paths to same host - - This illustrates that the proposed name conflict resolution mechanism - does not support detection or resolution of conflicts between hosts - on different links. This problem can also occur with unicast DNS - when a multi-homed host is connected to two different networks with - separated name spaces. It is not the intent of this document to - address the issue of uniqueness of names within DNS. - -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 - sockaddr_in6 structure exposes the scope within which each scoped - address exists, and this structure can be used for both IPv4 (using - v4-mapped IPv6 addresses) and IPv6 addresses. - - Following the example in Figure 2, an application on 'myhost' issues - the request getaddrinfo("A", ...) with ai_family=AF_INET6 and - ai_flags=AI_ALL|AI_V4MAPPED. LLMNR requests will be sent from both - 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 - 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 - are still indistinguishable, but this API allows the application to - communicate successfully with any address in the list. - -5. Security Considerations - - LLMNR is by nature a peer-to-peer name resolution protocol. It is - therefore inherently more vulnerable than DNS, since existing DNS - security mechanisms are difficult to apply to LLMNR. While tools - exist to allow an attacker to spoof a response to a DNS query, - spoofing a response to an LLMNR query is easier since the query is - 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: - - [1] Scope restrictions. - [2] Usage restrictions. - [3] Cache and port separation. - [4] Authentication. - - These techniques are described in the following sections. - -5.1. Scope restriction - - With LLMNR it is possible that hosts will allocate conflicting names - for a period of time, or that attackers will attempt to deny service - to other hosts by allocating the same name. Such attacks also allow - hosts to receive packets destined for other hosts. - - Since LLMNR is typically deployed in situations where no trust model - can be assumed, it is likely that LLMNR queries and responses will be - unauthenticated. In the absence of authentication, LLMNR reduces the - exposure to such threats by utilizing UDP queries sent to a link- - scope multicast address, as well as setting the TTL (IPv4) or Hop - Limit (IPv6) fields to one (1) on TCP queries and responses. - - Using a TTL of one (1) to set up a TCP connection in order to send a - unicast LLMNR query reduces the likelihood of both denial of service - attacks and spoofed responses. Checking that an LLMNR query is sent - to a link-scope multicast address should prevent spoofing of - multicast queries by off-link attackers. - - While this limits the ability of off-link attackers to spoof LLMNR - queries and responses, it does not eliminate it. For example, it is - 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 - LLMNR sender. - - When LLMNR queries are sent to a link-scope multicast address, it is - possible that some routers may not properly implement link-scope - multicast, or that link-scope multicast addresses may leak into the - multicast routing system. - - Setting the IPv6 Hop Limit or IPv4 TTL field to a value larger than - one in an LLMNR UDP response may enable denial of service attacks - across the Internet. However, since LLMNR responders only respond to - 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 - will require physical access to the home network, while wireless - attackers may reside outside the home. Link-layer security can be of - assistance against these threats if it is available. - -5.2. Usage restriction - - As noted in Sections 2 and 3, LLMNR is intended for usage in a - limited set of scenarios. - - If an LLMNR query is sent whenever a DNS server does not respond in a - timely way, then an attacker can poison the LLMNR cache by responding - to the query with incorrect information. To some extent, these - vulnerabilities exist today, since DNS response spoofing tools are - available that can allow an attacker to respond to a query more - quickly than a distant DNS server. - - Since LLMNR queries are sent and responded to on the local-link, an - attacker will need to respond more quickly to provide its own - response prior to arrival of the response from a legitimate - responder. If an LLMNR query is sent for an off-link host, spoofing a - response in a timely way is not difficult, since a legitimate - response will never be received. - - The vulnerability is more serious if LLMNR is given higher priority - than DNS among the enabled name resolution mechanisms. In such a - configuration, a denial of service attack on the DNS server would not - 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 - cache, eliminating the benefits of cache separation. As a result, - LLMNR is only used as a name resolution mechanism of last resort. - -5.3. Cache and port separation - - In order to prevent responses to LLMNR queries from polluting the DNS - cache, LLMNR implementations MUST use a distinct, isolated cache for - LLMNR on each interface. The use of separate caches is most effective - when LLMNR is used as a name resolution mechanism of last resort, - since this minimizes the opportunities for poisoning the LLMNR cache, - and decreases reliance on it. - - 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 - mechanisms. Since LLMNR does not support "delegated trust" (CD or AD - bits), and LLMNR senders are unlikely to be DNSSEC-aware, in practice - LLMNR is not compatible with DNSSEC. - - Since LLMNR implementations MAY NOT support TSIG or SIG(0), responses - to LLMNR queries may be unauthenticated. If authentication is - desired, and a pre-arranged security configuration is possible, then - IPsec ESP with a null-transform MAY be used to authenticate unicast - LLMNR queries and responses or LLMNR responses to multicast queries. - In a small network without a certificate authority, this can be most - easily accomplished through configuration of a group pre-shared key - for trusted hosts. - -6. IANA Considerations - - This specification creates one new name space: the reserved bits in - the LLMNR header. These are allocated by IETF Consensus, in - accordance with BCP 26 [RFC2434]. - - LLMNR requires allocation of port 5355 for both TCP and UDP. - - LLMNR requires allocation of link-scope multicast IPv4 address - 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 - -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. - -[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - -[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS - Specification", RFC 2181, July 1997. - -[RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", - RFC 2308, March 1998. - -[RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC - 2365, July 1998. - -[RFC2373] Hinden, R. and S. Deering, "IP Version 6 Addressing - Architecture", RFC 2373, July 1998. - -[RFC2434] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA - Considerations Section in RFCs", BCP 26, RFC 2434, October - 1998. - -[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 - (IPv6) Specification", RFC 2460, December 1998. - -[RFC2461] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery - for IP Version 6 (IPv6)", RFC 2461, December 1998. - -[RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC - 2535, March 1999. - -[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, - August 1999. - -[RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission - Timer", RFC 2988, November 2000. - -8.2. Informative References - -[RFC1536] Kumar, A., et. al., "DNS Implementation Errors and Suggested - Fixes", RFC 1536, October 1993. - -[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. - -[RFC2292] Stevens, W. and M. Thomas, "Advanced Sockets API for IPv6", - RFC 2292, February 1998. - -[RFC2553] Gilligan, R., Thomson, S., Bound, J. and W. Stevens, "Basic - Socket Interface Extensions for IPv6", RFC 2553, March 1999. - -[RFC2937] Smith, C., "The Name Service Search Option for DHCP", RFC - 2937, September 2000. - -[RFC3315] Droms, R., et al., "Dynamic Host Configuration Protocol for - IPv6 (DHCPv6)", RFC 3315, July 2003. - -[RFC3927] Cheshire, S., Aboba, B. and E. Guttman, "Dynamic Configuration - of Link-Local IPv4 Addresses", RFC 3927, October 2004. - -[DNSPerf] Jung, J., et al., "DNS Performance and the Effectiveness of - Caching", IEEE/ACM Transactions on Networking, Volume 10, - Number 5, pp. 589, October 2002. - -[DNSDisc] Durand, A., Hagino, I. and D. Thaler, "Well known site local - unicast addresses to communicate with recursive DNS servers", - Internet draft (work in progress), draft-ietf-ipv6-dns- - discovery-07.txt, October 2002. - -[POSIX] IEEE Std. 1003.1-2001 Standard for Information Technology -- - Portable Operating System Interface (POSIX). Open Group - Technical Standard: Base Specifications, Issue 6, December - 2001. ISO/IEC 9945:2002. http://www.opengroup.org/austin - -[LLMNREnable] - Guttman, E., "DHCP LLMNR Enable Option", Internet draft (work - in progress), draft-guttman-mdns-enable-02.txt, April 2002. - -[NodeInfo] - Crawford, M., "IPv6 Node Information Queries", Internet draft - (work in progress), draft-ietf-ipn-gwg-icmp-name- - lookups-09.txt, May 2002. - -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, - Christian Huitema, Olaf Kolkman, Mika Liljeberg, Keith Moore, - Tomohide Nagashima, Thomas Narten, Erik Nordmark, Markku Savela, Mike - St. Johns, Sander Van-Valkenburg, and Brian Zill. - -Authors' Addresses - - Levon Esibov - Microsoft Corporation - One Microsoft Way - Redmond, WA 98052 - - EMail: levone@microsoft.com - - Bernard Aboba - Microsoft Corporation - One Microsoft Way - Redmond, WA 98052 - - Phone: +1 425 706 6605 - EMail: bernarda@microsoft.com - - Dave Thaler - Microsoft Corporation - One Microsoft Way - Redmond, WA 98052 - - Phone: +1 425 703 8835 - EMail: dthaler@microsoft.com - -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. - - - - -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 - this standard. Please address the information to the IETF Executive - Director. - -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. - -Open Issues - - Open issues with this specification are tracked on the following web - site: - - http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html - - - - - - - - - - - - - - - - - - - - - - - -Esibov, Aboba & Thaler Standards Track [Page 28] - - - - diff --git a/doc/draft/draft-ietf-dnsext-nsec3-01.txt b/doc/draft/draft-ietf-dnsext-nsec3-01.txt deleted file mode 100644 index 10d8118412f..00000000000 --- a/doc/draft/draft-ietf-dnsext-nsec3-01.txt +++ /dev/null @@ -1,1009 +0,0 @@ - - -Network Working Group B. Laurie -Internet-Draft G. Sisson -Expires: August 2, 2005 Nominet - R. Arends - Telematica Instituut - february 2005 - - - DNSSEC Hash Authenticated Denial of Existence - draft-ietf-dnsext-nsec3-01 - -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 2, 2005. - -Copyright Notice - - Copyright (C) The Internet Society (2005). - -Abstract - - The DNS Security (DNSSEC) NSEC resource record (RR) is intended to be - used to provide authenticated denial of existence of DNS ownernames - and types; however, it permits any user to traverse a zone and obtain - a listing of all ownernames. - - - - -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 - multiple WHOIS queries to reveal registrant data which many - registries (particularly in Europe) may be under strict legal - obligations to protect. Many registries therefore prohibit copying - of their zone file; however the use of NSEC RRs makes renders - policies unenforceable. - - This document proposes a scheme which obscures original ownernames - while permitting authenticated denial of existence of non-existent - names. Non-authoritative delegation point NS RR types may be - excluded. - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 - 1.1 Rationale . . . . . . . . . . . . . . . . . . . . . . . . 4 - 1.2 Reserved Words . . . . . . . . . . . . . . . . . . . . . . 4 - 1.3 Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 - 2. The NSEC3 Resource Record . . . . . . . . . . . . . . . . . . 5 - 2.1 NSEC3 RDATA Wire Format . . . . . . . . . . . . . . . . . 5 - 2.1.1 The Authoritative Only Flag Field . . . . . . . . . . 6 - 2.1.2 The Hash Function Field . . . . . . . . . . . . . . . 6 - 2.1.3 The Iterations Field . . . . . . . . . . . . . . . . . 6 - 2.1.4 The Salt Length Field . . . . . . . . . . . . . . . . 6 - 2.1.5 The Salt Field . . . . . . . . . . . . . . . . . . . . 6 - 2.1.6 The Next Hashed Ownername Field . . . . . . . . . . . 7 - 2.1.7 The list of Type Bit Map(s) Field . . . . . . . . . . 7 - 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. 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 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Laurie, et al. Expires August 2, 2005 [Page 3] - -Internet-Draft nsec3 february 2005 - - -1. Introduction - - The DNS Security Extensions (DNSSEC) introduced the NSEC Resource - Record (RR) for Authenticated Denial of Existence. This document - introduces a new RR as an alternative to NSEC that provides measures - against zone traversal and allows for gradual expansion of - delegation-centric zones. - -1.1 Rationale - - The DNS Security Extensions included the NSEC RR to provide - authenticated denial of existence. Though the NSEC RR meets the - requirements for authenticated denial of Existence, it introduced a - side-effect in that the contents of a zone can be enumerated. This - property introduces undesired policy issues. - - A second requirement was that the existence of all record types in a - zone -including delegation point NS record types- can be accounted - for, despite the fact that delegation point NS RRsets are not - authoritative and not signed. This requirement has a side-effect - that the overhead of delegation centric signed zones is not related - to the increase in security of subzones. This requirement does not - allow delegation centric zones size to grow in relation to the growth - of signed subzones. - - In the past, solutions have been proposed as a measure against these - side effects but at the time were regarded as secondary over the need - to have a stable DNSSEC specification. With (draft-vixie-dnssec-ter) - a graceful transition path to future enhancements is introduced, - while current DNSSEC deployment can continue. This document - accumulates measures against the side effects introduced by NSEC, and - presents the NSEC3 Resource Record. - - The reader is assumed to be familiar with the basic DNS concepts - described in RFC1034 [RFC1034], RFC1035 [RFC1035] and subsequent RFCs - that update them: RFC2136 [RFC2136], RFC2181 [RFC2181] and RFC2308 - [RFC2308]. - -1.2 Reserved Words - - 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]. - -1.3 Terminology - - In this document the term "original ownername" refers to a standard - ownername. Because this proposal uses the result of a hash function - - - -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 - - The NSEC3 RR provides Authenticated Denial of Existence for DNS - Resource Record Sets. - - The NSEC3 Resource Record lists RR types present at the NSEC3 RR's - original ownername. It includes the next hashed ownername in the - canonical ordering of the zone. The complete set of NSEC3 RRs in a - zone indicates which RRsets exist for the original ownername of the - RRset and form a chain of hashed ownernames in the zone. This - information is used to provide authenticated denial of existence for - DNS data, as described in RFC 2535 [RFC2535]. Unsigned delegation - point NS RR sets can optionally be excluded. To provide protection - against zone traversal, the ownernames used in the NSEC3 RR are - cryptographic hash-value prepended to the name of the zone. The - NSEC3 RR record indicates which Hash Function is used to construct to - hash, which Salt is used, and how many iterations of the Hash - Function are performed over the original ownername. - - The type value for the NSEC3 RR is XX. - - The NSEC3 RR RDATA format is class independent. - - The NSEC3 RR SHOULD have the same TTL value as the SOA minimum TTL - field. This is in the spirit of negative caching [RFC2308]. - -2.1 NSEC3 RDATA Wire Format - - The RDATA of the NSEC3 RR is as shown below: - - 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 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - |A|Hash Function| Iterations | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Salt Length | Salt / - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - / Next Hashed Ownername / - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - / Type Bit Maps / - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - - - - - - -Laurie, et al. Expires August 2, 2005 [Page 5] - -Internet-Draft nsec3 february 2005 - - -2.1.1 The Authoritative Only Flag Field - - The Authoritative Only Flag field indicates whether the Type Bit Maps - include delegation point NS record types. - - If the flag is set to 1, the NS RR type bit for a delegation point - ownername SHOULD be clear when the NSEC3 RR is generated. The NS RR - type bit MUST be ignored during processing of the NSEC3 RR. The NS - RR type bit has no meaning in this context (it is not authoritative), - hence the NSEC3 does not contest the existence of a NS RR type record - for this ownername. When a delegation is not secured, there exist no - DS RR type nor any other authoritative types for this delegation, - hence the unsecured delegation has no NSEC3 record associated. - Please see the Special Consideration section for implications for - unsigned delegations. - - If the flag is set to 0, the NS RR type bit for a delegation point - 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 behaviour is identical to NSEC behaviour. - -2.1.2 The Hash Function Field - - The Hash Function field identifies the cryptographic hash function - used to construct the hash-value. - - This document defines Value 1 for SHA-1 and Value 127 for - Experimental. All other values are reserved. - - On reception, a resolver MUST discard an NSEC3 RR with an unknown - Hash Function value. - -2.1.3 The Iterations Field - - The Iterations field defines the number of times the hash has been - iterated. More iterations results in greater resiliency of the hash - value against dictionary attacks, but at a higher cost for both the - server and resolver. - -2.1.4 The Salt Length Field - - The Salt Length Field defines the length of the salt in octets. - -2.1.5 The Salt Field - - The salt field is not present when the Salt Length Field has a value - of 0. - - - -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. - - The salt is not prepended during iterations of the hash function. - - The Salt field value MUST be identical for all NSEC3 RRs generated - for the zone. If the salt were different for each NSEC3 RR, - collisions could occur where an NSEC3 denies the existence of - existing RRs due to the application of different salt values. - -2.1.6 The Next Hashed Ownername Field - - The Next Hashed Ownername Field contains the hash of the ownername of - the next RR in the canonical ordering of the hashed ownernames of the - zone. The value of the Next Hashed Ownername Field in the last NSEC3 - record in the zone is the same as the ownername of the first NSEC3 RR - in the zone in canonical order. - - A sender MUST NOT use DNS name compression on the Next Hashed - Ownername field when transmitting an NSEC3 RR. - - Hashed ownernames of RRsets not authoritative for the given zone - (such as glue records) MUST NOT be listed in the Hash of Next Domain - Name unless at least one authoritative RRset exists at the same owner - name. - -2.1.7 The list of Type Bit Map(s) Field - - The Type Bit Maps field identifies the RRset types which exist at the - NSEC3 RR's ownername. - - The Type bit for the NSEC3 and RRSIG MUST be set during generation, - and MUST be ignored during processing. - - The RR type space is split into 256 window blocks, each representing - the low-order 8 bits of the 16-bit RR type space. Each block that - has at least one active RR type is encoded using a single octet - window number (from 0 to 255), a single octet bitmap length (from 1 - to 32) indicating the number of octets used for the window block's - bitmap, and up to 32 octets (256 bits) of bitmap. - - Blocks are present in the NSEC3 RR RDATA in increasing numerical - order. - - "|" denotes concatenation - - Type Bit Map(s) Field = ( Window Block # | Bitmap Length | Bitmap ) + - - - - -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 - window block 0, bit 1 corresponds to RR type 1 (A), bit 2 corresponds - to RR type 2 (NS), and so forth. For window block 1, bit 1 - corresponds to RR type 257, bit 2 to RR type 258. If a bit is set to - 1, it indicates that an RRset of that type is present for the NSEC3 - RR's ownername. If a bit is set to 0, it indicates that no RRset of - that type is present for the NSEC3 RR's ownername. - - The RR type 2 (NS) is authoritative at the apex of a zone and is not - authoritative at delegation points. If the Authoritative Only Flag - is set to 1, the delegation point NS RR type MUST NOT be included in - the type bit maps. If the Authoritative Only Flag is set to 0, the - NS RR type at a delegation point MUST be included in the type bit - maps. - - Since bit 0 in window block 0 refers to the non-existing RR type 0, - it MUST be set to 0. After verification, the validator MUST ignore - the value of bit 0 in window block 0. - - Bits representing Meta-TYPEs or QTYPEs as specified in RFC 2929 [4] - (section 3.1) or within the range reserved for assignment only to - QTYPEs and Meta-TYPEs MUST be set to 0, since they do not appear in - zone data. If encountered, they must be ignored upon reading. - - Blocks with no types present MUST NOT be included. Trailing zero - octets in the bitmap MUST be omitted. The length of each block's - 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 interpreted as zero octets. - -2.2 The NSEC3 RR Presentation Format - - The presentation format of the RDATA portion is as follows: - - The Authoritative Only Field is represented as an unsigned decimal - integer. The value are either 0 or 1. - - The Hash field is presented as the name of the hash or as an unsigned - decimal integer. The value has a maximum of 127. - - The Iterations field is presented as an unsigned decimal integer. - - The Salt Length field is not presented. - - The Salt field is represented as a sequence of case-insensitive - hexadecimal digits. Whitespace is not allowed within the sequence. - - - -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. - - The Hash of Next Domain Name field is represented as a sequence of - case-insensitive base32 digits. Whitespace is allowed within the - sequence. - - The List of Type Bit Map(s) Field is represented as a sequence of RR - type mnemonics. When the mnemonic is not known, the TYPE - representation as described in RFC 3597 [5] (section 5) MUST be used. - -3. Creating Additional NSEC3 RR for Empty Non Terminals - - 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. - - Additional NSEC3 RRs cover every existing intermediate label level. - Additional NSEC3 RRs are identical in format to NSEC3 RRs that cover - existing RRs in the zone. The difference is that the type-bit-maps - only indicate the existence of an NSEC3 RR and a RRSIG type. - -4. Calculation of the Hash - - Define H(x) to be the hash of x using the hash function selected by - the NSEC3 record and || to indicate concatenation. Then define: - - IH(salt,x,0)=H(x || salt) - - IH(salt,x,k)=H(IH(salt,x,k-1) || salt) if k > 0 - - Then the calculated hash of an ownername is - IH(salt,ownername,iterations-1), where the ownername is the canonical - form. - - The canonical form of the ownername is the wire format of the - ownername where: - 1. The ownername is fully expanded (no DNS name compression) and - fully qualified; - 2. All uppercase US-ASCII letters are replaced by the corresponding - lowercase US-ASCII letters; - 3. If the ownername is a wildcard name, the ownername is in its - original unexpanded form, including the "*" label (no wildcard - substitution); - -5. Including NSEC3 RRs in a Zone - - Each owner name in the zone which has authoritative data or a secured - - - -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. - -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 behaviour when the flag value is - 1. - -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 - ownername of an unsigned delegation point. - - Since no authoritative data exist at this ownername, it is excluded - from the NSEC3 chain. This is an optimization since it relieves the - zone of including an NSEC3 record and its associated signature for - this name. - - An NSEC3 that denies existence of ownernames between X and X' with - the Authoritative Only Flag set to 1 can not be used to proof - presence nor absence of the delegation point NS records for unsigned - delegations in the interval X, X'. The Authoritative Only Flag - effectively states No Contest on the presence of delegation point NS - resource records. - - Since proof is absent, there exists a new attack vector. Unsigned - delegation point NS records can be deleted during a man in the middle - attack, effectively denying existence of the delegation. This is a - form of Denial of Service, where the victim has no information it is - under attack, since all signatures are valid and the fabricated - response form is a known type of response. - - The only possible mitigation is to either not use this method, hence - proving existence or absence of unsigned delegations, or signing the - delegated zone, changing the unsigned delegation into a signed - delegation. - - A second attack vector exists in that an adversary is able to - successfully fabricate a response claiming a not existent delegation - to exist, though unsigned. - - The only possible mitigation is to either not use this method, hence - proving absence of unsigned delegations. - -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 - of existence. - - 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 non-existence must be shown for all enclosers that - could be closer. - -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 - salt, the cost of the dictionary doubles. The NSEC3 RR can use - maximum 2040 bits of salt, multiplying the cost by 2^2040. - - The salt value for each NSEC3 RR MUST be equal for a single version - of the zone. - -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 - chance of a single collision is about 2^80. Though this probability - is extremely low, the following paragraphs deal with avoiding - collisions and assessing possible damage in the event of an attack - using Hash collisions. - -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 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. - -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 - 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, - the actual damage is that a response message can be generated which - claims that a certain QNAME (i.e. the second pre-image) does exist, - while in reality QNAME does not exist (a false positive), which will - either cause a security aware resolver to re-query for the - non-existent name, or to fail the initial query. Note that the - 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. - -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 - space in a DNS message is costly, truncation is tempting. Truncation - might be considered to allow for shorter ownernames and rdata for - hashed labels. In general, if a cryptographic hash is truncated to n - bits, then the expected number of domains required to give a 1 in 2 - probability of a single collision is approximately 2^(n/2) and the - work factor to produce a second preimage resistance is 2^n. - - An extreme hash value truncation would be truncating to the shortest - possible unique label value. Considering that hash values are - presented in base32, which represents 5 bits per label character, - truncation must be done on a 5 bit boundary. This would be unwise, - since the work factor to produce collisions would then approximate - the size of the zone. - - Though the mentioned truncation can be maximized to a certain - extreme, the probability of collision increases exponentially for - every truncated bit. Given the low impact of hash value collisions - and limited space in DNS messages, the balance between truncation - profit and collision damage may be determined by local policy. - -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. - -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. - Values 0, 2-126 are marked as Reserved For Future Use. Value 127 is - marked as Experimental. - - - - -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 - hashes of all likely domain names, comparing against the hashes found - in the NSEC3 records, and thus enumerating the zone). These are - substantially more expensive than traversing the original NSEC - records would have been, and in any case, such an attack could also - be used directly against the name server itself by performing queries - for all likely names. The expense of this attack can be chosen by - setting the iterations in the NSEC3 RR. - - High-value domains are also susceptible to a precalculated dictionary - attack - that is, a list of hashes for all likely names is computed - once, then NSEC3 is scanned periodically and compared against the - precomputed hashes. This attack is prevented by changing the salt on - a regular basis. - - Walking the NSEC3 RRs will reveal the total number of records in the - zone, and also what types they are. This could be mitigated by - adding dummy entries, but certainly an upper limit can always be - found. - - Hash collisions may occur. If they do, it will be impossible to - 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. - -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]. - -11. Security Considerations - -Appendix A. Example Zone - - This is a zone showing its NSEC3 records. They can also be used as - test vectors for the hash algorithm. RRSIG records have been elided. - - - - - - - - - - - -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" - 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 - 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 - a33559360eecb02f36b5c1b72c109126ca4f5a0d.example.com. 3600 IN NSEC3 \ - SHA-1 200 31323334 BFE6EA21DEE9D228889AE11FA58C4BD551D15801 \ - A RRSIG NSEC3 - 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 - 50016b56fd2f0ffc7b563c50faf0e34259763bbb.example.com. 3600 IN NSEC3 \ - SHA-1 200 31323334 83C06D3B7D01FBC9576C71AF2BEC1A1163435153 \ - A RRSIG NSEC3 - - -12. References - -12.1 Normative References - - [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. - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - - - -Laurie, et al. Expires August 2, 2005 [Page 15] - -Internet-Draft nsec3 february 2005 - - - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [RFC2136] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic - Updates in the Domain Name System (DNS UPDATE)", RFC 2136, - April 1997. - - [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS - Specification", RFC 2181, July 1997. - - [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS - NCACHE)", RFC 2308, March 1998. - - [RFC2535] Eastlake, D., "Domain Name System Security Extensions", - RFC 2535, March 1999. - -12.2 Informative References - - [RFC2026] Bradner, S., "The Internet Standards Process -- Revision - 3", BCP 9, RFC 2026, October 1996. - - [RFC2418] Bradner, S., "IETF Working Group Guidelines and - Procedures", BCP 25, RFC 2418, September 1998. - - [rollover] - Ihren, J., Kolkman, O. and B. Manning, "An In-Band - Rollover Algorithm and a Out-Of-Band Priming Method for - DNS Trust Anchors.", July 2004. - - -Authors' Addresses - - Ben Laurie - Nominet - 17 Perryn Road - London W3 7LR - England - - Phone: +44 (20) 8735 0686 - EMail: ben@algroup.co.uk - - - Geoffrey Sisson - Nominet - - - - - - - - -Laurie, et al. Expires August 2, 2005 [Page 16] - -Internet-Draft nsec3 february 2005 - - - Roy Arends - Telematica Instituut - Brouwerijstraat 1 - 7523 XC Enschede - The Netherlands - - Phone: +31 (53) 485 0485 - EMail: roy.arends@telin.nl - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Laurie, et al. Expires August 2, 2005 [Page 17] - -Internet-Draft nsec3 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. - - - - -Laurie, et al. Expires August 2, 2005 [Page 18] - - diff --git a/doc/draft/draft-ietf-dnsext-rfc2536bis-dsa-05.txt b/doc/draft/draft-ietf-dnsext-rfc2536bis-dsa-05.txt deleted file mode 100644 index c0b8a6a0cd9..00000000000 --- a/doc/draft/draft-ietf-dnsext-rfc2536bis-dsa-05.txt +++ /dev/null @@ -1,466 +0,0 @@ - - -INTERNET-DRAFT DSA Information in the DNS -OBSOLETES: RFC 2536 Donald E. Eastlake 3rd - Motorola Laboratories -Expires: September 2005 March 2005 - - - DSA Keying and Signature Information in the DNS - --- ------ --- --------- ----------- -- --- --- - - 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 DNS extensions working group mailing list - . - - 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 - - -Abstract - - The standard method of encoding US Government Digital Signature - Algorithm keying and signature information for use in the Domain Name - System is specified. - - -Copyright Notice - - Copyright (C) The Internet Society 2005. All Rights Reserved. - - - - - -D. Eastlake 3rd [Page 1] - - -INTERNET-DRAFT DSA Information in the DNS - - -Table of Contents - - Status of This Document....................................1 - Abstract...................................................1 - Copyright Notice...........................................1 - - Table of Contents..........................................2 - - 1. Introduction............................................3 - 2. DSA Keying Information..................................3 - 3. DSA Signature Information...............................4 - 4. Performance Considerations..............................4 - 5. Security Considerations.................................5 - 6. IANA Considerations.....................................5 - Copyright and Disclaimer...................................5 - - Normative References.......................................7 - Informative References.....................................7 - Authors Address............................................8 - Expiration and File Name...................................8 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -D. Eastlake 3rd [Page 2] - - -INTERNET-DRAFT DSA Information in the DNS - - -1. Introduction - - The Domain Name System (DNS) is the global hierarchical replicated - distributed database system for Internet addressing, mail proxy, and - other information [RFC 1034, 1035]. The DNS has been extended to - include digital signatures and cryptographic keys as described in - [RFC intro, proto, records] and additional work is underway which - would require the storage of keying and signature information in the - DNS. - - This document describes how to encode US Government Digital Signature - Algorithm (DSA) keys and signatures in the DNS. Familiarity with the - US Digital Signature Algorithm is assumed [FIPS 186-2, Schneier]. - - - -2. DSA Keying Information - - When DSA public keys are stored in the DNS, the structure of the - relevant part of the RDATA part of the RR being used is the fields - listed below in the order given. - - The period of key validity is not included in this data but is - indicated separately, for example by an RR such as RRSIG which signs - and authenticates the RR containing the keying information. - - Field Size - ----- ---- - T 1 octet - Q 20 octets - P 64 + T*8 octets - G 64 + T*8 octets - Y 64 + T*8 octets - - As described in [FIPS 186-2] and [Schneier], T is a key size - parameter chosen such that 0 <= T <= 8. (The meaning if the T octet - is greater than 8 is reserved and the remainder of the data may have - a different format in that case.) Q is a prime number selected at - key generation time such that 2**159 < Q < 2**160. Thus Q is always - 20 octets long and, as with all other fields, is stored in "big- - endian" network order. P, G, and Y are calculated as directed by the - [FIPS 186-2] key generation algorithm [Schneier]. P is in the range - 2**(511+64T) < P < 2**(512+64T) and thus is 64 + 8*T octets long. G - and Y are quantities modulo P and so can be up to the same length as - P and are allocated fixed size fields with the same number of octets - as P. - - During the key generation process, a random number X must be - generated such that 1 <= X <= Q-1. X is the private key and is used - in the final step of public key generation where Y is computed as - - -D. Eastlake 3rd [Page 3] - - -INTERNET-DRAFT DSA Information in the DNS - - - Y = G**X mod P - - - -3. DSA Signature Information - - The portion of the RDATA area used for US Digital Signature Algorithm - signature information is shown below with fields in the order they - are listed and the contents of each multi-octet field in "big-endian" - network order. - - Field Size - ----- ---- - T 1 octet - R 20 octets - S 20 octets - - First, the data signed must be determined. Then the following steps - are taken, as specified in [FIPS 186-2], where Q, P, G, and Y are as - specified in the public key [Schneier]: - - hash = SHA-1 ( data ) - - Generate a random K such that 0 < K < Q. - - R = ( G**K mod P ) mod Q - - S = ( K**(-1) * (hash + X*R) ) mod Q - - For information on the SHA-1 hash function see [FIPS 180-1] and [RFC - 3174]. - - Since Q is 160 bits long, R and S can not be larger than 20 octets, - which is the space allocated. - - T is copied from the public key. It is not logically necessary in - the SIG but is present so that values of T > 8 can more conveniently - be used as an escape for extended versions of DSA or other algorithms - as later standardized. - - - -4. Performance Considerations - - General signature generation speeds are roughly the same for RSA [RFC - 3110] and DSA. With sufficient pre-computation, signature generation - with DSA is faster than RSA. Key generation is also faster for DSA. - However, signature verification is an order of magnitude slower than - RSA when the RSA public exponent is chosen to be small, as is - recommended for some applications. - - -D. Eastlake 3rd [Page 4] - - -INTERNET-DRAFT DSA Information in the DNS - - - Current DNS implementations are optimized for small transfers, - typically less than 512 bytes including DNS overhead. Larger - transfers will perform correctly and extensions have been - standardized [RFC 2671] to make larger transfers more efficient, it - is still advisable at this time to make reasonable efforts to - minimize the size of RR sets containing keying and/or signature - inforamtion consistent with adequate security. - - - -5. 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. - - The key size limitation of a maximum of 1024 bits ( T = 8 ) in the - current DSA standard may limit the security of DSA. For particular - applications, implementors are encouraged to consider the range of - available algorithms and key sizes. - - DSA assumes the ability to frequently generate high quality random - numbers. See [random] for guidance. DSA is designed so that if - biased rather than random numbers are used, high bandwidth covert - channels are possible. See [Schneier] and more recent research. The - leakage of an entire DSA private key in only two DSA signatures has - been demonstrated. DSA provides security only if trusted - implementations, including trusted random number generation, are - used. - - - -6. IANA Considerations - - Allocation of meaning to values of the T parameter that are not - defined herein (i.e., > 8 ) requires an IETF standards actions. It - is intended that values unallocated herein be used to cover future - extensions of the DSS standard. - - - -Copyright 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. - - -D. Eastlake 3rd [Page 5] - - -INTERNET-DRAFT DSA Information in the DNS - - - 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. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -D. Eastlake 3rd [Page 6] - - -INTERNET-DRAFT DSA Information in the DNS - - -Normative References - - [FIPS 180-1] - U.S. Federal Information Processing Standard: Secure - Hash Standard, April 1995. - - [FIPS 186-2] - U.S. Federal Information Processing Standard: Digital - Signature Standard, 27 January 2000. - - [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. - - - -Informative References - - [random] - "Randomness Recommendations for Security", D. Eastlake, S. - Crocker, J. Schiller, work in progress, draft-eastlake- - randomness2-*.txt currently in RFC Editor's queue. - - [RFC 1034] - "Domain names - concepts and facilities", P. - Mockapetris, 11/01/1987. - - [RFC 1035] - "Domain names - implementation and specification", P. - Mockapetris, 11/01/1987. - - [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] - "Extension Mechanisms for DNS (EDNS0)", P. Vixie, August - 1999. - - [RFC 3110] - "RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System - (DNS)", D. Eastlake 3rd. May 2001. - - [RFC 3174] - "US Secure Hash Algorithm 1 (SHA1)", D. Eastlake, P. - Jones, September 2001. - - [Schneier] - "Applied Cryptography Second Edition: protocols, - algorithms, and source code in C" (second edition), Bruce Schneier, - 1996, John Wiley and Sons, ISBN 0-471-11709-9. - - - - - - -D. Eastlake 3rd [Page 7] - - -INTERNET-DRAFT DSA Information in the DNS - - -Authors Address - - Donald E. Eastlake 3rd - Motorola Labortories - 155 Beaver Street - Milford, MA 01757 USA - - Telephone: +1-508-786-7554(w) - EMail: Donald.Eastlake@motorola.com - - - -Expiration and File Name - - This draft expires in September 2005. - - Its file name is draft-ietf-dnsext-rfc2536bis-dsa-05.txt. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -D. Eastlake 3rd [Page 8] - - diff --git a/doc/draft/draft-ietf-dnsext-rfc2538bis-01.txt b/doc/draft/draft-ietf-dnsext-rfc2538bis-01.txt deleted file mode 100644 index 0d0451ace15..00000000000 --- a/doc/draft/draft-ietf-dnsext-rfc2538bis-01.txt +++ /dev/null @@ -1,785 +0,0 @@ - - -Network Working Group S. Josefsson -Internet-Draft January 2005 -Expires: July 2, 2005 - - - Storing Certificates in the Domain Name System (DNS) - draft-ietf-dnsext-rfc2538bis-01 - -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 July 2, 2005. - -Copyright Notice - - Copyright (C) The Internet Society (2005). - -Abstract - - Cryptographic public key are frequently published and their - authenticity demonstrated by certificates. A CERT resource record - (RR) is defined so that such certificates and related certificate - revocation lists can be stored in the Domain Name System (DNS). - - - - - - - -Josefsson Expires July 2, 2005 [Page 1] - -Internet-Draft Storing Certificates in the DNS January 2005 - - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 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 . . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . 14 - - - - - - - - - - - - - - - - - - - - - - - - - - - -Josefsson Expires July 2, 2005 [Page 2] - -Internet-Draft Storing Certificates in the DNS January 2005 - - -1. Introduction - - Public keys are frequently published in the form of a certificate and - their authenticity is commonly demonstrated by certificates and - related certificate revocation lists (CRLs). A certificate is a - binding, through a cryptographic digital signature, of a public key, - a validity interval and/or conditions, and identity, authorization, - or other information. A certificate revocation list is a list of - certificates that are revoked, and incidental information, all signed - by the signer (issuer) of the revoked certificates. Examples are - X.509 certificates/CRLs in the X.500 directory system or OpenPGP - certificates/revocations used by OpenPGP software. - - Section 2 below specifies a CERT resource record (RR) for the storage - of certificates in the Domain Name System. - - Section 3 discusses appropriate owner names for CERT RRs. - - Sections 4, 5, and 6 below cover performance, IANA, and security - considerations, respectively. - - 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 [10]. - -2. The CERT Resource Record - - The CERT resource record (RR) has the structure given below. Its RR - type code is 37. - - 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 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | type | key tag | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | algorithm | / - +---------------+ certificate or CRL / - / / - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| - - The type field is the certificate type as define in section 2.1 - below. - - The algorithm field has the same meaning as the algorithm field in - DNSKEY and RRSIG RRs [9] except that a zero algorithm field indicates - the algorithm is unknown to a secure DNS, which may simply be the - result of the algorithm not having been standardized for DNSSEC. - - - - -Josefsson Expires July 2, 2005 [Page 3] - -Internet-Draft Storing Certificates in the DNS January 2005 - - - The key tag field is the 16 bit value computed for the key embedded - in the certificate, using the RRSIG Key Tag Algorithm described in - Appendix B of [9]. This field is used as an efficiency measure to - pick which CERT RRs may be applicable to a particular key. The key - tag can be calculated for the key in question and then only CERT RRs - with the same key tag need be examined. However, the key must always - be transformed to the format it would have as the public key portion - of a DNSKEY RR before the key tag is computed. This is only possible - if the key is applicable to an algorithm (and limits such as key size - limits) defined for DNS security. If it is not, the algorithm field - MUST BE zero and the tag field is meaningless and SHOULD BE zero. - -2.1 Certificate Type Values - - The following values are defined or reserved: - - Value Mnemonic Certificate Type - ----- -------- ----------- ---- - 0 reserved - 1 PKIX X.509 as per PKIX - 2 SPKI SPKI certificate - 3 PGP OpenPGP packet - 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 - 65535 reserved - - The PKIX type is reserved to indicate an X.509 certificate conforming - to the profile being defined by the IETF PKIX working group. The - certificate section will start with a one byte unsigned OID length - and then an X.500 OID indicating the nature of the remainder of the - certificate section (see 2.3 below). (NOTE: X.509 certificates do - not include their X.500 directory type designating OID as a prefix.) - - The SPKI type is reserved to indicate a certificate formated as to be - specified by the IETF SPKI working group. - - The PGP type indicates an OpenPGP packet as described in [5] and its - extensions and successors. Two uses are to transfer public key - material and revocation signatures. The data is binary, and MUST NOT - be encoded into an ASCII armor. An implementation SHOULD process - transferable public keys as described in section 10.1 of [5], but it - MAY handle additional OpenPGP packets. - - - - -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 - equality but can use various forms of pattern matching so that, for - example, subtype or version information can also be encoded into the - URI. - - The OID private type indicates a private format certificate specified - by a an ISO OID prefix. The certificate section will start with a - one byte unsigned OID length and then a BER encoded OID indicating - the nature of the remainder of the certificate section. This can be - an X.509 certificate format or some other format. X.509 certificates - that conform to the IETF PKIX profile SHOULD be indicated by the PKIX - type, not the OID private type. Recognition of private certificate - types need not be based on OID equality but can use various forms of - pattern matching such as OID prefix. - -2.2 Text Representation of CERT RRs - - The RDATA portion of a CERT RR has the type field as an unsigned - decimal integer or as a mnemonic symbol as listed in section 2.1 - above. - - The key tag field is represented as an unsigned decimal integer. - - The algorithm field is represented as an unsigned decimal integer or - a mnemonic symbol as listed in [9]. - - The certificate / CRL portion is represented in base 64 [11] and may - be divided up into any number of white space separated substrings, - down to single base 64 digits, which are concatenated to obtain the - full signature. These substrings can span lines using the standard - parenthesis. - - 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. - -2.3 X.509 OIDs - - OIDs have been defined in connection with the X.500 directory for - user certificates, certification authority certificates, revocations - of certification authority, and revocations of user certificates. - The following table lists the OIDs, their BER encoding, and their - length prefixed hex format for use in CERT RRs: - - id-at-userCertificate - = { joint-iso-ccitt(2) ds(5) at(4) 36 } - == 0x 03 55 04 24 - id-at-cACertificate - = { joint-iso-ccitt(2) ds(5) at(4) 37 } - == 0x 03 55 04 25 - id-at-authorityRevocationList - = { joint-iso-ccitt(2) ds(5) at(4) 38 } - == 0x 03 55 04 26 - id-at-certificateRevocationList - = { joint-iso-ccitt(2) ds(5) at(4) 39 } - == 0x 03 55 04 27 - - -3. Appropriate Owner Names for CERT RRs - - It is recommended that certificate CERT RRs be stored under a domain - name related to their subject, i.e., the name of the entity intended - to control the private key corresponding to the public key being - certified. It is recommended that certificate revocation list CERT - RRs be stored under a domain name related to their issuer. - - Following some of the guidelines below may result in the use in DNS - names of characters that require DNS quoting which is to use a - backslash followed by the octal representation of the ASCII code for - the character such as \000 for NULL. - - The choice of name under which CERT RRs are stored is important to - clients that perform CERT queries. In some situations, the client - may not know all information about the CERT RR object it wishes to - retrieve. For example, a client may not know the subject name of an - X.509 certificate, or the e-mail address of the owner of an OpenPGP - 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 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 - selected to be a name that clients that wishes to retrieve CERT RRs - are expected to know; for example the host name of a X.509 protected - service or a Key ID of an OpenPGP key. Note that in some situations, - the content-based and purpose-based owner name can be the same; for - example when a client look up keys based on e-mail addresses for - incoming e-mail. - - Implementations SHOULD use the purpose-based owner name guidelines - described in this document, and MAY use CNAMEs at content-based owner - names (or other names), pointing to the purpose-based owner name. - -3.1 Content-based X.509 CERT RR Names - - Some X.509 versions permit multiple names to be associated with - subjects and issuers under "Subject Alternate Name" and "Issuer - Alternate Name". For example, x.509v3 has such Alternate Names with - an ASN.1 specification as follows: - - GeneralName ::= CHOICE { - otherName [0] INSTANCE OF OTHER-NAME, - rfc822Name [1] IA5String, - dNSName [2] IA5String, - x400Address [3] EXPLICIT OR-ADDRESS.&Type, - directoryName [4] EXPLICIT Name, - ediPartyName [5] EDIPartyName, - uniformResourceIdentifier [6] IA5String, - iPAddress [7] OCTET STRING, - registeredID [8] OBJECT IDENTIFIER - } - - The recommended locations of CERT storage are as follows, in priority - order: - 1. If a domain name is included in the identification in the - certificate or CRL, that should be used. - 2. If a domain name is not included but an IP address is included, - then the translation of that IP address into the appropriate - inverse domain name should be used. - 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 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- - doe.com, and (c) uri . Then - the storage locations recommended, in priority order, would be - 1. john-doe.com, - 2. www.secure.john-doe.com, and - 3. Doe.com.xy. - - 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 - of (a) domain name widget.foo.example, (b) IPv4 address - 10.251.13.201, and (c) string "James Hacker - ". Then the storage locations - recommended, in priority order, would be - 1. widget.foo.example, - 2. 201.13.251.10.in-addr.arpa, and - 3. hacker.mail.widget.foo.example. - -3.2 Purpose-based X.509 CERT RR Names - - It is difficult for clients that do not already posses a certificate - to reconstruct the content-based owner name that should be used to - retrieve the certificate. For this reason, purpose-based owner names - are recommended in this section. Because purpose-based owner names - by nature depend on the specific scenario, or purpose, for which the - certificate will be used, there are more than one recommendation. - The following table summarize the purpose-based X.509 CERT RR owner - name guidelines. - - Scenario Owner name - ------------------------------------------------------------------- - S/MIME Certificate Standard translation of RFC 822 email address. - Example: A S/MIME certificate for - "postmaster@example.org" will use a standard - hostname translation of the owner name, - i.e. "postmaster.example.org". - - SSL Certificate Hostname of the SSL server. - - IPSEC Certificate Hostname of the IPSEC machine, and/or - for the in-addr.arpa reverse lookup IP address. - - 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 - should be under the standard translation of the email address into a - domain name, which would be leslie.host.example in this case. If no - RFC 2822 name can be extracted from the string name no specific - domain name is recommended. - - 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: - - $ORIGIN example.org. - smith IN CERT PGP 0 0 - john.smith IN CNAME smith - js IN CNAME smith - - -3.4 Purpose-based OpenPGP CERT RR Names - - 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 ... - F835EDA21E94B565716F IN CERT PGP ... - B565716F IN CERT PGP ... - - If the same key material is stored at several owner names, the use of - CNAME may be used to avoid data duplication. Note that CNAME is not - always applicable, because it map an owner names to the other for all - 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 - advisable at this time to make every reasonable effort to minimize - the size of certificates stored within the DNS. Steps that can be - taken may include using the fewest possible optional or extensions - fields and using short field values for variable length fields that - must be included. - - The RDATA field in the DNS protocol may only hold data of size 65535 - 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 - address this by defining "indirect" data types for each normal type. - -5. Acknowledgements - - The majority of this document is copied verbatim from RFC 2538, by - Donald Eastlake 3rd and Olafur Gudmundsson. - - The author wishes to thank David Shaw and Michael Graff for their - contributions to the earlier work that motivated this revised - document. - - 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 - - By definition, certificates contain their own authenticating - signature. Thus it is reasonable to store certificates in non-secure - DNS zones or to retrieve certificates from DNS with DNS security - checking not implemented or deferred for efficiency. The results MAY - be trusted if the certificate chain is verified back to a known - trusted key and this conforms with the user's security policy. - - Alternatively, if certificates are retrieved from a secure DNS zone - with DNS security checking enabled and are verified by DNS security, - the key within the retrieved certificate MAY be trusted without - verifying the certificate chain if this conforms with the user's - security policy. - - 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. - - - - -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 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. - -8. Changes since RFC 2538 - - 1. Editorial changes to conform with new document requirements, - including splitting reference section into two parts and updating - the references to point at latest versions, and to add some - additional references. - 2. Improve terminology. For example replace "PGP" with "OpenPGP", - to align with RFC 2440. - 3. In section 2.1, clarify that OpenPGP public key data are binary, - not the ASCII armored format, and reference 10.1 in RFC 2440 on - how to deal with OpenPGP keys, and acknowledge that - implementations may handle additional packet types. - 4. Clarify that integers in the representation format are decimal. - 5. Replace KEY/SIG with DNSKEY/RRSIG etc, to align with DNSSECbis - terminology. Improve reference for Key Tag Algorithm - calculations. - 6. Add examples that suggest use of CNAME to reduce bandwidth. - 7. In section 3, appended the last paragraphs that discuss - "content-based" vs "purpose-based" owner names. Add section 3.2 - 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 - -9.1 Normative References - - [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. - - [3] Kille, S., Wahl, M., Grimstad, A., Huber, R. and S. Sataluri, - "Using Domains in LDAP/X.500 Distinguished Names", RFC 2247, - January 1998. - - [4] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource - Identifiers (URI): Generic Syntax", RFC 2396, August 1998. - - [5] Callas, J., Donnerhacke, L., Finney, H. and R. Thayer, "OpenPGP - Message Format", RFC 2440, November 1998. - - [6] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA - Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. - - [7] Resnick, P., "Internet Message Format", RFC 2822, April 2001. - - [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 - 2004. - - [9] Arends, R., "Resource Records for the DNS Security Extensions", - draft-ietf-dnsext-dnssec-records-11 (work in progress), October - 2004. - -9.2 Informative References - - [10] Bradner, S., "Key words for use in RFCs to Indicate Requirement - Levels", BCP 14, RFC 2119, March 1997. - - [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 - - Simon Josefsson - - EMail: simon@josefsson.org - -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 - anyone to use, modify, and distribute it in any way that does not - diminish the rights of anyone else to use, modify, and distribute it, - provided that redistributed derivative works do not contain - misleading author or version information. Derivative works need not - be licensed under similar terms. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Josefsson Expires July 2, 2005 [Page 13] - -Internet-Draft Storing Certificates in the DNS January 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. - - - - -Josefsson Expires July 2, 2005 [Page 14] - - diff --git a/doc/draft/draft-ietf-dnsext-rfc2539bis-dhk-05.txt b/doc/draft/draft-ietf-dnsext-rfc2539bis-dhk-05.txt deleted file mode 100644 index 1ce669c9b14..00000000000 --- a/doc/draft/draft-ietf-dnsext-rfc2539bis-dhk-05.txt +++ /dev/null @@ -1,581 +0,0 @@ - -INTERNET-DRAFT Diffie-Hellman Information in the DNS -OBSOLETES: RFC 2539 Donald E. Eastlake 3rd - Motorola Laboratories -Expires: September 2005 March 2005 - - - - - Storage of Diffie-Hellman Keying Information in the DNS - ------- -- -------------- ------ ----------- -- --- --- - - - - -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 DNS extensions working group mailing list - . - - 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 - - -Abstract - - The standard method for encoding Diffie-Hellman keys in the Domain - Name System is specified. - - - -Copyright - - Copyright (C) The Internet Society 2005. - - - -D. Eastlake 3rd [Page 1] - - -INTERNET-DRAFT Diffie-Hellman Information in the DNS - - -Acknowledgements - - Part of the format for Diffie-Hellman keys and the description - thereof was taken from a work in progress by Ashar Aziz, Tom Markson, - and Hemma Prafullchandra. In addition, the following persons - provided useful comments that were incorporated into the predecessor - of this document: Ran Atkinson, Thomas Narten. - - - -Table of Contents - - Status of This Document....................................1 - Abstract...................................................1 - Copyright..................................................1 - - Acknowledgements...........................................2 - Table of Contents..........................................2 - - 1. Introduction............................................3 - 1.1 About This Document....................................3 - 1.2 About Diffie-Hellman...................................3 - 2. Encoding Diffie-Hellman Keying Information..............4 - 3. Performance Considerations..............................5 - 4. IANA Considerations.....................................5 - 5. Security Considerations.................................5 - Copyright and Disclaimer...................................5 - - Normative References.......................................7 - Informative Refences.......................................7 - Author Address.............................................7 - Expiration and File Name...................................8 - - Appendix A: Well known prime/generator pairs...............9 - A.1. Well-Known Group 1: A 768 bit prime..................9 - A.2. Well-Known Group 2: A 1024 bit prime.................9 - A.3. Well-Known Group 3: A 1536 bit prime................10 - - - - - - - - - - - - - - - -D. Eastlake 3rd [Page 2] - - -INTERNET-DRAFT Diffie-Hellman Information in the DNS - - -1. Introduction - - The Domain Name System (DNS) is the global hierarchical replicated - distributed database system for Internet addressing, mail proxy, and - similar information [RFC 1034, 1035]. The DNS has been extended to - include digital signatures and cryptographic keys as described in - [RFC intro, proto, records] and additonal work is underway which - would use the storage of keying information in the DNS. - - - -1.1 About This Document - - This document describes how to store Diffie-Hellman keys in the DNS. - Familiarity with the Diffie-Hellman key exchange algorithm is assumed - [Schneier, RFC 2631]. - - - -1.2 About Diffie-Hellman - - Diffie-Hellman requires two parties to interact to derive keying - information which can then be used for authentication. Thus Diffie- - Hellman is inherently a key agreement algorithm. As a result, no - format is defined for Diffie-Hellman "signature information". For - example, assume that two parties have local secrets "i" and "j". - Assume they each respectively calculate X and Y as follows: - - X = g**i ( mod p ) - - Y = g**j ( mod p ) - - They exchange these quantities and then each calculates a Z as - follows: - - Zi = Y**i ( mod p ) - - Zj = X**j ( mod p ) - - Zi and Zj will both be equal to g**(i*j)(mod p) and will be a shared - secret between the two parties that an adversary who does not know i - or j will not be able to learn from the exchanged messages (unless - the adversary can derive i or j by performing a discrete logarithm - mod p which is hard for strong p and g). - - The private key for each party is their secret i (or j). The public - key is the pair p and g, which must be the same for the parties, and - their individual X (or Y). - - For further information about Diffie-Hellman and precautions to take - - -D. Eastlake 3rd [Page 3] - - -INTERNET-DRAFT Diffie-Hellman Information in the DNS - - - in deciding on a p and g, see [RFC 2631]. - - - -2. Encoding Diffie-Hellman Keying Information - - When Diffie-Hellman keys appear within the RDATA portion of a RR, - they are encoded as shown below. - - The period of key validity is not included in this data but is - indicated separately, for example by an RR such as RRSIG which signs - and authenticates the RR containing the keying information. - - 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 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | KEY flags | protocol | algorithm=2 | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | prime length (or flag) | prime (p) (or special) / - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - / prime (p) (variable length) | generator length | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | generator (g) (variable length) | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | public value length | public value (variable length)/ - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - / public value (g^i mod p) (variable length) | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - Prime length is the length of the Diffie-Hellman prime (p) in bytes - if it is 16 or greater. Prime contains the binary representation of - the Diffie-Hellman prime with most significant byte first (i.e., in - network order). If "prime length" field is 1 or 2, then the "prime" - field is actually an unsigned index into a table of 65,536 - prime/generator pairs and the generator length SHOULD be zero. See - Appedix A for defined table entries and Section 4 for information on - allocating additional table entries. The meaning of a zero or 3 - through 15 value for "prime length" is reserved. - - Generator length is the length of the generator (g) in bytes. - Generator is the binary representation of generator with most - significant byte first. PublicValueLen is the Length of the Public - Value (g**i (mod p)) in bytes. PublicValue is the binary - representation of the DH public value with most significant byte - first. - - - - - - - -D. Eastlake 3rd [Page 4] - - -INTERNET-DRAFT Diffie-Hellman Information in the DNS - - -3. Performance Considerations - - Current DNS implementations are optimized for small transfers, - typically less than 512 bytes including DNS overhead. Larger - transfers will perform correctly and extensions have been - standardized [RFC 2671] to make larger transfers more efficient. But - it is still advisable at this time to make reasonable efforts to - minimize the size of RR sets containing keying information consistent - with adequate security. - - - -4. IANA Considerations - - Assignment of meaning to Prime Lengths of 0 and 3 through 15 requires - an IETF consensus as defined in [RFC 2434]. - - Well known prime/generator pairs number 0x0000 through 0x07FF can - only be assigned by an IETF standards action. [RFC 2539], the - Proposed Standard predecessor of this document, assigned 0x0001 - through 0x0002. This document additionally assigns 0x0003. Pairs - number 0s0800 through 0xBFFF can be assigned based on RFC - documentation. Pairs number 0xC000 through 0xFFFF are available for - private use and are not centrally coordinated. Use of such private - pairs outside of a closed environment may result in conflicts and/or - security failures. - - - -5. Security Considerations - - Keying information retrieved from the DNS should not be trusted - unless (1) it has 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 important - and dependent on security policy. - - In addition, the usual Diffie-Hellman key strength considerations - apply. (p-1)/2 should also be prime, g should be primitive mod p, p - should be "large", etc. See [RFC 2631, Schneier]. - - - -Copyright 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. - - -D. Eastlake 3rd [Page 5] - - -INTERNET-DRAFT Diffie-Hellman Information in the DNS - - - 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. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -D. Eastlake 3rd [Page 6] - - -INTERNET-DRAFT Diffie-Hellman Information in the DNS - - -Normative References - - [RFC 2631] - "Diffie-Hellman Key Agreement Method", E. Rescorla, June - 1999. - - [RFC 2434] - "Guidelines for Writing an IANA Considerations Section - in RFCs", T. Narten, H. Alvestrand, 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. - - - -Informative Refences - - [RFC 1034] - "Domain names - concepts and facilities", P. - Mockapetris, November 1987. - - [RFC 1035] - "Domain names - implementation and specification", P. - Mockapetris, November 1987. - - [RFC 2539] - "Storage of Diffie-Hellman Keys in the Domain Name - System (DNS)", D. Eastlake, March 1999, obsoleted by this RFC. - - [RFC 2671] - "Extension Mechanisms for DNS (EDNS0)", P. Vixie, August - 1999. - - [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. - - [Schneier] - Bruce Schneier, "Applied Cryptography: Protocols, - Algorithms, and Source Code in C" (Second Edition), 1996, John Wiley - and Sons. - - - -Author Address - - Donald E. Eastlake 3rd - Motorola Laboratories - 155 Beaver Street - Milford, MA 01757 USA - - Telephone: +1-508-786-7554 - - -D. Eastlake 3rd [Page 7] - - -INTERNET-DRAFT Diffie-Hellman Information in the DNS - - - EMail: Donald.Eastlake@motorola.com - - - -Expiration and File Name - - This draft expires in September 2005. - - Its file name is draft-ietf-dnsext-rfc2539bis-dhk-05.txt. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -D. Eastlake 3rd [Page 8] - - -INTERNET-DRAFT Diffie-Hellman Information in the DNS - - -Appendix A: Well known prime/generator pairs - - These numbers are copied from the IPSEC effort where the derivation of - these values is more fully explained and additional information is - available. - Richard Schroeppel performed all the mathematical and computational - work for this appendix. - - - -A.1. Well-Known Group 1: A 768 bit prime - - The prime is 2^768 - 2^704 - 1 + 2^64 * { [2^638 pi] + 149686 }. Its - decimal value is - 155251809230070893513091813125848175563133404943451431320235 - 119490296623994910210725866945387659164244291000768028886422 - 915080371891804634263272761303128298374438082089019628850917 - 0691316593175367469551763119843371637221007210577919 - - Prime modulus: Length (32 bit words): 24, Data (hex): - FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 - 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD - EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245 - E485B576 625E7EC6 F44C42E9 A63A3620 FFFFFFFF FFFFFFFF - - Generator: Length (32 bit words): 1, Data (hex): 2 - - - -A.2. Well-Known Group 2: A 1024 bit prime - - The prime is 2^1024 - 2^960 - 1 + 2^64 * { [2^894 pi] + 129093 }. - Its decimal value is - 179769313486231590770839156793787453197860296048756011706444 - 423684197180216158519368947833795864925541502180565485980503 - 646440548199239100050792877003355816639229553136239076508735 - 759914822574862575007425302077447712589550957937778424442426 - 617334727629299387668709205606050270810842907692932019128194 - 467627007 - - Prime modulus: Length (32 bit words): 32, Data (hex): - FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 - 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD - EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245 - E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED - EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE65381 - FFFFFFFF FFFFFFFF - - Generator: Length (32 bit words): 1, Data (hex): 2 - - - -D. Eastlake 3rd [Page 9] - - -INTERNET-DRAFT Diffie-Hellman Information in the DNS - - -A.3. Well-Known Group 3: A 1536 bit prime - - The prime is 2^1536 - 2^1472 - 1 + 2^64 * { [2^1406 pi] + 741804 }. - Its decimal value is - 241031242692103258855207602219756607485695054850245994265411 - 694195810883168261222889009385826134161467322714147790401219 - 650364895705058263194273070680500922306273474534107340669624 - 601458936165977404102716924945320037872943417032584377865919 - 814376319377685986952408894019557734611984354530154704374720 - 774996976375008430892633929555996888245787241299381012913029 - 459299994792636526405928464720973038494721168143446471443848 - 8520940127459844288859336526896320919633919 - - Prime modulus Length (32 bit words): 48, Data (hex): - FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 - 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD - EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245 - E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED - EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE45B3D - C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8 FD24CF5F - 83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D - 670C354E 4ABC9804 F1746C08 CA237327 FFFFFFFF FFFFFFFF - - Generator: Length (32 bit words): 1, Data (hex): 2 - - - - - - - - - - - - - - - - - - - - - - - - - - - - -D. Eastlake 3rd [Page 10] - - diff --git a/doc/draft/draft-ietf-dnsext-trustupdate-timers-00.txt b/doc/draft/draft-ietf-dnsext-trustupdate-timers-00.txt deleted file mode 100644 index 32460b89b44..00000000000 --- a/doc/draft/draft-ietf-dnsext-trustupdate-timers-00.txt +++ /dev/null @@ -1,729 +0,0 @@ - - -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-03.txt b/doc/draft/draft-ietf-dnsext-tsig-sha-03.txt deleted file mode 100644 index cb3c44bd14a..00000000000 --- a/doc/draft/draft-ietf-dnsext-tsig-sha-03.txt +++ /dev/null @@ -1,582 +0,0 @@ - - -INTERNET-DRAFT Donald E. Eastlake 3rd -UPDATES RFC 2845 Motorola Laboratories -Expires: October 2005 April 2005 - - - HMAC SHA TSIG Algorithm Identifiers - ---- --- ---- --------- ----------- - - - -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. - - This draft is intended to be become a Proposed Standard RFC. - Distribution of this document is unlimited. Comments should be sent - to the DNSEXT working group mailing list . - - 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 - - -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 and implementation - requirements for additional HMAC SHA TSIG algorithms and standardizes - how to specify and handle the truncation of HMAC values. - - -Copyright Notice - - Copyright (C) The Internet Society 2005. All Rights Reserved. - - - - -D. Eastlake 3rd [Page 1] - - -INTERNET-DRAFT HMAC-SHA TSIG Identifiers - - -Table of Contents - - Status of This Document....................................1 - Abstract...................................................1 - Copyright Notice...........................................1 - - Table of Contents..........................................2 - - 1. Introduction............................................3 - - 2. Algorithms and Identifiers..............................4 - - 3. Specifying Truncation...................................5 - 3.1 Truncation Specification...............................5 - - 4. TSIG Policy Provisions and Truncation Error.............7 - - 5. IANA Considerations.....................................8 - 6. Security Considerations.................................8 - 6. Copyright and Disclaimer................................8 - - 7. Normative References....................................9 - 8. Informative References..................................9 - - Author's Address..........................................10 - Expiration and File Name..................................10 - - - - - - - - - - - - - - - - - - - - - - - - - - -D. Eastlake 3rd [Page 2] - - -INTERNET-DRAFT HMAC-SHA TSIG Identifiers - - -1. Introduction - - [RFC 2845] specifies a TSIG Resource Record (RR) that can be used to - authenticate DNS queries and responses. This RR contains a domain - name syntax data item which names the authentication algorithm used. - [RFC 2845] defines the HMAC-MD5.SIG-ALG.REG.INT name for - authentication codes using the HMAC [RFC 2104] algorithm with the MD5 - [RFC 1321] hash algorithm. IANA has also registered "gss-tsig" as an - identifier for TSIG authentication where the cryptographic operations - 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 - 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 - length of MAC (message authentication code) data given in the TSIG - RR. In particular, it specifies that a shorter length field value - specifies truncation and a longer length field is an error. - - In Section 4, policy restrictions and implications related to - truncation and a new error code to indicate truncation shorter than - permitted by policy are described and specified. - - The use herein of MUST, SHOULD, MAY, MUST NOT, and SHOULD NOT is as - defined in [RFC 2119]. - - - - - - - - - - - - - - - - - - - - - - - - - -D. Eastlake 3rd [Page 3] - - -INTERNET-DRAFT HMAC-SHA TSIG Identifiers - - -2. Algorithms and Identifiers - - TSIG Resource Records (RRs) [RFC 2845] are used to authenticate DNS - queries and responses. They are intended to be efficient symmetric - authentication codes based on a shared secret. (Asymmetric signatures - can be provided using the SIG RR [RFC 2931]. In particular, SIG(0) - can be used for transaction signatures.) Used with a strong hash - function, HMAC [RFC 2104] provides a way to calculate such symmetric - authentication codes. The only specified HMAC based TSIG algorithm - identifier has been HMAC-MD5.SIG-ALG.REG.INT based on MD5 [RFC 1321]. - - 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 3874] with 224, 256, 384, and 512 - bits, may be preferred in some cases 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 and - truncations are acceptable subject to the restrication and guidelines - in Section 3 and 4 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 - Mandatory hmac-sha1 - Optional hmac-sha224 - Mandatory hmac-sha256 - Optional hamc-sha384 - Optional hmac-sha512 - - - - - - - - - - - - - - - - - - - -D. Eastlake 3rd [Page 4] - - -INTERNET-DRAFT HMAC-SHA TSIG Identifiers - - -3. Specifying Truncation - - When space is at a premium and the strength of the full length of an - HMAC is not needed, it is reasonable to truncate the HMAC output and - use the truncated value for authentication. HMAC SHA-1 truncated to - 96 bits is an option available in several IETF protocols including - IPSEC and TLS. - - The TSIG RR [RFC 2845] includes a "MAC size" field, which gives the - size of the MAC field in octets. But [RFC 2845] does not specify what - to do if this MAC size differs from the length of the output of HMAC - for a particular hash function. Truncation is indicated by a MAC size - less than the HMAC size as specified below. - - - -3.1 Truncation Specification - - The specification for TSIG handling is changed as follows: - - 1. If "MAC size" field is greater than HMAC output length: - This case MUST NOT be generated and if received MUST cause the - packet to be dropped and RCODE 1 (FORMERR) to be returned. - - 2. If "MAC size" field equals HMAC output length: - Operation is as described in [RFC 2845] with the entire output - HMAC output present. - - 3. "MAC size" field is less than HMAC output length but greater than - that specified in case 4 below: - This is sent when the signer has truncated the HMAC output to - an allowable length, as described in RFC 2104, taking initial - octets and discarding trailing octets. TSIG truncation can only be - to an integral number of octets. On receipt of a packet with - truncation thus indicated, the locally calculated MAC is similarly - truncated and only the truncated values compared for - authentication. The request MAC used when calculating the TSIG MAC - for a reply is the trucated request MAC. - - 4. "MAC size" field is less than the larger of 10 (octets) and half - the length of the hash function in use: - With the exception of certain TSIG error messages described in - RFC 2845 section 3.2 where it is permitted that the MAC size be - zero, this case MUST NOT be generated and if received MUST cause - the packet to be dropped and RCODE 1 (FORMERR) to be returned. The - size limit for this case can also, for the hash functions - mentioned in this document, be stated as less than half the hash - function length for hash functions other than MD5 and less than 10 - octets for MD5. - - - -D. Eastlake 3rd [Page 5] - - -INTERNET-DRAFT HMAC-SHA TSIG Identifiers - - - SHA-1 truncated to 96 bits (12 octets) SHOULD be implemented. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -D. Eastlake 3rd [Page 6] - - -INTERNET-DRAFT HMAC-SHA TSIG Identifiers - - -4. TSIG Policy Provisions and Truncation Error - - Use of TSIG is by mutual agreement between a resolver and server. - Implicit in such "agreement" are policies as to acceptable keys and - algorithms and, with the extensions in this doucment, truncations. In - particular note the following: - - Such policies MAY require the rejection of TSIGs even though they - use an algorithm for which implementation is mandatory. - - When a policy calls for the acceptance of a TSIG with a particular - algorithm and a particular non-zero amount of trunction it SHOULD - also permit the use of that algorithm with lesser truncation (a - longer MAC) up to the full HMAC output. - - Regardless of a lower acceptable truncated MAC length specified by - policy, a reply SHOULD be sent with a MAC at least as long as that in - the corresponding request unless the request specified a MAC length - longer than the HMAC output. - - Implementations permitting policies with multiple acceptable - algorithms and/or truncations SHOULD permit this list to be ordered - by presumed strength and SHOULD allow different truncations for the - same algorithm to be treatred as spearate entities in this list. When - so implemented, policies SHOULD accept a presumed stronger algorithm - and truncation than the minimum strength required by the policy. - - If a TSIG is received with truncation which is permitted under - Section 3 above but the MAC is too short for the policy in force, an - RCODE of TBA [22 suggested](BADTRUNC) MUST be returned. - - - - - - - - - - - - - - - - - - - - - - -D. Eastlake 3rd [Page 7] - - -INTERNET-DRAFT HMAC-SHA TSIG Identifiers - - -5. IANA Considerations - - This document, on approval for publication as a standards track RFC, - (1) registers the new TSIG algorithm identifiers listed in Section 2 - with IANA and (2) Section 4 allocates the BADTRUNC RCODE TBA [22 - suggested]. - - - - -6. Security Considerations - - For all of the message authentication code algorithms listed herein, - those producing longer values are believed to be stronger; however, - while there have been some arguments that mild truncation can - strengthen a 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 brute force - [RFC 2104]. - - Significant progress has been made recently in cryptanalysis of hash - function of the type used herein, all of which ultimately derive from - the design of MD4. 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] from which - the limits on truncation in this RFC were taken. - - - -6. Copyright 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. - - - - - - - -D. Eastlake 3rd [Page 8] - - -INTERNET-DRAFT HMAC-SHA TSIG Identifiers - - -7. Normative References - - [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. - - [RFC 2104] - Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- - Hashing for Message Authentication", RFC 2104, February 1997. - - [RFC 2119] - Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [RFC 2845] - Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B. - Wellington, "Secret Key Transaction Authentication for DNS (TSIG)", - RFC 2845, May 2000. - - - -8. Informative References. - - [RFC 2931] - Eastlake 3rd, D., "DNS Request and Transaction - Signatures ( SIG(0)s )", RFC 2931, September 2000. - - [RFC 3174] - Eastlake 3rd, D. and P. Jones, "US Secure Hash Algorithm - 1 (SHA1)", RFC 3174, September 2001. - - [RFC 3645] - Kwan, S., Garg, P., Gilroy, J., Esibov, L., Westhead, - J., and R. Hall, "Generic Security Service Algorithm for Secret Key - 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, - - - - - - - - - - - - - - - - -D. Eastlake 3rd [Page 9] - - -INTERNET-DRAFT HMAC-SHA TSIG Identifiers - - -Author's Address - - Donald E. Eastlake 3rd - Motorola Laboratories - 155 Beaver Street - Milford, MA 01757 USA - - Telephone: +1-508-786-7554 (w) - - EMail: Donald.Eastlake@motorola.com - - - -Expiration and File Name - - This draft expires in October 2005. - - Its file name is draft-ietf-dnsext-tsig-sha-03.txt - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -D. Eastlake 3rd [Page 10] - - diff --git a/doc/draft/draft-ietf-dnsext-wcard-clarify-07.txt b/doc/draft/draft-ietf-dnsext-wcard-clarify-07.txt deleted file mode 100644 index 7f6f5a818bc..00000000000 --- a/doc/draft/draft-ietf-dnsext-wcard-clarify-07.txt +++ /dev/null @@ -1,861 +0,0 @@ -DNSEXT Working Group E. Lewis -INTERNET DRAFT NeuStar -Expiration Date: November 16, 2005 May 16, 2005 - - The Role of Wildcards - in the Domain Name System - draft-ietf-dnsext-wcard-clarify-07.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 - BCP 79. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as Internet- - Drafts. - - Internet-Drafts are draft documents valid for a maximum of six - months and may be updated, replaced, or obsoleted by other - documents at any time. It is inappropriate to use Internet-Drafts - as reference material or to cite them other than as "work in - progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html - - This Internet-Draft will expire on November 16, 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. - -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 [RFC4033]. 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 [...] -# 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 Describes 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 [...] -# the "*" label exists. - - To help describe the process of looking 'to see if [...] the "*" - label exists' a term has been coined to describe the last domain - (node) 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 to be 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 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 - - With the definition of DNSSEC [RFC4033, RFC4034, RFC4035] now - in place, the semantics of a wild card domain name owning an - NS RR has come to be poorly defined. The dilemma relates to - a conflict between the rules for synthesis in part 'c' and the - fact that the resulting synthesis generates a record for which - the zone is not authoritative. In a DNSSEC signed zone, the - mechanics of signature management (generation and inclusion - in a message) become unclear. - - After some lengthy discussions, there has been no clear "best - answer" on how to document the semantics of such a situation. - Barring such records from the DNS would require definition of - rules for that, as well as introducing a restriction on records - that were once legal. Allowing such records and amending the - process of signature management would entail complicating the - DNSSEC definition. - - Combining these observations with thought that a wild card - domain name owning an NS record is an operationally uninteresting - scenario, i.e., it won't happen in the normal course of events, - accomodating this situation in the specification would also be - categorized as "needless complication." Further, expending more - effort on this topic has proven to be an exercise in diminishing - returns. - - In summary, there is no definition given for wild card domain - names owning an NS RRSet. The semantics are left undefined until - there is a clear need to have a set defined, and until there is - a clear direction to proceed. Operationally, inclusion of wild - card NS RRSets in a zone is discouraged, but not barred. - -4.3 CNAME RRSet at a Wild Card Domain Name - - The issue of a CNAME RRSet owned by a wild card domain name 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 - - Ownership of a DNAME RRSet by a wild card domain name - represents a threat to the coherency of the DNS and is to be - avoided or outright rejected. Such a DNAME RRSet represents - non-deterministic synthesis of rules fed to different caches. - As caches are fed the different rules (in an unpredictable - manner) the caches will cease to be coherent. ("As caches - are fed" refers to the storage in a cache of records obtained - in responses by recursive or iterative servers.) - - For example, assume one cache, responding to a recursive request, - obtains the record "a.b.example. DNAME foo.bar.tld." and another - cache obtains "b.example. DNAME foo.bar.tld.", both generated - from the record "*.example. DNAME foo.bar.tld." by an - authoritative server. - - The DNAME specification is not clear on whether DNAME records - in a cache are used to rewrite queries. In some interpretations, - the rewrite occurs, in some, it is not. Allowing for the - occurrence of rewriting, queries for "sub.a.b.example. A" may - be rewritten as "sub.foo.bar.tld. A" by the former caching - server and may be rewritten as "sub.a.foo.bar.tld. A" by the - latter. Coherency is lost, an operational nightmare ensues. - - Another justification for banning or avoiding wildcard DNAME - records is the observation that such a record could synthesize - a DNAME owned by "sub.foo.bar.example." and "foo.bar.example." - There is a restriction in the DNAME definition that no domain - exist below a DNAME-owning domain, hence, the wildcard DNAME - is not to be permitted. - -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 - - A DS RRSet owned by a wild card domain name is meaningless and - harmless. - -4.7 NSEC RRSet at a Wild Card Domain Name - - Wild card domain names in DNSSEC signed zones will have an NSEC - RRSet. Synthesis of these records will only occur when the - query exactly matches the record. Synthesized NSEC RR's will not - be harmful as they will never be used in negative caching or to - generate a negative response. - -4.8 RRSIG at a Wild Card Domain Name - - RRSIG records will be present at a wild card domain name in a - signed zone, and will be synthesized along with data sought in a - query. The fact that the owner name is synthesized is not a - problem as the label count in the RRSIG will instruct the - verifying code to ignore it. - -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. IANA Considerations - - None. - -7. 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] Incremental Zone Transfer in DNS, M. Ohta, August 1996 - - [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 - - [RFC2308] Negative Caching of DNS Queries (DNS NCACHE), - M. Andrews, March 1998 - - [RFC2782] A DNS RR for specifying the location of services (DNS - SRV), A. Gulbrandsen, et.al., February 2000 - - [RFC4033] DNS Security Introduction and Requirements, R. Arends, - et.al., March 2005 - - [RFC4034] Resource Records for the DNS Security Extensions, - R. Arends, et.al., March 2005 - - [RFC4035] Protocol Modifications for the DNS Security Extensions, - R. Arends, et.al., March 2005 - - [RFC2672] Non-Terminal DNS Name Redirection, M. Crawford, - August 1999 - - Informative References - - [RFC2136] Dynamic Updates in the Domain Name System (DNS UPDATE), - P. Vixie, Ed., S. Thomson, Y. Rekhter, J. Bound, - April 1997 - -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. Others Contributing to the Document - - This document represents the work of a large working group. The - editor merely recorded the collective wisdom of the working group. - -10. Trailing Boilerplate - - 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. - -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 November 16, 2005. \ No newline at end of file diff --git a/doc/draft/draft-ietf-dnsop-bad-dns-res-03.txt b/doc/draft/draft-ietf-dnsop-bad-dns-res-03.txt deleted file mode 100644 index 9537af6534f..00000000000 --- a/doc/draft/draft-ietf-dnsop-bad-dns-res-03.txt +++ /dev/null @@ -1,1123 +0,0 @@ - - - -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-inaddr-required-06.txt b/doc/draft/draft-ietf-dnsop-inaddr-required-06.txt deleted file mode 100644 index 812440c7832..00000000000 --- a/doc/draft/draft-ietf-dnsop-inaddr-required-06.txt +++ /dev/null @@ -1,424 +0,0 @@ - -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-ipv6-dns-configuration-05.txt b/doc/draft/draft-ietf-dnsop-ipv6-dns-configuration-05.txt deleted file mode 100644 index ed63a23ddf3..00000000000 --- a/doc/draft/draft-ietf-dnsop-ipv6-dns-configuration-05.txt +++ /dev/null @@ -1,1427 +0,0 @@ -DNS Operations WG -Internet-Draft J. Jeong (ed.) - ETRI/University of Minnesota - -Expires: August 2005 19 February 2005 - - - IPv6 Host Configuration of DNS Server Information Approaches - draft-ietf-dnsop-ipv6-dns-configuration-05.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/1id-abstracts.html - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html" - - This Internet-Draft will expire on August 19, 2005. - -Copyright Notice - - Copyright (C) The Internet Society (2005). All Rights Reserved. - -Abstract - - This document describes three approaches for IPv6 recursive DNS - server address configuration. It details the operational - attributes of three solutions: RA option, DHCPv6 option, and - Well-known anycast addresses for recursive DNS servers. - - - -Jeong, et al. Expires - August 2005 [Page 1] - -Internet-Draft IPv6 Host Configuration of DNS Server February 2005 - - - Additionally, it suggests four deployment scenarios considering - multi-solution resolution. Therefore, this document will give the - audience a guideline for IPv6 DNS configuration to select the - approaches suitable for their host DNS configuration. - -Table of Contents - - 1. Introduction...................................................3 - 2. Terminology....................................................3 - 3. IPv6 DNS Configuration Approaches..............................3 - 3.1. RA Option..................................................3 - 3.1.1. Advantages...........................................4 - 3.1.2. Disadvantages........................................5 - 3.1.3. Observations.........................................6 - 3.2. DHCPv6 Option..............................................6 - 3.2.1. Advantages...........................................8 - 3.2.2. Disadvantages........................................8 - 3.2.3. Observations.........................................9 - 3.3. Well-known Anycast Addresses...............................9 - 3.3.1. Advantages..........................................10 - 3.3.2. Disadvantages.......................................10 - 3.3.3. Observations........................................11 - 4. Interworking among IPv6 DNS Configuration Approaches..........11 - 5. Deployment Scenarios..........................................12 - 5.1. ISP Network...............................................13 - 5.1.1. RA Option Approach..................................13 - 5.1.2. DHCPv6 Option Approach..............................13 - 5.1.3. Well-known Addresses Approach.......................14 - 5.2. Enterprise Network........................................14 - 5.3. 3GPP Network..............................................15 - 5.3.1. Currently Available Mechanisms and Recommendations..15 - 5.3.2. RA Extension........................................16 - 5.3.3. Stateless DHCPv6....................................17 - 5.3.4. Well-known Addresses................................18 - 5.3.5. Recommendations.....................................18 - 5.4. Unmanaged Network.........................................18 - 5.4.1. Case A: Gateway does not provide IPv6 at all........18 - 5.4.2. Case B: A dual-stack gateway connected to a dual-stack - ISP.................................................19 - 5.4.3. Case C: A dual-stack gateway connected to an IPv4-only - ISP.................................................19 - 5.4.4. Case D: A gateway connected to an IPv6-only ISP.....19 - 6. Security Considerations.......................................19 - 7. Acknowledgements..............................................20 - 8. Normative References..........................................20 - 9. Informative References........................................21 - 10. Appendix A - Link-layer Multicast Acknowledgements with RA - Option.......................................................23 - - -Jeong, et al. Expires - August 2005 [Page 2] - -Internet-Draft IPv6 Host Configuration of DNS Server February 2005 - - - 11. Authors' Addresses...........................................23 - 12. Intellectual Property Statement..............................25 - 13. Full Copyright Statement.....................................25 - Acknowledgement..................................................26 - -1. Introduction - - Neighbor Discovery (ND) for IP Version 6 and IPv6 Stateless Address - Autoconfiguration provide the ways to configure either fixed or - mobile nodes with one or more IPv6 addresses, default routes and - some other parameters [3][4]. To support the access to additional - services in the Internet that are identified by a DNS name, such as - a web server, the configuration of at least one recursive DNS - server is also needed for DNS name resolution. - - This document describes three approaches of recursive DNS server - address configuration for IPv6 host: (a) RA option [8], (b) DHCPv6 - option [5]-[7], and (c) Well-known anycast addresses for recursive - DNS servers [9]. Also, it suggests the applicable scenarios for - four kinds of networks: (a) ISP network, (b) Enterprise network, - (c) 3GPP network, and (d) Unmanaged network. - - This document is just an analysis of each possible approach, and - does not make any recommendation on particular one or on a - combination of particular ones. Some approaches may even not be - adopted at all as a result of further discussion. - - Therefore, the objective of this document is to help the audience - select the approaches suitable for IPv6 host configuration of - recursive DNS server. - -2. Terminology - - This document uses the terminology described in [3]-[9]. In - addition, a new term is defined below: - - Recursive DNS Server (RDNSS) A Recursive DNS Server is a name - server that offers the recursive - service of DNS name resolution. - -3. IPv6 DNS Configuration Approaches - - In this section, the operational attributes of three solutions are - described in detail. - -3.1. RA Option - - - - -Jeong, et al. Expires - August 2005 [Page 3] - -Internet-Draft IPv6 Host Configuration of DNS Server February 2005 - - - RA approach is to define a new ND option called RDNSS option that - contains a recursive DNS server address. Existing ND transport - mechanisms (i.e., advertisements and solicitations) are used. This - works in the same way that nodes learn about routers and prefixes. - An IPv6 host can configure the IPv6 addresses of one or more - RDNSSes via RA message periodically sent by router or solicited by - a Router Solicitation (RS) [8]. - - This approach needs RDNSS information to be configured in the - routers doing the advertisements. The configuration of RDNSS - address can be performed manually by operator or other ways, such - as automatic configuration through DHCPv6 client running on the - router. When advertising more than one RDNSS option, an RA message - includes as many RDNSS options as RDNSSes. - - Through ND protocol and RDNSS option along with prefix information - option, an IPv6 host can perform its network configuration of its - IPv6 address and RDNSS simultaneously [3][4]. The RA option for - RDNSS can be used on any network that supports the use of ND. - - However, it is worth noting that some link layers (e.g., WLAN) need - to acknowledge multicast packets, which may increase the amount of - link-layer traffic [25]-[28]. This is discussed in Appendix A. - - The RA approach is useful in some mobile environments where the - addresses of the RDNSSes are changing because the RA option - includes a lifetime field that allows client to use RDNSSes nearer - to the client. This can be configured to a value that will require - the client to time out the entry and switch over to another RDNSS - address [8]. However, from the viewpoint of implementation, the - lifetime would seem to make matters a bit more complex. Instead of - just writing DNS configuration file, such as resolv.conf for the - list of RDNSS addresses, we have to have a daemon around (or a - program that is called at the defined intervals) that keeps - monitoring the lifetime of RDNSSes all the time. - - The preference value of RDNSS, included in RDNSS option, allows - IPv6 hosts to select primary RDNSS among several RDNSSes; this can - be used for load balancing of RDNSSes [8]. - -3.1.1. Advantages - - The RA option for RDNSS has a number of advantages. These include: - - 1) The RA option is an extension of existing ND/Autoconfig - mechanisms [3][4], and does not require a change in the base ND - protocol. - - - -Jeong, et al. Expires - August 2005 [Page 4] - -Internet-Draft IPv6 Host Configuration of DNS Server February 2005 - - - 2) This approach, like ND, works well on a variety of link types - including point-to-point links, point-to-multipoint, and - multi-point (i.e., Ethernet LANs), etc. RFC2461 [3] states, - however, that there may be some link types on which ND is not - possible; on such links, some other mechanisms will be needed for - DNS configuration. - - 3) All of the information a host needs to run the basic Internet - applications such as the email, web, ftp, etc., can be obtained - with the addition of this option to ND and address autoconfiguration - The use of a single mechanism is more reliable and easier to provide - than when the RDNSS information is learned via another protocol - mechanism. Debugging problems when multiple protocol mechanisms are - being used is harder and much more complex. - - 4) This mechanism works over a broad range of scenarios and - leverages IPv6 ND. This works well on links that support broadcast - reliably (e.g., Ethernet LANs) but not necessarily on other links - (e.g., Wireless LANs): Refer to Appendix A. Also, this works well - on links that are high performance (e.g., Ethernet LANs) and low - performance (e.g., Cellular networks). In the latter case, - combining the RDNSS information with the other information in the - RA, the host can learn all of the information needed to use most - Internet applications, such as the web in a single packet. This - not only saves bandwidth where this is an issue, but also minimizes - the delay needed to learn the RDNSS information. - - 5) The RA approach could be used as a model for other similar types - of configuration information. New RA options for other server - addresses, such as NTP server address, that are common to all - clients on a subnet would be easy to define. - -3.1.2. Disadvantages - - 1) ND is mostly implemented in the kernel part of operating system. - Therefore, if ND supports the configuration of some additional - services, such as DNS servers, ND should be extended in the kernel - part, and complemented by a user-land process. DHCPv6, however, - has more flexibility for the extension of service discovery because - it is an application layer protocol. - - 2) The current ND framework should be modified due to the - synchronization between another ND cache for RDNSSes in the kernel - space and the DNS configuration file in the user space. Because it - is unacceptable to write and rewrite the DNS configuration file - (e.g., resolv.conf) from the kernel, another approach is needed. - One simple approach to solve this is to have a daemon listening to - - - -Jeong, et al. Expires - August 2005 [Page 5] - -Internet-Draft IPv6 Host Configuration of DNS Server February 2005 - - - what the kernel conveys, and to have the daemon do these steps, but - such a daemon is not needed with the current ND framework. - - 3) It is necessary to configure RDNSS addresses at least at one - router on every link where this information needs to be configured - by RA option. - -3.1.3. Observations - - The proposed RDNSS RA option along with the IPv6 ND and - Autoconfiguration allows a host to obtain all of the information it - needs to access the basic Internet services like the web, email, - ftp, etc. This is preferable in the environments where hosts use - RAs to autoconfigure their addresses and all the hosts on the - subnet share the same router and server addresses. If the - configuration information can be obtained from a single mechanism, - it is preferable because it does not add additional delay, and it - uses a minimum of bandwidth. The environments like this include - the homes, public cellular networks, and enterprise environments - where no per host configuration is needed, but exclude public WLAN - hot spots. - - DHCPv6 is preferable where it is being used for address - configuration and if there is a need for host specific - configuration [5]-[7]. The environments like this are most likely - the enterprise environments where the local administration chooses - to have per host configuration control. - - Note: the observation section is based on what the proponents of - each approach think makes a good overall solution. - -3.2. DHCPv6 Option - - DHCPv6 [5] includes the "DNS Recursive Name Server" option, through - which a host can obtain a list of IP addresses of recursive DNS - servers [7]. The DNS Recursive Name Server option carries a list - of IPv6 addresses of RDNSSes to which the host may send DNS queries. - The DNS servers are listed in the order of preference for use by - the DNS resolver on the host. - - The DNS Recursive Name Server option can be carried in any DHCPv6 - Reply message, in response to either a Request or an Information - request message. Thus, the DNS Recursive Name Server option can be - used either when DHCPv6 is used for address assignment, or when - DHCPv6 is used only for other configuration information as - stateless DHCPv6 [6]. - - - - -Jeong, et al. Expires - August 2005 [Page 6] - -Internet-Draft IPv6 Host Configuration of DNS Server February 2005 - - - Stateless DHCPv6 can be deployed either using DHCPv6 servers - running on general-purpose computers, or on router hardware. - Several router vendors currently implement stateless DHCPv6 servers. - Deploying stateless DHCPv6 in routers has the advantage that no - special hardware is required, and should work well for networks - where DHCPv6 is needed for very straightforward configuration of - network devices. - - However, routers can also act as DHCPv6 relay agents. In this case, - the DHCPv6 server need not be on the router - it can be on a - general purpose computer. This has the potential to give the - operator of the DHCPv6 server more flexibility in how the DHCPv6 - server responds to individual clients - clients can easily be given - different configuration information based on their identity, or for - any other reason. Nothing precludes adding this flexibility to a - router, but generally in current practice, DHCP servers running on - general-purpose hosts tend to have more configuration options than - those that are embedded in routers. - - DHCPv6 currently provides a mechanism for reconfiguring DHCPv6 - clients that use stateful configuration assignment. To do this, - the DHCPv6 server sends a Reconfigure message to the client. The - client validates the Reconfigure message, and then contacts the - DHCPv6 server to obtain updated configuration information. Using - this mechanism, it is currently possible to propagate new - configuration information to DHCPv6 clients as this information - changes. - - The DHC Working Group is currently studying an additional mechanism - through which configuration information, including the list of - RDNSSes, can be updated. The lifetime option for DHCPv6 [10] - assigns a lifetime to configuration information obtained through - DHCPv6. At the expiration of the lifetime, the host contacts the - DHCPv6 server to obtain updated configuration information, - including the list of RDNSSes. This lifetime gives the network - administrator another mechanism to configure hosts with new RDNSSes - by controlling the time at which the host refreshes the list. - - The DHC Working Group has also discussed the possibility of - defining an extension to DHCPv6 that would allow the use of - multicast to provide configuration information to multiple hosts - with a single DHCPv6 message. Because of the lack of deployment - experience, the WG has deferred consideration of multicast DHCPv6 - configuration at this time. Experience with DHCPv4 has not - identified a requirement for multicast message delivery, even in - large service provider networks with tens of thousands of hosts - that may initiate a DHCPv4 message exchange simultaneously. - - - -Jeong, et al. Expires - August 2005 [Page 7] - -Internet-Draft IPv6 Host Configuration of DNS Server February 2005 - - -3.2.1. Advantages - - The DHCPv6 option for RDNSS has a number of advantages. These - include: - - 1) DHCPv6 currently provides a general mechanism for conveying - network configuration information to clients. So configuring - DHCPv6 servers allows the network administrator to configure - RDNSSes along with the addresses of other network services, as well - as location-specific information like time zones. - - 2) As a consequence, when the network administrator goes to - configure DHCPv6, all the configuration information can be managed - through a single service, typically with a single user interface - and a single configuration database. - - 3) DHCPv6 allows for the configuration of a host with information - specific to that host, so that hosts on the same link can be - configured with different RDNSSes as well as other configuration - information. This capability is important in some network - deployments such as service provider networks or WiFi hot spots. - - 4) A mechanism exists for extending DHCPv6 to support the - transmission of additional configuration that has not yet been - anticipated. - - 5) Hosts that require other configuration information such as the - addresses of SIP servers and NTP servers are likely to need DHCPv6 - for other configuration information. - - 6) The specification for configuration of RDNSSes through DHCPv6 is - available as an RFC. No new protocol extensions such as new - options are necessary. - - 7) Interoperability among independent implementations has been - demonstrated. - -3.2.2. Disadvantages - - The DHCPv6 option for RDNSS has a few disadvantages. These - include: - - 1) Update currently requires message from server (however, see - [10]). - - 2) Because DNS information is not contained in RA message, the host - must receive two messages from the router, and must transmit at - least one message to the router. On networks where bandwidth is at - - -Jeong, et al. Expires - August 2005 [Page 8] - -Internet-Draft IPv6 Host Configuration of DNS Server February 2005 - - - a premium, this is a disadvantage, although on most networks it is - not a practical concern. - - 3) Increased latency for initial configuration - in addition to - waiting for an RA message, the client must now exchange packets - with a DHCPv6 server; even if it is locally installed on a router, - this will slightly extend the time required to configure the client. - For clients that are moving rapidly from one network to another, - this will be a disadvantage. - -3.2.3. Observations - - In the general case, on general-purpose networks, stateless DHCPv6 - provides significant advantages and no significant disadvantages. - Even in the case where bandwidth is at a premium and low latency is - desired, if hosts require other configuration information in - addition to a list of RDNSSes or if hosts must be configured - selectively, those hosts will use DHCPv6 and the use of the DHCPv6 - DNS recursive name server option will be advantageous. - - However, we are aware of some applications where it would be - preferable to put the RDNSS information into an RA packet; for - example, on a cell phone network, where bandwidth is at a premium - and extremely low latency is desired. The final DNS configuration - draft should be written so as to allow these special applications - to be handled using DNS information in the RA packet. - -3.3. Well-known Anycast Addresses - - Anycast uses the same routing system as unicast [11]. However, - administrative entities are local ones. The local entities may - accept unicast routes (including default routes) to anycast servers - from adjacent entities. The administrative entities should not - advertise their peers routes to their internal anycast servers, if - they want to prohibit external access from some peers to the - servers. If some advertisement is inevitable (such as the case - with default routes), the packets to the servers should be blocked - at the boundary of the entities. Thus, for this anycast, not only - unicast routing but also unicast ND protocols can be used as is. - - First of all, the well-known anycast addresses approach is much - different from that discussed at IPv6 Working Group in the past [9]. - It should be noted that "anycast" in this memo is simpler than that - of RFC1546 [11] and RFC3513 [12] where it is assumed to be - prohibited to have multiple servers on a single link sharing an - anycast address. That is, on a link, anycast address is assumed to - be unique. DNS clients today already have redundancy by having - multiple well-known anycast addresses configured as RDNSS addresses. - - -Jeong, et al. Expires - August 2005 [Page 9] - -Internet-Draft IPv6 Host Configuration of DNS Server February 2005 - - - There is no point in having multiple RDNSSes sharing an anycast - address on a single link. - - The approach with well-known anycast addresses is to set multiple - well-known anycast addresses in clients' resolver configuration - files from the beginning, say, as factory default. Thus, there is - no transport mechanism and no packet format [9]. - - An anycast address is an address shared by multiple servers (in - this case, the servers are RDNSSes). Request from a client to the - anycast address is routed to a server selected by the routing - system. However, it is a bad idea to mandate "site" boundary on - anycast addresses, because most users just do not have their own - servers and want to access their ISPs' across their site boundaries. - Larger sites may also depend on their ISPs or may have their own - RDNSSes within "site" boundaries. - -3.3.1. Advantages - - The basic advantage of the well-known addresses approach is that it - uses no transport mechanism. Thus, - - 1) There is no delay to get the response and no further delay by - packet losses. - - 2) The approach can be combined with any other configuration - mechanisms, such as RA-based approach and DHCP based approach, as - well as factory default configuration. - - 3) The approach works over any environment where DNS works. - - Another advantage is that the approach needs to configure DNS - servers as a router, but nothing else. Considering that DNS - servers do need configuration, the amount of overall configuration - effort is proportional to the number of the DNS servers and scales - linearly. It should be noted that, in the simplest case where a - subscriber to an ISP does not have any DNS server, the subscriber - naturally accesses DNS servers of the ISP even though the - subscriber and the ISP do nothing and there is no protocol to - exchange DNS server information between the subscriber and the ISP. - -3.3.2. Disadvantages - - Well-known anycast addresses approach requires that DNS servers (or - routers near it as a proxy) act as routers to advertise their - anycast addresses to the routing system, which requires some - configuration (see the last paragraph of the previous section on - the scalability of the effort). - - -Jeong, et al. Expires - August 2005 [Page 10] - -Internet-Draft IPv6 Host Configuration of DNS Server February 2005 - - - -3.3.3. Observations - - If other approaches are used in addition, the well-known anycast - addresses should also be set in RA or DHCP configuration files to - reduce the configuration effort of users. - - The redundancy by multiple RDNSSes is better provided by multiple - servers having different anycast addresses than multiple servers - sharing the same anycast address because the former approach allows - stale servers to still generate routes to their anycast addresses. - Thus, in a routing domain (or domains sharing DNS servers), there - will be only one server having an anycast address unless the domain - is so large that load distribution is necessary. - - Small ISPs will operate one RDNSS at each anycast address which is - shared by all the subscribers. Large ISPs may operate multiple - RDNSSes at each anycast address to distribute and reduce load, - where boundary between RDNSSes may be fixed (redundancy is still - provided by multiple addresses) or change dynamically. DNS packets - with the well-known anycast addresses are not expected (though not - prohibited) to cross ISP boundaries, as ISPs are expected to be - able to take care of themselves. - - Because "anycast" in this memo is simpler than that of RFC1546 [11] - and RFC3513 [12] where it is assumed to be administratively - prohibited to have multiple servers on a single link sharing an - anycast address, anycast in this memo should be implemented as - UNICAST of RFC2461 [3] and RFC3513 [12]. As a result, ND-related - instability disappears. Thus, anycast in well-known anycast - addresses approach can and should use the anycast address as a - source unicast (according to RFC3513 [12]) address of packets of - UDP and TCP responses. With TCP, if route flips and packets to an - anycast address are routed to a new server, it is expected that the - flip is detected by ICMP or sequence number inconsistency and the - TCP connection is reset and retried. - -4. Interworking among IPv6 DNS Configuration Approaches - - Three approaches can work together for IPv6 host configuration of - RDNSS. This section shows a consideration on how these approaches - can interwork each other. - - For ordering between RA and DHCP approaches, O (Other stateful - configuration) flag in RA message can be used [8]. If no RDNSS - option is included, an IPv6 host may perform DNS configuration - through DHCPv6 [5]-[7] regardless of whether the O flag is set or - not. - - -Jeong, et al. Expires - August 2005 [Page 11] - -Internet-Draft IPv6 Host Configuration of DNS Server February 2005 - - - - The well-known anycast addresses approach fully interworks with the - other approaches. That is, the other approaches can remove the - configuration effort on servers by using the well-known addresses - as the default configuration. Moreover, the clients preconfigured - with the well-known anycast addresses can be further configured to - use other approaches to override the well-known addresses, if the - configuration information from other approaches are available. - That is, all the clients should have the well-known anycast - addresses preconfigured, in the case where there are no other - mechanisms available. In order to fly anycast approach with the - other solutions, there are three options as follows: - - 1) The first option is that well-known addresses are used as last - resort, when an IPv6 host can not get RDNSS information through RA - and DHCP. The well-known anycast addresses have to be preconfigured - in IPv6 hosts' resolver configuration files. - - 2) The second is that an IPv6 host can configure well-known - addresses as the most preferable in its configuration file even - though either RA option or DHCP option is available. - - 3) The last is that the well-known anycast addresses can be set in - RA or DHCP configuration to reduce configuration effort of users. - According to either RA or DHCP mechanism, the well-known addresses - can be obtained by IPv6 host. Because this approach is the most - convenient for users, the last option is recommended. - - Note: this section does not necessarily mean this document suggests - adopting all these three approaches and making them interwork in - the way described here. In fact, some approaches may even not be - adopted at all as a result of further discussion. - -5. Deployment Scenarios - - Regarding the DNS configuration on the IPv6 host, several - mechanisms are being considered at the DNSOP Working Group such as - RA option, DHCPv6 option and well-known preconfigured anycast - addresses as of today, and this document is a final result from the - long thread. In this section, we suggest four applicable scenarios - of three approaches for IPv6 DNS configuration. - - Note: in the applicable scenarios, authors do not implicitly push - any specific approaches into the restricted environments. No - enforcement is in each scenario and all mentioned scenarios are - probable. The main objective of this work is to provide a useful - guideline for IPv6 DNS configuration. - - - -Jeong, et al. Expires - August 2005 [Page 12] - -Internet-Draft IPv6 Host Configuration of DNS Server February 2005 - - -5.1. ISP Network - - A characteristic of ISP network is that multiple Customer Premises - Equipment (CPE) devices are connected to IPv6 PE (Provider Edge) - routers and each PE connects multiple CPE devices to the backbone - network infrastructure [13]. The CPEs may be hosts or routers. - - In the case where the CPE is a router, there is a customer network - that is connected to the ISP backbone through the CPE. Typically, - each customer network gets a different IPv6 prefix from an IPv6 PE - router, but the same RDNSS configuration will be distributed. - - This section discusses how the different approaches to distributing - DNS information are compared in an ISP network. - -5.1.1. RA Option Approach - - When the CPE is a host, the RA option for RDNSS can be used to - allow the CPE to get RDNSS information as well as /64 prefix - information for stateless address autoconfiguration at the same - time when the host is attached to a new subnet [8]. Because an - IPv6 host must receive at least one RA message for stateless - address autoconfiguration and router configuration, the host could - receive RDNSS configuration information in that RA without the - overhead of an additional message exchange. - - When the CPE is a router, the CPE may accept the RDNSS information - from the RA on the interface connected to the ISP, and copy that - information into the RAs advertised in the customer network. - - This approach is more valuable in the mobile host scenario, in - which the host must receive at least an RA message for detecting a - new network, than in other scenarios generally although - administrator should configure RDNSS information on the routers. - Secure ND [14] can provide extended security when using RA message. - -5.1.2. DHCPv6 Option Approach - - DHCPv6 can be used for RDNSS configuration through the use of the - DNS option, and can provide other configuration information in the - same message with RDNSS configuration [5]-[7]. DHCPv6 DNS option - is already in place for DHCPv6 as RFC 3646 [7] and DHCPv6-lite - or stateless DHCP [6] is nowhere as complex as a full DHCPv6 - implementation. DHCP is a client-server model protocol, so ISP can - handle user identification on its network intentionally, and also - authenticated DHCP [15] can be used for secure message exchange. - - - - -Jeong, et al. Expires - August 2005 [Page 13] - -Internet-Draft IPv6 Host Configuration of DNS Server February 2005 - - - The expected model for deployment of IPv6 service by ISPs is to - assign a prefix to each customer, which will be used by the - customer gateway to assign a /64 prefix to each network in the - customer's network. Prefix delegation with DHCP (DHCPv6 PD) has - already been adopted by ISPs for automating the assignment of the - customer prefix to the customer gateway [17]. DNS configuration - can be carried in the same DHCPv6 message exchange used for DHCPv6 - to efficiently provide that information, along with any other - configuration information needed by the customer gateway or - customer network. This service model can be useful to Home or SOHO - subscribers. The Home or SOHO gateway, which is a customer gateway - for ISP, can then pass that RDNSS configuration information to the - hosts in the customer network through DHCP. - -5.1.3. Well-known Addresses Approach - - Well-known anycast addresses approach is also a feasible and simple - mechanism for ISP [9]. The use of well-known anycast addresses - avoids some of the security risks in rogue messages sent through an - external protocol like RA or DHCPv6. The configuration of hosts - for the use of well-known anycast addresses requires no protocol or - manual configuration, but the configuration of routing for the - anycast addresses requires intervention on the part of the network - administrator. Also, the number of special addresses would be - equal to the number of RDNSSes that could be made available to - subscribers. - -5.2. Enterprise Network - - Enterprise network is defined as a network that has multiple - internal links, one or more router connections, to one or more - Providers and is actively managed by a network operations entity - [16]. An enterprise network can get network prefixes from ISP by - either manual configuration or prefix delegation [17]. In most - cases, because an enterprise network manages its own DNS domains, - it operates its own DNS servers for the domains. These DNS servers - within enterprise network process recursive DNS name resolution - requests from IPv6 hosts as RDNSSes. The RDNSS configuration in - the enterprise network can be performed like in Section 4, in which - three approaches can be used together as follows: - - 1) IPv6 host can decide which approach is or may be used in its - subnet with O flag in RA message [8]. As the first option in - Section 4, well-known anycast addresses can be used as a last - resort when RDNSS information can not be obtained through either RA - option or DHCP option. This case needs IPv6 hosts to preconfigure - the well-known anycast addresses in their DNS configuration files. - - - -Jeong, et al. Expires - August 2005 [Page 14] - -Internet-Draft IPv6 Host Configuration of DNS Server February 2005 - - - 2) When the enterprise prefers well-known anycast approach to the - others, IPv6 hosts should preconfigure the well-known anycast - addresses like in the first option. - - 3) The last option, a more convenient and transparent way, does not - need IPv6 hosts to preconfigure the well-known anycast addresses - because the addresses are delivered to IPv6 hosts through either RA - option or DHCPv6 option as if they were unicast addresses. This - way is most recommended for the sake of user's convenience. - -5.3. 3GPP Network - - IPv6 DNS configuration is a missing part of IPv6 autoconfiguration - and an important part of the basic IPv6 functionality in the 3GPP - User Equipment (UE). Higher level description of the 3GPP - architecture can be found in [18], and transition to IPv6 in 3GPP - networks is analyzed in [19] and [20]. - - In 3GPP architecture, there is a dedicated link between the UE and - the GGSN called the Packet Data Protocol (PDP) Context. This link - is created through the PDP Context activation procedure [21]. - There is a separate PDP context type for IPv4 and IPv6 traffic. If - a 3GPP UE user is communicating using IPv6 (having an active IPv6 - PDP context), it can not be assumed that (s)he has simultaneously - active IPv4 PDP context, and DNS queries could be done using IPv4. - A 3GPP UE can thus be an IPv6 node, and it needs to somehow - discover the address of the RDNSS. Before IP-based services (e.g., - web browsing or e-mail) can be used, the IPv6 (and IPv4) RDNSS - addresses need to be discovered in the 3GPP UE. - - Section 5.3.1 briefly summarizes currently available mechanisms in - 3GPP networks and recommendations. 5.3.2 analyzes the Router - Advertisement based solution, 5.3.3 analyzes the Stateless DHCPv6 - mechanism, and 5.3.4 analyzes the Well-known addresses approach. - Section 5.3.5 finally summarizes the recommendations. - -5.3.1. Currently Available Mechanisms and Recommendations - - 3GPP has defined a mechanism, in which RDNSS addresses can be - received in the PDP context activation (a control plane mechanism). - That is called the Protocol Configuration Options Information - Element (PCO-IE) mechanism [22]. The RDNSS addresses can also be - received over the air (using text messages), or typed in manually - in the UE. Note that the two last mechanisms are not very well - scalable. The UE user most probably does not want to type IPv6 - RDNSS addresses manually in his/her UE. The use of well-known - addresses is briefly discussed in section 5.3.4. - - - -Jeong, et al. Expires - August 2005 [Page 15] - -Internet-Draft IPv6 Host Configuration of DNS Server February 2005 - - - It is seen that the mechanisms above most probably are not - sufficient for the 3GPP environment. IPv6 is intended to operate - in a zero-configuration manner, no matter what the underlying - network infrastructure is. Typically, the RDNSS address is needed - to make an IPv6 node operational - and the DNS configuration should - be as simple as the address autoconfiguration mechanism. It must - also be noted that there will be additional IP interfaces in some - near future 3GPP UEs, e.g., WLAN, and 3GPP-specific DNS - configuration mechanisms (such as PCO-IE [22]) do not work for - those IP interfaces. In other words, a good IPv6 DNS configuration - mechanism should also work in a multi-access network environment. - - From 3GPP point of view, the best IPv6 DNS configuration solution - is feasible for a very large number of IPv6-capable UEs (can be - even hundreds of millions in one operator's network), is automatic - and thus requires no user action. It is suggested to standardize a - lightweight, stateless mechanism that works in all network - environments. The solution could then be used for 3GPP, 3GPP2, - WLAN and other access network technologies. A light, stateless - IPv6 DNS configuration mechanism is thus not only needed in 3GPP - networks, but also 3GPP networks and UEs would certainly benefit - from the new mechanism. - -5.3.2. RA Extension - - Router Advertisement extension [8] is a lightweight IPv6 DNS - configuration mechanism that requires minor changes in 3GPP UE IPv6 - stack and Gateway GPRS Support Node (GGSN, the default router in - the 3GPP architecture) IPv6 stack. This solution can be specified - in the IETF (no action needed in the 3GPP) and taken in use in 3GPP - UEs and GGSNs. - - In this solution, an IPv6-capable UE configures DNS information - via RA message sent by its default router (GGSN), i.e., RDNSS - option for recursive DNS server is included in the RA message. - This solution is easily scalable for a very large number of UEs. - The operator can configure the RDNSS addresses in the GGSN as a - part of normal GGSN configuration. The IPv6 RDNSS address is - received in the Router Advertisement, and an extra Round Trip Time - (RTT) for asking RDNSS addresses can be avoided. - - If thinking about cons, this mechanism still requires - standardization effort in the IETF, and the end nodes and routers - need to support this mechanism. The equipment software update - should, however, be pretty straightforward, and new IPv6 equipment - could support RA extension already from the beginning. - - - - -Jeong, et al. Expires - August 2005 [Page 16] - -Internet-Draft IPv6 Host Configuration of DNS Server February 2005 - - -5.3.3. Stateless DHCPv6 - - DHCPv6-based solution needs the implementation of Stateless DHCP - [6] and DHCPv6 DNS options [7] in the UE, and a DHCPv6 server in - the operator's network. A possible configuration is such that the - GGSN works as a DHCP relay. - - Pros for Stateless DHCPv6-based solution are - - 1) Stateless DHCPv6 is a standardized mechanism. - - 2) DHCPv6 can be used for receiving other configuration information - than RDNSS addresses, e.g., SIP server addresses. - - 3) DHCPv6 works in different network environments. - - 4) When DHCPv6 service is deployed through a single, centralized - server, the RDNSS configuration information can be updated by the - network administrator at a single source. - - Some issues with DHCPv6 in 3GPP networks are listed below: - - 1) DHCPv6 requires an additional server in the network unless the - (Stateless) DHCPv6 functionality is integrated into an existing - router already, and it is one box more to be maintained. - - 2) DHCPv6 is not necessarily needed for 3GPP UE IPv6 addressing - (3GPP Stateless Address Autoconfiguration is typically used), and - not automatically implemented in 3GPP IPv6 UEs. - - 3) Scalability and reliability of DHCPv6 in very large 3GPP - networks (with tens or hundreds of millions of UEs) may be an issue, - at least the redundancy needs to be taken care of. However, if the - DHCPv6 service is integrated into the network elements, such as - router operating system, scalability and reliability is comparable - with other DNS configuration approaches. - - 4) It is sub-optimal to utilize the radio resources in 3GPP - networks for DHCPv6 messages if there is a simpler alternative - available. - - a) Use of Stateless DHCPv6 adds one round trip delay to the case - in which the UE can start transmitting data right after the - Router Advertisement. - - 5) If the DNS information (suddenly) changes, Stateless DHCPv6 can - not automatically update the UE, see [23]. - - - -Jeong, et al. Expires - August 2005 [Page 17] - -Internet-Draft IPv6 Host Configuration of DNS Server February 2005 - - -5.3.4. Well-known Addresses - - Using well-known addresses is also a feasible and a light mechanism - for 3GPP UEs. Those well-known addresses can be preconfigured in - the UE software and the operator makes the corresponding - configuration on the network side. So this is a very easy - mechanism for the UE, but requires some configuration work in the - network. When using well-known addresses, UE forwards queries to - any of the preconfigured addresses. In the current proposal [9], - IPv6 anycast addresses are suggested. - - Note: IPv6 DNS configuration proposal based on the use of - well-known site-local addresses developed at the IPv6 Working Group - was seen as a feasible mechanism for 3GPP UEs, but opposition by - some people in the IETF and finally deprecating IPv6 site-local - addresses made it impossible to standardize it. Note that this - mechanism is implemented in some existing operating systems today - (also in some 3GPP UEs) as a last resort of IPv6 DNS configuration. - -5.3.5. Recommendations - - It is suggested that a lightweight, stateless DNS configuration - mechanism is specified as soon as possible. From 3GPP UE's and - networks' point of view, Router Advertisement based mechanism looks - most promising. The sooner a light, stateless mechanism is - specified, the sooner we can get rid of using well-known site-local - addresses for IPv6 DNS configuration. - -5.4. Unmanaged Network - - There are 4 deployment scenarios of interest in unmanaged networks - [24]: - - 1) A gateway which does not provide IPv6 at all; - - 2) A dual-stack gateway connected to a dual-stack ISP; - - 3) A dual-stack gateway connected to an IPv4-only ISP; and - - 4) A gateway connected to an IPv6-only ISP. - -5.4.1. Case A: Gateway does not provide IPv6 at all - - In this case, the gateway does not provide IPv6; the ISP may or may - not provide IPv6. Automatic or Configured tunnels are the - recommended transition mechanisms for this scenario. - - - - -Jeong, et al. Expires - August 2005 [Page 18] - -Internet-Draft IPv6 Host Configuration of DNS Server February 2005 - - - The case where dual-stack hosts behind an NAT, that need access to - an IPv6 RDNSS, can not be entirely ruled out. The DNS - configuration mechanism has to work over the tunnel, and the - underlying tunneling mechanism could be implementing NAT traversal. - The tunnel server assumes the role of a relay (both for DHCP and - Well-known anycast addresses approaches). - - RA-based mechanism is relatively straightforward in its operation, - assuming the tunnel server is also the IPv6 router emitting RAs. - Well-known anycast addresses approach seems also simple in - operation across the tunnel, but the deployment model using - Well-known anycast addresses in a tunneled environment is unclear or - not well understood. - -5.4.2. Case B: A dual-stack gateway connected to a dual-stack ISP - - This is similar to a typical IPv4 home user scenario, where DNS - configuration parameters are obtained using DHCP. Except that - Stateless DHCPv6 is used, as opposed to the IPv4 scenario where the - DHCP server is stateful (maintains the state for clients). - -5.4.3. Case C: A dual-stack gateway connected to an IPv4-only ISP - - This is similar to Case B. If a gateway provides IPv6 connectivity - by managing tunnels, then it is also supposed to provide access to - an RDNSS. Like this, the tunnel for IPv6 connectivity originates - from the dual-stack gateway instead of the host. - -5.4.4. Case D: A gateway connected to an IPv6-only ISP - - This is similar to Case B. - -6. Security Considerations - - As security requirements depend solely on applications and are - different application by application, there can be no generic - requirement defined at higher IP or lower application layer of DNS. - - However, it should be noted that cryptographic security requires - configured secret information that full autoconfiguration and - cryptographic security are mutually exclusive. People insisting on - secure full autoconfiguration will get false security, false - autoconfiguration or both. - - In some deployment scenarios [19], where cryptographic security is - required for applications, the secret information for the - cryptographic security is preconfigured through which application - specific configuration data, including those for DNS, can be - - -Jeong, et al. Expires - August 2005 [Page 19] - -Internet-Draft IPv6 Host Configuration of DNS Server February 2005 - - - securely configured. It should be noted that if applications - requiring cryptographic security depend on DNS, the applications - also require cryptographic security to DNS. Therefore, the full - autoconfiguration of DNS is not acceptable. - - However, with full autoconfiguration, weaker but still reasonable - security is being widely accepted and will continue to be - acceptable. That is, with full autoconfiguration, which means - there is no cryptographic security for the autoconfiguration, it is - already assumed that the local environment is secure enough that - the information from the local autoconfiguration server has - acceptable security even without cryptographic security. Thus, the - communication between the local DNS client and local DNS server has - the acceptable security. - - In autoconfiguring recursive servers, DNSSEC may be overkill, - because DNSSEC [29] needs the configuration and reconfiguration of - clients at root key roll-over [30][31]. Even if additional keys - for secure key roll-over are added at the initial configuration, - they are as vulnerable as the original keys to some forms of - attacks, such as social hacking. Another problem of using DNSSEC - and autoconfiguration together is that DNSSEC requires secure time, - which means secure communication with autoconfigured time servers, - which requires configured secret information. Therefore, in order - that the autoconfiguration may be secure, it requires configured - secret information. - - If DNSSEC [29] is used and the signatures are verified on the - client host, the misconfiguration of a DNS server may be simply - denial of service. Also, if local routing environment is not - reliable, clients may be directed to a false resolver with the same - IP address as the true one. - - For security considerations of each approach, refer to the - corresponding drafts [5]-[9]. - -7. Acknowledgements - - This draft has greatly benefited from inputs by David Meyer, Rob - Austein, Tatuya Jinmei, Pekka Savola, Tim Chown, Luc Beloeil, - Christian Huitema, Thomas Narten, Pascal Thubert, and Greg Daley. - The authors appreciate their contributions. - -8. Normative References - - [1] S. Bradner, "Intellectual Property Rights in IETF Technology", - RFC 3668, February 2004. - - - -Jeong, et al. Expires - August 2005 [Page 20] - -Internet-Draft IPv6 Host Configuration of DNS Server February 2005 - - - [2] S. Bradner, "IETF Rights in Contributions", RFC 3667, February - 2004. - - [3] T. Narten, E. Nordmark and W. Simpson, "Neighbor Discovery for - IP Version 6 (IPv6)", RFC 2461, December 1998. - - [4] S. Thomson and T. Narten, "IPv6 Stateless Address - Autoconfiguration", RFC 2462, December 1998. - - [5] R. Droms et al., "Dynamic Host Configuration Protocol for IPv6 - (DHCPv6)", RFC 3315, July 2003. - - [6] R. Droms, "Stateless Dynamic Host Configuration Protocol - (DHCP) Service for IPv6", RFC 3736, April 2004. - - [7] R. Droms et al., "DNS Configuration options for Dynamic Host - Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, December - 2003. - -9. Informative References - - [8] J. Jeong, S. Park, L. Beloeil and S. Madanapalli, "IPv6 DNS - Discovery based on Router Advertisement", - draft-jeong-dnsop-ipv6-dns-discovery-04.txt, February 2005, - Work in Progress. - - [9] M. Ohta, "Preconfigured DNS Server Addresses", - draft-ohta-preconfigured-dns-01.txt, February 2004, Work in - Progress. - - [10] S. Venaas, T. Chown and B. Volz, "Information Refresh Time - Option for DHCPv6", draft-ietf-dhc-lifetime-03.txt, January - 2005, Work in Progress. - - [11] C. Partridge, T. Mendez and W. Milliken, "Host Anycasting - Service", RFC 1546, November 1993. - - [12] R. Hinden and S. Deering, "Internet Protocol Version 6 (IPv6) - Addressing Architecture", RFC 3513, April 2003. - - [13] M. Lind et al., "Scenarios and Analysis for Introduction IPv6 - into ISP Networks", - draft-ietf-v6ops-isp-scenarios-analysis-03.txt, June 2004, - Work in Progress. - - [14] J. Arkko et al., "SEcure Neighbor Discovery (SEND)", - draft-ietf-send-ndopt-06.txt, July 2004, Work in Progress. - - - -Jeong, et al. Expires - August 2005 [Page 21] - -Internet-Draft IPv6 Host Configuration of DNS Server February 2005 - - - [15] R. Droms and W. Arbaugh, "Authentication for DHCP Messages", - RFC 3118, June 2001. - - [16] J. Bound et al., "IPv6 Enterprise Network Scenarios", - draft-ietf-v6ops-ent-scenarios-05.txt, July 2004, Work in - Progress. - - [17] O. Troan and R. Droms, "IPv6 Prefix Options for Dynamic Host - Configuration Protocol (DHCP) version 6", RFC 3633, December - 2003. - - [18] M. Wasserman, Ed., "Recommendations for IPv6 in 3GPP - Standards", RFC 3314, September 2002. - - [19] J. Soininen, Ed., "Transition Scenarios for 3GPP Networks", - RFC 3574, August 2003. - - [20] J. Wiljakka, Ed., "Analysis on IPv6 Transition in 3GPP - Networks", draft-ietf-v6ops-3gpp-analysis-11.txt, October 2004, - Work in Progress. - - [21] 3GPP TS 23.060 V5.4.0, "General Packet Radio Service (GPRS); - Service description; Stage 2 (Release 5)", December 2002. - - [22] 3GPP TS 24.008 V5.8.0, "Mobile radio interface Layer 3 - specification; Core network protocols; Stage 3 (Release 5)", - June 2003. - - [23] T. Chown, S. Venaas and A. Vijayabhaskar, "Renumbering - Requirements for Stateless DHCPv6", - draft-ietf-dhc-stateless-dhcpv6-renumbering-02.txt, October - 2004, Work in Progress. - - [24] C. Huitema et al., "Unmanaged Networks IPv6 Transition - Scenarios", RFC 3750, April 2004. - - [25] ANSI/IEEE Std 802.11, "Part 11: Wireless LAN Medium Access - Control (MAC) and Physical Layer (PHY) Specifications", March - 1999. - - [26] IEEE Std 802.11a, "Part 11: Wireless LAN Medium Access Control - (MAC) and Physical Layer (PHY) specifications: High-speed - Physical Layer in the 5 GHZ Band", September 1999. - - [27] IEEE Std 802.11b, "Part 11: Wireless LAN Medium Access Control - (MAC) and Physical Layer (PHY) specifications: Higher-Speed - Physical Layer Extension in the 2.4 GHz Band", September 1999. - - - -Jeong, et al. Expires - August 2005 [Page 22] - -Internet-Draft IPv6 Host Configuration of DNS Server February 2005 - - - [28] IEEE P802.11g/D8.2, "Part 11: Wireless LAN Medium Access - Control (MAC) and Physical Layer (PHY) specifications: Further - Higher Data Rate Extension in the 2.4 GHz Band", April 2003. - - [29] D. Eastlake, "Domain Name System Security Extensions", RFC - 2535, March 1999. - - [30] O. Kolkman and R. Gieben, "DNSSEC Operational Practices", - draft-ietf-dnsop-dnssec-operational-practices-03.txt, - December 2004. - - [31] G. Guette and O. Courtay, "Requirements for Automated Key - Rollover in DNSSEC", - draft-ietf-dnsop-key-rollover-requirements-02.txt, January - 2005. - -10. Appendix A - Link-layer Multicast Acknowledgements with RA Option - - One benefit of RA option is to be able to multicast the - advertisements, reducing the need for duplicated unicast - communications. - - However, some link-layers may not support this as well as others. - Consider, for example, WLAN networks where multicast is unreliable. - The unreliability problem is caused by lack of ACK for multicast, - especially on the path from the Access Point (AP) to the Station - (STA), which is specific to CSMA/CA of WLAN [25]-[28]. Namely, - multicast packet is unacknowledged on the path from the AP to the - STA, but acknowledged in the reverse direction from the STA to the - AP [25]. For example, when a router is placed at wired network - connected to an AP, a host may sometimes not receive RA message - advertised through the AP. - - The fact that this problem has not been addressed in Neighbor - Discovery [3] indicates that the extra link-layer acknowledgements - have not been considered a serious problem till now. - - A possible mitigation technique could be to map all-nodes link-local - multicast address to the link-layer broadcast address, and to rely - on the ND retransmissions for message delivery. - -11. Authors' Addresses - - Jaehoon Paul Jeong, Editor - ETRI/University of Minnesota at Twin Cities - 117 Pleasant Street SE - Minneapolis, MN 55455 - USA - - -Jeong, et al. Expires - August 2005 [Page 23] - -Internet-Draft IPv6 Host Configuration of DNS Server February 2005 - - - - Phone: +1 651 587 7774 - EMail: jjeong@cs.umn.edu - - Ralph Droms - Cisco Systems - 1414 Massachusetts Ave. - Boxboro, MA 01719 - USA - - Phone: +1 978 936 1674 - EMail: rdroms@cisco.com - - Robert M. Hinden - Nokia - 313 Fairchild Drive - Mountain View, CA 94043 - USA - - Phone: +1 650 625 2004 - EMail: bob.hinden@nokia.com - - Ted Lemon - Nominum, Inc. - 950 Charter Street - Redwood City, CA 94043 - USA - - EMail: Ted.Lemon@nominum.com - - Masataka Ohta - Graduate School of Information Science and Engineering - Tokyo Institute of Technology - 2-12-1, O-okayama, Meguro-ku - Tokyo 152-8552 - Japan - - Phone: +81 3 5734 3299 - Fax: +81 3 5734 3299 - EMail: mohta@necom830.hpcl.titech.ac.jp - - Soohong Daniel Park - Mobile Platform Laboratory, SAMSUNG Electronics - 416, Maetan-3dong, Paldal-gu, Suwon - Gyeonggi-Do - Korea - - Phone: +82 31 200 4508 - - -Jeong, et al. Expires - August 2005 [Page 24] - -Internet-Draft IPv6 Host Configuration of DNS Server February 2005 - - - EMail: soohong.park@samsung.com - - Suresh Satapati - Cisco Systems, Inc. - San Jose, CA 95134 - USA - - EMail: satapati@cisco.com - - Juha Wiljakka - Nokia - Visiokatu 3 - FIN-33720 TAMPERE - Finland - - Phone: +358 7180 48372 - EMail: juha.wiljakka@nokia.com - -12. 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. - -13. 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. - - -Jeong, et al. Expires - August 2005 [Page 25] - -Internet-Draft IPv6 Host Configuration of DNS Server February 2005 - - - - 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. - -Acknowledgement - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Jeong, et al. Expires - August 2005 [Page 26] - diff --git a/doc/draft/draft-ietf-dnsop-ipv6-dns-issues-10.txt b/doc/draft/draft-ietf-dnsop-ipv6-dns-issues-10.txt deleted file mode 100644 index f0ddf003f71..00000000000 --- a/doc/draft/draft-ietf-dnsop-ipv6-dns-issues-10.txt +++ /dev/null @@ -1,1971 +0,0 @@ - -DNS Operations WG A. Durand -Internet-Draft SUN Microsystems, Inc. -Expires: April 24, 2005 J. Ihren - Autonomica - P. Savola - CSC/FUNET - October 24, 2004 - - - - Operational Considerations and Issues with IPv6 DNS - draft-ietf-dnsop-ipv6-dns-issues-10.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 April 24, 2005. - - -Copyright Notice - - - Copyright (C) The Internet Society (2004). - - -Abstract - - - This memo presents operational considerations and issues with IPv6 - Domain Name System (DNS), including a summary of special IPv6 - addresses, documentation of known DNS implementation misbehaviour, - recommendations and considerations on how to perform DNS naming for - - - - -Durand, et al. Expires April 24, 2005 [Page 1] -Internet-Draft Considerations and Issues with IPv6 DNS October 2004 - - - - service provisioning and for DNS resolver IPv6 support, - considerations for DNS updates for both the forward and reverse - trees, and miscellaneous issues. This memo is aimed to include a - summary of information about IPv6 DNS considerations for those who - have experience with IPv4 DNS. - - -Table of Contents - - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 - 1.1 Representing IPv6 Addresses in DNS Records . . . . . . . . 4 - 1.2 Independence of DNS Transport and DNS Records . . . . . . 4 - 1.3 Avoiding IPv4/IPv6 Name Space Fragmentation . . . . . . . 5 - 1.4 Query Type '*' and A/AAAA Records . . . . . . . . . . . . 5 - 2. DNS Considerations about Special IPv6 Addresses . . . . . . . 5 - 2.1 Limited-scope Addresses . . . . . . . . . . . . . . . . . 6 - 2.2 Temporary Addresses . . . . . . . . . . . . . . . . . . . 6 - 2.3 6to4 Addresses . . . . . . . . . . . . . . . . . . . . . . 6 - 2.4 Other Transition Mechanisms . . . . . . . . . . . . . . . 6 - 3. Observed DNS Implementation Misbehaviour . . . . . . . . . . . 7 - 3.1 Misbehaviour of DNS Servers and Load-balancers . . . . . . 7 - 3.2 Misbehaviour of DNS Resolvers . . . . . . . . . . . . . . 7 - 4. Recommendations for Service Provisioning using DNS . . . . . . 8 - 4.1 Use of Service Names instead of Node Names . . . . . . . . 8 - 4.2 Separate vs the Same Service Names for IPv4 and IPv6 . . . 8 - 4.3 Adding the Records Only when Fully IPv6-enabled . . . . . 9 - 4.4 Behaviour of Additional Data in IPv4/IPv6 Environments . . 10 - 4.4.1 Description of Additional Data Scenarios . . . . . . . 10 - 4.4.2 Which Additional Data to Keep, If Any? . . . . . . . . 11 - 4.4.3 Discussion of the Problems . . . . . . . . . . . . . . 12 - 4.5 The Use of TTL for IPv4 and IPv6 RRs . . . . . . . . . . . 13 - 4.6 IPv6 Transport Guidelines for DNS Servers . . . . . . . . 14 - 5. Recommendations for DNS Resolver IPv6 Support . . . . . . . . 15 - 5.1 DNS Lookups May Query IPv6 Records Prematurely . . . . . . 15 - 5.2 Obtaining a List of DNS Recursive Resolvers . . . . . . . 16 - 5.3 IPv6 Transport Guidelines for Resolvers . . . . . . . . . 17 - 6. Considerations about Forward DNS Updating . . . . . . . . . . 17 - 6.1 Manual or Custom DNS Updates . . . . . . . . . . . . . . . 17 - 6.2 Dynamic DNS . . . . . . . . . . . . . . . . . . . . . . . 18 - 7. Considerations about Reverse DNS Updating . . . . . . . . . . 19 - 7.1 Applicability of Reverse DNS . . . . . . . . . . . . . . . 19 - 7.2 Manual or Custom DNS Updates . . . . . . . . . . . . . . . 20 - 7.3 DDNS with Stateless Address Autoconfiguration . . . . . . 20 - 7.4 DDNS with DHCP . . . . . . . . . . . . . . . . . . . . . . 21 - 7.5 DDNS with Dynamic Prefix Delegation . . . . . . . . . . . 22 - 8. Miscellaneous DNS Considerations . . . . . . . . . . . . . . . 23 - 8.1 NAT-PT with DNS-ALG . . . . . . . . . . . . . . . . . . . 23 - 8.2 Renumbering Procedures and Applications' Use of DNS . . . 23 - 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23 - - - - -Durand, et al. Expires April 24, 2005 [Page 2] -Internet-Draft Considerations and Issues with IPv6 DNS October 2004 - - - - 10. Security Considerations . . . . . . . . . . . . . . . . . . 24 - 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 - 11.1 Normative References . . . . . . . . . . . . . . . . . . . . 24 - 11.2 Informative References . . . . . . . . . . . . . . . . . . . 26 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 28 - A. Site-local Addressing Considerations for DNS . . . . . . . . . 29 - Intellectual Property and Copyright Statements . . . . . . . . 30 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Durand, et al. Expires April 24, 2005 [Page 3] -Internet-Draft Considerations and Issues with IPv6 DNS October 2004 - - - -1. Introduction - - - This memo presents operational considerations and issues with IPv6 - DNS; it is meant to be an extensive summary and a list of pointers - for more information about IPv6 DNS considerations for those with - experience with IPv4 DNS. - - - The purpose of this document is to give information about various - issues and considerations related to DNS operations with IPv6; it is - not meant to be a normative specification or standard for IPv6 DNS. - - - The first section gives a brief overview of how IPv6 addresses and - names are represented in the DNS, how transport protocols and - resource records (don't) relate, and what IPv4/IPv6 name space - fragmentation means and how to avoid it; all of these are described - at more length in other documents. - - - The second section summarizes the special IPv6 address types and how - they relate to DNS. The third section describes observed DNS - implementation misbehaviours which have a varying effect on the use - of IPv6 records with DNS. The fourth section lists recommendations - and considerations for provisioning services with DNS. The fifth - section in turn looks at recommendations and considerations about - providing IPv6 support in the resolvers. The sixth and seventh - sections describe considerations with forward and reverse DNS - updates, respectively. The eighth section introduces several - miscellaneous IPv6 issues relating to DNS for which no better place - has been found in this memo. Appendix A looks briefly at the - requirements for site-local addressing. - - -1.1 Representing IPv6 Addresses in DNS Records - - - In the forward zones, IPv6 addresses are represented using AAAA - records. In the reverse zones, IPv6 address are represented using - PTR records in the nibble format under the ip6.arpa. tree. See - [RFC3596] for more about IPv6 DNS usage, and [RFC3363] or [RFC3152] - for background information. - - - In particular one should note that the use of A6 records in the - forward tree or Bitlabels in the reverse tree is not recommended - [RFC3363]. Using DNAME records is not recommended in the reverse - tree in conjunction with A6 records; the document did not mean to - take a stance on any other use of DNAME records [RFC3364]. - - -1.2 Independence of DNS Transport and DNS Records - - - DNS has been designed to present a single, globally unique name space - [RFC2826]. This property should be maintained, as described here and - - - - -Durand, et al. Expires April 24, 2005 [Page 4] -Internet-Draft Considerations and Issues with IPv6 DNS October 2004 - - - - in Section 1.3. - - - The IP version used to transport the DNS queries and responses is - independent of the records being queried: AAAA records can be queried - over IPv4, and A records over IPv6. The DNS servers must not make - any assumptions about what data to return for Answer and Authority - sections based on the underlying transport used in a query. - - - However, there is some debate whether the addresses in Additional - section could be selected or filtered using hints obtained from which - transport was being used; this has some obvious problems because in - many cases the transport protocol does not correlate with the - requests, and because a "bad" answer is in a way worse than no answer - at all (consider the case where the client is led to believe that a - name received in the additional record does not have any AAAA records - at all). - - - As stated in [RFC3596]: - - - The IP protocol version used for querying resource records is - independent of the protocol version of the resource records; e.g., - IPv4 transport can be used to query IPv6 records and vice versa. - - - -1.3 Avoiding IPv4/IPv6 Name Space Fragmentation - - - To avoid the DNS name space from fragmenting into parts where some - parts of DNS are only visible using IPv4 (or IPv6) transport, the - recommendation is to always keep at least one authoritative server - IPv4-enabled, and to ensure that recursive DNS servers support IPv4. - See DNS IPv6 transport guidelines [RFC3901] for more information. - - -1.4 Query Type '*' and A/AAAA Records - - - QTYPE=* is typically only used for debugging or management purposes; - it is worth keeping in mind that QTYPE=* ("ANY" queries) only return - any available RRsets, not *all* the RRsets, because the caches do not - necessarily have all the RRsets and have no way of guaranteeing that - they have all the RRsets. Therefore, to get both A and AAAA records - reliably, two separate queries must be made. - - -2. DNS Considerations about Special IPv6 Addresses - - - There are a couple of IPv6 address types which are somewhat special; - these are considered here. - - - - - - - -Durand, et al. Expires April 24, 2005 [Page 5] -Internet-Draft Considerations and Issues with IPv6 DNS October 2004 - - - -2.1 Limited-scope Addresses - - - The IPv6 addressing architecture [RFC3513] includes two kinds of - local-use addresses: link-local (fe80::/10) and site-local - (fec0::/10). The site-local addresses have been deprecated - [RFC3879], and are only discussed in Appendix A. - - - Link-local addresses should never be published in DNS (whether in - forward or reverse tree), because they have only local (to the - connected link) significance - [I-D.ietf-dnsop-dontpublish-unreachable]. - - -2.2 Temporary Addresses - - - Temporary addresses defined in RFC3041 [RFC3041] (sometimes called - "privacy addresses") use a random number as the interface identifier. - Having DNS AAAA records that are updated to always contain the - current value of a node's temporary address would defeat the purpose - of the mechanism and is not recommended. However, it would still be - possible to return a non-identifiable name (e.g., the IPv6 address in - hexadecimal format), as described in [RFC3041]. - - -2.3 6to4 Addresses - - - 6to4 [RFC3056] specifies an automatic tunneling mechanism which maps - a public IPv4 address V4ADDR to an IPv6 prefix 2002:V4ADDR::/48. - - - If the reverse DNS population would be desirable (see Section 7.1 for - applicability), there are a number of possible ways to do so - [I-D.moore-6to4-dns], some more applicable than the others. - - - The main proposal [I-D.huston-6to4-reverse-dns] aims to design an - autonomous reverse-delegation system that anyone being capable of - communicating using a specific 6to4 address would be able to set up a - reverse delegation to the corresponding 6to4 prefix. This could be - deployed by e.g., Regional Internet Registries (RIRs). This is a - practical solution, but may have some scalability concerns. - - -2.4 Other Transition Mechanisms - - - 6to4, above, is mentioned as a case of an IPv6 transition mechanism - requiring special considerations. In general, mechanisms which - include a special prefix may need a custom solution; otherwise, for - example when IPv4 address is embedded as the suffix or not embedded - at all, special solutions are likely not needed. This is why only - 6to4 and Teredo [I-D.huitema-v6ops-teredo] are described. - - - Note that it does not seem feasible to provide reverse DNS with - - - - -Durand, et al. Expires April 24, 2005 [Page 6] -Internet-Draft Considerations and Issues with IPv6 DNS October 2004 - - - - another automatic tunneling mechanism, Teredo; this is because the - IPv6 address is based on the IPv4 address and UDP port of the current - NAT mapping which is likely to be relatively short-lived. - - -3. Observed DNS Implementation Misbehaviour - - - Several classes of misbehaviour in DNS servers, load-balancers and - resolvers have been observed. Most of these are rather generic, not - only applicable to IPv6 -- but in some cases, the consequences of - this misbehaviour are extremely severe in IPv6 environments and - deserve to be mentioned. - - -3.1 Misbehaviour of DNS Servers and Load-balancers - - - There are several classes of misbehaviour in certain DNS servers and - load-balancers which have been noticed and documented - [I-D.ietf-dnsop-misbehavior-against-aaaa]: some implementations - silently drop queries for unimplemented DNS records types, or provide - wrong answers to such queries (instead of a proper negative reply). - While typically these issues are not limited to AAAA records, the - problems are aggravated by the fact that AAAA records are being - queried instead of (mainly) A records. - - - The problems are serious because when looking up a DNS name, typical - getaddrinfo() implementations, with AF_UNSPEC hint given, first try - to query the AAAA records of the name, and after receiving a - response, query the A records. This is done in a serial fashion -- - if the first query is never responded to (instead of properly - returning a negative answer), significant timeouts will occur. - - - In consequence, this is an enormous problem for IPv6 deployments, and - in some cases, IPv6 support in the software has even been disabled - due to these problems. - - - The solution is to fix or retire those misbehaving implementations, - but that is likely not going to be effective. There are some - possible ways to mitigate the problem, e.g., by performing the - lookups somewhat in parallel and reducing the timeout as long as at - least one answer has been received; but such methods remain to be - investigated; slightly more on this is included in Section 5. - - -3.2 Misbehaviour of DNS Resolvers - - - Several classes of misbehaviour have also been noticed in DNS - resolvers [I-D.ietf-dnsop-bad-dns-res]. However, these do not seem - to directly impair IPv6 use, and are only referred to for - completeness. - - - - - -Durand, et al. Expires April 24, 2005 [Page 7] -Internet-Draft Considerations and Issues with IPv6 DNS October 2004 - - - -4. Recommendations for Service Provisioning using DNS - - - When names are added in the DNS to facilitate a service, there are - several general guidelines to consider to be able to do it as - smoothly as possible. - - -4.1 Use of Service Names instead of Node Names - - - It makes sense to keep logically separate services by a node separate - in the DNS, due to a number of reasons, for example: - - - o It allows more flexibility and ease for migration of (only a part - of) services from one node to another, - - - o It allows configuring different properties (e.g., TTL) for each - service, and - - - o It allows deciding separately for each service whether to publish - the IPv6 addresses or not (in cases if some services are more - IPv6-ready than others). - - - Using SRV records [RFC2782] would avoid these problems. - Unfortunately, those are not sufficiently widely used to be - applicable in most cases. Hence an operation technique is to use - service names instead of node names (or, "hostnames"). This - operational technique is not specific to IPv6, but required to - understand the considerations described in Section 4.2 and Section - 4.3. - - - For example, assume a node named "pobox.example.com" provides both - SMTP and IMAP service. Instead of configuring the MX records to - point at "pobox.example.com", and configuring the mail clients to - look up the mail via IMAP from "pobox.example.com", one could use - e.g., "smtp.example.com" for SMTP (for both message submission and - mail relaying between SMTP servers) and "imap.example.com" for IMAP. - Note that in the specific case of SMTP relaying, the server itself - must typically also be configured to know all its names to ensure - loops do not occur. DNS can provide a layer of indirection between - service names and where the service actually is, and using which - addresses. (Obviously, when wanting to reach a specific node, one - should use the hostname rather than a service name.) - - -4.2 Separate vs the Same Service Names for IPv4 and IPv6 - - - The service naming can be achieved in basically two ways: when a - service is named "service.example.com" for IPv4, the IPv6-enabled - service could be either added to "service.example.com", or added - separately under a different name, e.g., in a sub-domain, like, - - - - -Durand, et al. Expires April 24, 2005 [Page 8] -Internet-Draft Considerations and Issues with IPv6 DNS October 2004 - - - - "service.ipv6.example.com". - - - These two methods have different characteristics. Using a different - name allows for easier service piloting, minimizing the disturbance - to the "regular" users of IPv4 service; however, the service would - not be used transparently, without the user/application explicitly - finding it and asking for it -- which would be a disadvantage in most - cases. When the different name is under a sub-domain, if the - services are deployed within a restricted network (e.g., inside an - enterprise), it's possible to prefer them transparently, at least to - a degree, by modifying the DNS search path; however, this is a - suboptimal solution. Using the same service name is the "long-term" - solution, but may degrade performance for those clients whose IPv6 - performance is lower than IPv4, or does not work as well (see Section - 4.3 for more). - - - In most cases, it makes sense to pilot or test a service using - separate service names, and move to the use of the same name when - confident enough that the service level will not degrade for the - users unaware of IPv6. - - -4.3 Adding the Records Only when Fully IPv6-enabled - - - The recommendation is that AAAA records for a service should not be - added to the DNS until all of following are true: - - - 1. The address is assigned to the interface on the node. - - - 2. The address is configured on the interface. - - - 3. The interface is on a link which is connected to the IPv6 - infrastructure. - - - In addition, if the AAAA record is added for the node, instead of - service as recommended, all the services of the node should be - IPv6-enabled prior to adding the resource record. - - - For example, if an IPv6 node is isolated from an IPv6 perspective - (e.g., it is not connected to IPv6 Internet) constraint #3 would mean - that it should not have an address in the DNS. - - - Consider the case of two dual-stack nodes, which both have IPv6 - enabled, but the server does not have (global) IPv6 connectivity. As - the client looks up the server's name, only A records are returned - (if the recommendations above are followed), and no IPv6 - communication, which would have been unsuccessful, is even attempted. - - - The issues are not always so black-and-white. Usually it's important - - - - -Durand, et al. Expires April 24, 2005 [Page 9] -Internet-Draft Considerations and Issues with IPv6 DNS October 2004 - - - - if the service offered using both protocols is of roughly equal - quality, using the appropriate metrics for the service (e.g., - latency, throughput, low packet loss, general reliability, etc.) -- - this is typically very important especially for interactive or - real-time services. In many cases, the quality of IPv6 connectivity - may not yet be equal to that of IPv4, at least globally -- this has - to be taken into consideration when enabling services - [I-D.savola-v6ops-6bone-mess]. - - -4.4 Behaviour of Additional Data in IPv4/IPv6 Environments - - - DNS responses do not always fit in a single UDP packet. We'll - examine the cases which happen when this is due to too much data in - the Additional Section. - - -4.4.1 Description of Additional Data Scenarios - - - There are two kinds of additional data: - - - 1. "critical" additional data; this must be included in all - scenarios, with all the RRsets, and - - - 2. "courtesy" additional data; this could be sent in full, with only - a few RRsets, or with no RRsets, and can be fetched separately as - well, but at the cost of additional queries. - - - The responding server can algorithmically determine which type the - additional data is by checking whether it's at or below a zone cut. - - - Only those additional data records (even if sometimes carelessly - termed "glue") are considered "critical" or real "glue" if and only - if they meet the abovementioned condition, as specified in Section - 4.2.1 of [RFC1034]. - - - Remember that resource record sets (RRsets) are never "broken up", so - if a name has 4 A records and 5 AAAA records, you can either return - all 9, all 4 A records, all 5 AAAA records or nothing. In - particular, notice that for the "critical" additional data getting - all the RRsets can be critical. - - - In particular, [RFC2181] specifies (in Section 9) that: - - - a. if all the "critical" RRsets do not fit, the sender should set - the TC bit, and the recipient should discard the whole response - and retry using mechanism allowing larger responses such as TCP. - - - b. "courtesy" additional data should not cause the setting of TC - bit, but instead all the non-fitting additional data RRsets - - - - -Durand, et al. Expires April 24, 2005 [Page 10] -Internet-Draft Considerations and Issues with IPv6 DNS October 2004 - - - - should be removed. - - - An example of the "courtesy" additional data is A/AAAA records in - conjunction of MX records is shown in Section 4.5; an example of the - "critical" additional data is shown below (where getting both the A - and AAAA RRsets is critical): - - - child.example.com. IN NS ns.child.example.com. - ns.child.example.com. IN A 192.0.2.1 - ns.child.example.com. IN AAAA 2001:db8::1 - - - When there is too much courtesy additional data, at least the - non-fitting RRsets should be removed [RFC2181]; however, as the - additional data is not critical, even all of it could be safely - removed. - - - When there is too much critical additional data, TC bit will have to - be set, and the recipient should ignore the response and retry using - TCP; if some data were to be left in the UDP response, the issue is - which data could be retained. - - - Failing to discard the response with TC bit set leads to a protocol - problem. Omitting only some of the RRsets if all would not fit leads - to a performance problem. These are discussed in Section 4.4.3. - - -4.4.2 Which Additional Data to Keep, If Any? - - - If the implementation decides to keep as much data (whether - "critical" or "courtesy") as possible in the UDP responses, it might - be tempting to use the transport of the DNS query as a hint in either - of these cases: return the AAAA records if the query was done over - IPv6, or return the A records if the query was done over IPv4. - However, this breaks the model of independence of DNS transport and - resource records, as noted in Section 1.2. - - - With courtesy additional data, as long as enough RRsets will be - removed so that TC will not be set, it is allowed to send as many - complete RRsets as the implementations prefers. However, the - implementations are also free to omit all such RRsets, even if - complete. Removing all the RRsets if some would not fit obviates a - performance problem, which would require the users to issue second - queries to obtain consistent information. - - - With critical additional data, the alternatives are either returning - nothing (and absolutely requiring a retry with TCP) or returning - something (working also in the case if the recipient does not discard - the response and retry using TCP) in addition to setting the TC bit. - If the process for selecting "something" from the critical data would - - - - -Durand, et al. Expires April 24, 2005 [Page 11] -Internet-Draft Considerations and Issues with IPv6 DNS October 2004 - - - - otherwise be practically "flipping the coin" between A and AAAA - records, it could be argued that if one looked at the transport of - the query, it would have a larger possibility of being right than - just 50/50. In other words, if the returned critical additional data - would have to be selected somehow, using something more sophisticated - than a random process would seem justifiable. - - - That is, leaving in some intelligently selected critical additional - data is a tradeoff between creating an optimization for those - resolvers which ignore the "should discard" recommendation, and a - causing a protocol problem by propagating inconsistent information - about "critical" records in the caches. - - - Similarly, leaving in the complete courtesy additional data RRsets - instead of removing all the RRsets is a performance tradeoff as - described in the next section. - - -4.4.3 Discussion of the Problems - - - As noted above, the temptation for omitting only some of the - additional data based on the transport of the query could be - problematic. In particular, there appears to be little justification - for doing so in the case of "courtesy" data. - - - For courtesy additional data, this causes a performance problem as - this requires that the clients issue re-query for the potentially - omitted RRsets. For critical additional data, this causes a - potential protocol problem if the response is not discarded and the - query not re-tried with TCP, as the nameservers might be reachable - only through the omitted RRsets. - - - If an implementation would look at the transport used for the query, - it is worth remembering that often the host using the records is - different from the node requesting them from the authoritative DNS - server (or even a caching resolver). So, whichever version the - requestor (e.g., a recursive server in the middle) uses makes no - difference to the ultimate user of the records, whose transport - capabilities might differ from those of the requestor. This might - result in e.g., inappropriately returning A records to an IPv6-only - node, going through a translation, or opening up another IP-level - session (e.g., a PDP context [I-D.ietf-v6ops-3gpp-analysis]). - Therefore, at least in many scenarios, it would be very useful if the - information returned would be consistent and complete -- or if that - is not feasible, return no misleading information but rather leave it - to the client to query again. - - - The problem of too much additional data seems to be an operational - one: the zone administrator entering too many records which will be - - - - -Durand, et al. Expires April 24, 2005 [Page 12] -Internet-Draft Considerations and Issues with IPv6 DNS October 2004 - - - - returned either truncated (or missing some RRsets, depending on - implementations) to the users. A protocol fix for this is using - EDNS0 [RFC2671] to signal the capacity for larger UDP packet sizes, - pushing up the relevant threshold. Further, DNS server - implementations should rather omit courtesy additional data - completely rather than including only some RRsets [RFC2181]. An - operational fix for this is having the DNS server implementations - return a warning when the administrators create zones which would - result in too much additional data being returned. Further, DNS - server implementations should warn of or disallow such zone - configurations which are recursive or otherwise difficult to manage - by the protocol. - - - Additionally, to avoid the case where an application would not get an - address at all due to some of "courtesy" additional data being - omitted, the resolvers should be able to query the specific records - of the desired protocol, not just rely on getting all the required - RRsets in the additional section. - - -4.5 The Use of TTL for IPv4 and IPv6 RRs - - - In the previous section, we discussed a danger with queries, - potentially leading to omitting RRsets from the additional section; - this could happen to both critical and "courtesy" additional data - (however, both of these are recommended against in [RFC2181]). This - section discusses another problem with courtesy additional data, - leading to omitting RRsets in cached data, highlighted in the - IPv4/IPv6 environment. - - - The behaviour of DNS caching when different TTL values are used for - different RRsets of the same name requires explicit discussion. For - example, let's consider a part of a zone: - - - example.com. 300 IN MX foo.example.com. - foo.example.com. 300 IN A 192.0.2.1 - foo.example.com. 100 IN AAAA 2001:db8::1 - - - When a caching resolver asks for the MX record of example.com, it - gets back "foo.example.com". It may also get back either one or both - of the A and AAAA records in the additional section. So, there are - three cases about returning records for the MX in the additional - section: - - - 1. We get back no A or AAAA RRsets: this is the simplest case, - because then we have to query which information is required - explicitly, guaranteeing that we get all the information we're - interested in. - - - - - -Durand, et al. Expires April 24, 2005 [Page 13] -Internet-Draft Considerations and Issues with IPv6 DNS October 2004 - - - - 2. We get back all the RRsets: this is an optimization as there is - no need to perform more queries, causing lower latency. However, - it is impossible to guarantee that in fact we would always get - back all the records (the only way to ensure that is to send a - AAAA query for the name after getting the cached reply with A - records or vice versa). - - - 3. We only get back A or AAAA RRsets even if both existed: this is - indistinguishable from the previous case, and may have - performance problems at least in certain environments as - described in the previous section. - - - As the third case was considered in the previous section, we assume - we get back both A and AAAA records of foo.example.com, or the stub - resolver explicitly asks, in two separate queries, both A and AAAA - records. - - - After 100 seconds, the AAAA record is removed from the cache(s) - because its TTL expired. It could be argued to be useful for the - caching resolvers to discard the A record when the shorter TTL (in - this case, for the AAAA record) expires; this would avoid the - situation where there would be a window of 200 seconds when - incomplete information is returned from the cache. Further argument - for discarding is that in the normal operation, the TTL values are so - high that very likely the incurred additional queries would not be - noticeable, compared to the obtained performance optimization. The - behaviour in this scenario is unspecified. - - - To simplify the situation, it might help to use the same TTL for all - the resource record sets referring to the same name, unless there is - a particular reason for not doing so. However, there are some - scenarios (e.g., when renumbering IPv6 but keeping IPv4 intact) where - a different strategy is preferable. - - - Thus, applications that use the response should not rely on a - particular TTL configuration. For example, even if an application - gets a response that only has the A record in the example described - above, it should be still aware that there could be a AAAA record for - "foo.example.com". That is, the application should try to fetch the - missing records itself if it needs the record. - - -4.6 IPv6 Transport Guidelines for DNS Servers - - - As described in Section 1.3 and [RFC3901], there should continue to - be at least one authoritative IPv4 DNS server for every zone, even if - the zone has only IPv6 records. (Note that obviously, having more - servers with robust connectivity would be preferable, but this is the - minimum recommendation; also see [RFC2182].) - - - - -Durand, et al. Expires April 24, 2005 [Page 14] -Internet-Draft Considerations and Issues with IPv6 DNS October 2004 - - - -5. Recommendations for DNS Resolver IPv6 Support - - - When IPv6 is enabled on a node, there are several things to consider - to ensure that the process is as smooth as possible. - - -5.1 DNS Lookups May Query IPv6 Records Prematurely - - - The system library that implements the getaddrinfo() function for - looking up names is a critical piece when considering the robustness - of enabling IPv6; it may come in basically three flavours: - - - 1. The system library does not know whether IPv6 has been enabled in - the kernel of the operating system: it may start looking up AAAA - records with getaddrinfo() and AF_UNSPEC hint when the system is - upgraded to a system library version which supports IPv6. - - - 2. The system library might start to perform IPv6 queries with - getaddrinfo() only when IPv6 has been enabled in the kernel. - However, this does not guarantee that there exists any useful - IPv6 connectivity (e.g., the node could be isolated from the - other IPv6 networks, only having link-local addresses). - - - 3. The system library might implement a toggle which would apply - some heuristics to the "IPv6-readiness" of the node before - starting to perform queries; for example, it could check whether - only link-local IPv6 address(es) exists, or if at least one - global IPv6 address exists. - - - First, let us consider generic implications of unnecessary queries - for AAAA records: when looking up all the records in the DNS, AAAA - records are typically tried first, and then A records. These are - done in serial, and the A query is not performed until a response is - received to the AAAA query. Considering the misbehaviour of DNS - servers and load-balancers, as described in Section 3.1, the look-up - delay for AAAA may incur additional unnecessary latency, and - introduce a component of unreliability. - - - One option here could be to do the queries partially in parallel; for - example, if the final response to the AAAA query is not received in - 0.5 seconds, start performing the A query while waiting for the - result (immediate parallelism might be unoptimal, at least without - information sharing between the look-up threads, as that would - probably lead to duplicate non-cached delegation chain lookups). - - - An additional concern is the address selection, which may, in some - circumstances, prefer AAAA records over A records even when the node - does not have any IPv6 connectivity [I-D.ietf-v6ops-v6onbydefault]. - In some cases, the implementation may attempt to connect or send a - - - - -Durand, et al. Expires April 24, 2005 [Page 15] -Internet-Draft Considerations and Issues with IPv6 DNS October 2004 - - - - datagram on a physical link [I-D.ietf-v6ops-onlinkassumption], - incurring very long protocol timeouts, instead of quickly failing - back to IPv4. - - - Now, we can consider the issues specific to each of the three - possibilities: - - - In the first case, the node performs a number of completely useless - DNS lookups as it will not be able to use the returned AAAA records - anyway. (The only exception is where the application desires to know - what's in the DNS, but not use the result for communication.) One - should be able to disable these unnecessary queries, for both latency - and reliability reasons. However, as IPv6 has not been enabled, the - connections to IPv6 addresses fail immediately, and if the - application is programmed properly, the application can fall - gracefully back to IPv4 [I-D.ietf-v6ops-application-transition]. - - - The second case is similar to the first, except it happens to a - smaller set of nodes when IPv6 has been enabled but connectivity has - not been provided yet; similar considerations apply, with the - exception that IPv6 records, when returned, will be actually tried - first which may typically lead to long timeouts. - - - The third case is a bit more complex: optimizing away the DNS lookups - with only link-locals is probably safe (but may be desirable with - different lookup services which getaddrinfo() may support), as the - link-locals are typically automatically generated when IPv6 is - enabled, and do not indicate any form of IPv6 connectivity. That is, - performing DNS lookups only when a non-link-local address has been - configured on any interface could be beneficial -- this would be an - indication that either the address has been configured either from a - router advertisement, DHCPv6 [RFC3315], or manually. Each would - indicate at least some form of IPv6 connectivity, even though there - would not be guarantees of it. - - - These issues should be analyzed at more depth, and the fixes found - consensus on, perhaps in a separate document. - - -5.2 Obtaining a List of DNS Recursive Resolvers - - - In scenarios where DHCPv6 is available, a host can discover a list of - DNS recursive resolvers through DHCPv6 "DNS Recursive Name Server" - option [RFC3646]. This option can be passed to a host through a - subset of DHCPv6 [RFC3736]. - - - The IETF is considering the development of alternative mechanisms for - obtaining the list of DNS recursive name servers when DHCPv6 is - unavailable or inappropriate. No decision about taking on this - - - - -Durand, et al. Expires April 24, 2005 [Page 16] -Internet-Draft Considerations and Issues with IPv6 DNS October 2004 - - - - development work has been reached as of this writing (Aug 2004) - [I-D.ietf-dnsop-ipv6-dns-configuration]. - - - In scenarios where DHCPv6 is unavailable or inappropriate, mechanisms - under consideration for development include the use of well-known - addresses [I-D.ohta-preconfigured-dns] and the use of Router - Advertisements to convey the information - [I-D.jeong-dnsop-ipv6-dns-discovery]. - - - Note that even though IPv6 DNS resolver discovery is a recommended - procedure, it is not required for dual-stack nodes in dual-stack - networks as IPv6 DNS records can be queried over IPv4 as well as - IPv6. Obviously, nodes which are meant to function without manual - configuration in IPv6-only networks must implement the DNS resolver - discovery function. - - -5.3 IPv6 Transport Guidelines for Resolvers - - - As described in Section 1.3 and [RFC3901], the recursive resolvers - should be IPv4-only or dual-stack to be able to reach any IPv4-only - DNS server. Note that this requirement is also fulfilled by an - IPv6-only stub resolver pointing to a dual-stack recursive DNS - resolver. - - -6. Considerations about Forward DNS Updating - - - While the topic how to enable updating the forward DNS, i.e., the - mapping from names to the correct new addresses, is not specific to - IPv6, it should be considered especially due to the advent of - Stateless Address Autoconfiguration [RFC2462]. - - - Typically forward DNS updates are more manageable than doing them in - the reverse DNS, because the updater can often be assumed to "own" a - certain DNS name -- and we can create a form of security relationship - with the DNS name and the node which is allowed to update it to point - to a new address. - - - A more complex form of DNS updates -- adding a whole new name into a - DNS zone, instead of updating an existing name -- is considered out - of scope for this memo as it could require zone-wide authentication. - Adding a new name in the forward zone is a problem which is still - being explored with IPv4, and IPv6 does not seem to add much new in - that area. - - -6.1 Manual or Custom DNS Updates - - - The DNS mappings can also be maintained by hand, in a semi-automatic - fashion or by running non-standardized protocols. These are not - - - - -Durand, et al. Expires April 24, 2005 [Page 17] -Internet-Draft Considerations and Issues with IPv6 DNS October 2004 - - - - considered at more length in this memo. - - -6.2 Dynamic DNS - - - Dynamic DNS updates (DDNS) [RFC2136][RFC3007] is a standardized - mechanism for dynamically updating the DNS. It works equally well - with stateless address autoconfiguration (SLAAC), DHCPv6 or manual - address configuration. It is important to consider how each of these - behave if IP address-based authentication, instead of stronger - mechanisms [RFC3007], was used in the updates. - - - 1. manual addresses are static and can be configured - - - 2. DHCPv6 addresses could be reasonably static or dynamic, depending - on the deployment, and could or could not be configured on the - DNS server for the long term - - - 3. SLAAC addresses are typically stable for a long time, but could - require work to be configured and maintained. - - - As relying on IP addresses for Dynamic DNS is rather insecure at - best, stronger authentication should always be used; however, this - requires that the authorization keying will be explicitly configured - using unspecified operational methods. - - - Note that with DHCP it is also possible that the DHCP server updates - the DNS, not the host. The host might only indicate in the DHCP - exchange which hostname it would prefer, and the DHCP server would - make the appropriate updates. Nonetheless, while this makes setting - up a secure channel between the updater and the DNS server easier, it - does not help much with "content" security, i.e., whether the - hostname was acceptable -- if the DNS server does not include - policies, they must be included in the DHCP server (e.g., a regular - host should not be able to state that its name is "www.example.com"). - DHCP-initiated DDNS updates have been extensively described in - [I-D.ietf-dhc-ddns-resolution], [I-D.ietf-dhc-fqdn-option] and - [I-D.ietf-dnsext-dhcid-rr]. - - - The nodes must somehow be configured with the information about the - servers where they will attempt to update their addresses, sufficient - security material for authenticating themselves to the server, and - the hostname they will be updating. Unless otherwise configured, the - first could be obtained by looking up the authoritative name servers - for the hostname; the second must be configured explicitly unless one - chooses to trust the IP address-based authentication (not a good - idea); and lastly, the nodename is typically pre-configured somehow - on the node, e.g., at install time. - - - - - -Durand, et al. Expires April 24, 2005 [Page 18] -Internet-Draft Considerations and Issues with IPv6 DNS October 2004 - - - - Care should be observed when updating the addresses not to use longer - TTLs for addresses than are preferred lifetimes for the addresses, so - that if the node is renumbered in a managed fashion, the amount of - stale DNS information is kept to the minimum. That is, if the - preferred lifetime of an address expires, the TTL of the record needs - be modified unless it was already done before the expiration. For - better flexibility, the DNS TTL should be much shorter (e.g., a half - or a third) than the lifetime of an address; that way, the node can - start lowering the DNS TTL if it seems like the address has not been - renewed/refreshed in a while. Some discussion on how an - administrator could manage the DNS TTL is included in - [I-D.ietf-v6ops-renumbering-procedure]; this could be applied to - (smart) hosts as well. - - -7. Considerations about Reverse DNS Updating - - - Updating the reverse DNS zone may be difficult because of the split - authority over an address. However, first we have to consider the - applicability of reverse DNS in the first place. - - -7.1 Applicability of Reverse DNS - - - Today, some applications use reverse DNS to either look up some hints - about the topological information associated with an address (e.g. - resolving web server access logs), or as a weak form of a security - check, to get a feel whether the user's network administrator has - "authorized" the use of the address (on the premises that adding a - reverse record for an address would signal some form of - authorization). - - - One additional, maybe slightly more useful usage is ensuring that the - reverse and forward DNS contents match (by looking up the pointer to - the name by the IP address from the reverse tree, and ensuring that a - record under the name in the forward tree points to the IP address) - and correspond to a configured name or domain. As a security check, - it is typically accompanied by other mechanisms, such as a - user/password login; the main purpose of the reverse+forward DNS - check is to weed out the majority of unauthorized users, and if - someone managed to bypass the checks, he would still need to - authenticate "properly". - - - It may also be desirable to store IPsec keying material corresponding - to an IP address to the reverse DNS, as justified and described in - [I-D.ietf-ipseckey-rr]. - - - It is not clear whether it makes sense to require or recommend that - reverse DNS records be updated. In many cases, it would just make - more sense to use proper mechanisms for security (or topological - - - - -Durand, et al. Expires April 24, 2005 [Page 19] -Internet-Draft Considerations and Issues with IPv6 DNS October 2004 - - - - information lookup) in the first place. At minimum, the applications - which use it as a generic authorization (in the sense that a record - exists at all) should be modified as soon as possible to avoid such - lookups completely. - - - The applicability is discussed at more length in - [I-D.ietf-dnsop-inaddr-required]. - - -7.2 Manual or Custom DNS Updates - - - Reverse DNS can of course be updated using manual or custom methods. - These are not further described here, except for one special case. - - - One way to deploy reverse DNS would be to use wildcard records, for - example, by configuring one name for a subnet (/64) or a site (/48). - As a concrete example, a site (or the site's ISP) could configure the - reverses of the prefix 2001:db8:f00::/48 to point to one name using a - wildcard record like "*.0.0.f.0.8.b.d.0.1.0.0.2.ip6.arpa. IN PTR - site.example.com." Naturally, such a name could not be verified from - the forward DNS, but would at least provide some form of "topological - information" or "weak authorization" if that is really considered to - be useful. Note that this is not actually updating the DNS as such, - as the whole point is to avoid DNS updates completely by manually - configuring a generic name. - - -7.3 DDNS with Stateless Address Autoconfiguration - - - Dynamic reverse DNS with SLAAC is simpler than forward DNS updates in - some regard, while being more difficult in another, as described - below. - - - The address space administrator decides whether the hosts are trusted - to update their reverse DNS records or not. If they are trusted and - deployed at the same site (e.g., not across the Internet), a simple - address-based authorization is typically sufficient (i.e., check that - the DNS update is done from the same IP address as the record being - updated); stronger security can also be used [RFC3007]. If they - aren't allowed to update the reverses, no update can occur. However, - such address-based update authorization operationally requires that - ingress filtering [RFC3704] has been set up at the border of the site - where the updates occur, and as close to the updater as possible. - - - Address-based authorization is simpler with reverse DNS (as there is - a connection between the record and the address) than with forward - DNS. However, when a stronger form of security is used, forward DNS - updates are simpler to manage because the host can be assumed to have - an association with the domain. Note that the user may roam to - different networks, and does not necessarily have any association - - - - -Durand, et al. Expires April 24, 2005 [Page 20] -Internet-Draft Considerations and Issues with IPv6 DNS October 2004 - - - - with the owner of that address space -- so, assuming stronger form of - authorization for reverse DNS updates than an address association is - generally unfeasible. - - - Moreover, the reverse zones must be cleaned up by an unspecified - janitorial process: the node does not typically know a priori that it - will be disconnected, and cannot send a DNS update using the correct - source address to remove a record. - - - A problem with defining the clean-up process is that it is difficult - to ensure that a specific IP address and the corresponding record are - no longer being used. Considering the huge address space, and the - unlikelihood of collision within 64 bits of the interface - identifiers, a process which would remove the record after no traffic - has been seen from a node in a long period of time (e.g., a month or - year) might be one possible approach. - - - To insert or update the record, the node must discover the DNS server - to send the update to somehow, similar to as discussed in Section - 6.2. One way to automate this is looking up the DNS server - authoritative (e.g., through SOA record) for the IP address being - updated, but the security material (unless the IP address-based - authorization is trusted) must also be established by some other - means. - - - One should note that Cryptographically Generated Addresses - [I-D.ietf-send-cga] (CGAs) may require a slightly different kind of - treatment. CGAs are addresses where the interface identifier is - calculated from a public key, a modifier (used as a nonce), the - subnet prefix, and other data. Depending on the usage profile, CGAs - might or might not be changed periodically due to e.g., privacy - reasons. As the CGA address is not predicatable, a reverse record - can only reasonably be inserted in the DNS by the node which - generates the address. - - -7.4 DDNS with DHCP - - - With DHCPv4, the reverse DNS name is typically already inserted to - the DNS that reflects to the name (e.g., "dhcp-67.example.com"). One - can assume similar practice may become commonplace with DHCPv6 as - well; all such mappings would be pre-configured, and would require no - updating. - - - If a more explicit control is required, similar considerations as - with SLAAC apply, except for the fact that typically one must update - a reverse DNS record instead of inserting one (if an address - assignment policy that reassigns disused addresses is adopted) and - updating a record seems like a slightly more difficult thing to - - - - -Durand, et al. Expires April 24, 2005 [Page 21] -Internet-Draft Considerations and Issues with IPv6 DNS October 2004 - - - - secure. However, it is yet uncertain how DHCPv6 is going to be used - for address assignment. - - - Note that when using DHCP, either the host or the DHCP server could - perform the DNS updates; see the implications in Section 6.2. - - - If disused addresses were to be reassigned, host-based DDNS reverse - updates would need policy considerations for DNS record modification, - as noted above. On the other hand, if disused address were not to be - assigned, host-based DNS reverse updates would have similar - considerations as SLAAC in Section 7.3. Server-based updates have - similar properties except that the janitorial process could be - integrated with DHCP address assignment. - - -7.5 DDNS with Dynamic Prefix Delegation - - - In cases where a prefix, instead of an address, is being used and - updated, one should consider what is the location of the server where - DDNS updates are made. That is, where the DNS server is located: - - - 1. At the same organization as the prefix delegator. - - - 2. At the site where the prefixes are delegated to. In this case, - the authority of the DNS reverse zone corresponding to the - delegated prefix is also delegated to the site. - - - 3. Elsewhere; this implies a relationship between the site and where - DNS server is located, and such a relationship should be rather - straightforward to secure as well. Like in the previous case, - the authority of the DNS reverse zone is also delegated. - - - In the first case, managing the reverse DNS (delegation) is simpler - as the DNS server and the prefix delegator are in the same - administrative domain (as there is no need to delegate anything at - all); alternatively, the prefix delegator might forgo DDNS reverse - capability altogether, and use e.g., wildcard records (as described - in Section 7.2). In the other cases, it can be slighly more - difficult, particularly as the site will have to configure the DNS - server to be authoritative for the delegated reverse zone, implying - automatic configuration of the DNS server -- as the prefix may be - dynamic. - - - Managing the DDNS reverse updates is typically simple in the second - case, as the updated server is located at the local site, and - arguably IP address-based authentication could be sufficient (or if - not, setting up security relationships would be simpler). As there - is an explicit (security) relationship between the parties in the - third case, setting up the security relationships to allow reverse - - - - -Durand, et al. Expires April 24, 2005 [Page 22] -Internet-Draft Considerations and Issues with IPv6 DNS October 2004 - - - - DDNS updates should be rather straightforward as well (but IP - address-based authentication might not be acceptable). In the first - case, however, setting up and managing such relationships might be a - lot more difficult. - - -8. Miscellaneous DNS Considerations - - - This section describes miscellaneous considerations about DNS which - seem related to IPv6, for which no better place has been found in - this document. - - -8.1 NAT-PT with DNS-ALG - - - The DNS-ALG component of NAT-PT mangles A records to look like AAAA - records to the IPv6-only nodes. Numerous problems have been - identified with DNS-ALG [I-D.durand-v6ops-natpt-dns-alg-issues]. - This is a strong reason not to use NAT-PT in the first place. - - -8.2 Renumbering Procedures and Applications' Use of DNS - - - One of the most difficult problems of systematic IP address - renumbering procedures [I-D.ietf-v6ops-renumbering-procedure] is that - an application which looks up a DNS name disregards information such - as TTL, and uses the result obtained from DNS as long as it happens - to be stored in the memory of the application. For applications - which run for a long time, this could be days, weeks or even months; - some applications may be clever enough to organize the data - structures and functions in such a manner that look-ups get refreshed - now and then. - - - While the issue appears to have a clear solution, "fix the - applications", practically this is not reasonable immediate advice; - the TTL information is not typically available in the APIs and - libraries (so, the advice becomes "fix the applications, APIs and - libraries"), and a lot more analysis is needed on how to practically - go about to achieve the ultimate goal of avoiding using the names - longer than expected. - - -9. Acknowledgements - - - Some recommendations (Section 4.3, Section 5.1) about IPv6 service - provisioning were moved here from [I-D.ietf-v6ops-mech-v2] by Erik - Nordmark and Bob Gilligan. Havard Eidnes and Michael Patton provided - useful feedback and improvements. Scott Rose, Rob Austein, Masataka - Ohta, and Mark Andrews helped in clarifying the issues regarding - additional data and the use of TTL. Jefsey Morfin, Ralph Droms, - Peter Koch, Jinmei Tatuya, Iljitsch van Beijnum, Edward Lewis, and - Rob Austein provided useful feedback during the WG last call. Thomas - - - - -Durand, et al. Expires April 24, 2005 [Page 23] -Internet-Draft Considerations and Issues with IPv6 DNS October 2004 - - - - Narten provided extensive feedback during the IESG evaluation. - - -10. Security Considerations - - - This document reviews the operational procedures for IPv6 DNS - operations and does not have security considerations in itself. - - - However, it is worth noting that in particular with Dynamic DNS - Updates, security models based on the source address validation are - very weak and cannot be recommended -- they could only be considered - in the environments where ingress filtering [RFC3704] has been - deployed. On the other hand, it should be noted that setting up an - authorization mechanism (e.g., a shared secret, or public-private - keys) between a node and the DNS server has to be done manually, and - may require quite a bit of time and expertise. - - - To re-emphasize which was already stated, the reverse+forward DNS - check provides very weak security at best, and the only - (questionable) security-related use for them may be in conjunction - with other mechanisms when authenticating a user. - - -11. References - - -11.1 Normative References - - - [I-D.ietf-dnsop-ipv6-dns-configuration] - Jeong, J., "IPv6 Host Configuration of DNS Server - Information Approaches", - draft-ietf-dnsop-ipv6-dns-configuration-04 (work in - progress), September 2004. - - - [I-D.ietf-dnsop-misbehavior-against-aaaa] - Morishita, Y. and T. Jinmei, "Common Misbehavior against - DNS Queries for IPv6 Addresses", - draft-ietf-dnsop-misbehavior-against-aaaa-01 (work in - progress), April 2004. - - - [I-D.ietf-v6ops-application-transition] - Shin, M., "Application Aspects of IPv6 Transition", - draft-ietf-v6ops-application-transition-03 (work in - progress), June 2004. - - - [I-D.ietf-v6ops-renumbering-procedure] - Baker, F., Lear, E. and R. Droms, "Procedures for - Renumbering an IPv6 Network without a Flag Day", - draft-ietf-v6ops-renumbering-procedure-01 (work in - progress), July 2004. - - - - - -Durand, et al. Expires April 24, 2005 [Page 24] -Internet-Draft Considerations and Issues with IPv6 DNS October 2004 - - - - [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", - STD 13, RFC 1034, November 1987. - - - [RFC2136] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic - Updates in the Domain Name System (DNS UPDATE)", RFC 2136, - April 1997. - - - [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS - Specification", RFC 2181, July 1997. - - - [RFC2182] Elz, R., Bush, R., Bradner, S. and M. Patton, "Selection - and Operation of Secondary DNS Servers", BCP 16, RFC 2182, - July 1997. - - - [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address - Autoconfiguration", RFC 2462, December 1998. - - - [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC - 2671, August 1999. - - - [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic - Update", RFC 3007, November 2000. - - - [RFC3041] Narten, T. and R. Draves, "Privacy Extensions for - Stateless Address Autoconfiguration in IPv6", RFC 3041, - January 2001. - - - [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains - via IPv4 Clouds", RFC 3056, February 2001. - - - [RFC3152] Bush, R., "Delegation of IP6.ARPA", BCP 49, RFC 3152, - August 2001. - - - [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and - M. Carney, "Dynamic Host Configuration Protocol for IPv6 - (DHCPv6)", RFC 3315, July 2003. - - - [RFC3363] Bush, R., Durand, A., Fink, B., Gudmundsson, O. and T. - Hain, "Representing Internet Protocol version 6 (IPv6) - Addresses in the Domain Name System (DNS)", RFC 3363, - August 2002. - - - [RFC3364] Austein, R., "Tradeoffs in Domain Name System (DNS) - Support for Internet Protocol version 6 (IPv6)", RFC 3364, - August 2002. - - - [RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 - (IPv6) Addressing Architecture", RFC 3513, April 2003. - - - - -Durand, et al. Expires April 24, 2005 [Page 25] -Internet-Draft Considerations and Issues with IPv6 DNS October 2004 - - - - [RFC3596] Thomson, S., Huitema, C., Ksinant, V. and M. Souissi, "DNS - Extensions to Support IP Version 6", RFC 3596, October - 2003. - - - [RFC3646] Droms, R., "DNS Configuration options for Dynamic Host - Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, - December 2003. - - - [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol - (DHCP) Service for IPv6", RFC 3736, April 2004. - - - [RFC3879] Huitema, C. and B. Carpenter, "Deprecating Site Local - Addresses", RFC 3879, September 2004. - - - [RFC3901] Durand, A. and J. Ihren, "DNS IPv6 Transport Operational - Guidelines", BCP 91, RFC 3901, September 2004. - - -11.2 Informative References - - - [I-D.durand-v6ops-natpt-dns-alg-issues] - Durand, A., "Issues with NAT-PT DNS ALG in RFC2766", - draft-durand-v6ops-natpt-dns-alg-issues-00 (work in - progress), February 2003. - - - [I-D.huitema-v6ops-teredo] - Huitema, C., "Teredo: Tunneling IPv6 over UDP through - NATs", draft-huitema-v6ops-teredo-02 (work in progress), - June 2004. - - - [I-D.huston-6to4-reverse-dns] - Huston, G., "6to4 Reverse DNS Delegation", - draft-huston-6to4-reverse-dns-03 (work in progress), - October 2004. - - - [I-D.ietf-dhc-ddns-resolution] - Stapp, M., "Resolution of DNS Name Conflicts Among DHCP - Clients", draft-ietf-dhc-ddns-resolution-08 (work in - progress), October 2004. - - - [I-D.ietf-dhc-fqdn-option] - Stapp, M. and Y. Rekhter, "The DHCP Client FQDN Option", - draft-ietf-dhc-fqdn-option-07 (work in progress), July - 2004. - - - [I-D.ietf-dnsext-dhcid-rr] - Stapp, M., Lemon, T. and A. Gustafsson, "A DNS RR for - encoding DHCP information (DHCID RR)", - draft-ietf-dnsext-dhcid-rr-08 (work in progress), July - - - - -Durand, et al. Expires April 24, 2005 [Page 26] -Internet-Draft Considerations and Issues with IPv6 DNS October 2004 - - - - 2004. - - - [I-D.ietf-dnsop-bad-dns-res] - Larson, M. and P. Barber, "Observed DNS Resolution - Misbehavior", draft-ietf-dnsop-bad-dns-res-02 (work in - progress), July 2004. - - - [I-D.ietf-dnsop-dontpublish-unreachable] - Hazel, P., "IP Addresses that should never appear in the - public DNS", draft-ietf-dnsop-dontpublish-unreachable-03 - (work in progress), February 2002. - - - [I-D.ietf-dnsop-inaddr-required] - Senie, D., "Requiring DNS IN-ADDR Mapping", - draft-ietf-dnsop-inaddr-required-05 (work in progress), - April 2004. - - - [I-D.ietf-ipseckey-rr] - Richardson, M., "A method for storing IPsec keying - material in DNS", draft-ietf-ipseckey-rr-11 (work in - progress), July 2004. - - - [I-D.ietf-ipv6-unique-local-addr] - Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast - Addresses", draft-ietf-ipv6-unique-local-addr-06 (work in - progress), September 2004. - - - [I-D.ietf-send-cga] - Aura, T., "Cryptographically Generated Addresses (CGA)", - draft-ietf-send-cga-06 (work in progress), April 2004. - - - [I-D.ietf-v6ops-3gpp-analysis] - Wiljakka, J., "Analysis on IPv6 Transition in 3GPP - Networks", draft-ietf-v6ops-3gpp-analysis-10 (work in - progress), May 2004. - - - [I-D.ietf-v6ops-mech-v2] - Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms - for IPv6 Hosts and Routers", draft-ietf-v6ops-mech-v2-06 - (work in progress), September 2004. - - - [I-D.ietf-v6ops-onlinkassumption] - Roy, S., Durand, A. and J. Paugh, "IPv6 Neighbor Discovery - On-Link Assumption Considered Harmful", - draft-ietf-v6ops-onlinkassumption-02 (work in progress), - May 2004. - - - [I-D.ietf-v6ops-v6onbydefault] - - - - -Durand, et al. Expires April 24, 2005 [Page 27] -Internet-Draft Considerations and Issues with IPv6 DNS October 2004 - - - - Roy, S., Durand, A. and J. Paugh, "Issues with Dual Stack - IPv6 on by Default", draft-ietf-v6ops-v6onbydefault-03 - (work in progress), July 2004. - - - [I-D.jeong-dnsop-ipv6-dns-discovery] - Jeong, J., "IPv6 DNS Discovery based on Router - Advertisement", draft-jeong-dnsop-ipv6-dns-discovery-02 - (work in progress), July 2004. - - - [I-D.moore-6to4-dns] - Moore, K., "6to4 and DNS", draft-moore-6to4-dns-03 (work - in progress), October 2002. - - - [I-D.ohta-preconfigured-dns] - Ohta, M., "Preconfigured DNS Server Addresses", - draft-ohta-preconfigured-dns-01 (work in progress), - February 2004. - - - [I-D.savola-v6ops-6bone-mess] - Savola, P., "Moving from 6bone to IPv6 Internet", - draft-savola-v6ops-6bone-mess-01 (work in progress), - November 2002. - - - [RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address - Translation - Protocol Translation (NAT-PT)", RFC 2766, - February 2000. - - - [RFC2782] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for - specifying the location of services (DNS SRV)", RFC 2782, - February 2000. - - - [RFC2826] Internet Architecture Board, "IAB Technical Comment on the - Unique DNS Root", RFC 2826, May 2000. - - - [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed - Networks", BCP 84, RFC 3704, March 2004. - - - -Authors' Addresses - - - Alain Durand - SUN Microsystems, Inc. - 17 Network circle UMPL17-202 - Menlo Park, CA 94025 - USA - - - EMail: Alain.Durand@sun.com - - - - - -Durand, et al. Expires April 24, 2005 [Page 28] -Internet-Draft Considerations and Issues with IPv6 DNS October 2004 - - - - Johan Ihren - Autonomica - Bellmansgatan 30 - SE-118 47 Stockholm - Sweden - - - EMail: johani@autonomica.se - - - - Pekka Savola - CSC/FUNET - Espoo - Finland - - - EMail: psavola@funet.fi - - -Appendix A. Site-local Addressing Considerations for DNS - - - As site-local addressing has been deprecated, the considerations for - site-local addressing are discussed briefly here. Unique local - addressing format [I-D.ietf-ipv6-unique-local-addr] has been proposed - as a replacement, but being work-in-progress, it is not considered - further. - - - The interactions with DNS come in two flavors: forward and reverse - DNS. - - - To actually use site-local addresses within a site, this implies the - deployment of a "split-faced" or a fragmented DNS name space, for the - zones internal to the site, and the outsiders' view to it. The - procedures to achieve this are not elaborated here. The implication - is that site-local addresses must not be published in the public DNS. - - - To faciliate reverse DNS (if desired) with site-local addresses, the - stub resolvers must look for DNS information from the local DNS - servers, not e.g. starting from the root servers, so that the - site-local information may be provided locally. Note that the - experience of private addresses in IPv4 has shown that the root - servers get loaded for requests for private address lookups in any - case. - - - - - - - - - - - - -Durand, et al. Expires April 24, 2005 [Page 29] -Internet-Draft Considerations and Issues with IPv6 DNS 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. - - - - - -Durand, et al. Expires April 24, 2005 [Page 30] \ No newline at end of file diff --git a/doc/draft/draft-ietf-dnsop-respsize-01.txt b/doc/draft/draft-ietf-dnsop-respsize-01.txt deleted file mode 100644 index f6ece882103..00000000000 --- a/doc/draft/draft-ietf-dnsop-respsize-01.txt +++ /dev/null @@ -1,485 +0,0 @@ - DNSOP Working Group Paul Vixie, ISC (Ed.) - INTERNET-DRAFT Akira Kato, WIDE - July, 2004 - - - DNS Response Size Issues - - - 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 we are aware have been or will be disclosed, and any of which - we 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. - - - Copyright Notice - - - Copyright (C) The Internet Society (2003-2004). All Rights Reserved. - - - - - - Abstract - - - With a mandated default minimum maximum message size of 512 octets, - the DNS protocol presents some special problems for zones wishing to - expose a moderate or high number of authority servers (NS RRs). This - document explains the operational issues caused by, or related to - this response size limit. - - - - - - - Expires December 2004 [Page 1] - INTERNET-DRAFT June 2003 RESPSIZE - - - - 1 - Introduction and Overview - - - 1.1. The DNS standard (see [RFC1035 4.2.1]) limits message size to 512 - octets. Even though this limitation was due to the required minimum UDP - reassembly limit for IPv4, it is a hard DNS protocol limit and is not - implicitly relaxed by changes in transport, for example to IPv6. - - - 1.2. The EDNS0 standard (see [RFC2671 2.3, 4.5]) permits larger - responses by mutual agreement of the requestor and responder. However, - deployment of EDNS0 cannot be expected to reach every Internet resolver - in the short or medium term. The 512 octet message size limit remains - in practical effect at this time. - - - 1.3. Since DNS responses include a copy of the request, the space - available for response data is somewhat less than the full 512 octets. - For negative responses, there is rarely a space constraint. For - positive and delegation responses, though, every octet must be carefully - and sparingly allocated. This document specifically addresses - delegation response sizes. - - - 2 - Delegation Details - - - 2.1. A delegation response will include the following elements: - - - Header Section: fixed length (12 octets) - Question Section: original query (name, class, type) - Answer Section: (empty) - Authority Section: NS RRset (nameserver names) - Additional Section: A and AAAA RRsets (nameserver addresses) - - - 2.2. If the total response size would exceed 512 octets, and if the data - that would not fit was in the question, answer, or authority section, - then the TC bit will be set (indicating truncation) which may cause the - requestor to retry using TCP, depending on what information was present - and what was omitted. If a retry using TCP is needed, the total cost of - the transaction is much higher. - - - 2.3. RRsets are never sent partially, so if truncation occurs, entire - RRsets are omitted. Note that the authority section consists of a - single RRset. It is absolutely essential that truncation not occur in - the authority section. - - - - - - - - - Expires December 2004 [Page 2] - INTERNET-DRAFT June 2003 RESPSIZE - - - - 2.4. DNS label compression allows a domain name to be instantiated only - once per DNS message, and then referenced with a two-octet "pointer" - from other locations in that same DNS message. If all nameserver names - in a message are similar (for example, all ending in ".ROOT- - SERVERS.NET"), then more space will be available for uncompressable data - (such as nameserver addresses). - - - 2.5. The query name can be as long as 255 characters of presentation - data, which can be up to 256 octets of network data. In this worst case - scenario, the question section will be 260 octets in size, which would - leave only 240 octets for the authority and additional sections (after - deducting 12 octets for the fixed length header.) - - - 2.6. Average and maximum question section sizes can be predicted by the - zone owner, since they will know what names actually exist, and can - measure which ones are queried for most often. For cost and performance - reasons, the majority of requests should be satisfied without truncation - or TCP retry. - - - 2.7. Requestors who deliberately send large queries to force truncation - are only increasing their own costs, and cannot effectively attack the - resources of an authority server since the requestor would have to retry - using TCP to complete the attack. An attack that always used TCP would - have a lower cost. - - - 2.8. The minimum useful number of address records is two, since with - only one address, the probability that it would refer to an unreachable - server is too high. Truncation which occurs after two address records - have been added to the additional data section is therefore less - operationally significant than truncation which occurs earlier. - - - 2.9. The best case is no truncation. (This is because many requestors - will retry using TCP by reflex, without considering whether the omitted - data was actually necessary.) - - - - - - - - - - - - - - - - Expires December 2004 [Page 3] - INTERNET-DRAFT June 2003 RESPSIZE - - - - 3 - Analysis - - - 3.1. An instrumented protocol trace of a best case delegation response - follows. Note that 13 servers are named, and 13 addresses are given. - This query was artificially designed to exactly reach the 512 octet - limit. - - - ;; flags: qr rd; QUERY: 1, ANS: 0, AUTH: 13, ADDIT: 13 - ;; QUERY SECTION: - ;; [23456789.123456789.123456789.\ - 123456789.123456789.123456789.com A IN] ;; @80 - - - ;; AUTHORITY SECTION: - com. 86400 NS E.GTLD-SERVERS.NET. ;; @112 - com. 86400 NS F.GTLD-SERVERS.NET. ;; @128 - com. 86400 NS G.GTLD-SERVERS.NET. ;; @144 - com. 86400 NS H.GTLD-SERVERS.NET. ;; @160 - com. 86400 NS I.GTLD-SERVERS.NET. ;; @176 - com. 86400 NS J.GTLD-SERVERS.NET. ;; @192 - com. 86400 NS K.GTLD-SERVERS.NET. ;; @208 - com. 86400 NS L.GTLD-SERVERS.NET. ;; @224 - com. 86400 NS M.GTLD-SERVERS.NET. ;; @240 - com. 86400 NS A.GTLD-SERVERS.NET. ;; @256 - com. 86400 NS B.GTLD-SERVERS.NET. ;; @272 - com. 86400 NS C.GTLD-SERVERS.NET. ;; @288 - com. 86400 NS D.GTLD-SERVERS.NET. ;; @304 - - - ;; ADDITIONAL SECTION: - A.GTLD-SERVERS.NET. 86400 A 192.5.6.30 ;; @320 - B.GTLD-SERVERS.NET. 86400 A 192.33.14.30 ;; @336 - C.GTLD-SERVERS.NET. 86400 A 192.26.92.30 ;; @352 - D.GTLD-SERVERS.NET. 86400 A 192.31.80.30 ;; @368 - E.GTLD-SERVERS.NET. 86400 A 192.12.94.30 ;; @384 - F.GTLD-SERVERS.NET. 86400 A 192.35.51.30 ;; @400 - G.GTLD-SERVERS.NET. 86400 A 192.42.93.30 ;; @416 - H.GTLD-SERVERS.NET. 86400 A 192.54.112.30 ;; @432 - I.GTLD-SERVERS.NET. 86400 A 192.43.172.30 ;; @448 - J.GTLD-SERVERS.NET. 86400 A 192.48.79.30 ;; @464 - K.GTLD-SERVERS.NET. 86400 A 192.52.178.30 ;; @480 - L.GTLD-SERVERS.NET. 86400 A 192.41.162.30 ;; @496 - M.GTLD-SERVERS.NET. 86400 A 192.55.83.30 ;; @512 - - - ;; MSG SIZE sent: 80 rcvd: 512 - - - - - - - Expires December 2004 [Page 4] - INTERNET-DRAFT June 2003 RESPSIZE - - - - 3.2. For longer query names, the number of address records supplied will - be lower. Furthermore, it is only by using a common parent name (which - is GTLD-SERVERS.NET in this example) that all 13 addresses are able to - fit. The following output from a response simulator demonstrates these - properties: - - - % perl respsize.pl 13 13 0 - common name, average case: msg:303 nsaddr#13 (green) - common name, worst case: msg:495 nsaddr# 1 (red) - uncommon name, average case: msg:457 nsaddr# 3 (orange) - uncommon name, worst case: msg:649(*) nsaddr# 0 (red) - % perl respsize.pl 13 13 2 - common name, average case: msg:303 nsaddr#11 (orange) - common name, worst case: msg:495 nsaddr# 1 (red) - uncommon name, average case: msg:457 nsaddr# 2 (orange) - uncommon name, worst case: msg:649(*) nsaddr# 0 (red) - - - (Note: The response simulator program is shown in Section 5.) - - - Here we use the term "green" if all address records could fit, or - "orange" if two or more could fit, or "red" if fewer than two could fit. - It's clear that without a common parent for nameserver names, much space - would be lost. - - - We're assuming an average query name size of 64 since that is the - typical average maximum size seen in trace data at the time of this - writing. If Internationalized Domain Name (IDN) or any other technology - which results in larger query names be deployed significantly in advance - of EDNS, then more new measurements and new estimates will have to be - made. - - - 4 - Conclusions - - - 4.1. The current practice of giving all nameserver names a common parent - (such as GTLD-SERVERS.NET or ROOT-SERVERS.NET) saves space in DNS - responses and allows for more nameservers to be enumerated than would - otherwise be possible. (Note that in this case it is wise to serve the - common parent domain's zone from the same servers that are named within - it, in order to limit external dependencies when all your eggs are in a - single basket.) - - - 4.2. Thirteen (13) seems to be the effective maximum number of - nameserver names usable traditional (non-extended) DNS, assuming a - common parent domain name, and assuming that additional-data truncation - is undesirable in the average case. - - - - - Expires December 2004 [Page 5] - INTERNET-DRAFT June 2003 RESPSIZE - - - - 4.3. Adding two to five IPv6 nameserver address records (AAAA RRs) to a - prototypical delegation that currently contains thirteen (13) IPv4 - nameserver addresses (A RRs) for thirteen (13) nameserver names under a - common parent, would not have a significant negative operational impact - on the domain name system. - - - 5 - Source Code - - - #!/usr/bin/perl -w - - - $asize = 2+2+2+4+2+4; - $aaaasize = 2+2+2+4+2+16; - ($nns, $na, $naaaa) = @ARGV; - test("common", "average", common_name_average($nns), - $na, $naaaa); - test("common", "worst", common_name_worst($nns), - $na, $naaaa); - test("uncommon", "average", uncommon_name_average($nns), - $na, $naaaa); - test("uncommon", "worst", uncommon_name_worst($nns), - $na, $naaaa); - exit 0; - - - sub test { my ($namekind, $casekind, $msg, $na, $naaaa) = @_; - my $nglue = numglue($msg, $na, $naaaa); - printf "%8s name, %7s case: msg:%3d%s nsaddr#%2d (%s)\n", - $namekind, $casekind, - $msg, ($msg > 512) ? "(*)" : " ", - $nglue, ($nglue == $na + $naaaa) ? "green" - : ($nglue >= 2) ? "orange" - : "red"; - } - - - sub pnum { my ($num, $tot) = @_; - return sprintf "%3d%s", - } - - - sub numglue { my ($msg, $na, $naaaa) = @_; - my $space = ($msg > 512) ? 0 : (512 - $msg); - my $num = 0; - - - while ($space && ($na || $naaaa )) { - if ($na) { - if ($space >= $asize) { - $space -= $asize; - - - - - Expires December 2004 [Page 6] - INTERNET-DRAFT June 2003 RESPSIZE - - - - $num++; - } - $na--; - } - if ($naaaa) { - if ($space >= $aaaasize) { - $space -= $aaaasize; - $num++; - } - $naaaa--; - } - } - return $num; - } - - - sub msgsize { my ($qname, $nns, $nsns) = @_; - return 12 + # header - $qname+2+2 + # query - 0 + # answer - $nns * (4+2+2+4+2+$nsns); # authority - } - - - sub average_case { my ($nns, $nsns) = @_; - return msgsize(64, $nns, $nsns); - } - - - sub worst_case { my ($nns, $nsns) = @_; - return msgsize(256, $nns, $nsns); - } - - - sub common_name_average { my ($nns) = @_; - return 15 + average_case($nns, 2); - } - - - sub common_name_worst { my ($nns) = @_; - return 15 + worst_case($nns, 2); - } - - - sub uncommon_name_average { my ($nns) = @_; - return average_case($nns, 15); - } - - - sub uncommon_name_worst { my ($nns) = @_; - return worst_case($nns, 15); - } - - - - - Expires December 2004 [Page 7] - INTERNET-DRAFT June 2003 RESPSIZE - - - - Security Considerations - - - The recommendations contained in this document have no known security - implications. - - - IANA Considerations - - - This document does not call for changes or additions to any IANA - registry. - - - IPR Statement - - - Copyright (C) The Internet Society (2003-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. - - - Authors' Addresses - - - Paul Vixie - 950 Charter Street - Redwood City, CA 94063 - +1 650 423 1301 - vixie@isc.org - - - Akira Kato - University of Tokyo, Information Technology Center - 2-11-16 Yayoi Bunkyo - Tokyo 113-8658, JAPAN - +81 3 5841 2750 - kato@wide.ad.jp - - - - - - - - - - - Expires December 2004 [Page 8] \ No newline at end of file diff --git a/doc/draft/draft-ietf-dnsop-serverid-02.txt b/doc/draft/draft-ietf-dnsop-serverid-02.txt deleted file mode 100644 index b593c57179e..00000000000 --- a/doc/draft/draft-ietf-dnsop-serverid-02.txt +++ /dev/null @@ -1,617 +0,0 @@ - - -Network Working Group S. Woolf -Internet-Draft Internet Systems Consortium, Inc. -Expires: January 16, 2005 D. Conrad - Nominum, Inc. - July 18, 2004 - - - Identifying an Authoritative Name `Server - draft-ietf-dnsop-serverid-02 - -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 January 16, 2005. - -Copyright Notice - - Copyright (C) The Internet Society (2004). All Rights Reserved. - -Abstract - - With the increased use of DNS anycast, load balancing, and other - mechanisms allowing more than one DNS name server to share a single - IP address, it is sometimes difficult to tell which of a pool of name - servers has answered a particular query. A standardized mechanism to - determine the identity of a name server responding to a particular - query would be useful, particularly as a diagnostic aid. Existing ad - - - -Woolf & Conrad Expires January 16, 2005 [Page 1] - -Internet-Draft Identifying an Authoritative Name `Server July 2004 - - - hoc mechanisms for addressing this concern are not adequate. This - document attempts to describe the common ad hoc solution to this - problem, including its advantages and disadvantasges, and to - characterize an improved mechanism. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Woolf & Conrad Expires January 16, 2005 [Page 2] - -Internet-Draft Identifying an Authoritative Name `Server July 2004 - - -1. Introduction - - With the increased use of DNS anycast, load balancing, and other - mechanisms allowing more than one DNS name server to share a single - IP address, it is sometimes difficult to tell which of a pool of name - servers has answered a particular query. A standardized mechanism to - determine the identity of a name server responding to a particular - query would be useful, particularly as a diagnostic aid. - - Unfortunately, existing ad-hoc mechanisms for providing such - identification have some shortcomings, not the least of which is the - lack of prior analysis of exactly how such a mechanism should be - designed and deployed. This document describes the existing - convention used in one widely deployed implementation of the DNS - protocol and discusses requirements for an improved solution to the - problem. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Woolf & Conrad Expires January 16, 2005 [Page 3] - -Internet-Draft Identifying an Authoritative Name `Server July 2004 - - -2. Rationale - - Identifying which name server is responding to queries is often - useful, particularly in attempting to diagnose name server - difficulties. However, relying on the IP address of the name server - has become more problematic due the deployment of various load - balancing solutions, including the use of shared unicast addresses as - documented in [RFC3258]. - - An unfortunate side effect of these load balancing solutions is that - traditional methods of determining which server is responding can be - unreliable. Specifically, non-DNS methods such as ICMP ping, TCP - connections, or non-DNS UDP packets (e.g., as generated by tools such - as "traceroute"), etc., can end up going to a different server than - that which receives the DNS queries. - - The widespread use of the existing convention suggests a need for a - documented, interoperable means of querying the identity of a - nameserver that may be part of an anycast or load-balancing cluster. - At the same time, however, it also has some drawbacks that argue - against standardizing it as it's been practiced so far. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Woolf & Conrad Expires January 16, 2005 [Page 4] - -Internet-Draft Identifying an Authoritative Name `Server July 2004 - - -3. Existing Conventions - - Recent versions of the commonly deployed Berkeley Internet Name - Domain implementation of the DNS protocol suite from the Internet - Software Consortium [BIND] support a way of identifying a particular - server via the use of a standard, if somewhat unusual, DNS query. - Specifically, a query to a late model BIND server for a TXT resource - record in class 3 (CHAOS) for the domain name "HOSTNAME.BIND." will - return a string that can be configured by the name server - administrator to provide a unique identifier for the responding - server (defaulting to the value of a gethostname() call). This - mechanism, which is an extension of the BIND convention of using - CHAOS class TXT RR queries to sub-domains of the "BIND." domain for - version information, has been copied by several name server vendors. - - For reference, the other well-known name used by recent versions of - BIND within the CHAOS class "BIND." domain is "VERSION.BIND." A - query for a TXT RR for this name will return an administratively re- - definable string which defaults to the version of the server - responding. - -3.1 Advantages - - There are several valuable attributes to this mechanism, which - account for its usefulness. - 1. This mechanism is within the DNS protocol itself. An - identification mechanism that relies on the DNS protocol is more - likely to be successful (although not guaranteed) in going to the - same machine as a "normal" DNS query. - 2. It is simple to configure. An administrator can easily turn on - this feature and control the results of the relevant query. - 3. It allows the administrator complete control of what information - is given out in the response, minimizing passive leakage of - implementation or configuration details. Such details are often - considered sensitive by infrastructure operators. - -3.2 Disadvantages - - At the same time, there are some forbidding drawbacks to the - VERSION.BIND mechanism that argue against standardizing it as it - currently operates. - 1. It requires an additional query to correlate between the answer - to a DNS query under normal conditions and the supposed identity - of the server receiving the query. There are a number of - situations in which this simply isn't reliable. - 2. It reserves an entire class in the DNS (CHAOS) for what amounts - to one zone. While CHAOS class is defined in [RFC1034] and - [RFC1035], it's not clear that supporting it solely for this - - - -Woolf & Conrad Expires January 16, 2005 [Page 5] - -Internet-Draft Identifying an Authoritative Name `Server July 2004 - - - purpose is a good use of the namespace or of implementation - effort. - 3. It is implementation specific. BIND is one DNS implementation. - At the time of this writing, it is probably the most prevalent, - for authoritative servers anyway. This does not justify - standardizing on its ad hoc solution to a problem shared across - many operators and implementors. - - The first of the listed disadvantages is technically the most - serious. It argues for an attempt to design a good answer to the - problem that "I need to know what nameserver is answering my - queries", not simply a convenient one. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Woolf & Conrad Expires January 16, 2005 [Page 6] - -Internet-Draft Identifying an Authoritative Name `Server July 2004 - - -4. Characteristics of an Implementation Neutral Convention - - The discussion above of advantages and disadvantages to the - HOSTNAME.BIND mechanism suggest some requirements for a better - solution to the server identification problem. These are summarized - here as guidelines for any effort to provide appropriate protocol - extensions: - 1. The mechanism adopted MUST be in-band for the DNS protocol. That - is, it needs to allow the query for the server's identifying - information to be part of a normal, operational query. It SHOULD - also permit a separate, dedicated query for the server's - identifying information. - 2. The new mechanism should not require dedicated namespaces or - other reserved values outside of the existing protocol mechanisms - for these, i.e. the OPT pseudo-RR. - 3. Support for the identification functionality SHOULD be easy to - implement and easy to enable. It MUST be easy to disable and - SHOULD lend itself to access controls on who can query for it. - 4. It should be possible to return a unique identifier for a server - without requiring the exposure of information that may be - non-public and considered sensitive by the operator, such as a - hostname or unicast IP address maintained for administrative - purposes. - 5. The identification mechanism SHOULD NOT be - implementation-specific. - - - - - - - - - - - - - - - - - - - - - - - - - - -Woolf & Conrad Expires January 16, 2005 [Page 7] - -Internet-Draft Identifying an Authoritative Name `Server July 2004 - - -5. IANA Considerations - - This document proposes no specific IANA action. Protocol extensions, - if any, to meet the requirements described are out of scope for this - document. Should such extensions be specified and adopted by normal - IETF process, the specification will include appropriate guidance to - IANA. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Woolf & Conrad Expires January 16, 2005 [Page 8] - -Internet-Draft Identifying an Authoritative Name `Server July 2004 - - -6. Security Considerations - - Providing identifying information as to which server is responding - can be seen as information leakage and thus a security risk. This - motivates the suggestion above that a new mechanism for server - identification allow the administrator to disable the functionality - altogether or partially restrict availability of the data. It also - suggests that the serverid data should not be readily correlated with - a hostname or unicast IP address that may be considered private to - the nameserver operator's management infrastructure. - - Propagation of protocol or service meta-data can sometimes expose the - application to denial of service or other attack. As DNS is a - critically important infrastructure service for the production - Internet, extra care needs to be taken against this risk for - designers, implementors, and operators of a new mechanism for server - identification. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Woolf & Conrad Expires January 16, 2005 [Page 9] - -Internet-Draft Identifying an Authoritative Name `Server July 2004 - - -7. Acknowledgements - - The technique for host identification documented here was initially - implemented by Paul Vixie of the Internet Software Consortium in the - Berkeley Internet Name Daemon package. Comments and questions on - earlier drafts were provided by Bob Halley, Brian Wellington, Andreas - Gustafsson, Ted Hardie, Chris Yarnell, Randy Bush, and members of the - ICANN Root Server System Advisory Committee. The newest draft takes - a significantly different direction from previous versions, owing to - discussion among contributors to the DNSOP working group and others, - particularly Olafur Gudmundsson, Ed Lewis, Bill Manning, Sam Weiler, - and Rob Austein. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Woolf & Conrad Expires January 16, 2005 [Page 10] - -Internet-Draft Identifying an Authoritative Name `Server July 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. - - - - -Woolf & Conrad Expires January 16, 2005 [Page 11] - -