diff --git a/doc/draft/draft-ietf-dnsext-insensitive-00.txt b/doc/draft/draft-ietf-dnsext-insensitive-00.txt new file mode 100644 index 0000000000..d6a85ccac9 --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-insensitive-00.txt @@ -0,0 +1,464 @@ + +INTERNET-DRAFT Donald E. Eastlake 3rd +Clarifies STD0013 Motorola Laboratories +Expires July 2003 January 2003 + + + + Domain Name System (DNS) Case Insensitivity Clarification + ------ ---- ------ ----- ---- ------------- ------------- + + + Donald E. Eastlake 3rd + + + +Status of This Document + + Distribution of this document is unlimited. Comments should be sent + to the DNSEXT working group at namedroppers@ops.ietf.org. + + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC 2026. Internet-Drafts are + working documents of the Internet Engineering Task Force (IETF), its + areas, and its working groups. Note that other groups may also + distribute working documents as Internet-Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet- Drafts as reference + material or to cite them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + + +Abstract + + Domain Name System (DNS) names are "case insensitive". This document + explains exactly what that means and provides a clear specification + of the rules. This clarification should not have any interoperability + consequences. + + + + + + + + + + + +D. Eastlake 3rd [Page 1] + + +INTERNET-DRAFT DNS Case Insensitivity + + +Table of Contents + + Status of This Document....................................1 + Abstract...................................................1 + + Table of Contents..........................................2 + + 1. Introduction............................................3 + 2. Case Insensitivity of DNS Labels........................3 + 3. Additional DNS Case Insensitivity Considerations........4 + 3.1 CLASS Case Insensitivity Considerations................4 + 3.2 Label Type Case Insensitivity Considerations...........5 + 4. Case on Input and Output................................5 + 5. Security Considerations.................................6 + + Normative References.......................................7 + Informative References.....................................7 + + Author's Address...........................................8 + Expiration and File Name...................................8 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +D. Eastlake 3rd [Page 2] + + +INTERNET-DRAFT DNS Case Insensitivity + + +1. Introduction + + The Domain Name System (DNS) is the global hierarchical replicated + distributed database system for Internet addressing, mail proxy, and + other information. Each node in the DNS tree has a name consisting of + zero or more labels [STD 13][RFC 1591, 2606] which have always been + specified as being treated in a case insensitive fashion. This + document clarifies the meaning of "case insensitive" for this + application. + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [RFC 2119]. + + + +2. Case Insensitivity of DNS Labels + + DNS was specified in the era of [ASCII]. DNS names were expected to + look like most host names or Internet email address right halves (the + part after the at-sign ("@")) or be numeric as in the in-addr.arpa + part of the DNS name space. For example, + + foo.example.net. + aol.com. + www.gnu.ai.mit.edu. + or 69.2.0.192.in-addr.arpa. + + Case varied alternatives to the above would be DNS names like + + Foo.ExamplE.net. + AOL.COM. + WWW.gnu.AI.mit.EDU. + or 69.2.0.192.in-ADDR.ARPA. + + The individual bytes of which DNS names consist are not limited to + valid ASCII character codes. They are defined as 8-bit bytes and all + values are allowed. It is just that they are traditionally interpreted + as ASCII characters. + + The typographic convention for bytes that do not correspond to an + ASCII printing graphic is to show them as a back-slash followed by + three hex digits for the value of the byte as an unsigned + integer. This includes all byte values outside of the inclusive range + of 0x21 ("!") to 0x7E ("~"). That is to say, all byte values in the + two inclusive ranges 0x00 to 0x20 and 0x7F to 0xFF. The same + convention can be used for the back-slash character and the special + label separator period ("."). A period can also be protected from + recognition as a separator, so that it will be treated as a normal + label character, by preceeding it with a back-slash. The first example + + +D. Eastlake 3rd [Page 3] + + +INTERNET-DRAFT DNS Case Insensitivity + + + below shows embedded spaces and a period (".") within a label. The + second one show a 4 byte label where the second byte has all bits zero + and the third byte has all bits one. + + Donald\040E\.\040Eastlake\0403rd.example. + or a\000\377z.example. + + The design decision was made that comparisons on name lookup for DNS + queries should be case insensitive [STD 13]. That is to say, a lookup + string byte with a value in the inclusive range of 0x41 to 0x5A, the + upper case ASCII letters, MUST match the identical value and also + match the corresponding value in the inclusive range 0x61 to 0x7A, + the lower case ASCII letters. And a lookup string byte with a lower + case ASCII letter value MUST similarly match the identical value and + also match the corresponding value in the upper case ASCII letter + range. One way to implement this rule would be, when comparing bytes, + to subtract 0x20 from all bytes in the inclusive range 0x61 to 0x7A + before the comparison. Such an operation is commonly known as "case + folding". + + (Historic Note: the terms "upper case" and "lower case" were invented + after movable type became wide spread for printing. The terms + originally refered 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".) + + DNS labels in wire encoded names have a type associated with them. + The original DNS standard [RFC 1035] had only two types. ASCII + labels, with a length of from zero to 63 bytes and indirect labels + which consist of an offset pointer to a name location elsewhere in + the wire encoding. (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 above. 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. Additional DNS Case Insensitivity Considerations + + This section clarifies the effect of DNS CLASS and extended Label + Type on case insensitivity. + + + +3.1 CLASS Case Insensitivity Considerations + + As described in [STD 13] and [RFC 2929], DNS has an additional axis + for data location called CLASS. The only CLASS in global use at this + time is the "IN" or Internet CLASS. + + +D. Eastlake 3rd [Page 4] + + +INTERNET-DRAFT DNS Case Insensitivity + + + The handling of DNS label case is not CLASS dependent. + + + +3.2 Label Type Case Insensitivity Considerations + + DNS was extended by [RFC 2671] to have additional label type numbers + available. (The only such type defined so far it the BINARY type [RFC + 2673].) + + The ASCII case insensitivity conventions, or case folding, only apply + to ASCII labels, that is to say, label type 0x0, whether appearing + directly or invoked by indirect labels. + + + +4. Case on Input and Output + + While ASCII label comparisons are case insensitive, case MUST be + preserved on output, except when output is optimized by the use of + indirect labels, and preserved when possible on input. + + [STD 13] views the DNS namespace as a node tree. ASCII output is as + if a name was marshalled by taking the label on the node whose name + is to be output, converting it to a typographicly encoded ASCII + string, walking up the tree outputting each label encountered, and + preceeding all labels but the first with a period ("."). Wire output + follows the same sequence but each label is wire encoded and no + periods inserted. No "case conversion" or "case folding" is done + during such output operations. 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 is the "same" as the + remainder of the name being optimized, the case insensitive + comparison specified above is done. Thus such optimization MAY + destroy the output preservation of case. This type of optimization is + commonly called "name compression". + + Originally, DNS input came from an ASCII Master File as defined in + [STD 13]. DNS Dynamic update has been added as a source of DNS data + [RFC 2136, 3007]. When a node in the DNS name tree is created by such + input, no case conversion is done and the case of ASCII labels is + preserved if they are for nodes being creted. However, no change is + made in the name label on nodes that already exist is the DNS data + being augmented or updated. It is quite common for higher level nodes + to already exist. For example, if data with owner name + "foo.bar.example" is input and then later data with owner name + "xyz.BAR.example" is input, the name of the label on the + "bar.example" node, i.e. "bar", is not changed to "BAR". Thus later + retrieval of data stored under "xyz.bar.example" in this case can + easily result is obtaining data with "xyz.BAR.example". + + +D. Eastlake 3rd [Page 5] + + +INTERNET-DRAFT DNS Case Insensitivity + + + 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 + unpredicatable output capitalization. + + There is one additional instance of note, which relfects the general + rules that output case reflects input case unless there is + conflicting capitalization in the DNS database or the output case is + hidden by name compression. This is when a query matches a wild card + in the DNS database at a server. In that case, the answer SHOULD + reflect the input case of the label or labels that matched the + wildcard unless they are replaced by an indirect label which MAY + point to a name with different captialization. + + + +5. Security Considerations + + The equivalence of certain DNS label types with case differences, as + clarified in this document, can lead to security problems. For + example, a user could be confused by believing two domain names + differing only in case were actually different names. + + Furthermore, a domain name may be used in contexts other than the + DNS. It could be used as an index into some case sensitive data base + system. Or it could be interpreted as binary data by some integrity + or authentication code system. These problems can usually be handled + by using a standardized or "canonical" form of the DNS ASCII type + labels, that is, always map the ASCII letter value octets in ASCII + labels to some specific pre-chosen case, either upper case or lower + case. An example of a canonical form for domain names (and also a + canonical ordering for them) appears in Section 8 of [RFC 2535]. See + also [UNKRR]. + + + + + + + + + + + + + + + + + + + +D. Eastlake 3rd [Page 6] + + +INTERNET-DRAFT DNS Case Insensitivity + + +Normative References + + [ASCII] - ANSI, "USA Standard Code for Information Interchange", + X3.4, American National Standards Institute: New York, 1968. + + [RFC 1034, 1035] - See [STD 13]. + + [RFC 2119] - "Key words for use in RFCs to Indicate Requirement + Levels", S. Bradner, March 1997. + + [RFC 2136] - P. Vixie, Ed., S. Thomson, Y. Rekhter, J. Bound, + "Dynamic Updates in the Domain Name System (DNS UPDATE)", April 1997. + + [RFC 2535] - D. Eastlake, "Domain Name System Security Extensions", + March 1999. + + [RFC 3007] - B. Wellington, "Secure Domain Name System (DNS) Dynamic + Update", November 2000. + + [STD 13] + - P. Mockapetris, "Domain names - concepts and facilities", RFC + 1034, November 1987. + - P. Mockapetris, "Domain names - implementation and + specification", RFC 1035, November 1987. + + [UNKRR] - Andreas Gustafsson, "Handling of Unknown DNS RR Types", + draft-ietf-dnsext-unknown-rrs-04.txt, September 2002. + + + +Informative References + + [RFC 1591] - J. Postel, "Domain Name System Structure and + Delegation", March 1994. + + [RFC 2606] - D. Eastlake, A. Panitz, "Reserved Top Level DNS Names", + June 1999. + + [RFC 2929] - D. Eastlake, E. Brunner-Williams, B. Manning, "Domain + Name System (DNS) IANA Considerations", September 2000. + + [RFC 2671] - P. Vixie, "Extension mechanisms for DNS (EDNS0)", August + 1999. + + [RFC 2673] - M. Crawford, "Binary Labels in the Domain Name System", + August 1999. + + + + + + +D. Eastlake 3rd [Page 7] + + +INTERNET-DRAFT DNS Case Insensitivity + + +Author's Address + + Donald E. Eastlake 3rd + Motorola Laboratories + 155 Beaver Street + Milford, MA 01757 USA + + Telephone: +1 508-851-8280 (w) + +1 508-634-2066 (h) + EMail: Donald.Eastlake@motorola.com + + + + +Expiration and File Name + + This draft expires July 2003. + + Its file name is draft-ietf-dnsext-insensitive-00.txt. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +D. Eastlake 3rd [Page 8] +