summaryrefslogtreecommitdiffstats
path: root/contrib/bind9/doc/rfc/rfc4343.txt
diff options
context:
space:
mode:
Diffstat (limited to 'contrib/bind9/doc/rfc/rfc4343.txt')
-rw-r--r--contrib/bind9/doc/rfc/rfc4343.txt563
1 files changed, 563 insertions, 0 deletions
diff --git a/contrib/bind9/doc/rfc/rfc4343.txt b/contrib/bind9/doc/rfc/rfc4343.txt
new file mode 100644
index 0000000..621420a
--- /dev/null
+++ b/contrib/bind9/doc/rfc/rfc4343.txt
@@ -0,0 +1,563 @@
+
+
+
+
+
+
+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",
+ <http://www.unicode.org/unicode/standard/standard.html>.
+
+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]
+
OpenPOWER on IntegriCloud