Working Group Edmon Chung & David Leung Internet Draft Neteka Inc. September 2000 DNSII Transitional Reflexive ASCII Compatible Encoding (TRACE) 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. Abstract ASCII Compatible Encoding (ACE) schemes should only be used as a transitional strategy with a well-defined way forward to the eventual enabling of a truly multilingual name space for the DNS. The previous DNSII documents surrounding multilingual domain names have focused on the ultimate form with the DNSII-MDNR suggesting possible tunneling techniques where ACE may be used. This document furthers the discussion on an ACE system, which not only provides a pathway towards the ultimate DNSII scheme but also an interim solution taking care of the immediate needs. A reflexive CNAME process RENAME is introduced where non-ASCII incoming queries will be automatically CNAMEd to its ASCII counterpart without requiring an actual lookup. The resolver will then be responsible for recursively looking up the corresponding translated alphanumeric name. This document does not attempt to create another ACE scheme, instead it discusses the way an ACE scheme could be used as a transition towards the ultimate goal of a true multilingual name on the wire. Chung & Leung [Page 1] DNSII-TRACE DNSII Transitional Reflexive ACE (TRACE) August 2000 Table of Contents 1. Introduction....................................................2 1.1 Terminology....................................................2 2. TRACE - Introduced with Due Obsolescence........................3 2.1 Problems & Benefits of ACE.....................................3 2.2 TRACE Format...................................................3 2.3 TRACE Identifier...............................................3 2.4 TRACE Zone Handling............................................4 3. REflexive CNAME (RENAME)........................................4 3.1 Non-Recursive Name Servers with RENAME-ON......................5 3.1 Recursive Name Servers (Resolvers) with RENAME-ON..............6 3.2 Benefits of RENAME.............................................6 3.3 Problems with RENAME...........................................7 4. Use of RENAME with Respect to DNS Hierarchy.....................7 4.1 General Rules for using RENAME.................................8 4.2 Transitioning towards Identification Based DNSII...............8 5. Security Considerations.........................................9 6. Conclusion......................................................9 7. Intellectual Property Considerations...........................10 8. References.....................................................10 1. Introduction ACE usage should be limited to machine read only and steps should be taken to avoid the user being able to easily input the names through an application onto the wire. This is a well-understood concept because without this requirement, the creation of an ACE system effectively creates an alternate universe model that is counter to the spirit of the DNS. In essence, if an ACE scheme could easily be typed in, people who are typing that sequence of characters may be unexpectedly be brought to another site which happens to have the same "code". TRACE outlines a scheme that uses an ACE scheme but is identified in a 7-bit format that could not easily be typed in by a user. Thereby preventing an inconsistent expectation of a domain name. Beyond the specification of an identifier a RENAME function for an ACE resolution process is also introduced. 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 characters used in this document are in a Big-5 encoding, you could select your view encoding type to traditional Chinese or Big-5 for it to be displayed properly. Chung & Leung [Page 2] DNSII-TRACE DNSII Transitional Reflexive ACE (TRACE) August 2000 2. TRACE - Introduced with Due Obsolescence TRACE is designed to be a transitional scheme with due obsolescence once a full-fledged DNSII mode is attained. 2.1 Problems & Benefits of ACE One of the major problems with ACE is the evident result of creating an extra layer on top of the DNS. DNS was designed to be the human friendly machine identifier with its names human readable. With ACE, it is certain that an added layer is required to decode a domain name. This also effectively results in a quasi-alternate universe mode whereby the actual characters represent a translation into the existing domain name space. However, ACE has its benefits as well and the most prominent one is that host servers need not migrate to new name servers. Also it will ensure that there is a lengthy enough migration period for other applications to start adapting to the new DNS specifications. 2.2 TRACE Format TRACE does not intend to introduce a new type of encoding. Rather, it is concerned with using a 7-bit compatible identifier and a reflexive mechanism for switching from regular DNS packets to TRACE. 2.3 TRACE Identifier In other ACE proposals, identifiers are often created from alphanumeric characters, which end users can easily type in. The problem with this approach is easy to understand, for each multilingual name, one alphanumeric name must be reserved simply for the use of the multilingual conversion and will not be available for normal usage. For example from Paul Hoffman's draft [RACE-01], the sample conversion for a value 0x3a27 would result in a string "bq--hitq". The name "bq--hitq" which is a perfectly usable name on its own must now be reserved for a multilingual name. Also, 4 character spaces will be wasted just for the identifier. Instead of using an alphanumeric identifier, a single 7-bit compliant control character is used. The proposed character is the control character with the value 0x7F. With this character, a multilingual name part could be effectively identified while it would be very difficult for the average user to enter the character into an application, thereby avoiding the issue discussed above. In any case, an ACE form name is not intended for an end user to type in. The only reason for ACE is that the current name servers could Chung & Leung [Page 3] DNSII-TRACE DNSII Transitional Reflexive ACE (TRACE) August 2000 easily handle them. TRACE provides a simple and effective way which is 7-bit compliant and a string that is could not be easily imitated. 2.4 TRACE Zone Handling A zone administrator could also easily enter the TRACE Identifier into the zone file. To insert the TRACE Identifier in a BIND server, the administrator could simply append the string "\127" before the ACE label. Current BIND servers will understand that "\127" calls for the character with the value 127 and therefore load it into memory accordingly. The BIND should also be reconfigured to set the options for "check-names" to "ignore". In the following examples, the ACE format used is simply the hex value of the corresponding character encoding. RACE or other ACE formats or hex of other encoding schemes may be used. To set up an NS record to ns1.trace.tld and an A record to 123.4.5.6 for the name "ρρρ…" in a BIND server, using UTF-8 (E4B8AD E69687) the following lines are included into the zone file: \127e4b8ade69687 IN NS ns1.trace.tld. \127e4b8ade69687 IN A 123.4.5.6 Section 4.3 will discuss a method to prepare the zone file for the transition into a fully DNSII compliant mode. 3. REflexive CNAME (RENAME) To complement an ACE transition, a reflexive mechanism is introduced. REflexive CNAME (RENAME) successfully creates a scheme whereby child DNS nodes could keep using their BIND name servers while be capable of hosting multilingual domain names. RENAME is simply a mechanism that attaches an incoming multilingual name to its ACE counterpart as it enters a RENAME-ON name server. When to use RENAME is discussed in Section 4. As an example, if an incoming query contains a the domain name "ρρ ρ….tld" .tld in UTF-8 encoding reaches a RENAME-ON name server, the following automatic response will be created: ρρρ….tld IN CNAME \127e4b8ade69687.tld If the server is in non-recursive mode, the RENAMEd name will now be used for a lookup within the zone and the corresponding response returned to the inquirer, including the CNAME process. If the server is in recursive mode, the RENAMEd name will be used for lookup within cache and passed on through the DNS hierarchy when not found. Chung & Leung [Page 4] DNSII-TRACE DNSII Transitional Reflexive ACE (TRACE) August 2000 3.1 Non-Recursive Name Servers with RENAME-ON The two basic modes for a name server includes a non-recursive mode, which are usually used by registries, root or authoritative host servers; and a recursive mode, which are usually resolvers installed in ISPs. A non-recursive mode server with RENAME-ON would upon receiving a multilingual name label, automatically CNAME the name to an ACE format. If a complete match is found, the response will be passed back to the inquirer including the CNAME record. If no direct match is found, it will pass along either an authoritative NXDomain or the nearest NS Record in ACE format so that the inquirer may continue its recursive request. The following diagram and descriptions details the resolution process for the domain "www.ρρρ….ρρρ….tld" or . .tld, with a DNSII TRACE RENAME-ON server installed at the Parent domain "ρρρ….tld" and a BIND server installed at the Child DNS domain "ρρρ….ρρρ….tld": (3) +--------+ +------------+ +---------------+ | | (1) | | (2) | | | Client |-------->| Resolver |-------->| Parent Domain | ρρρ….tld | |<--------| |<--------| (RENAME-ON) | | | (8) | | (4) | | +--------+ +------------+ +---------------+ ^ | | | (6) | | (5) +--------------+ | +-------->| | +-----------| Child Domain | ρρρ….ρρρ….tld (7) | (using BIND) | | | +--------------+ (1) A user enters a query for the A record of "www.ρρρ….ρρρ….tld" or ..tld using an ISO10646 encoding input. (2) The DNS recursive resolver arrives at the parent domain "ρρ ρ….tld" .tld (3) With RENAME-ON and detection that the incoming query is non-ASCII, the server reflexively assigns the CNAME to the domain: www.ρρρ….ρρρ….tld. IN CNAME www.\127e4b8ade69687. \127e4b8ade69687.tld. Chung & Leung [Page 5] DNSII-TRACE DNSII Transitional Reflexive ACE (TRACE) August 2000 (4) Since a direct match is not found in the Parent DNS, the closest NS record is returned to the Resolver, with the CNAME part included: www.ρρρ….ρρρ….tld. IN CNAME www.\127e4b8ade69687. \127e4b8ade69687.tld. \127e4b8ade69687.\127e4b8ade69687.tld. IN NS ns1.\127e4b8ade69687.\127e4b8ade69687.tld. ns1.\127e4b8ade69687.\127e4b8ade69687.tld. IN A 123.5.6.7 (5) The recursive resolver passes on the request using the CNAME record to the Child DNS as: www.\127e4b8ade69687.\127e4b8ade69687.tld. Asking for an A record for the corresponding domain. (6) The Child DNS simply does a regular look up for the domain with the corresponding response. (7) Assuming that the correct IP address for www.ρρρ….ρρρ….tld is 123.6.7.8, the response would be: www.\127e4b8ade69687.\127e4b8ade69687.tld. IN A 123.6.7.8 (8) The resolver will then respond to the client request accordingly, including the CNAME record. 3.1 Recursive Name Servers (Resolvers) with RENAME-ON If the recursive resolver is DNSII compatible and have switched the RENAME-ON, then both the parent and child DNSs could still run BIND and be able to serve multilingual names. As the request goes through the resolver, it is automatically CNAMEd to the corresponding ACE format name and passed along for further resolution. When the corresponding response is obtained, the definite answer including the CNAME record will both be passed to the client. 3.2 Benefits of RENAME The immediate benefit for using RENAME is that once it is deployed at a particular DNS level, all its child, or sub-level DNSs could continue to run a BIND-based or current name server while still be capable of serving multilingual domain names. Most ACE implementations expect the client application to begin migration first. This is unfortunately would take a long time because we understand that client end migration may take years to Chung & Leung [Page 6] DNSII-TRACE DNSII Transitional Reflexive ACE (TRACE) August 2000 complete. With RENAME however, the migration could be dynamic. Section 4 explains further how and when RENAME should be used to complement and facilitate the resolution of multilingual names even when some of the components are not fully multilingual aware. 3.3 Problems with RENAME RENAME effectively creates an ACE based name space which is ultimately undesired. Also, wherever the RENAME function is located, it will intensify the processing requirements for the machine to handle the conversion of the incoming multilingual label into an ACE format and package the CNAME record accordingly. 4. Use of RENAME with Respect to DNS Hierarchy For the discussion within this document, the DNS hierarchy is summarized into four nodes, beginning with the client end application, through the resolver, to the root or NIC servers then finally at the authoritative host for a second-level domain. This more or less summarizes the DNS process from the initiation of a request to the authoritative host. All together, there are 16 combinations with the basic DNS environments. The following chart outlines the different combinations with the denotations as: B = B-DNS = Current Bind-based DNS D = DNSII = DNSII Compliant Name Servers RENAME(X-X-X-X) = RENAME(Client/application-Resolver-Root/NIC-Host) with X = ON = RENAME-ON FF = RENAME-OFF OP = Optional ON/OFF NA = Not Applicable Scenario | Client |Resolver|Root/NIC| Host | RENAME(ON/OFF) ---------+--------+--------+--------+--------+--------------------- 1) BBBB | B-DNS | B-DNS | B-DNS | B-DNS | existing system +--------+--------+--------+--------+ 2) BBBD | B-DNS | B DNS | B-DNS | DNSII | RENAME(NA-NA-NA-FF) +--------+--------+--------+--------+ 3) BBDB | B-DNS | B DNS | DNSII | B-DNS | RENAME(NA-NA-ON-NA) +--------+--------+--------+--------+ 4) BDBB | B-DNS | DNSII | B DNS | B-DNS | RENAME(NA-ON-NA-NA) +--------+--------+--------+--------+ 5) DBBB | DNSII | B-DNS | B-DNS | B-DNS | RENAME(ON-NA-NA-NA) +--------+--------+--------+--------+ 6) BBDD | B-DNS | B-DNS | DNSII | DNSII | RENAME(NA-NA-FF-FF) +--------+--------+--------+--------+ 7) DNND | B-DNS | DNSII | DNSII | B-DNS | RENAME(NA-OP-ON-NA) +--------+--------+--------+--------+ Chung & Leung [Page 7] DNSII-TRACE DNSII Transitional Reflexive ACE (TRACE) August 2000 Scenario | Client |Resolver|Root/NIC| Host | RENAME(ON/OFF) ---------+--------+--------+--------+--------+--------------------- 8) DDBB | DNSII | DNSII | B-DNS | B-DNS | RENAME(OP-ON-NA-NA) +--------+--------+--------+--------+ 9) DBBD | DNSII | B-DNS | B-DNS | DNSII | RENAME(ON-NA-NA-FF) +--------+--------+--------+--------+ 10) BDBD | B-DNS | DNSII | B-DNS | DNSII | RENAME(NA-ON-NA-FF) +--------+--------+--------+--------+ 11) DBDB | DNSII | B-DNS | DNSII | B-DNS | RENAME(ON-NA-OP-NA) +--------+--------+--------+--------+ 12) BDDD | B-DNS | DNSII | DNSII | DNSII | RENAME(NA-FF-FF-FF) +--------+--------+--------+--------+ 13) DDDB | DNSII | DNSII | DNSII | B-DNS | RENAME(OP-OP-ON-NA) +--------+--------+--------+--------+ 14) DDBD | DNSII | DNSII | B-DNS | DNSII | RENAME(OP-ON-NA-FF) +--------+--------+--------+--------+ 15) DBDD | DNSII | B-DNS | DNSII | DNSII | RENAME(ON-NA-FF-FF) +--------+--------+--------+--------+ 16) DDDD | DNSII | DNSII | DNSII | DNSII | Full DNSII mode +--------+--------+--------+--------+ 4.1 General Rules for using RENAME As a general rule, RENAME should be turned on whenever there is an anticipation that further down the DNS hierarchy or resolution process, a host has not been migrated and is still using existing name server software. For example, Scenario(3),(4) or (5) and their equivalents. If it is known that the entire set of child hosts is DNSII compliant, then RENAME is optional even if there exists child sub-sub-domain host beneath the sub-domain level that uses existing name servers. For example, Scenario(7) and the sample given in Section 3. The end host without any more child sub-domains SHOULD never turn on RENAME. This consideration is given to reduce the amount of transition traffic created due to the reflexive answer where no further resolution is required. 4.2 Transitioning towards Identification Based DNSII Following the DNSII-MDNP recommendations, TRACE could smooth the transition into a multilingual name space by starting at the registry level and without requiring the host DNSs to migrate. As the user-end applications or recursive ISP resolvers began the migration, new multilingual TLDs could also be introduced even before the root servers begin any migration. Eventually, when the root servers migrate, they should be enabled with both the full DNSII capability with the InPacket Identifier, Chung & Leung [Page 8] DNSII-TRACE DNSII Transitional Reflexive ACE (TRACE) August 2000 ILET as well as TRACE as a fallback should there be any host DNS still using existing servers. From the general rules, we understand that if the entire child DNSs are DNSII enabled, then the RENAME function of the parent DNS could be turned off. This therefore makes way for a very sensible migration strategy owing to the hierarchical structure of the DNS. Since a parent DNS must know a glue record for its immediate children, it is easy for the zone administrator to determine whether it could turn off the RENAME function for its zone. While it is understood that gradually, all name servers should migrate to be DNSII capable and that multilingual names, TRACE creates a very effective way of monitoring the migration by encouraging child DNSs to begin transition first followed by upper and more important levels, up to the root. A fully DNSII aware server should also be prepared for DNSII queries. That is, it should be able to process requests containing the DNSII Identifier and ILET. As a working example, a Neteka Enhanced BIND (for a demo copy please mailto:netekare@neteka.com) has been developed as a demonstration. To enter a full DNSII label, in the product, simply duplicate the TRACE identifier and insert a corresponding ILET. As an example, for "ρρρ….tld" .tld with ILET = 1000 = Unicode, an A record for the IP address 123.4.5.6 could be added to the zone file as: \127\12710004e2d6587.tld. IN A 123.4.5.6 In such an environment, DNSII aware queries will be answered accordingly utilizing the "\127\127" record. 5. Security Considerations The implementation of TRACE constitutes no further security burden on the DNS. DNSSEC could be used in parallel with TRACE resolution and records. RENAME records will be secured through transaction authentication, while authoritative records will have their own SIG RRs. Moreover, the TRACE identifier actually increases the security for multilingual names over other ACE implementations by using the 0x7F character, which is difficult for an end user to key in, thereby reducing the possible confusions. 6. Conclusion With any implementation, the first step towards universal deployment of a multilingual aware name space should be an 8-bit clean approach. For current BIND servers it is a simple configuration matter, which could be set as an option for checknames to be ignored. Chung & Leung [Page 9] DNSII-TRACE DNSII Transitional Reflexive ACE (TRACE) August 2000 With TRACE, the migration from the current system could be dynamic. While it is encouraged that the registries begin the migration first because it is most sensible, client end or recursive resolvers could also begin the migration. The use of the control character 0x7F also solves two problems at once: 1) a 7-bit identifier to avoid disruption of other applications using DNS; and, 2) an identifier that is not easily input by a client end user to prevent confusion between a multilingual name and an English alphanumeric only name. RENAME successfully creates an environment where host level DNSs could hold on to their existing BIND based name servers while being able to host multilingual domains, thereby relieving the migration stress for hosting facilities and ISPs. 7. Intellectual Property Considerations It is the intention of Neteka to submit the DNSII protocol and other elements of the multilingual domain name server software to IETF for review, comment or standardization. Neteka Inc. has applied for one or more patents on the technology related to multilingual domain name server software and multilingual email server software suite. If a standard is adopted by IETF and any patents are issued to Neteka with claims that are necessary for practicing the standard, any party will be able to obtain the right to implement, use and distribute the technology or works when implementing, using or distributing technology based upon the specific specifications under fair, reasonable and non-discriminatory terms. 8. References [DNSII-MDNP] E. Chung & D. Leung "DNSII Multilingual Domain Name Protocol", August 2000 [RACE] P. Hoffman "RACE: Row-based ASCII Compatible Encoding for IDN", August 31, 2000 [RFC1700] J. Reynolds, J. Postel, "ASSIGNED NUMBERS", RFC 1700, October 1994. [ISO10646] ISO/IEC 10646-1:2000. International Standard -- Information technology -- Universal Multiple-Octet Coded Character Set (UCS) [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels," RFC 2119, March 1997 Chung & Leung [Page 10] DNSII-TRACE DNSII Transitional Reflexive ACE (TRACE) August 2000 Authors: Edmon Chung Neteka Inc. 2462 Yonge St. Toronto, Ontario, Canada M4P 2H5 edmon@neteka.com David Leung Neteka Inc. 2462 Yonge St. Toronto, Ontario, Canada M4P 2H5 david@neteka.com Chung & Leung [Page 11]