IDN Working Group Edmon Chung & David Leung Internet Draft Neteka Inc. February 2001 The DNSII Multilingual Domain Name Protocol STATUS OF THIS MEMO This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The reader is cautioned not to depend on the values that appear in examples to be current or complete, since their purpose is primarily educational. Distribution of this memo is unlimited. 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. A copy of this particular draft is also archived at http://www.dnsii.org. Abstract The core thinking for DNSII is that multilingual DNS requests SHOULD be signaled within a DNS label whether by way of a binary tag or an alphanumeric prefix, and that compatibility to legacy client applications SHOULD be taken into concern alongside legacy server implementations. Besides the original specifications, four alternatives including the use of EDNS are included for discussion purposes in this document. Historically, the DNS is capable of handling only names within the basic English alphanumeric character set (plus the hyphen), yet the standards were so elegantly and openly designed that the extension of the DNS into a multilingual and symbols based system proves to be possible with simple adjustments. These adjustments will be made on both the client side and the server side. However, DNSII works on the principal that it is preferable to make the transition to multilingual domain names seamless and DNSII-MDNP Multilingual Domain Name Protocol August 2000 transparent to the end-user. Which means initially the server SHOULD take the primary responsibility for the technical implementation of the changes required for a multilingual Internet. The DNSII protocol is designed to allow the preservation of interoperability, consistency and simplicity of the original DNS, while being expandable and flexible for the handling of any character or symbol used for the naming of an Internet domain. DNSII intends to provide a platform for the implementation of multilingual domain names. Table Of Contents 1. Introduction....................................................2 1.1 Terminology....................................................2 1.2 DNSII..........................................................3 2. DNSII Protocol..................................................3 2.1 InPacket DNSII Identifier......................................3 2.2 InPacket Label Encoding Type (ILET)............................4 2.3 The Rationale for using ILET...................................5 2.4 Considerations for Specific Requests...........................6 2.4.1 PTR Records..................................................6 3. Alternate Implementations.......................................7 3.1 Restricted ILET Values.........................................7 3.2 Reduced ILET Bit Allocation....................................8 3.3 DNSII over EDNS................................................9 3.3.1 DNSII Identifier using EDNS..................................9 3.3.2 ILET using EDNS OPT RRs.....................................10 4. Implementation & Deployment Strategies.........................11 5. IDN Requirements Considerations................................12 6. DNSSEC, EDNS and IPv6 Considerations...........................12 7. Intellectual Property Considerations...........................13 8. References.....................................................13 1. Introduction This Internet-draft describes details of the DNSII Multilingual Domain Name protocol. The Internet-Draft assumes that the reader is familiar with the concepts discussed in the widely distributed RFCs "Domain Names Concepts and Facilities" [RFC 1034] and "Domain Names Implementation and Specification" [RFC 1035]. 1.1 Terminology The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED", and "MAY" in this document are to be interpreted as described in RFC 2119 [RFC2119]. A number of multilingual characters are used in this document for examples. Please select your view encoding type to UTF-8 for it to be displayed properly. DNSII-MDNP Multilingual Domain Name Protocol August 2000 1.2 DNSII The DNSII specifications takes a radically different approach: it successfully identifies the difference between original DNS and DNSII packets within the labels and at the same time allows the use of multiple charsets to be easily incorporated in a standardized manner. It causes no harm to the current DNS because it embraces the original format for DNS laid out in RFC1035, complemented with the ideas incorporated in EDNS [RFC2671]. 2. DNSII Protocol The DNSII Protocol consists mainly of two parts: the InPacket DNSII Identifier and the InPacket Label Encoding Type. In addition, there are several special considerations for specific record types. 2.1 InPacket DNSII Identifier In the DNSII specifications, an InPacket DNSII Identifier MUST be inserted before a label to signify that it contains extended characters that are not supported by the current DNS. This DNSII flag, which is the first two bits of a label, effectively distinguishes a DNSII compliant request from the existing format, without having to conduct a guess from a name check whether the incoming packet is multilingual aware. This is a substantial improvement over character encoding schemes and multilingual implementations in which it is almost impossible to determine the language of an incoming request. The DNSII flag makes the process clear and simple. Currently: "00" regular label [RFC1035] "11" a redirection for DNS compression [RFC1035] "01" indicates the use of EDNS for multiple UDP packets [RFC2671] DNSII calls for the use of the bit sequence "10" to identify that the querying node is DNSII aware. This will mean that all the possible variations at top two label bits will be used. Therefore, in consideration, following two bits MUST be reserved for future flagging use. The 2 bits SHOULD be arbitrarily set to "00". This effectively opens up 3 more possible implementations for future enhancements. The motivation for this approach is the belief there should be no ambiguity in name resolution. Any name that the client wishes to resolve, should resolve, regardless of the client side-encoding scheme. DNSII-MDNP Multilingual Domain Name Protocol August 2000 2.2 InPacket Label Encoding Type (ILET) Immediately following the 2 assigned DNSII flag and the 2 reserved bits are 12 bits assigned to determine the InPacket Label Encoding Type (ILET). The ILET is a 12-bit number that is used to determine the encoding scheme used by the characters of the label. The MIBenum numbers [RFC1700] SHOULD be used in this field. The allocation of 12 bits aligns perfectly with the MIBenum specification, of which the value goes up to over 2200. With 12 bits, the total possible values would be 4096 (with 11 bits, the largest value that can be represented is only 2047, slightly short of the specification). The reason for the adoption of MIBenum is to make use of the existing list of encoding numbering schemes rather than re-inventing the wheel. The value in the ILET field SHOULD only be allowed for the valid encoding schemes defined in the MIBenum list. After identifying the encoding type, the regular count-label scheme of the DNS resumes. The resulting label should look like this: 1 1 1 1 1 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +---+---+-------+---------------+ |1 0| z | ILET | +---------------+---------------+ | COUNT | characters... | +---------------+---------------+ To minimize the size of a DNS packet, if the entire label is constituted in characters only from the ANSI table, the DNS label will appear identical to current implementations. The first two bits will remain "00". For example, using the DNSII format the label for "dns" MAY be represented as: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | 1 0| 0 0| 0 0 0 0 0 0 0 0 0 0 1 1| MIBenum 3 = ANSI +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | 3 | 6 4 | "d"=64 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | 6 E | 7 3 | "n"=6E "s"=73 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ Or, the same domain label "dns" MAY also be represented as: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | 3 | d | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | n | s | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ Chung & Leung [Page 4] DNSII-MDNP Multilingual Domain Name Protocol August 2000 With a multilingual domain name ns.厲枀伸圑﹪礃.tld as an example: 1 1 1 1 1 1 1 1 1 1 1 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +---------------------------------------------------------------+ |1 0| z | ANSI=3 | 2 | n | +---------------------------------------------------------------+ | s |1 0|0 0| UCS-2=1000 | 4 | +---------------------------------------------------------------+ | 厲
