draft-ietf-idn-dnsii-trace-00.txt

bind-3.2.

Working Group                                 Edmon Chung & David Leung
Internet Draft                                              Neteka Inc.
<draft-ietf-idn-dnsii-trace-00.txt>                      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 "耨駞" <U+4e2d><U+6587> 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" <U+4e2d><U+6587>.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 <U+4e2d><U+6587>.<U+4e2d> 
   <U+6587>.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 
       <U+4e2d><U+6587>.<U+4e2d><U+6587>.tld using an ISO10646 encoding 
       input. 
    
   (2) The DNS recursive resolver arrives at the parent domain "耨
       駞.tld" <U+4e2d><U+6587>.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,