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

bind-3.2.

       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:[e-mail]) 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" <U+4e2d> 
   <U+6587>.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 
   [e-mail] 
    
   David Leung 
   Neteka Inc. 
   2462 Yonge St. Toronto, 
   Ontario, Canada M4P 2H5 
   [e-mail] 
    






































  
Chung & Leung                                                 [Page 11]