From: cvs2git Date: Tue, 6 Mar 2007 07:05:50 +0000 (+0000) Subject: This commit was manufactured by cvs2git to create tag 'v9_3_3rc1'. X-Git-Tag: v9.3.3rc1^0 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=26d954aa045ae0efbbbfbcd28bdd6ce58e38f217;p=thirdparty%2Fbind9.git This commit was manufactured by cvs2git to create tag 'v9_3_3rc1'. --- 26d954aa045ae0efbbbfbcd28bdd6ce58e38f217 diff --cc doc/draft/draft-ietf-dnsext-dnssec-online-signing-02.txt index 7503c66ab31,7503c66ab31..00000000000 deleted file mode 100644,100644 --- a/doc/draft/draft-ietf-dnsext-dnssec-online-signing-02.txt +++ /dev/null @@@ -1,616 -1,616 +1,0 @@@ -- -- -- --Network Working Group S. Weiler --Internet-Draft SPARTA, Inc --Updates: 4034, 4035 (if approved) J. Ihren --Expires: July 24, 2006 Autonomica AB -- January 20, 2006 -- -- -- Minimally Covering NSEC Records and DNSSEC On-line Signing -- draft-ietf-dnsext-dnssec-online-signing-02 -- --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 July 24, 2006. -- --Copyright Notice -- -- Copyright (C) The Internet Society (2006). -- --Abstract -- -- This document describes how to construct DNSSEC NSEC resource records -- that cover a smaller range of names than called for by RFC4034. By -- generating and signing these records on demand, authoritative name -- servers can effectively stop the disclosure of zone contents -- otherwise made possible by walking the chain of NSEC records in a -- signed zone. -- -- -- -- --Weiler & Ihren Expires July 24, 2006 [Page 1] -- --Internet-Draft NSEC Epsilon January 2006 -- -- --Changes from ietf-01 to ietf-02 -- -- Clarified that a generated NSEC RR's type bitmap MUST have the RRSIG -- and NSEC bits set, to be consistent with DNSSECbis -- previous text -- said SHOULD. -- -- Made the applicability statement a little less oppressive. -- --Changes from ietf-00 to ietf-01 -- -- Added an applicability statement, making reference to ongoing work on -- NSEC3. -- -- Added the phrase "epsilon functions", which has been commonly used to -- describe the technique and already appeared in the header of each -- page, in place of "increment and decrement functions". Also added an -- explanatory sentence. -- -- Corrected references from 4034 section 6.2 to section 6.1. -- -- Fixed an out-of-date reference to [-bis] and other typos. -- -- Replaced IANA Considerations text. -- -- Escaped close parentheses in examples. -- -- Added some more acknowledgements. -- --Changes from weiler-01 to ietf-00 -- -- Inserted RFC numbers for 4033, 4034, and 4035. -- -- Specified contents of bitmap field in synthesized NSEC RR's, pointing -- out that this relaxes a constraint in 4035. Added 4035 to the -- Updates header. -- --Changes from weiler-00 to weiler-01 -- -- Clarified that this updates RFC4034 by relaxing requirements on the -- next name field. -- -- Added examples covering wildcard names. -- -- In the 'better functions' section, reiterated that perfect functions -- aren't needed. -- -- Added a reference to RFC 2119. -- -- -- -- --Weiler & Ihren Expires July 24, 2006 [Page 2] -- --Internet-Draft NSEC Epsilon January 2006 -- -- --Table of Contents -- -- 1. Introduction and Terminology . . . . . . . . . . . . . . . . . 4 -- 2. Applicability of This Technique . . . . . . . . . . . . . . . 4 -- 3. Minimally Covering NSEC Records . . . . . . . . . . . . . . . 5 -- 4. Better Epsilon Functions . . . . . . . . . . . . . . . . . . . 6 -- 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 -- 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 -- 7. Normative References . . . . . . . . . . . . . . . . . . . . . 8 -- Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 8 -- Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 -- Intellectual Property and Copyright Statements . . . . . . . . . . 11 -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --Weiler & Ihren Expires July 24, 2006 [Page 3] -- --Internet-Draft NSEC Epsilon January 2006 -- -- --1. Introduction and Terminology -- -- With DNSSEC [1], an NSEC record lists the next instantiated name in -- its zone, proving that no names exist in the "span" between the -- NSEC's owner name and the name in the "next name" field. In this -- document, an NSEC record is said to "cover" the names between its -- owner name and next name. -- -- Through repeated queries that return NSEC records, it is possible to -- retrieve all of the names in the zone, a process commonly called -- "walking" the zone. Some zone owners have policies forbidding zone -- transfers by arbitrary clients; this side-effect of the NSEC -- architecture subverts those policies. -- -- This document presents a way to prevent zone walking by constructing -- NSEC records that cover fewer names. These records can make zone -- walking take approximately as many queries as simply asking for all -- possible names in a zone, making zone walking impractical. Some of -- these records must be created and signed on demand, which requires -- on-line private keys. Anyone contemplating use of this technique is -- strongly encouraged to review the discussion of the risks of on-line -- signing in Section 6. -- -- 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 [4]. -- -- --2. Applicability of This Technique -- -- The technique presented here may be useful to a zone owner that wants -- to use DNSSEC, is concerned about exposure of its zone contents via -- zone walking, and is willing to bear the costs of on-line signing. -- -- As discussed in Section 6, on-line signing has several security -- risks, including an increased likelihood of private keys being -- disclosed and an increased risk of denial of service attack. Anyone -- contemplating use of this technique is strongly encouraged to review -- the discussion of the risks of on-line signing in Section 6. -- -- Furthermore, at the time this document was published, the DNSEXT -- working group was actively working on a mechanism to prevent zone -- walking that does not require on-line signing (tentatively called -- NSEC3). The new mechanism is likely to expose slightly more -- information about the zone than this technique (e.g. the number of -- instantiated names), but it may be preferable to this technique. -- -- -- -- -- --Weiler & Ihren Expires July 24, 2006 [Page 4] -- --Internet-Draft NSEC Epsilon January 2006 -- -- --3. Minimally Covering NSEC Records -- -- This mechanism involves changes to NSEC records for instantiated -- names, which can still be generated and signed in advance, as well as -- the on-demand generation and signing of new NSEC records whenever a -- name must be proven not to exist. -- -- In the 'next name' field of instantiated names' NSEC records, rather -- than list the next instantiated name in the zone, list any name that -- falls lexically after the NSEC's owner name and before the next -- instantiated name in the zone, according to the ordering function in -- RFC4034 [2] section 6.1. This relaxes the requirement in section -- 4.1.1 of RFC4034 that the 'next name' field contains the next owner -- name in the zone. This change is expected to be fully compatible -- with all existing DNSSEC validators. These NSEC records are returned -- whenever proving something specifically about the owner name (e.g. -- that no resource records of a given type appear at that name). -- -- Whenever an NSEC record is needed to prove the non-existence of a -- name, a new NSEC record is dynamically produced and signed. The new -- NSEC record has an owner name lexically before the QNAME but -- lexically following any existing name and a 'next name' lexically -- following the QNAME but before any existing name. -- -- The generated NSEC record's type bitmap MUST have the RRSIG and NSEC -- bits set and SHOULD NOT have any other bits set. This relaxes the -- requirement in Section 2.3 of RFC4035 that NSEC RRs not appear at -- names that did not exist before the zone was signed. -- -- The functions to generate the lexically following and proceeding -- names need not be perfect nor consistent, but the generated NSEC -- records must not cover any existing names. Furthermore, this -- technique works best when the generated NSEC records cover as few -- names as possible. In this document, the functions that generate the -- nearby names are called 'epsilon' functions, a reference to the -- mathematical convention of using the greek letter epsilon to -- represent small deviations. -- -- An NSEC record denying the existence of a wildcard may be generated -- in the same way. Since the NSEC record covering a non-existent -- wildcard is likely to be used in response to many queries, -- authoritative name servers using the techniques described here may -- want to pregenerate or cache that record and its corresponding RRSIG. -- -- For example, a query for an A record at the non-instantiated name -- example.com might produce the following two NSEC records, the first -- denying the existence of the name example.com and the second denying -- the existence of a wildcard: -- -- -- --Weiler & Ihren Expires July 24, 2006 [Page 5] -- --Internet-Draft NSEC Epsilon January 2006 -- -- -- exampld.com 3600 IN NSEC example-.com ( RRSIG NSEC ) -- -- \).com 3600 IN NSEC +.com ( RRSIG NSEC ) -- -- Before answering a query with these records, an authoritative server -- must test for the existence of names between these endpoints. If the -- generated NSEC would cover existing names (e.g. exampldd.com or -- *bizarre.example.com), a better epsilon function may be used or the -- covered name closest to the QNAME could be used as the NSEC owner -- name or next name, as appropriate. If an existing name is used as -- the NSEC owner name, that name's real NSEC record MUST be returned. -- Using the same example, assuming an exampldd.com delegation exists, -- this record might be returned from the parent: -- -- exampldd.com 3600 IN NSEC example-.com ( NS DS RRSIG NSEC ) -- -- Like every authoritative record in the zone, each generated NSEC -- record MUST have corresponding RRSIGs generated using each algorithm -- (but not necessarily each DNSKEY) in the zone's DNSKEY RRset, as -- described in RFC4035 [3] section 2.2. To minimize the number of -- signatures that must be generated, a zone may wish to limit the -- number of algorithms in its DNSKEY RRset. -- -- --4. Better Epsilon Functions -- -- Section 6.1 of RFC4034 defines a strict ordering of DNS names. -- Working backwards from that definition, it should be possible to -- define epsilon functions that generate the immediately following and -- preceding names, respectively. This document does not define such -- functions. Instead, this section presents functions that come -- reasonably close to the perfect ones. As described above, an -- authoritative server should still ensure than no generated NSEC -- covers any existing name. -- -- To increment a name, add a leading label with a single null (zero- -- value) octet. -- -- To decrement a name, decrement the last character of the leftmost -- label, then fill that label to a length of 63 octets with octets of -- value 255. To decrement a null (zero-value) octet, remove the octet -- -- if an empty label is left, remove the label. Defining this -- function numerically: fill the left-most label to its maximum length -- with zeros (numeric, not ASCII zeros) and subtract one. -- -- In response to a query for the non-existent name foo.example.com, -- these functions produce NSEC records of: -- -- -- -- --Weiler & Ihren Expires July 24, 2006 [Page 6] -- --Internet-Draft NSEC Epsilon January 2006 -- -- -- fon\255\255\255\255\255\255\255\255\255\255\255\255\255\255 -- \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255 -- \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255 -- \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255 -- \255.example.com 3600 IN NSEC \000.foo.example.com ( NSEC RRSIG ) -- -- \)\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255 -- \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255 -- \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255 -- \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255 -- \255\255.example.com 3600 IN NSEC \000.*.example.com ( NSEC RRSIG ) -- -- The first of these NSEC RRs proves that no exact match for -- foo.example.com exists, and the second proves that there is no -- wildcard in example.com. -- -- Both of these functions are imperfect: they don't take into account -- constraints on number of labels in a name nor total length of a name. -- As noted in the previous section, though, this technique does not -- depend on the use of perfect epsilon functions: it is sufficient to -- test whether any instantiated names fall into the span covered by the -- generated NSEC and, if so, substitute those instantiated owner names -- for the NSEC owner name or next name, as appropriate. -- -- --5. IANA Considerations -- -- This document specifies no IANA Actions. -- -- --6. Security Considerations -- -- This approach requires on-demand generation of RRSIG records. This -- creates several new vulnerabilities. -- -- First, on-demand signing requires that a zone's authoritative servers -- have access to its private keys. Storing private keys on well-known -- internet-accessible servers may make them more vulnerable to -- unintended disclosure. -- -- Second, since generation of digital signatures tends to be -- computationally demanding, the requirement for on-demand signing -- makes authoritative servers vulnerable to a denial of service attack. -- -- Lastly, if the epsilon functions are predictable, on-demand signing -- may enable a chosen-plaintext attack on a zone's private keys. Zones -- using this approach should attempt to use cryptographic algorithms -- that are resistant to chosen-plaintext attacks. It's worth noting -- -- -- --Weiler & Ihren Expires July 24, 2006 [Page 7] -- --Internet-Draft NSEC Epsilon January 2006 -- -- -- that while DNSSEC has a "mandatory to implement" algorithm, that is a -- requirement on resolvers and validators -- there is no requirement -- that a zone be signed with any given algorithm. -- -- The success of using minimally covering NSEC record to prevent zone -- walking depends greatly on the quality of the epsilon functions -- chosen. An increment function that chooses a name obviously derived -- from the next instantiated name may be easily reverse engineered, -- destroying the value of this technique. An increment function that -- always returns a name close to the next instantiated name is likewise -- a poor choice. Good choices of epsilon functions are the ones that -- produce the immediately following and preceding names, respectively, -- though zone administrators may wish to use less perfect functions -- that return more human-friendly names than the functions described in -- Section 4 above. -- -- Another obvious but misguided concern is the danger from synthesized -- NSEC records being replayed. It's possible for an attacker to replay -- an old but still validly signed NSEC record after a new name has been -- added in the span covered by that NSEC, incorrectly proving that -- there is no record at that name. This danger exists with DNSSEC as -- defined in [3]. The techniques described here actually decrease the -- danger, since the span covered by any NSEC record is smaller than -- before. Choosing better epsilon functions will further reduce this -- danger. -- --7. Normative References -- -- [1] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, -- "DNS Security Introduction and Requirements", RFC 4033, -- March 2005. -- -- [2] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, -- "Resource Records for the DNS Security Extensions", RFC 4034, -- March 2005. -- -- [3] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, -- "Protocol Modifications for the DNS Security Extensions", -- RFC 4035, March 2005. -- -- [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement -- Levels", BCP 14, RFC 2119, March 1997. -- -- --Appendix A. Acknowledgments -- -- Many individuals contributed to this design. They include, in -- addition to the authors of this document, Olaf Kolkman, Ed Lewis, -- -- -- --Weiler & Ihren Expires July 24, 2006 [Page 8] -- --Internet-Draft NSEC Epsilon January 2006 -- -- -- Peter Koch, Matt Larson, David Blacka, Suzanne Woolf, Jaap Akkerhuis, -- Jakob Schlyter, Bill Manning, and Joao Damas. -- -- In addition, the editors would like to thank Ed Lewis, Scott Rose, -- and David Blacka for their careful review of the document. -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --Weiler & Ihren Expires July 24, 2006 [Page 9] -- --Internet-Draft NSEC Epsilon January 2006 -- -- --Authors' Addresses -- -- Samuel Weiler -- SPARTA, Inc -- 7075 Samuel Morse Drive -- Columbia, Maryland 21046 -- US -- -- Email: weiler@tislabs.com -- -- -- Johan Ihren -- Autonomica AB -- Bellmansgatan 30 -- Stockholm SE-118 47 -- Sweden -- -- Email: johani@autonomica.se -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --Weiler & Ihren Expires July 24, 2006 [Page 10] -- --Internet-Draft NSEC Epsilon January 2006 -- -- --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 (2006). 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. -- -- -- -- --Weiler & Ihren Expires July 24, 2006 [Page 11] -- diff --cc doc/draft/draft-ietf-dnsext-nsid-01.txt index 90d1a0609d4,90d1a0609d4..00000000000 deleted file mode 100644,100644 --- a/doc/draft/draft-ietf-dnsext-nsid-01.txt +++ /dev/null @@@ -1,840 -1,840 +1,0 @@@ -- -- -- --Network Working Group R. Austein --Internet-Draft ISC --Expires: July 15, 2006 January 11, 2006 -- -- -- DNS Name Server Identifier Option (NSID) -- draft-ietf-dnsext-nsid-01 -- --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 July 15, 2006. -- --Copyright Notice -- -- Copyright (C) The Internet Society (2006). -- --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. While existing ad-hoc -- mechanism allow an operator to send follow-up queries when it is -- necessary to debug such a configuration, the only completely reliable -- way to obtain the identity of the name server which responded is to -- have the name server include this information in the response itself. -- This note defines a protocol extension to support this functionality. -- -- -- --Austein Expires July 15, 2006 [Page 1] -- --Internet-Draft DNS NSID January 2006 -- -- --Table of Contents -- -- 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 -- 1.1. Reserved Words . . . . . . . . . . . . . . . . . . . . . . 3 -- 2. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 -- 2.1. Resolver Behavior . . . . . . . . . . . . . . . . . . . . 4 -- 2.2. Name Server Behavior . . . . . . . . . . . . . . . . . . . 4 -- 2.3. The NSID Option . . . . . . . . . . . . . . . . . . . . . 4 -- 2.4. Presentation Format . . . . . . . . . . . . . . . . . . . 5 -- 3. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 6 -- 3.1. The NSID Payload . . . . . . . . . . . . . . . . . . . . . 6 -- 3.2. NSID Is Not Transitive . . . . . . . . . . . . . . . . . . 8 -- 3.3. User Interface Issues . . . . . . . . . . . . . . . . . . 8 -- 3.4. Truncation . . . . . . . . . . . . . . . . . . . . . . . . 9 -- 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 -- 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 -- 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 -- 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 -- 7.1. Normative References . . . . . . . . . . . . . . . . . . . 13 -- 7.2. Informative References . . . . . . . . . . . . . . . . . . 13 -- Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 -- Intellectual Property and Copyright Statements . . . . . . . . . . 15 -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --Austein Expires July 15, 2006 [Page 2] -- --Internet-Draft DNS NSID January 2006 -- -- --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. -- -- Existing ad-hoc mechanisms allow an operator to send follow-up -- queries when it is necessary to debug such a configuration, but there -- are situations in which this is not a totally satisfactory solution, -- since anycast routing may have changed, or the server pool in -- question may be behind some kind of extremely dynamic load balancing -- hardware. Thus, while these ad-hoc mechanisms are certainly better -- than nothing (and have the advantage of already being deployed), a -- better solution seems desirable. -- -- Given that a DNS query is an idempotent operation with no retained -- state, it would appear that the only completely reliable way to -- obtain the identity of the name server which responded to a -- particular query is to have that name server include identifying -- information in the response itself. This note defines a protocol -- enhancement to achieve this. -- --1.1. 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 [RFC2119]. -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --Austein Expires July 15, 2006 [Page 3] -- --Internet-Draft DNS NSID January 2006 -- -- --2. Protocol -- -- This note uses an EDNS [RFC2671] option to signal the resolver's -- desire for information identifying the name server and to hold the -- name server's response, if any. -- --2.1. Resolver Behavior -- -- A resolver signals its desire for information identifying a name -- server by sending an empty NSID option (Section 2.3) in an EDNS OPT -- pseudo-RR in the query message. -- -- The resolver MUST NOT include any NSID payload data in the query -- message. -- -- The semantics of an NSID request are not transitive. That is: the -- presence of an NSID option in a query is a request that the name -- server which receives the query identify itself. If the name server -- side of a recursive name server receives an NSID request, the client -- is asking the recursive name server to identify itself; if the -- resolver side of the recursive name server wishes to receive -- identifying information, it is free to add NSID requests in its own -- queries, but that is a separate matter. -- --2.2. Name Server Behavior -- -- A name server which understands the NSID option and chooses to honor -- a particular NSID request responds by including identifying -- information in a NSID option (Section 2.3) in an EDNS OPT pseudo-RR -- in the response message. -- -- The name server MUST ignore any NSID payload data that might be -- present in the query message. -- -- The NSID option is not transitive. A name server MUST NOT send an -- NSID option back to a resolver which did not request it. In -- particular, while a recursive name server may choose to add an NSID -- option when sending a query, this has no effect on the presence or -- absence of the NSID option in the recursive name server's response to -- the original client. -- -- As stated in Section 2.1, this mechanism is not restricted to -- authoritative name servers; the semantics are intended to be equally -- applicable to recursive name servers. -- --2.3. The NSID Option -- -- The OPTION-CODE for the NSID option is [TBD]. -- -- -- --Austein Expires July 15, 2006 [Page 4] -- --Internet-Draft DNS NSID January 2006 -- -- -- The OPTION-DATA for the NSID option is an opaque byte string the -- semantics of which are deliberately left outside the protocol. See -- Section 3.1 for discussion. -- --2.4. Presentation Format -- -- User interfaces MUST read and write the content of the NSID option as -- a sequence of hexadecimal digits, two digits per payload octet. -- -- The NSID payload is binary data. Any comparison between NSID -- payloads MUST be a comparison of the raw binary data. Copy -- operations MUST NOT assume that the raw NSID payload is null- -- terminated. Any resemblance between raw NSID payload data and any -- form of text is purely a convenience, and does not change the -- underlying nature of the payload data. -- -- See Section 3.3 for discussion. -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --Austein Expires July 15, 2006 [Page 5] -- --Internet-Draft DNS NSID January 2006 -- -- --3. Discussion -- -- This section discusses certain aspects of the protocol and explains -- considerations that led to the chosen design. -- --3.1. The NSID Payload -- -- The syntax and semantics of the content of the NSID option is -- deliberately left outside the scope of this specification. This -- section describe some of the kinds of data that server administrators -- might choose to provide as the content of the NSID option, and -- explains the reasoning behind choosing a simple opaque byte string. -- -- There are several possibilities for the payload of the NSID option: -- -- o It could be the "real" name of the specific name server within the -- name server pool. -- -- o It could be the "real" IP address (IPv4 or IPv6) of the name -- server within the name server pool. -- -- o It could be some sort of pseudo-random number generated in a -- predictable fashion somehow using the server's IP address or name -- as a seed value. -- -- o It could be some sort of probabilisticly unique identifier -- initially derived from some sort of random number generator then -- preserved across reboots of the name server. -- -- o It could be some sort of dynamicly generated identifier so that -- only the name server operator could tell whether or not any two -- queries had been answered by the same server. -- -- o It could be a blob of signed data, with a corresponding key which -- might (or might not) be available via DNS lookups. -- -- o It could be a blob of encrypted data, the key for which could be -- restricted to parties with a need to know (in the opinion of the -- server operator). -- -- o It could be an arbitrary string of octets chosen at the discretion -- of the name server operator. -- -- Each of these options has advantages and disadvantages: -- -- o Using the "real" name is simple, but the name server may not have -- a "real" name. -- -- -- -- --Austein Expires July 15, 2006 [Page 6] -- --Internet-Draft DNS NSID January 2006 -- -- -- o Using the "real" address is also simple, and the name server -- almost certainly does have at least one non-anycast IP address for -- maintenance operations, but the operator of the name server may -- not be willing to divulge its non-anycast address. -- -- o Given that one common reason for using anycast DNS techniques is -- an attempt to harden a critical name server against denial of -- service attacks, some name server operators are likely to want an -- identifier other than the "real" name or "real" address of the -- name server instance. -- -- o Using a hash or pseudo-random number can provide a fixed length -- value that the resolver can use to tell two name servers apart -- without necessarily being able to tell where either one of them -- "really" is, but makes debugging more difficult if one happens to -- be in a friendly open environment. Furthermore, hashing might not -- add much value, since a hash based on an IPv4 address still only -- involves a 32-bit search space, and DNS names used for servers -- that operators might have to debug at 4am tend not to be very -- random. -- -- o Probabilisticly unique identifiers have similar properties to -- hashed identifiers, but (given a sufficiently good random number -- generator) are immune to the search space issues. However, the -- strength of this approach is also its weakness: there is no -- algorithmic transformation by which even the server operator can -- associate name server instances with identifiers while debugging, -- which might be annoying. This approach also requires the name -- server instance to preserve the probabilisticly unique identifier -- across reboots, but this does not appear to be a serious -- restriction, since authoritative nameservers almost always have -- some form of nonvolatile storage in any case, and in the rare case -- of a name server that does not have any way to store such an -- identifier, nothing terrible will happen if the name server just -- generates a new identifier every time it reboots. -- -- o Using an arbitrary octet string gives name server operators yet -- another thing to configure, or mis-configure, or forget to -- configure. Having all the nodes in an anycast name server -- constellation identify themselves as "My Name Server" would not be -- particularly useful. -- -- Given all of the issues listed above, there does not appear to be a -- single solution that will meet all needs. Section 2.3 therefore -- defines the NSID payload to be an opaque byte string and leaves the -- choice up to the implementor and name server operator. The following -- guidelines may be useful to implementors and server operators: -- -- -- -- --Austein Expires July 15, 2006 [Page 7] -- --Internet-Draft DNS NSID January 2006 -- -- -- o Operators for whom divulging the unicast address is an issue could -- use the raw binary representation of a probabilisticly unique -- random number. This should probably be the default implementation -- behavior. -- -- o Operators for whom divulging the unicast address is not an issue -- could just use the raw binary representation of a unicast address -- for simplicity. This should only be done via an explicit -- configuration choice by the operator. -- -- o Operators who really need or want the ability to set the NSID -- payload to an arbitrary value could do so, but this should only be -- done via an explicit configuration choice by the operator. -- -- This approach appears to provide enough information for useful -- debugging without unintentionally leaking the maintenance addresses -- of anycast name servers to nogoodniks, while also allowing name -- server operators who do not find such leakage threatening to provide -- more information at their own discretion. -- --3.2. NSID Is Not Transitive -- -- As specified in Section 2.1 and Section 2.2, the NSID option is not -- transitive. This is strictly a hop-by-hop mechanism. -- -- Most of the discussion of name server identification to date has -- focused on identifying authoritative name servers, since the best -- known cases of anycast name servers are a subset of the name servers -- for the root zone. However, given that anycast DNS techniques are -- also applicable to recursive name servers, the mechanism may also be -- useful with recursive name servers. The hop-by-hop semantics support -- this. -- -- While there might be some utility in having a transitive variant of -- this mechanism (so that, for example, a stub resolver could ask a -- recursive server to tell it which authoritative name server provided -- a particular answer to the recursive name server), the semantics of -- such a variant would be more complicated, and are left for future -- work. -- --3.3. User Interface Issues -- -- Given the range of possible payload contents described in -- Section 3.1, it is not possible to define a single presentation -- format for the NSID payload that is efficient, convenient, -- unambiguous, and aesthetically pleasing. In particular, while it is -- tempting to use a presentation format that uses some form of textual -- strings, attempting to support this would significantly complicate -- -- -- --Austein Expires July 15, 2006 [Page 8] -- --Internet-Draft DNS NSID January 2006 -- -- -- what's intended to be a very simple debugging mechanism. -- -- In some cases the content of the NSID payload may be binary data -- meaningful only to the name server operator, and may not be -- meaningful to the user or application, but the user or application -- must be able to capture the entire content anyway in order for it to -- be useful. Thus, the presentation format must support arbitrary -- binary data. -- -- In cases where the name server operator derives the NSID payload from -- textual data, a textual form such as US-ASCII or UTF-8 strings might -- at first glance seem easier for a user to deal with. There are, -- however, a number of complex issues involving internationalized text -- which, if fully addressed here, would require a set of rules -- significantly longer than the rest of this specification. See -- [RFC2277] for an overview of some of these issues. -- -- It is much more important for the NSID payload data to be passed -- unambiguously from server administrator to user and back again than -- it is for the payload data data to be pretty while in transit. In -- particular, it's critical that it be straightforward for a user to -- cut and paste an exact copy of the NSID payload output by a debugging -- tool into other formats such as email messages or web forms without -- distortion. Hexadecimal strings, while ugly, are also robust. -- --3.4. Truncation -- -- In some cases, adding the NSID option to a response message may -- trigger message truncation. This specification does not change the -- rules for DNS message truncation in any way, but implementors will -- need to pay attention to this issue. -- -- Including the NSID option in a response is always optional, so this -- specification never requires name servers to truncate response -- messages. -- -- By definition, a resolver that requests NSID responses also supports -- EDNS, so a resolver that requests NSID responses can also use the -- "sender's UDP payload size" field of the OPT pseudo-RR to signal a -- receive buffer size large enough to make truncation unlikely. -- -- -- -- -- -- -- -- -- -- -- --Austein Expires July 15, 2006 [Page 9] -- --Internet-Draft DNS NSID January 2006 -- -- --4. IANA Considerations -- -- This mechanism requires allocation of one ENDS option code for the -- NSID option (Section 2.3). -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --Austein Expires July 15, 2006 [Page 10] -- --Internet-Draft DNS NSID January 2006 -- -- --5. Security Considerations -- -- This document describes a channel signaling mechanism, intended -- primarily for debugging. Channel signaling mechanisms are outside -- the scope of DNSSEC per se. Applications that require integrity -- protection for the data being signaled will need to use a channel -- security mechanism such as TSIG [RFC2845]. -- -- Section 3.1 discusses a number of different kinds of information that -- a name server operator might choose to provide as the value of the -- NSID option. Some of these kinds of information are security -- sensitive in some environments. This specification deliberately -- leaves the syntax and semantics of the NSID option content up to the -- implementation and the name server operator. -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --Austein Expires July 15, 2006 [Page 11] -- --Internet-Draft DNS NSID January 2006 -- -- --6. Acknowledgements -- -- Joe Abley, Harald Alvestrand, Mark Andrews, Roy Arends, Steve -- Bellovin, Randy Bush, David Conrad, Johan Ihren, Daniel Karrenberg, -- Peter Koch, Mike Patton, Mike StJohns, Paul Vixie, Sam Weiler, and -- Suzanne Woolf. Apologies to anyone inadvertently omitted from the -- above list. -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --Austein Expires July 15, 2006 [Page 12] -- --Internet-Draft DNS NSID January 2006 -- -- --7. References -- --7.1. Normative References -- -- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate -- Requirement Levels", RFC 2119, BCP 14, March 1997. -- -- [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", -- RFC 2671, August 1999. -- -- [RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B. -- Wellington, "Secret Key Transaction Authentication for DNS -- (TSIG)", RFC 2845, May 2000. -- --7.2. Informative References -- -- [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and -- Languages", RFC 2277, BCP 18, January 1998. -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --Austein Expires July 15, 2006 [Page 13] -- --Internet-Draft DNS NSID January 2006 -- -- --Author's Address -- -- Rob Austein -- ISC -- 950 Charter Street -- Redwood City, CA 94063 -- USA -- -- Email: sra@isc.org -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --Austein Expires July 15, 2006 [Page 14] -- --Internet-Draft DNS NSID January 2006 -- -- --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 (2006). 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. -- -- -- -- --Austein Expires July 15, 2006 [Page 15] -- diff --cc doc/draft/draft-ietf-dnsext-wcard-clarify-10.txt index 9cf88a5831f,9cf88a5831f..00000000000 deleted file mode 100644,100644 --- a/doc/draft/draft-ietf-dnsext-wcard-clarify-10.txt +++ /dev/null @@@ -1,1063 -1,1063 +1,0 @@@ --Internet-Draft dnsext-wcard January 9, 2006 -- --DNSEXT Working Group E. Lewis --INTERNET DRAFT NeuStar --Expiration Date: July 9, 2006 January 9, 2006 --Updates RFC 1034, RFC 2672 -- -- The Role of Wildcards -- in the Domain Name System -- draft-ietf-dnsext-wcard-clarify-10.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 July 9, 2006. -- --Copyright Notice -- -- Copyright (C) The Internet Society (2006). -- --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. -- -- -- -- --DNSEXT Working Group Expires July 9, 2006 [Page 1] -- --Internet-Draft dnsext-wcard January 9, 2006 -- --Table of Contents -- --1. Introduction . . . . . . . . . . . . . . . . 3 --1 1 Motivation 3 --1 2 The Original Definition 3 --1 3 Roadmap to This Document 4 --1 3 1 New Terms 4 --1.3.2 Changed Text 5 --1.3.3 Considerations with Special Types 5 --1.4 Standards Terminology 5 --2. Wildcard Syntax . . . . . . . . . . . . . . . 6 --2.1 Identifying a Wildcard 6 --2.1.1 Wild Card Domain Name and Asterisk Label 6 --2.1.2 Asterisks and Other Characters 6 --2.1.3 Non-terminal Wild Card Domain Names 6 --2.2 Existence Rules 7 --2.2.1 An Example 7 --2.2.2 Empty Non-terminals 9 --2.2.3 Yet Another Definition of Existence 10 --2.3 When is a Wild Card Domain Name Not Special 10 --3. Impact of a Wild Card Domain Name On a Response . . . . . 10 --3.1 Step 2 10 --3.2 Step 3 11 --3.3 Part 'c' 11 --3.3.1 Closest Encloser and the Source of Synthesis 12 --3.3.2 Closest Encloser and Source of Synthesis Examples 12 --3.3.3 Type Matching 13 --4. Considerations with Special Types . . . . . . . . . 13 --4.1 SOA RRSet at a Wild Card Domain Name 13 --4.2 NS RRSet at a Wild Card Domain Name 14 --4.2.1 Discarded Notions 14 --4.3 CNAME RRSet at a Wild Card Domain Name 15 --4.4 DNAME RRSet at a Wild Card Domain Name 15 --4.5 SRV RRSet at a Wild Card Domain Name 16 --4.6 DS RRSet at a Wild Card Domain Name 16 --4.7 NSEC RRSet at a Wild Card Domain Name 17 --4.8 RRSIG at a Wild Card Domain Name 17 --4.9 Empty Non-terminal Wild Card Domain Name 17 --5. Security Considerations . . . . . . . . . . . . . 17 --6. IANA Considerations . . . . . . . . . . . . . 17 --7. References . . . . . . . . . . . . . 17 --8. Editor . . . . . . . . . . . . . 18 --9. Others Contributing to the Document . . . . . . . . 18 --10. Trailing Boilerplate . . . . . . . . . . . . . 19 -- -- -- -- -- -- -- -- --DNSEXT Working Group Expires July 9, 2006 [Page 2] -- --Internet-Draft dnsext-wcard January 9, 2006 -- --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 is given to minimize any backwards -- compatibility issues with implementations that comply with RFC -- 1034's definition. -- -- This document is focused on the concept of wildcards as defined -- in RFC 1034. Nothing is implied regarding alternative means of -- synthesizing resource record sets, nor are alternatives discussed. -- --1.1 Motivation -- -- Many DNS implementations diverge, in different ways, from the -- original definition of wildcards. 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 its changes, documenting only -- those based on implementation experience, and to remain as close -- to the original document as possible. To reinforce that this -- document is meant to clarify and adjust and not redefine wildcards, -- relevant sections of RFC 1034 are repeated verbatim to facilitate -- comparison of the old and new text. -- --1.2 The Original Definition -- -- The definition of the wildcard concept is comprised by the -- documentation of 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). -- -- This is the definition of the term "wildcard" as it appears in -- RFC 1034, section 4.3.3. -- -- -- --DNSEXT Working Group Expires July 9, 2006 [Page 3] -- --Internet-Draft dnsext-wcard January 9, 2006 -- --# 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 follows 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 relevant portion of the "Algorithm." -- --# 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 Roadmap to 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. -- --DNSEXT Working Group Expires July 9, 2006 [Page 4] -- --Internet-Draft dnsext-wcard January 9, 2006 -- -- The new terms are used to make discussions of wildcards clearer. -- Terminology doesn't directly have an impact on implementations. -- --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 -- RFC 1034 contained no specification on when and how to enforce the -- restriction. -- --1.3.3 Considerations with Special Types -- -- This document describes semantics of wildcard RRSets for -- "interesting" types as well as empty non-terminal wildcards. -- Understanding these situations 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. References to section "4.3.2" are assumed to refer -- to RFC 1034's section 4.3.2, simply titled "Algorithm." -- -- -- -- -- --DNSEXT Working Group Expires July 9, 2006 [Page 5] -- --Internet-Draft dnsext-wcard January 9, 2006 -- --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] just as non-wildcard resource records are. -- This feature has been under appreciated 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 so these labels 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...................... -- --DNSEXT Working Group Expires July 9, 2006 [Page 6] -- --Internet-Draft dnsext-wcard January 9, 2006 -- -- The restriction is now removed. The original documentation of it -- is incomplete and the restriction does not serve any purpose -- given years of operational experience. -- -- There are three possible reasons for putting the restriction in -- place, but none of the three has held up over time. One is -- that the restriction meant that there would never be subdomains -- of wild card domain names, but the restriciton as stated still -- permits "example.*.example." for instance. Another is that -- wild card domain names are not intended to be empty non-terminals, -- but this situation does not disrupt the algorithm in 4.3.2. -- Finally, "nested" wild card domain names are not ambiguous once -- the concept of the closest encloser had been documented. -- -- 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 -- -- "Existence" is therefore an important concept in the understanding -- of wildcards. Unfortunately, the definition of what exists, in RFC -- 1034, is unclear. So, in sections 2.2.2. and 2.2.3, another look is -- taken at the definition of existence. -- --2.2.1 An Example -- -- To illustrate what is meant by existence consider this complete -- zone: -- -- -- -- -- -- -- -- -- --DNSEXT Working Group Expires July 9, 2006 [Page 7] -- --Internet-Draft dnsext-wcard January 9, 2006 -- -- $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 responses would be synthesized from one of the -- wildcards in the zone: -- -- 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 responses would not be synthesized from any of the -- wildcards in the zone: -- -- QNAME=host1.example., QTYPE=MX, QCLASS=IN -- because host1.example. exists -- -- QNAME=sub.*.example., QTYPE=MX, QCLASS=IN -- because sub.*.example. exists -- --DNSEXT Working Group Expires July 9, 2006 [Page 8] -- --Internet-Draft dnsext-wcard January 9, 2006 -- -- 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) -- -- QNAME=ghost.*.example., QTYPE=MX, QCLASS=IN -- because *.example. exists -- -- The final example highlights one common misconception about -- wildcards. A wildcard "blocks itself" in the sense that a -- wildcard does not match its own subdomains. I.e. "*.example." -- does not match all names in the "example." zone, it fails to -- match the names below "*.example." To cover names under -- "*.example.", another wild card domain name is needed - -- "*.*.example." - which covers all but it's own subdomains. -- --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, so this apparently -- is not the intent of the original definition, justifying the -- need for an updated definition in the next section. -- -- -- -- --DNSEXT Working Group Expires July 9, 2006 [Page 9] -- --Internet-Draft dnsext-wcard January 9, 2006 -- --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 one RRSet. A node may exist with no -- RRSets only if it has descendents that do, this node is an empty -- non-terminal. -- -- 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. In the delegating zone, 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 is a Wild Card Domain Name 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 matches a single, corresponding 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 -- -- RFC 1034's description of how wildcards impact response -- generation is in its 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 wildcard. -- -- The algorithm in 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 suggested means of implementing the -- requirements. As such, in step 3, parts a, b, and c, do not have -- to be implemented in that order, provided that the result of the -- implemented code is compliant with the protocol's specification. -- --3.1 Step 2 -- -- Step 2 of 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. -- --DNSEXT Working Group Expires July 9, 2006 [Page 10] -- --Internet-Draft dnsext-wcard January 9, 2006 -- -- 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. -- --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." -- -- -- -- --DNSEXT Working Group Expires July 9, 2006 [Page 11] -- --Internet-Draft dnsext-wcard January 9, 2006 -- --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 -- -- -- -- -- -- -- --DNSEXT Working Group Expires July 9, 2006 [Page 12] -- --Internet-Draft dnsext-wcard January 9, 2006 -- --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' prior to the -- instructions to "go to step 6": -- -- 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. -- -- --DNSEXT Working Group Expires July 9, 2006 [Page 13] -- --Internet-Draft dnsext-wcard January 9, 2006 -- -- 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 asterisk label only becomes -- significant when section 4.3.2, step 3 part 'c' is 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 RRSet 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) have become unclear. -- -- Salient points of the working group discussion on this topic is -- summarized in section 4.2.1. -- -- As a result of these discussion, 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.2.1 Discarded Notions -- -- Prior to DNSSEC, a wild card domain name owning a NS RRSet -- appeared to be workable, and there are some instances in which -- it is found in deployments using implementations that support -- this. Continuing to allow this in the specification is not -- tenable with DNSSEC. The reason is that the synthesis of the -- NS RRSet is being done in a zone that has delegated away the -- responsibility for the name. This "unauthorized" synthesis is -- not a problem for the base DNS protocol, but DNSSEC, in affirming -- the authorization model for DNS exposes the problem. -- --DNSEXT Working Group Expires July 9, 2006 [Page 14] -- --Internet-Draft dnsext-wcard January 9, 2006 -- -- Outright banning of wildcards of type NS is also untenable as -- the DNS protocol does not define how to handle "illegal" data. -- Implementations may choose not to load a zone, but there is no -- protocol definition. The lack of the definition is complicated -- by having to cover dynamic update [RFC 2136], zone transfers, -- as well as loading at the master server. The case of a client -- (resolver, caching server) getting a wildcard of type NS in -- a reply would also have to be considered. -- -- Given the daunting challenge of a complete definition of how to -- ban such records, dealing with existing implementations that -- permit the records today is a further complication. There are -- uses of wild card domain name owning NS RRSets. -- -- One compromise proposed would have redefined wildcards of type -- NS to not be used in synthesis, this compromise fell apart -- because it would have required significant edits to the DNSSEC -- signing and validation work. (Again, DNSSEC catches -- unauthorized data.) -- -- With no clear consensus forming on the solution to this dilemma, -- and the realization that wildcards of type NS are a rarity in -- operations, the best course of action is to leave this open-ended -- until "it matters." -- --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 [RFC2672] 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.example.net." -- and another cache obtains: -- "b.example. DNAME foo.bar.example.net." -- both generated from the record: -- "*.example. DNAME foo.bar.example.net." -- by an authoritative server. -- --DNSEXT Working Group Expires July 9, 2006 [Page 15] -- --Internet-Draft dnsext-wcard January 9, 2006 -- -- 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 the owner 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 is 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. This statement is made in the context that an NS RRSet -- at a wild card domain name is undefined. At a non-delegation -- --DNSEXT Working Group Expires July 9, 2006 [Page 16] -- --Internet-Draft dnsext-wcard January 9, 2006 -- -- point, a DS RRSet has no value (no corresponding DNSKEY RRSet -- will be used in DNSSEC validation). If there is a synthesized -- DS RRSet, it alone will not be very useful as it exists in the -- context of a delegation point. -- --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. [RFC2308] -- --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 -- --DNSEXT Working Group Expires July 9, 2006 [Page 17] -- --Internet-Draft dnsext-wcard January 9, 2006 -- -- [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 -- -- [RFC2308] Negative Caching of DNS Queries (DNS NCACHE), -- M. Andrews, March 1998 -- -- [RFC2672] Non-Terminal DNS Name Redirection, M. Crawford, -- August 1999. -- -- [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 -- -- 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. -- -- -- -- -- -- -- -- -- --DNSEXT Working Group Expires July 9, 2006 [Page 17] -- --Internet-Draft dnsext-wcard January 9, 2006 -- --10. Trailing Boilerplate -- -- Copyright (C) The Internet Society (2006). -- -- 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 July 9, 2006. -- -- -- --DNSEXT Working Group Expires July 9, 2006 [Page 19] diff --cc doc/draft/draft-ietf-dnsop-bad-dns-res-05.txt index 0855ba358c9,0855ba358c9..00000000000 deleted file mode 100644,100644 --- a/doc/draft/draft-ietf-dnsop-bad-dns-res-05.txt +++ /dev/null @@@ -1,1232 -1,1232 +1,0 @@@ -- -- -- --DNS Operations M. Larson --Internet-Draft P. Barber --Expires: August 14, 2006 VeriSign -- February 10, 2006 -- -- -- Observed DNS Resolution Misbehavior -- draft-ietf-dnsop-bad-dns-res-05 -- --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 August 14, 2006. -- --Copyright Notice -- -- Copyright (C) The Internet Society (2006). -- --Abstract -- -- This memo describes DNS iterative resolver behavior that results in a -- significant query volume sent to the root and top-level domain (TLD) -- name servers. We offer implementation advice to iterative resolver -- developers to alleviate these unnecessary queries. The -- recommendations made in this document are a direct byproduct of -- observation and analysis of abnormal query traffic patterns seen at -- two of the thirteen root name servers and all thirteen com/net TLD -- name servers. -- -- -- --Larson & Barber Expires August 14, 2006 [Page 1] -- --Internet-Draft Observed DNS Resolution Misbehavior February 2006 -- -- -- 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 . . . . . . . . . . . . . 7 -- 2.2.1. Recommendation . . . . . . . . . . . . . . . . . . . . 7 -- 2.3. Inability to follow multiple levels of indirection . . . . 8 -- 2.3.1. Recommendation . . . . . . . . . . . . . . . . . . . . 9 -- 2.4. Aggressive retransmission when fetching glue . . . . . . . 9 -- 2.4.1. Recommendation . . . . . . . . . . . . . . . . . . . . 10 -- 2.5. Aggressive retransmission behind firewalls . . . . . . . . 10 -- 2.5.1. Recommendation . . . . . . . . . . . . . . . . . . . . 11 -- 2.6. Misconfigured NS records . . . . . . . . . . . . . . . . . 11 -- 2.6.1. Recommendation . . . . . . . . . . . . . . . . . . . . 12 -- 2.7. Name server records with zero TTL . . . . . . . . . . . . 12 -- 2.7.1. Recommendation . . . . . . . . . . . . . . . . . . . . 13 -- 2.8. Unnecessary dynamic update messages . . . . . . . . . . . 13 -- 2.8.1. Recommendation . . . . . . . . . . . . . . . . . . . . 14 -- 2.9. Queries for domain names resembling IPv4 addresses . . . . 14 -- 2.9.1. Recommendation . . . . . . . . . . . . . . . . . . . . 14 -- 2.10. Misdirected recursive queries . . . . . . . . . . . . . . 15 -- 2.10.1. Recommendation . . . . . . . . . . . . . . . . . . . . 15 -- 2.11. Suboptimal name server selection algorithm . . . . . . . . 15 -- 2.11.1. Recommendation . . . . . . . . . . . . . . . . . . . . 16 -- 3. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 -- 4. IANA considerations . . . . . . . . . . . . . . . . . . . . . 18 -- 5. Security considerations . . . . . . . . . . . . . . . . . . . 19 -- 6. Internationalization considerations . . . . . . . . . . . . . 20 -- 7. Informative References . . . . . . . . . . . . . . . . . . . . 20 -- Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 -- Intellectual Property and Copyright Statements . . . . . . . . . . 22 -- -- -- -- -- -- -- -- -- -- -- -- --Larson & Barber Expires August 14, 2006 [Page 2] -- --Internet-Draft Observed DNS Resolution Misbehavior February 2006 -- -- --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 indirection 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. None of the changes recommended affects the core DNS protocol -- specification; instead, this document consists of guidelines to -- implementors of iterative resolvers. -- --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 -- to answer questions about certain zones authoritatively. This entity -- is an iterative resolver combined with an authoritative name server -- and is often called a "recursive name server" or a "caching 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", -- -- -- --Larson & Barber Expires August 14, 2006 [Page 3] -- --Internet-Draft Observed DNS Resolution Misbehavior February 2006 -- -- -- because the focus is usually on that component. In instances where -- the name server role of this entity requires mentioning, this memo -- uses the term "recursive name server". As an example of the -- difference, 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 record" to -- encompass both A and AAAA records when a particular situation is -- relevant to both types. -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --Larson & Barber Expires August 14, 2006 [Page 4] -- --Internet-Draft Observed DNS Resolution Misbehavior February 2006 -- -- --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. (Note -- that queries with QTYPE=NS are not required by the standard -- resolution algorithm described in section 4.3.2 of RFC 1034 [2]. -- These NS queries represent this implementation's addition to that -- algorithm.) -- -- 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 would be pointless: this query to the parent would come so -- quickly on the heels of the referral that it would be almost certain -- -- -- --Larson & Barber Expires August 14, 2006 [Page 5] -- --Internet-Draft Observed DNS Resolution Misbehavior February 2006 -- -- -- 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 -- 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 [3], 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. -- -- This section should not be understood to claim that all queries to a -- zone's parent are bad. In some cases, such queries are not only -- reasonable but required. Consider the situation when required -- information, such as the address of a name server (i.e., the address -- record corresponding to the RDATA of an NS record), has timed out of -- an iterative resolver's cache before the corresponding NS record. If -- the name of the name server is below the apex of the zone, then the -- name server's address record is only available as glue in the parent -- zone. For example, consider this NS record: -- -- example.com. IN NS ns.example.com. -- -- If a cache has this NS record but not the address record for -- "ns.example.com", it is unable to contact the "example.com" zone -- directly and must query the "com" zone to obtain the address record. -- Note, however, that such a query would not have QTYPE=NS according to -- the standard resolution algorithm. -- --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 -- -- -- --Larson & Barber Expires August 14, 2006 [Page 6] -- --Internet-Draft Observed DNS Resolution Misbehavior February 2006 -- -- -- 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 [4]. -- --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 -- 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. -- -- It should also be noted, however, that some authoritative name server -- implementations appear to be lame only for queries of certain types -- as described in RFC 4074 [5]. In this case, it makes sense to retry -- the "lame" servers for other types of queries, particularly when all -- known authoritative name servers appear to be "lame". -- --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). -- If this caching is performed, 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. -- -- -- --Larson & Barber Expires August 14, 2006 [Page 7] -- --Internet-Draft Observed DNS Resolution Misbehavior February 2006 -- -- -- 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. -- -- An exception to this recommendation occurs if all name servers for a -- zone are marked lame. In that case, the iterative resolver SHOULD -- temporarily ignore the servers' lameness status and query one or more -- servers. This behavior is a workaround for the type-specific -- lameness issue described in the previous section. -- -- Implementors should take care not to make lame server avoidance logic -- overly broad: note that a name server could be lame for a parent zone -- but not a child zone, e.g., lame for "example.com" but properly -- authoritative for "sub.example.com". Therefore a name server should -- not be automatically considered lame for subzones. In the case -- above, even if a name server is known to be lame for "example.com", -- it should be queried for QNAMEs at or below "sub.example.com" if an -- NS record indicates it should be authoritative for that zone. -- --2.3. Inability to follow multiple levels of indirection -- -- Some iterative resolver implementations are unable to follow -- sufficient levels of indirection. 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 existing gTLDs, increasing the -- number of delegations using out-of-zone name servers. -- -- -- -- -- -- --Larson & Barber Expires August 14, 2006 [Page 8] -- --Internet-Draft Observed DNS Resolution Misbehavior February 2006 -- -- --2.3.1. Recommendation -- -- Clearly constructing a delegation that relies on multiple levels of -- indirection is not a good administrative practice. However, the -- practice is widespread enough to require that iterative resolvers be -- able to cope with it. Iterative resolvers SHOULD be able to handle -- arbitrary levels of indirection resulting from out-of-zone name -- servers. Iterative resolvers SHOULD implement a level-of-effort -- counter to avoid loops or otherwise performing too much work in -- resolving pathological cases. -- -- A best practice that avoids this entire issue of indirection is to -- name one or more of a zone's name servers in the zone itself. For -- example, if the zone is named "example.com", consider naming some of -- the name servers "ns{1,2,...}.example.com" (or similar). -- --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 -- -- -- --Larson & Barber Expires August 14, 2006 [Page 9] -- --Internet-Draft Observed DNS Resolution Misbehavior February 2006 -- -- -- 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 -- 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 -- -- -- --Larson & Barber Expires August 14, 2006 [Page 10] -- --Internet-Draft Observed DNS Resolution Misbehavior February 2006 -- -- -- servers, which could explain how such a situation could persist -- without being detected. -- --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 [3], 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" -- -- -- --Larson & Barber Expires August 14, 2006 [Page 11] -- --Internet-Draft Observed DNS Resolution Misbehavior February 2006 -- -- -- authoritative server. -- -- But the "example.com" zone contains the erroneous NS RRset as shown -- in the example above. Subsequent queries for names in "example.com" -- will cause the 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 apex 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. -- -- An authoritative name server SHOULD issue a warning when one of a -- zone's NS records references a name server below the zone's apex when -- a corresponding address record does not exist in the zone AND there -- are no delegated subzones where the address record could exist. -- --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 -- -- -- --Larson & Barber Expires August 14, 2006 [Page 12] -- --Internet-Draft Observed DNS Resolution Misbehavior February 2006 -- -- -- zone parent/child relationships we are aware of, there is typically -- some delay involved in effecting changes. Further, changes to the -- set of a zone's authoritative name servers (and therefore to the -- zone's NS RRset) are typically relatively rare: providing reliable -- authoritative service requires a reasonably stable set of servers. -- Therefore an extremely low or zero TTL on a zone's NS RRset rarely -- makes sense, except in anticipation of an upcoming change. In this -- case, when the zone's administrator has planned a change and does not -- want 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. -- --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- -- -- -- --Larson & Barber Expires August 14, 2006 [Page 13] -- --Internet-Draft Observed DNS Resolution Misbehavior February 2006 -- -- -- public TLD or root zones that would be the appropriate targets for a -- dynamic update. -- -- 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 names 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 IPv4 addresses -- -- The root name servers receive a significant number of A record -- queries where the QNAME looks like an IPv4 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 -- -- -- --Larson & Barber Expires August 14, 2006 [Page 14] -- --Internet-Draft Observed DNS Resolution Misbehavior February 2006 -- -- -- bandwidth. A possible solution 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 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. Of course, the proper and usual root zone -- change procedures would have to be followed to make such a change to -- the root zone. -- --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 -- 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. -- -- -- --Larson & Barber Expires August 14, 2006 [Page 15] -- --Internet-Draft Observed DNS Resolution Misbehavior February 2006 -- -- -- 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 August 14, 2006 [Page 16] -- --Internet-Draft Observed DNS Resolution Misbehavior February 2006 -- -- --3. Acknowledgments -- -- The authors would like to thank the following people for their -- comments that improved this document: Andras Salamon, Dave Meyer, -- Doug Barton, Jaap Akkerhuis, Jinmei Tatuya, John Brady, Kevin Darcy, -- Olafur Gudmundsson, Pekka Savola, Peter Koch and Rob Austein. We -- apologize if we have omitted anyone; any oversight was unintentional. -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --Larson & Barber Expires August 14, 2006 [Page 17] -- --Internet-Draft Observed DNS Resolution Misbehavior February 2006 -- -- --4. IANA considerations -- -- There are no new IANA considerations introduced by this memo. -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --Larson & Barber Expires August 14, 2006 [Page 18] -- --Internet-Draft Observed DNS Resolution Misbehavior February 2006 -- -- --5. Security considerations -- -- The iterative resolver misbehavior discussed in this document exposes -- the root and TLD name servers to increased risk of both intentional -- and unintentional denial of service attacks. -- -- We believe that implementation of the recommendations offered in this -- document will reduce the amount of unnecessary traffic seen at root -- and TLD name servers, thus reducing the opportunity for an attacker -- to use such queries to his or her advantage. -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --Larson & Barber Expires August 14, 2006 [Page 19] -- --Internet-Draft Observed DNS Resolution Misbehavior February 2006 -- -- --6. Internationalization considerations -- -- There are no new internationalization considerations introduced by -- this memo. -- --7. Informative 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] Elz, R. and R. Bush, "Clarifications to the DNS Specification", -- RFC 2181, July 1997. -- -- [4] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", -- RFC 2308, March 1998. -- -- [5] Morishita, Y. and T. Jinmei, "Common Misbehavior Against DNS -- Queries for IPv6 Addresses", RFC 4074, May 2005. -- -- [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] -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --Larson & Barber Expires August 14, 2006 [Page 20] -- --Internet-Draft Observed DNS Resolution Misbehavior February 2006 -- -- --Authors' Addresses -- -- Matt Larson -- VeriSign, Inc. -- 21345 Ridgetop Circle -- Dulles, VA 20166-6503 -- USA -- -- Email: mlarson@verisign.com -- -- -- Piet Barber -- VeriSign, Inc. -- 21345 Ridgetop Circle -- Dulles, VA 20166-6503 -- USA -- -- Email: pbarber@verisign.com -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --Larson & Barber Expires August 14, 2006 [Page 21] -- --Internet-Draft Observed DNS Resolution Misbehavior February 2006 -- -- --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 (2006). 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 August 14, 2006 [Page 22] -- diff --cc doc/rfc/rfc4193.txt index 17e2c0b42da,17e2c0b42da..00000000000 deleted file mode 100644,100644 --- a/doc/rfc/rfc4193.txt +++ /dev/null @@@ -1,899 -1,899 +1,0 @@@ -- -- -- -- -- -- --Network Working Group R. Hinden --Request for Comments: 4193 Nokia --Category: Standards Track B. Haberman -- JHU-APL -- October 2005 -- -- -- Unique Local IPv6 Unicast Addresses -- --Status of This Memo -- -- This document specifies an Internet standards track protocol for the -- Internet community, and requests discussion and suggestions for -- improvements. Please refer to the current edition of the "Internet -- Official Protocol Standards" (STD 1) for the standardization state -- and status of this protocol. Distribution of this memo is unlimited. -- --Copyright Notice -- -- Copyright (C) The Internet Society (2005). -- --Abstract -- -- This document defines an IPv6 unicast address format that is globally -- unique and is intended for local communications, usually inside of a -- site. These addresses are not expected to be routable on the global -- Internet. -- --Table of Contents -- -- 1. Introduction ....................................................2 -- 2. Acknowledgements ................................................3 -- 3. Local IPv6 Unicast Addresses ....................................3 -- 3.1. Format .....................................................3 -- 3.1.1. Background ..........................................4 -- 3.2. Global ID ..................................................4 -- 3.2.1. Locally Assigned Global IDs .........................5 -- 3.2.2. Sample Code for Pseudo-Random Global ID Algorithm ...5 -- 3.2.3. Analysis of the Uniqueness of Global IDs ............6 -- 3.3. Scope Definition ...........................................6 -- 4. Operational Guidelines ..........................................7 -- 4.1. Routing ....................................................7 -- 4.2. Renumbering and Site Merging ...............................7 -- 4.3. Site Border Router and Firewall Packet Filtering ...........8 -- 4.4. DNS Issues .................................................8 -- 4.5. Application and Higher Level Protocol Issues ...............9 -- 4.6. Use of Local IPv6 Addresses for Local Communication ........9 -- 4.7. Use of Local IPv6 Addresses with VPNs .....................10 -- -- -- --Hinden & Haberman Standards Track [Page 1] -- --RFC 4193 Unique Local IPv6 Unicast Addresses October 2005 -- -- -- 5. Global Routing Considerations ..................................11 -- 5.1. From the Standpoint of the Internet .......................11 -- 5.2. From the Standpoint of a Site .............................11 -- 6. Advantages and Disadvantages ...................................12 -- 6.1. Advantages ................................................12 -- 6.2. Disadvantages .............................................13 -- 7. Security Considerations ........................................13 -- 8. IANA Considerations ............................................13 -- 9. References .....................................................13 -- 9.1. Normative References ......................................13 -- 9.2. Informative References ....................................14 -- --1. Introduction -- -- This document defines an IPv6 unicast address format that is globally -- unique and is intended for local communications [IPV6]. These -- addresses are called Unique Local IPv6 Unicast Addresses and are -- abbreviated in this document as Local IPv6 addresses. They are not -- expected to be routable on the global Internet. They are routable -- inside of a more limited area such as a site. They may also be -- routed between a limited set of sites. -- -- Local IPv6 unicast addresses have the following characteristics: -- -- - Globally unique prefix (with high probability of uniqueness). -- -- - Well-known prefix to allow for easy filtering at site -- boundaries. -- -- - Allow sites to be combined or privately interconnected without -- creating any address conflicts or requiring renumbering of -- interfaces that use these prefixes. -- -- - Internet Service Provider independent and can be used for -- communications inside of a site without having any permanent or -- intermittent Internet connectivity. -- -- - If accidentally leaked outside of a site via routing or DNS, -- there is no conflict with any other addresses. -- -- - In practice, applications may treat these addresses like global -- scoped addresses. -- -- This document defines the format of Local IPv6 addresses, how to -- allocate them, and usage considerations including routing, site -- border routers, DNS, application support, VPN usage, and guidelines -- for how to use for local communication inside a site. -- -- -- -- --Hinden & Haberman Standards Track [Page 2] -- --RFC 4193 Unique Local IPv6 Unicast Addresses October 2005 -- -- -- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", -- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this -- document are to be interpreted as described in [RFC2119]. -- --2. Acknowledgements -- -- The underlying idea of creating Local IPv6 addresses described in -- this document has been proposed a number of times by a variety of -- people. The authors of this document do not claim exclusive credit. -- Credit goes to Brian Carpenter, Christian Huitema, Aidan Williams, -- Andrew White, Charlie Perkins, and many others. The authors would -- also like to thank Brian Carpenter, Charlie Perkins, Harald -- Alvestrand, Keith Moore, Margaret Wasserman, Shannon Behrens, Alan -- Beard, Hans Kruse, Geoff Huston, Pekka Savola, Christian Huitema, Tim -- Chown, Steve Bellovin, Alex Zinin, Tony Hain, Bill Fenner, Sam -- Hartman, and Elwyn Davies for their comments and suggestions on this -- document. -- --3. Local IPv6 Unicast Addresses -- --3.1. Format -- -- The Local IPv6 addresses are created using a pseudo-randomly -- allocated global ID. They have the following format: -- -- | 7 bits |1| 40 bits | 16 bits | 64 bits | -- +--------+-+------------+-----------+----------------------------+ -- | Prefix |L| Global ID | Subnet ID | Interface ID | -- +--------+-+------------+-----------+----------------------------+ -- -- Where: -- -- Prefix FC00::/7 prefix to identify Local IPv6 unicast -- addresses. -- -- L Set to 1 if the prefix is locally assigned. -- Set to 0 may be defined in the future. See -- Section 3.2 for additional information. -- -- Global ID 40-bit global identifier used to create a -- globally unique prefix. See Section 3.2 for -- additional information. -- -- Subnet ID 16-bit Subnet ID is an identifier of a subnet -- within the site. -- -- Interface ID 64-bit Interface ID as defined in [ADDARCH]. -- -- -- -- --Hinden & Haberman Standards Track [Page 3] -- --RFC 4193 Unique Local IPv6 Unicast Addresses October 2005 -- -- --3.1.1. Background -- -- There were a range of choices available when choosing the size of the -- prefix and Global ID field length. There is a direct tradeoff -- between having a Global ID field large enough to support foreseeable -- future growth and not using too much of the IPv6 address space -- needlessly. A reasonable way of evaluating a specific field length -- is to compare it to a projected 2050 world population of 9.3 billion -- [POPUL] and the number of resulting /48 prefixes per person. A range -- of prefix choices is shown in the following table: -- -- Prefix Global ID Number of Prefixes % of IPv6 -- Length /48 Prefixes per Person Address Space -- -- /11 37 137,438,953,472 15 0.049% -- /10 38 274,877,906,944 30 0.098% -- /9 39 549,755,813,888 59 0.195% -- /8 40 1,099,511,627,776 118 0.391% -- /7 41 2,199,023,255,552 236 0.781% -- /6 42 4,398,046,511,104 473 1.563% -- -- A very high utilization ratio of these allocations can be assumed -- because the Global ID field does not require internal structure, and -- there is no reason to be able to aggregate the prefixes. -- -- The authors believe that a /7 prefix resulting in a 41-bit Global ID -- space (including the L bit) is a good choice. It provides for a -- large number of assignments (i.e., 2.2 trillion) and at the same time -- uses less than .8% of the total IPv6 address space. It is unlikely -- that this space will be exhausted. If more than this were to be -- needed, then additional IPv6 address space could be allocated for -- this purpose. -- --3.2. Global ID -- -- The allocation of Global IDs is pseudo-random [RANDOM]. They MUST -- NOT be assigned sequentially or with well-known numbers. This is to -- ensure that there is not any relationship between allocations and to -- help clarify that these prefixes are not intended to be routed -- globally. Specifically, these prefixes are not designed to -- aggregate. -- -- This document defines a specific local method to allocate Global IDs, -- indicated by setting the L bit to 1. Another method, indicated by -- clearing the L bit, may be defined later. Apart from the allocation -- method, all Local IPv6 addresses behave and are treated identically. -- -- -- -- -- --Hinden & Haberman Standards Track [Page 4] -- --RFC 4193 Unique Local IPv6 Unicast Addresses October 2005 -- -- -- The local assignments are self-generated and do not need any central -- coordination or assignment, but have an extremely high probability of -- being unique. -- --3.2.1. Locally Assigned Global IDs -- -- Locally assigned Global IDs MUST be generated with a pseudo-random -- algorithm consistent with [RANDOM]. Section 3.2.2 describes a -- suggested algorithm. It is important that all sites generating -- Global IDs use a functionally similar algorithm to ensure there is a -- high probability of uniqueness. -- -- The use of a pseudo-random algorithm to generate Global IDs in the -- locally assigned prefix gives an assurance that any network numbered -- using such a prefix is highly unlikely to have that address space -- clash with any other network that has another locally assigned prefix -- allocated to it. This is a particularly useful property when -- considering a number of scenarios including networks that merge, -- overlapping VPN address space, or hosts mobile between such networks. -- --3.2.2. Sample Code for Pseudo-Random Global ID Algorithm -- -- The algorithm described below is intended to be used for locally -- assigned Global IDs. In each case the resulting global ID will be -- used in the appropriate prefix as defined in Section 3.2. -- -- 1) Obtain the current time of day in 64-bit NTP format [NTP]. -- -- 2) Obtain an EUI-64 identifier from the system running this -- algorithm. If an EUI-64 does not exist, one can be created from -- a 48-bit MAC address as specified in [ADDARCH]. If an EUI-64 -- cannot be obtained or created, a suitably unique identifier, -- local to the node, should be used (e.g., system serial number). -- -- 3) Concatenate the time of day with the system-specific identifier -- in order to create a key. -- -- 4) Compute an SHA-1 digest on the key as specified in [FIPS, SHA1]; -- the resulting value is 160 bits. -- -- 5) Use the least significant 40 bits as the Global ID. -- -- 6) Concatenate FC00::/7, the L bit set to 1, and the 40-bit Global -- ID to create a Local IPv6 address prefix. -- -- This algorithm will result in a Global ID that is reasonably unique -- and can be used to create a locally assigned Local IPv6 address -- prefix. -- -- -- --Hinden & Haberman Standards Track [Page 5] -- --RFC 4193 Unique Local IPv6 Unicast Addresses October 2005 -- -- --3.2.3. Analysis of the Uniqueness of Global IDs -- -- The selection of a pseudo random Global ID is similar to the -- selection of an SSRC identifier in RTP/RTCP defined in Section 8.1 of -- [RTP]. This analysis is adapted from that document. -- -- Since Global IDs are chosen randomly (and independently), it is -- possible that separate networks have chosen the same Global ID. For -- any given network, with one or more random Global IDs, that has -- inter-connections to other such networks, having a total of N such -- IDs, the probability that two or more of these IDs will collide can -- be approximated using the formula: -- -- P = 1 - exp(-N**2 / 2**(L+1)) -- -- where P is the probability of collision, N is the number of -- interconnected Global IDs, and L is the length of the Global ID. -- -- The following table shows the probability of a collision for a range -- of connections using a 40-bit Global ID field. -- -- Connections Probability of Collision -- -- 2 1.81*10^-12 -- 10 4.54*10^-11 -- 100 4.54*10^-09 -- 1000 4.54*10^-07 -- 10000 4.54*10^-05 -- -- Based on this analysis, the uniqueness of locally generated Global -- IDs is adequate for sites planning a small to moderate amount of -- inter-site communication using locally generated Global IDs. -- --3.3. Scope Definition -- -- By default, the scope of these addresses is global. That is, they -- are not limited by ambiguity like the site-local addresses defined in -- [ADDARCH]. Rather, these prefixes are globally unique, and as such, -- their applicability is greater than site-local addresses. Their -- limitation is in the routability of the prefixes, which is limited to -- a site and any explicit routing agreements with other sites to -- propagate them (also see Section 4.1). Also, unlike site-locals, a -- site may have more than one of these prefixes and use them at the -- same time. -- -- -- -- -- -- -- --Hinden & Haberman Standards Track [Page 6] -- --RFC 4193 Unique Local IPv6 Unicast Addresses October 2005 -- -- --4. Operational Guidelines -- -- The guidelines in this section do not require any change to the -- normal routing and forwarding functionality in an IPv6 host or -- router. These are configuration and operational usage guidelines. -- --4.1. Routing -- -- Local IPv6 addresses are designed to be routed inside of a site in -- the same manner as other types of unicast addresses. They can be -- carried in any IPv6 routing protocol without any change. -- -- It is expected that they would share the same Subnet IDs with -- provider-based global unicast addresses, if they were being used -- concurrently [GLOBAL]. -- -- The default behavior of exterior routing protocol sessions between -- administrative routing regions must be to ignore receipt of and not -- advertise prefixes in the FC00::/7 block. A network operator may -- specifically configure prefixes longer than FC00::/7 for inter-site -- communication. -- -- If BGP is being used at the site border with an ISP, the default BGP -- configuration must filter out any Local IPv6 address prefixes, both -- incoming and outgoing. It must be set both to keep any Local IPv6 -- address prefixes from being advertised outside of the site as well as -- to keep these prefixes from being learned from another site. The -- exception to this is if there are specific /48 or longer routes -- created for one or more Local IPv6 prefixes. -- -- For link-state IGPs, it is suggested that a site utilizing IPv6 local -- address prefixes be contained within one IGP domain or area. By -- containing an IPv6 local address prefix to a single link-state area -- or domain, the distribution of prefixes can be controlled. -- --4.2. Renumbering and Site Merging -- -- The use of Local IPv6 addresses in a site results in making -- communication that uses these addresses independent of renumbering a -- site's provider-based global addresses. -- -- When merging multiple sites, the addresses created with these -- prefixes are unlikely to need to be renumbered because all of the -- addresses have a high probability of being unique. Routes for each -- specific prefix would have to be configured to allow routing to work -- correctly between the formerly separate sites. -- -- -- -- -- --Hinden & Haberman Standards Track [Page 7] -- --RFC 4193 Unique Local IPv6 Unicast Addresses October 2005 -- -- --4.3. Site Border Router and Firewall Packet Filtering -- -- While no serious harm will be done if packets with these addresses -- are sent outside of a site via a default route, it is recommended -- that routers be configured by default to keep any packets with Local -- IPv6 addresses from leaking outside of the site and to keep any site -- prefixes from being advertised outside of their site. -- -- Site border routers and firewalls should be configured to not forward -- any packets with Local IPv6 source or destination addresses outside -- of the site, unless they have been explicitly configured with routing -- information about specific /48 or longer Local IPv6 prefixes. This -- will ensure that packets with Local IPv6 destination addresses will -- not be forwarded outside of the site via a default route. The -- default behavior of these devices should be to install a "reject" -- route for these prefixes. Site border routers should respond with -- the appropriate ICMPv6 Destination Unreachable message to inform the -- source that the packet was not forwarded. [ICMPV6]. This feedback is -- important to avoid transport protocol timeouts. -- -- Routers that maintain peering arrangements between Autonomous Systems -- throughout the Internet should obey the recommendations for site -- border routers, unless configured otherwise. -- --4.4. DNS Issues -- -- At the present time, AAAA and PTR records for locally assigned local -- IPv6 addresses are not recommended to be installed in the global DNS. -- -- For background on this recommendation, one of the concerns about -- adding AAAA and PTR records to the global DNS for locally assigned -- Local IPv6 addresses stems from the lack of complete assurance that -- the prefixes are unique. There is a small possibility that the same -- locally assigned IPv6 Local addresses will be used by two different -- organizations both claiming to be authoritative with different -- contents. In this scenario, it is likely there will be a connection -- attempt to the closest host with the corresponding locally assigned -- IPv6 Local address. This may result in connection timeouts, -- connection failures indicated by ICMP Destination Unreachable -- messages, or successful connections to the wrong host. Due to this -- concern, adding AAAA records for these addresses to the global DNS is -- thought to be unwise. -- -- Reverse (address-to-name) queries for locally assigned IPv6 Local -- addresses MUST NOT be sent to name servers for the global DNS, due to -- the load that such queries would create for the authoritative name -- servers for the ip6.arpa zone. This form of query load is not -- specific to locally assigned Local IPv6 addresses; any current form -- -- -- --Hinden & Haberman Standards Track [Page 8] -- --RFC 4193 Unique Local IPv6 Unicast Addresses October 2005 -- -- -- of local addressing creates additional load of this kind, due to -- reverse queries leaking out of the site. However, since allowing -- such queries to escape from the site serves no useful purpose, there -- is no good reason to make the existing load problems worse. -- -- The recommended way to avoid sending such queries to nameservers for -- the global DNS is for recursive name server implementations to act as -- if they were authoritative for an empty d.f.ip6.arpa zone and return -- RCODE 3 for any such query. Implementations that choose this -- strategy should allow it to be overridden, but returning an RCODE 3 -- response for such queries should be the default, both because this -- will reduce the query load problem and also because, if the site -- administrator has not set up the reverse tree corresponding to the -- locally assigned IPv6 Local addresses in use, returning RCODE 3 is in -- fact the correct answer. -- --4.5. Application and Higher Level Protocol Issues -- -- Application and other higher level protocols can treat Local IPv6 -- addresses in the same manner as other types of global unicast -- addresses. No special handling is required. This type of address -- may not be reachable, but that is no different from other types of -- IPv6 global unicast address. Applications need to be able to handle -- multiple addresses that may or may not be reachable at any point in -- time. In most cases, this complexity should be hidden in APIs. -- -- From a host's perspective, the difference between Local IPv6 and -- other types of global unicast addresses shows up as different -- reachability and could be handled by default in that way. In some -- cases, it is better for nodes and applications to treat them -- differently from global unicast addresses. A starting point might be -- to give them preference over global unicast, but fall back to global -- unicast if a particular destination is found to be unreachable. Much -- of this behavior can be controlled by how they are allocated to nodes -- and put into the DNS. However, it is useful if a host can have both -- types of addresses and use them appropriately. -- -- Note that the address selection mechanisms of [ADDSEL], and in -- particular the policy override mechanism replacing default address -- selection, are expected to be used on a site where Local IPv6 -- addresses are configured. -- --4.6. Use of Local IPv6 Addresses for Local Communication -- -- Local IPv6 addresses, like global scope unicast addresses, are only -- assigned to nodes if their use has been enabled (via IPv6 address -- autoconfiguration [ADDAUTO], DHCPv6 [DHCP6], or manually). They are -- -- -- -- --Hinden & Haberman Standards Track [Page 9] -- --RFC 4193 Unique Local IPv6 Unicast Addresses October 2005 -- -- -- not created automatically in the way that IPv6 link-local addresses -- are and will not appear or be used unless they are purposely -- configured. -- -- In order for hosts to autoconfigure Local IPv6 addresses, routers -- have to be configured to advertise Local IPv6 /64 prefixes in router -- advertisements, or a DHCPv6 server must have been configured to -- assign them. In order for a node to learn the Local IPv6 address of -- another node, the Local IPv6 address must have been installed in a -- naming system (e.g., DNS, proprietary naming system, etc.) For these -- reasons, controlling their usage in a site is straightforward. -- -- To limit the use of Local IPv6 addresses the following guidelines -- apply: -- -- - Nodes that are to only be reachable inside of a site: The local -- DNS should be configured to only include the Local IPv6 -- addresses of these nodes. Nodes with only Local IPv6 addresses -- must not be installed in the global DNS. -- -- - Nodes that are to be limited to only communicate with other -- nodes in the site: These nodes should be set to only -- autoconfigure Local IPv6 addresses via [ADDAUTO] or to only -- receive Local IPv6 addresses via [DHCP6]. Note: For the case -- where both global and Local IPv6 prefixes are being advertised -- on a subnet, this will require a switch in the devices to only -- autoconfigure Local IPv6 addresses. -- -- - Nodes that are to be reachable from inside of the site and from -- outside of the site: The DNS should be configured to include -- the global addresses of these nodes. The local DNS may be -- configured to also include the Local IPv6 addresses of these -- nodes. -- -- - Nodes that can communicate with other nodes inside of the site -- and outside of the site: These nodes should autoconfigure global -- addresses via [ADDAUTO] or receive global address via [DHCP6]. -- They may also obtain Local IPv6 addresses via the same -- mechanisms. -- --4.7. Use of Local IPv6 Addresses with VPNs -- -- Local IPv6 addresses can be used for inter-site Virtual Private -- Networks (VPN) if appropriate routes are set up. Because the -- addresses are unique, these VPNs will work reliably and without the -- need for translation. They have the additional property that they -- will continue to work if the individual sites are renumbered or -- merged. -- -- -- --Hinden & Haberman Standards Track [Page 10] -- --RFC 4193 Unique Local IPv6 Unicast Addresses October 2005 -- -- --5. Global Routing Considerations -- -- Section 4.1 provides operational guidelines that forbid default -- routing of local addresses between sites. Concerns were raised to -- the IPv6 working group and to the IETF as a whole that sites may -- attempt to use local addresses as globally routed provider- -- independent addresses. This section describes why using local -- addresses as globally-routed provider-independent addresses is -- unadvisable. -- --5.1. From the Standpoint of the Internet -- -- There is a mismatch between the structure of IPv6 local addresses and -- the normal IPv6 wide area routing model. The /48 prefix of an IPv6 -- local addresses fits nowhere in the normal hierarchy of IPv6 unicast -- addresses. Normal IPv6 unicast addresses can be routed -- hierarchically down to physical subnet (link) level and only have to -- be flat-routed on the physical subnet. IPv6 local addresses would -- have to be flat-routed even over the wide area Internet. -- -- Thus, packets whose destination address is an IPv6 local address -- could be routed over the wide area only if the corresponding /48 -- prefix were carried by the wide area routing protocol in use, such as -- BGP. This contravenes the operational assumption that long prefixes -- will be aggregated into many fewer short prefixes, to limit the table -- size and convergence time of the routing protocol. If a network uses -- both normal IPv6 addresses [ADDARCH] and IPv6 local addresses, these -- types of addresses will certainly not aggregate with each other, -- since they differ from the most significant bit onwards. Neither -- will IPv6 local addresses aggregate with each other, due to their -- random bit patterns. This means that there would be a very -- significant operational penalty for attempting to use IPv6 local -- address prefixes generically with currently known wide area routing -- technology. -- --5.2. From the Standpoint of a Site -- -- There are a number of design factors in IPv6 local addresses that -- reduce the likelihood that IPv6 local addresses will be used as -- arbitrary global unicast addresses. These include: -- -- - The default rules to filter packets and routes make it very -- difficult to use IPv6 local addresses for arbitrary use across -- the Internet. For a site to use them as general purpose unicast -- addresses, it would have to make sure that the default rules -- were not being used by all other sites and intermediate ISPs -- used for their current and future communication. -- -- -- -- --Hinden & Haberman Standards Track [Page 11] -- --RFC 4193 Unique Local IPv6 Unicast Addresses October 2005 -- -- -- - They are not mathematically guaranteed to be unique and are not -- registered in public databases. Collisions, while highly -- unlikely, are possible and a collision can compromise the -- integrity of the communications. The lack of public -- registration creates operational problems. -- -- - The addresses are allocated randomly. If a site had multiple -- prefixes that it wanted to be used globally, the cost of -- advertising them would be very high because they could not be -- aggregated. -- -- - They have a long prefix (i.e., /48) so a single local address -- prefix doesn't provide enough address space to be used -- exclusively by the largest organizations. -- --6. Advantages and Disadvantages -- --6.1. Advantages -- -- This approach has the following advantages: -- -- - Provides Local IPv6 prefixes that can be used independently of -- any provider-based IPv6 unicast address allocations. This is -- useful for sites not always connected to the Internet or sites -- that wish to have a distinct prefix that can be used to localize -- traffic inside of the site. -- -- - Applications can treat these addresses in an identical manner as -- any other type of global IPv6 unicast addresses. -- -- - Sites can be merged without any renumbering of the Local IPv6 -- addresses. -- -- - Sites can change their provider-based IPv6 unicast address -- without disrupting any communication that uses Local IPv6 -- addresses. -- -- - Well-known prefix that allows for easy filtering at site -- boundary. -- -- - Can be used for inter-site VPNs. -- -- - If accidently leaked outside of a site via routing or DNS, there -- is no conflict with any other addresses. -- -- -- -- -- -- -- --Hinden & Haberman Standards Track [Page 12] -- --RFC 4193 Unique Local IPv6 Unicast Addresses October 2005 -- -- --6.2. Disadvantages -- -- This approach has the following disadvantages: -- -- - Not possible to route Local IPv6 prefixes on the global Internet -- with current routing technology. Consequentially, it is -- necessary to have the default behavior of site border routers to -- filter these addresses. -- -- - There is a very low probability of non-unique locally assigned -- Global IDs being generated by the algorithm in Section 3.2.3. -- This risk can be ignored for all practical purposes, but it -- leads to a theoretical risk of clashing address prefixes. -- --7. Security Considerations -- -- Local IPv6 addresses do not provide any inherent security to the -- nodes that use them. They may be used with filters at site -- boundaries to keep Local IPv6 traffic inside of the site, but this is -- no more or less secure than filtering any other type of global IPv6 -- unicast addresses. -- -- Local IPv6 addresses do allow for address-based security mechanisms, -- including IPsec, across end to end VPN connections. -- --8. IANA Considerations -- -- The IANA has assigned the FC00::/7 prefix to "Unique Local Unicast". -- --9. References -- --9.1. Normative References -- -- [ADDARCH] Hinden, R. and S. Deering, "Internet Protocol Version 6 -- (IPv6) Addressing Architecture", RFC 3513, April 2003. -- -- [FIPS] "Federal Information Processing Standards Publication", -- (FIPS PUB) 180-1, Secure Hash Standard, 17 April 1995. -- -- [GLOBAL] Hinden, R., Deering, S., and E. Nordmark, "IPv6 Global -- Unicast Address Format", RFC 3587, August 2003. -- -- [ICMPV6] Conta, A. and S. Deering, "Internet Control Message -- Protocol (ICMPv6) for the Internet Protocol Version 6 -- (IPv6) Specification", RFC 2463, December 1998. -- -- -- -- -- -- --Hinden & Haberman Standards Track [Page 13] -- --RFC 4193 Unique Local IPv6 Unicast Addresses October 2005 -- -- -- [IPV6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 -- (IPv6) Specification", RFC 2460, December 1998. -- -- [NTP] Mills, D., "Network Time Protocol (Version 3) -- Specification, Implementation and Analysis", RFC 1305, -- March 1992. -- -- [RANDOM] Eastlake, D., 3rd, Schiller, J., and S. Crocker, -- "Randomness Requirements for Security", BCP 106, RFC 4086, -- June 2005. -- -- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate -- Requirement Levels", BCP 14, RFC 2119, March 1997. -- -- [SHA1] Eastlake 3rd, D. and P. Jones, "US Secure Hash Algorithm 1 -- (SHA1)", RFC 3174, September 2001. -- --9.2. Informative References -- -- [ADDAUTO] Thomson, S. and T. Narten, "IPv6 Stateless Address -- Autoconfiguration", RFC 2462, December 1998. -- -- [ADDSEL] Draves, R., "Default Address Selection for Internet -- Protocol version 6 (IPv6)", RFC 3484, February 2003. -- -- [DHCP6] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and -- M. Carney, "Dynamic Host Configuration Protocol for IPv6 -- (DHCPv6)", RFC 3315, July 2003. -- -- [POPUL] Population Reference Bureau, "World Population Data Sheet -- of the Population Reference Bureau 2002", August 2002. -- -- [RTP] Schulzrinne, H., Casner, S., Frederick, R., and V. -- Jacobson, "RTP: A Transport Protocol for Real-Time -- Applications", STD 64, RFC 3550, July 2003. -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --Hinden & Haberman Standards Track [Page 14] -- --RFC 4193 Unique Local IPv6 Unicast Addresses October 2005 -- -- --Authors' Addresses -- -- Robert M. Hinden -- Nokia -- 313 Fairchild Drive -- Mountain View, CA 94043 -- USA -- -- Phone: +1 650 625-2004 -- EMail: bob.hinden@nokia.com -- -- -- Brian Haberman -- Johns Hopkins University -- Applied Physics Lab -- 11100 Johns Hopkins Road -- Laurel, MD 20723 -- USA -- -- Phone: +1 443 778 1319 -- EMail: brian@innovationslab.net -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --Hinden & Haberman Standards Track [Page 15] -- --RFC 4193 Unique Local IPv6 Unicast Addresses October 2005 -- -- --Full Copyright Statement -- -- Copyright (C) The Internet Society (2005). -- -- This document is subject to the rights, licenses and restrictions -- contained in BCP 78, and except as set forth therein, the authors -- retain all their rights. -- -- This document and the information contained herein are provided on an -- "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS -- OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET -- ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, -- INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE -- INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED -- WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. -- --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. -- -- -- -- -- -- -- --Hinden & Haberman Standards Track [Page 16] -- diff --cc doc/rfc/rfc4255.txt index f350b7af957,f350b7af957..00000000000 deleted file mode 100644,100644 --- a/doc/rfc/rfc4255.txt +++ /dev/null @@@ -1,507 -1,507 +1,0 @@@ -- -- -- -- -- -- --Network Working Group J. Schlyter --Request for Comments: 4255 OpenSSH --Category: Standards Track W. Griffin -- SPARTA -- January 2006 -- -- -- Using DNS to Securely Publish Secure Shell (SSH) Key Fingerprints -- --Status of This Memo -- -- This document specifies an Internet standards track protocol for the -- Internet community, and requests discussion and suggestions for -- improvements. Please refer to the current edition of the "Internet -- Official Protocol Standards" (STD 1) for the standardization state -- and status of this protocol. Distribution of this memo is unlimited. -- --Copyright Notice -- -- Copyright (C) The Internet Society (2006). -- --Abstract -- -- This document describes a method of verifying Secure Shell (SSH) host -- keys using Domain Name System Security (DNSSEC). The document -- defines a new DNS resource record that contains a standard SSH key -- fingerprint. -- --Table of Contents -- -- 1. Introduction ....................................................2 -- 2. SSH Host Key Verification .......................................2 -- 2.1. Method .....................................................2 -- 2.2. Implementation Notes .......................................2 -- 2.3. Fingerprint Matching .......................................3 -- 2.4. Authentication .............................................3 -- 3. The SSHFP Resource Record .......................................3 -- 3.1. The SSHFP RDATA Format .....................................4 -- 3.1.1. Algorithm Number Specification ......................4 -- 3.1.2. Fingerprint Type Specification ......................4 -- 3.1.3. Fingerprint .........................................5 -- 3.2. Presentation Format of the SSHFP RR ........................5 -- 4. Security Considerations .........................................5 -- 5. IANA Considerations .............................................6 -- 6. Normative References ............................................7 -- 7. Informational References ........................................7 -- 8. Acknowledgements ................................................8 -- -- -- -- --Schlyter & Griffin Standards Track [Page 1] -- --RFC 4255 DNS and SSH Fingerprints January 2006 -- -- --1. Introduction -- -- The SSH [6] protocol provides secure remote login and other secure -- network services over an insecure network. The security of the -- connection relies on the server authenticating itself to the client -- as well as the user authenticating itself to the server. -- -- If a connection is established to a server whose public key is not -- already known to the client, a fingerprint of the key is presented to -- the user for verification. If the user decides that the fingerprint -- is correct and accepts the key, the key is saved locally and used for -- verification for all following connections. While some security- -- conscious users verify the fingerprint out-of-band before accepting -- the key, many users blindly accept the presented key. -- -- The method described here can provide out-of-band verification by -- looking up a fingerprint of the server public key in the DNS [1][2] -- and using DNSSEC [5] to verify the lookup. -- -- In order to distribute the fingerprint using DNS, this document -- defines a new DNS resource record, "SSHFP", to carry the fingerprint. -- -- Basic understanding of the DNS system [1][2] and the DNS security -- extensions [5] is assumed by 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 [3]. -- --2. SSH Host Key Verification -- --2.1. Method -- -- Upon connection to an SSH server, the SSH client MAY look up the -- SSHFP resource record(s) for the host it is connecting to. If the -- algorithm and fingerprint of the key received from the SSH server -- match the algorithm and fingerprint of one of the SSHFP resource -- record(s) returned from DNS, the client MAY accept the identity of -- the server. -- --2.2. Implementation Notes -- -- Client implementors SHOULD provide a configurable policy used to -- select the order of methods used to verify a host key. This document -- defines one method: Fingerprint storage in DNS. Another method -- defined in the SSH Architecture [6] uses local files to store keys -- for comparison. Other methods that could be defined in the future -- might include storing fingerprints in LDAP or other databases. A -- -- -- --Schlyter & Griffin Standards Track [Page 2] -- --RFC 4255 DNS and SSH Fingerprints January 2006 -- -- -- configurable policy will allow administrators to determine which -- methods they want to use and in what order the methods should be -- prioritized. This will allow administrators to determine how much -- trust they want to place in the different methods. -- -- One specific scenario for having a configurable policy is where -- clients do not use fully qualified host names to connect to servers. -- In this scenario, the implementation SHOULD verify the host key -- against a local database before verifying the key via the fingerprint -- returned from DNS. This would help prevent an attacker from -- injecting a DNS search path into the local resolver and forcing the -- client to connect to a different host. -- --2.3. Fingerprint Matching -- -- The public key and the SSHFP resource record are matched together by -- comparing algorithm number and fingerprint. -- -- The public key algorithm and the SSHFP algorithm number MUST -- match. -- -- A message digest of the public key, using the message digest -- algorithm specified in the SSHFP fingerprint type, MUST match the -- SSHFP fingerprint. -- --2.4. Authentication -- -- A public key verified using this method MUST NOT be trusted if the -- SSHFP resource record (RR) used for verification was not -- authenticated by a trusted SIG RR. -- -- Clients that do validate the DNSSEC signatures themselves SHOULD use -- standard DNSSEC validation procedures. -- -- Clients that do not validate the DNSSEC signatures themselves MUST -- use a secure transport (e.g., TSIG [9], SIG(0) [10], or IPsec [8]) -- between themselves and the entity performing the signature -- validation. -- --3. The SSHFP Resource Record -- -- The SSHFP resource record (RR) is used to store a fingerprint of an -- SSH public host key that is associated with a Domain Name System -- (DNS) name. -- -- The RR type code for the SSHFP RR is 44. -- -- -- -- -- --Schlyter & Griffin Standards Track [Page 3] -- --RFC 4255 DNS and SSH Fingerprints January 2006 -- -- --3.1. The SSHFP RDATA Format -- -- The RDATA for a SSHFP RR consists of an algorithm number, fingerprint -- type and the fingerprint of the public host key. -- -- 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 -- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -- | algorithm | fp type | / -- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / -- / / -- / fingerprint / -- / / -- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -- --3.1.1. Algorithm Number Specification -- -- This algorithm number octet describes the algorithm of the public -- key. The following values are assigned: -- -- Value Algorithm name -- ----- -------------- -- 0 reserved -- 1 RSA -- 2 DSS -- -- Reserving other types requires IETF consensus [4]. -- --3.1.2. Fingerprint Type Specification -- -- The fingerprint type octet describes the message-digest algorithm -- used to calculate the fingerprint of the public key. The following -- values are assigned: -- -- Value Fingerprint type -- ----- ---------------- -- 0 reserved -- 1 SHA-1 -- -- Reserving other types requires IETF consensus [4]. -- -- For interoperability reasons, as few fingerprint types as possible -- should be reserved. The only reason to reserve additional types is -- to increase security. -- -- -- -- -- -- -- --Schlyter & Griffin Standards Track [Page 4] -- --RFC 4255 DNS and SSH Fingerprints January 2006 -- -- --3.1.3. Fingerprint -- -- The fingerprint is calculated over the public key blob as described -- in [7]. -- -- The message-digest algorithm is presumed to produce an opaque octet -- string output, which is placed as-is in the RDATA fingerprint field. -- --3.2. Presentation Format of the SSHFP RR -- -- The RDATA of the presentation format of the SSHFP resource record -- consists of two numbers (algorithm and fingerprint type) followed by -- the fingerprint itself, presented in hex, e.g.: -- -- host.example. SSHFP 2 1 123456789abcdef67890123456789abcdef67890 -- -- The use of mnemonics instead of numbers is not allowed. -- --4. Security Considerations -- -- Currently, the amount of trust a user can realistically place in a -- server key is proportional to the amount of attention paid to -- verifying that the public key presented actually corresponds to the -- private key of the server. If a user accepts a key without verifying -- the fingerprint with something learned through a secured channel, the -- connection is vulnerable to a man-in-the-middle attack. -- -- The overall security of using SSHFP for SSH host key verification is -- dependent on the security policies of the SSH host administrator and -- DNS zone administrator (in transferring the fingerprint), detailed -- aspects of how verification is done in the SSH implementation, and in -- the client's diligence in accessing the DNS in a secure manner. -- -- One such aspect is in which order fingerprints are looked up (e.g., -- first checking local file and then SSHFP). We note that, in addition -- to protecting the first-time transfer of host keys, SSHFP can -- optionally be used for stronger host key protection. -- -- If SSHFP is checked first, new SSH host keys may be distributed by -- replacing the corresponding SSHFP in DNS. -- -- If SSH host key verification can be configured to require SSHFP, -- SSH host key revocation can be implemented by removing the -- corresponding SSHFP from DNS. -- -- -- -- -- -- -- --Schlyter & Griffin Standards Track [Page 5] -- --RFC 4255 DNS and SSH Fingerprints January 2006 -- -- -- As stated in Section 2.2, we recommend that SSH implementors provide -- a policy mechanism to control the order of methods used for host key -- verification. One specific scenario for having a configurable policy -- is where clients use unqualified host names to connect to servers. -- In this case, we recommend that SSH implementations check the host -- key against a local database before verifying the key via the -- fingerprint returned from DNS. This would help prevent an attacker -- from injecting a DNS search path into the local resolver and forcing -- the client to connect to a different host. -- -- A different approach to solve the DNS search path issue would be for -- clients to use a trusted DNS search path, i.e., one not acquired -- through DHCP or other autoconfiguration mechanisms. Since there is -- no way with current DNS lookup APIs to tell whether a search path is -- from a trusted source, the entire client system would need to be -- configured with this trusted DNS search path. -- -- Another dependency is on the implementation of DNSSEC itself. As -- stated in Section 2.4, we mandate the use of secure methods for -- lookup and that SSHFP RRs are authenticated by trusted SIG RRs. This -- is especially important if SSHFP is to be used as a basis for host -- key rollover and/or revocation, as described above. -- -- Since DNSSEC only protects the integrity of the host key fingerprint -- after it is signed by the DNS zone administrator, the fingerprint -- must be transferred securely from the SSH host administrator to the -- DNS zone administrator. This could be done manually between the -- administrators or automatically using secure DNS dynamic update [11] -- between the SSH server and the nameserver. We note that this is no -- different from other key enrollment situations, e.g., a client -- sending a certificate request to a certificate authority for signing. -- --5. IANA Considerations -- -- IANA has allocated the RR type code 44 for SSHFP from the standard RR -- type space. -- -- IANA has opened a new registry for the SSHFP RR type for public key -- algorithms. The defined types are: -- -- 0 is reserved -- 1 is RSA -- 2 is DSA -- -- Adding new reservations requires IETF consensus [4]. -- -- -- -- -- -- --Schlyter & Griffin Standards Track [Page 6] -- --RFC 4255 DNS and SSH Fingerprints January 2006 -- -- -- IANA has opened a new registry for the SSHFP RR type for fingerprint -- types. The defined types are: -- -- 0 is reserved -- 1 is SHA-1 -- -- Adding new reservations requires IETF consensus [4]. -- --6. Normative References -- -- [1] Mockapetris, P., "Domain names - concepts and facilities", STD -- 13, RFC 1034, November 1987. -- -- [2] Mockapetris, P., "Domain names - implementation and -- specification", STD 13, RFC 1035, November 1987. -- -- [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement -- Levels", BCP 14, RFC 2119, March 1997. -- -- [4] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA -- Considerations Section in RFCs", BCP 26, RFC 2434, October -- 1998. -- -- [5] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, -- "DNS Security Introduction and Requirements", RFC 4033, March -- 2005. -- -- Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, -- "Resource Records for the DNS Security Extensions", RFC 4034, -- March 2005. -- -- Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, -- "Protocol Modifications for the DNS Security Extensions", RFC -- 4035, March 2005. -- -- [6] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) -- Protocol Architecture", RFC 4251, January 2006. -- -- [7] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) -- Transport Layer Protocol", RFC 4253, January 2006. -- --7. Informational References -- -- [8] Thayer, R., Doraswamy, N., and R. Glenn, "IP Security Document -- Roadmap", RFC 2411, November 1998. -- -- -- -- -- -- --Schlyter & Griffin Standards Track [Page 7] -- --RFC 4255 DNS and SSH Fingerprints January 2006 -- -- -- [9] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B. -- Wellington, "Secret Key Transaction Authentication for DNS -- (TSIG)", RFC 2845, May 2000. -- -- [10] Eastlake 3rd, D., "DNS Request and Transaction Signatures -- ( SIG(0)s )", RFC 2931, September 2000. -- -- [11] Wellington, B., "Secure Domain Name System (DNS) Dynamic -- Update", RFC 3007, November 2000. -- --8. Acknowledgements -- -- The authors gratefully acknowledge, in no particular order, the -- contributions of the following persons: -- -- Martin Fredriksson -- -- Olafur Gudmundsson -- -- Edward Lewis -- -- Bill Sommerfeld -- --Authors' Addresses -- -- Jakob Schlyter -- OpenSSH -- 812 23rd Avenue SE -- Calgary, Alberta T2G 1N8 -- Canada -- -- EMail: jakob@openssh.com -- URI: http://www.openssh.com/ -- -- -- Wesley Griffin -- SPARTA -- 7075 Samuel Morse Drive -- Columbia, MD 21046 -- USA -- -- EMail: wgriffin@sparta.com -- URI: http://www.sparta.com/ -- -- -- -- -- -- -- -- --Schlyter & Griffin Standards Track [Page 8] -- --RFC 4255 DNS and SSH Fingerprints January 2006 -- -- --Full Copyright Statement -- -- Copyright (C) The Internet Society (2006). -- -- 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 provided by the IETF -- Administrative Support Activity (IASA). -- -- -- -- -- -- -- --Schlyter & Griffin Standards Track [Page 9] -- diff --cc doc/rfc/rfc4343.txt index 621420a45f4,621420a45f4..00000000000 deleted file mode 100644,100644 --- a/doc/rfc/rfc4343.txt +++ /dev/null @@@ -1,563 -1,563 +1,0 @@@ -- -- -- -- -- -- --Network Working Group D. Eastlake 3rd --Request for Comments: 4343 Motorola Laboratories --Updates: 1034, 1035, 2181 January 2006 --Category: Standards Track -- -- -- Domain Name System (DNS) Case Insensitivity Clarification -- --Status of This Memo -- -- This document specifies an Internet standards track protocol for the -- Internet community, and requests discussion and suggestions for -- improvements. Please refer to the current edition of the "Internet -- Official Protocol Standards" (STD 1) for the standardization state -- and status of this protocol. Distribution of this memo is unlimited. -- --Copyright Notice -- -- Copyright (C) The Internet Society (2006). -- --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, 1035, and 2181. -- --Table of Contents -- -- 1. Introduction ....................................................2 -- 2. Case Insensitivity of DNS Labels ................................2 -- 2.1. Escaping Unusual DNS Label Octets ..........................2 -- 2.2. Example Labels with Escapes ................................3 -- 3. Name Lookup, Label Types, and CLASS .............................3 -- 3.1. Original DNS Label Types ...................................4 -- 3.2. Extended Label Type Case Insensitivity Considerations ......4 -- 3.3. CLASS Case Insensitivity Considerations ....................4 -- 4. Case on Input and Output ........................................5 -- 4.1. DNS Output Case Preservation ...............................5 -- 4.2. DNS Input Case Preservation ................................5 -- 5. Internationalized Domain Names ..................................6 -- 6. Security Considerations .........................................6 -- 7. Acknowledgements ................................................7 -- Normative References................................................7 -- Informative References..............................................8 -- -- -- -- -- -- -- --Eastlake 3rd Standards Track [Page 1] -- --RFC 4343 DNS Case Insensitivity Clarification January 2006 -- -- --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 [STD13, RFC1591, RFC2606] that are treated in -- a case insensitive fashion. This document clarifies the meaning of -- "case insensitive" for the DNS. This clarification updates RFCs -- 1034, 1035 [STD13], and [RFC2181]. -- -- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", -- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this -- document are to be interpreted as described in [RFC2119]. -- --2. 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 to 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 [RFC3092] 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 [STD13] 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 from 0x21 -- ("!") to 0x7E ("~"). That is to say, 0x2E and all octet values in -- the two inclusive ranges from 0x00 to 0x20 and from 0x7F to 0xFF. -- -- -- -- -- --Eastlake 3rd Standards Track [Page 2] -- --RFC 4343 DNS Case Insensitivity Clarification January 2006 -- -- -- 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 \. 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 shows 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 -- -- According to the original DNS design decision, comparisons on name -- lookup for DNS queries should be case insensitive [STD13]. That is -- to say, a lookup string octet with a value in the inclusive range -- from 0x41 to 0x5A, the uppercase ASCII letters, MUST match the -- identical value and also match the corresponding value in the -- inclusive range from 0x61 to 0x7A, the lowercase ASCII letters. A -- lookup string octet with a lowercase ASCII letter value MUST -- similarly match the identical value and also match the corresponding -- value in the uppercase ASCII letter range. -- -- (Historical note: The terms "uppercase" and "lowercase" were invented -- after movable type. The terms originally referred to the two font -- trays for storing, in partitioned areas, the different physical type -- elements. Before movable type, the nearest equivalent terms were -- "majuscule" and "minuscule".) -- -- -- -- -- --Eastlake 3rd Standards Track [Page 3] -- --RFC 4343 DNS Case Insensitivity Clarification January 2006 -- -- -- One way to implement this rule would be to subtract 0x20 from all -- octets in the inclusive range from 0x61 to 0x7A before comparing -- octets. 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 [STD13] had only two types: ASCII labels, -- with a length from zero to 63 octets, and indirect (or compression) -- 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 [RFC2671] so that additional label type numbers -- would be available. (The only such type defined so far is the BINARY -- type [RFC2673], which is now Experimental [RFC3363].) -- -- 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 [STD13] and [RFC2929], DNS has an additional axis for -- data location called CLASS. The only CLASS in global use at this -- time is the "IN" (Internet) CLASS. -- -- The handling of DNS label case is not CLASS dependent. With the -- original design of DNS, it was intended that a recursive DNS resolver -- be able to handle new CLASSes that were unknown at the time of its -- implementation. This requires uniform handling of label case -- insensitivity. Should it become desirable, for example, to allocate -- a CLASS with "case sensitive ASCII labels", it would be necessary to -- allocate a new label type for these labels. -- -- -- -- --Eastlake 3rd Standards Track [Page 4] -- --RFC 4343 DNS Case Insensitivity Clarification January 2006 -- -- --4. Case on Input and Output -- -- While ASCII label comparisons are case insensitive, [STD13] 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 -- -- [STD13] views the DNS namespace as a node tree. ASCII output is as -- if a name were 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 are 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 data came from an ASCII Master File as defined in -- [STD13] or a zone transfer. DNS Dynamic update and incremental zone -- transfers [RFC1995] have been added as a source of DNS data [RFC2136, -- RFC3007]. 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 exists in DNS data being -- held, the situation is more complex. Implementations are free to -- retain the case first loaded for such a label, to allow new input to -- override the old case, or even to maintain separate copies preserving -- the input case. -- -- For example, if data with owner name "foo.bar.example" [RFC3092] is -- loaded 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" in the DNS stored data. Thus, -- later retrieval of data stored under "xyz.bar.example" in this case -- can use "xyz.BAR.example" in all returned data, use "xyz.bar.example" -- in all returned data, or even, when more than one RR is being -- returned, use a mixture of these two capitalizations. This last case -- -- -- --Eastlake 3rd Standards Track [Page 5] -- --RFC 4343 DNS Case Insensitivity Clarification January 2006 -- -- -- is unlikely, as optimization of answer length through indirect labels -- tends to cause only one copy of the name tail ("bar.example" or -- "BAR.example") to be used for all returned RRs. Note that none of -- this has any effect on the number or completeness of the RR set -- returned, only on the case of the names in the RR set returned. -- -- The same considerations apply when inputting multiple data records -- with owner names differing only in case. For example, if an "A" -- record is the first resource record stored 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, the second MAY override the first so that -- only an uppercase initial label is retained, or both capitalizations -- MAY be kept in the DNS stored data. In any case, a retrieval with -- either capitalization will retrieve all RRs with either -- capitalization. -- -- 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 [RFC3490, RFC3454, -- RFC3491, and RFC3492]. 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 [RFC3454] and [RFC3491], 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 that 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 database -- or file 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 -- -- -- --Eastlake 3rd Standards Track [Page 6] -- --RFC 4343 DNS Case Insensitivity Clarification January 2006 -- -- -- ASCII type labels; that is, always mapping the ASCII letter value -- octets in ASCII labels to some specific pre-chosen case, either -- uppercase or lower case. An example of a canonical form for domain -- names (and also a canonical ordering for them) appears in Section 6 -- of [RFC4034]. See also [RFC3597]. -- -- Finally, a non-DNS name may be stored into DNS with the false -- expectation that case will always be preserved. For example, -- although this would be quite rare, on a system with case sensitive -- email address local parts, an attempt to store two Responsible Person -- (RP) [RFC1183] 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. -- --7. Acknowledgements -- -- The contributions to this document by Rob Austein, Olafur -- Gudmundsson, Daniel J. Anderson, Alan Barrett, Marc Blanchet, Dana, -- Andreas Gustafsson, Andrew Main, Thomas Narten, and Scott Seligman -- are gratefully acknowledged. -- --Normative References -- -- [ASCII] ANSI, "USA Standard Code for Information Interchange", -- X3.4, American National Standards Institute: New York, -- 1968. -- -- [RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, -- August 1996. -- -- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate -- 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. -- -- [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic -- Update", RFC 3007, November 2000. -- -- -- -- -- -- --Eastlake 3rd Standards Track [Page 7] -- --RFC 4343 DNS Case Insensitivity Clarification January 2006 -- -- -- [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record -- (RR) Types", RFC 3597, September 2003. -- -- [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. -- Rose, "Resource Records for the DNS Security -- Extensions", RFC 4034, March 2005. -- -- [STD13] Mockapetris, P., "Domain names - concepts and -- facilities", STD 13, RFC 1034, November 1987. -- -- Mockapetris, P., "Domain names - implementation and -- specification", STD 13, RFC 1035, November 1987. -- --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. -- -- [RFC1183] Everhart, C., Mamakos, L., Ullmann, R., and P. -- Mockapetris, "New DNS RR Definitions", RFC 1183, October -- 1990. -- -- [RFC1591] Postel, J., "Domain Name System Structure and -- Delegation", RFC 1591, March 1994. -- -- [RFC2606] Eastlake 3rd, D. and A. Panitz, "Reserved Top Level DNS -- Names", BCP 32, RFC 2606, June 1999. -- -- [RFC2929] Eastlake 3rd, D., Brunner-Williams, E., and B. Manning, -- "Domain Name System (DNS) IANA Considerations", BCP 42, -- RFC 2929, September 2000. -- -- [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC -- 2671, August 1999. -- -- [RFC2673] Crawford, M., "Binary Labels in the Domain Name System", -- RFC 2673, August 1999. -- -- [RFC3092] Eastlake 3rd, D., Manros, C., and E. Raymond, "Etymology -- of "Foo"", RFC 3092, 1 April 2001. -- -- [RFC3363] Bush, R., Durand, A., Fink, B., Gudmundsson, O., and T. -- Hain, "Representing Internet Protocol version 6 (IPv6) -- Addresses in the Domain Name System (DNS)", RFC 3363, -- August 2002. -- -- -- --Eastlake 3rd Standards Track [Page 8] -- --RFC 4343 DNS Case Insensitivity Clarification January 2006 -- -- -- [RFC3454] Hoffman, P. and M. Blanchet, "Preparation of -- Internationalized Strings ("stringprep")", RFC 3454, -- December 2002. -- -- [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, -- "Internationalizing Domain Names in Applications -- (IDNA)", RFC 3490, March 2003. -- -- [RFC3491] Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep -- Profile for Internationalized Domain Names (IDN)", RFC -- 3491, March 2003. -- -- [RFC3492] Costello, A., "Punycode: A Bootstring encoding of -- Unicode for Internationalized Domain Names in -- Applications (IDNA)", RFC 3492, March 2003. -- -- [UNICODE] The Unicode Consortium, "The Unicode Standard", -- . -- --Author's Address -- -- Donald E. Eastlake 3rd -- Motorola Laboratories -- 155 Beaver Street -- Milford, MA 01757 USA -- -- Phone: +1 508-786-7554 (w) -- EMail: Donald.Eastlake@motorola.com -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --Eastlake 3rd Standards Track [Page 9] -- --RFC 4343 DNS Case Insensitivity Clarification January 2006 -- -- --Full Copyright Statement -- -- Copyright (C) The Internet Society (2006). -- -- 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 provided by the IETF -- Administrative Support Activity (IASA). -- -- -- -- -- -- -- --Eastlake 3rd Standards Track [Page 10] --