
IDN Working Group                             Edmon Chung & David Leung
Internet Draft                                              Neteka Inc.
<draft-ietf-idn-dnsii-mdnr-01.txt>                        February 2001
 
 
                                     
               DNSII Multilingual Domain Name Resolution 
 
 
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 
    
   This document outlines a resolution process that forms a framework 
   for the resolution of multilingual domain names.  Additionally, a 
   tunneling mechanism utilizing additional RRs is introduced for the 
   transition to a fully multilingual capable name space. 
    
   The Internet-Draft for DNSII-MDNP was focused purely on discussing 
   the ultimate packet protocol that is being sent around the Internet 
   for multilingual domain names.  This paper complements the previous 
   paper by outlining the contemplated resolution process with the DNSII 
   protocol throughout the DNS name resolution process. 
    
   Whether the DNSII protocol is implemented exactly as specified in 
   DNSII-MDNP is less relevant, rather it is the idea of having a 
   multilingual packet identifier and the fall back process that 
   matters.  The DNSII-MDNR successfully addresses the transitional 
   issues at each node of the DNS resolution process providing a clear 
   migration path and strategy for the deployment of a multilingual 
  
DNSII-MDNR       Multilingual Domain Name Resolution        August 2000  
 
   enabled DNS system.  It also outlines the conformance levels required 
   for basic or complete implementations for applications, resolvers and 
   name servers. 
    
    
Table of Contents 
    
   1. Introduction....................................................2 
   1.1 Terminology....................................................2 
   1.2 Multilingual Domain Name Resolution............................3 
   1.2 DNSII-MDNR.....................................................3 
   2. DNSII Proposal with respect to the DNS Layers...................3 
   3. The Resolution Process..........................................5 
   3.1 Steady State Resolution........................................5 
   3.2 Client-End or Inquirer Transitional Fall-Back Strategy.........6 
   3.2.1 Tunneling MDNP through DNSII RR..............................6 
   3.2.2 Tunneling ILET RRs...........................................8 
   3.3 Resolvers & Server-End Transitional Fallback Strategy..........9 
   3.3.1 Tunneling MDNP Responses through DNSII ANS RR................9 
   3.3.2 Reinsertion of ILET and DNSII Identifier....................10 
   4. DNSII Conformance Levels.......................................10 
   4.1 Application Conformance Levels................................11 
   4.2 Resolver Conformance Levels...................................11 
   4.3 Authoritative Server Conformance Levels.......................11 
   5. Transition Schedule & Strategy.................................12 
   6. Summary of Discussion..........................................12 
   6.1 Client/Application Resolution Strategy........................13 
   6.2 Resolver Resolution Strategy..................................13 
   6.3 Authoritative Name Server Resolution Strategy.................13 
   7. Security Considerations........................................14 
   8. Intellectual Property Considerations...........................14 
   9. References.....................................................14 
    
    
1. Introduction 
    
   This Internet-Draft describes details of the contemplated resolution 
   process after the deployment of DNSII-MDNP, or other multilingual 
   domain name efforts containing a bit flag multilingual packet 
   identifier or otherwise InPacket identifications for that matter. 
    
   The reader is assumed to be familiar with the concepts discussed in 
   the DNSII-MDNP Internet-Draft <draft-ietf-idn-dnsii-mdnp.txt>. 
    
    
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]. 
    


  
DNSII-MDNR       Multilingual Domain Name Resolution        August 2000  
 
   A number of multilingual characters are used in this document for 
   examples.  Please select your view encoding type to Big-5 
   (Traditional Chinese) for them to be displayed properly. 
    
    
    
    
1.2 Multilingual Domain Name Resolution 
    
   The original specifications for the DNS were designed to be open 
   enough for simple implementation of a multilingual naming system with 
   slight adjustments as laid out in DNSII-MDNP.  The transition and 
   especially its resolution process during migration is however a 
   tricky problem.  Several things that MUST be kept in mind is that 
   there is a initial phase, an intermediate phase and an ultimate 
   steady state phase.  DNSII-MDNP only described the ideal protocol at 
   steady state, with incorporated flexibility for transition from the 
   present to multilingual as well as again towards future unknown 
   grounds. 
    
   It is important to remember that the ultimate form SHOULD be 
   determined and then the transition scheme laid out.  While an ASCII 
   translation system might seem favorable in the short-run, it 
   effectively creates an alternative universe which is counter to the 
   spirit of the DNS.  However an ASCII translation is implemented, it 
   immediately creates a "human-multilingual" universe and a "machine-
   ASCII" universe.  This document introduces a tunneling mechanism to 
   transition the DNS from today's monolingual system, through an 8-bit 
   or 7-bit migration scheme towards a truly sustainable multilingual 
   name space, arriving at a DNSII type system. 
     
    
1.2 DNSII-MDNR 
    
   While DNSII-MDNP describes the framework for the ultimate protocol 
   format of a multilingual DNS, DNSII-MDNR will discuss how the packet 
   SHOULD be transported and interpreted throughout the DNS.  The 
   document will describe both the intended resolution process as well 
   as part of the transition strategy from the existing DNS to a DNSII 
   enabled system. 
    
    
2. DNSII Proposal with respect to the DNS Layers 
    
   The following diagram illustrates the use of DNSII-MDNP at a steady 
   state.  Section 3 will discuss the fallback strategies while Section 
   4 will talk about issues on conformance levels. 
    





  
DNSII-MDNR       Multilingual Domain Name Resolution        August 2000  
 
   +---------------+ 
   |               | NamePrep: 
   |  Application  | Canonicalize in Form C/KC 
   |               | Insert DNSII Identifier    +---------------------+ 
   |               | Insert appropriate ILET    |    (Base data)      | 
   +---------------+                            +---------------------+ 
           |                                            | 
           |  DNS Packet with DNSII                     | (no standard) 
           |  Identifier & ILET                         |  RECOMMENDS 
           |                                            |  UCS-2/4 
   +---------------+                                    | 
   |   Resolver    | Canonicalize, Case Fold    +---------------------+ 
   |               | (for cache lookup) or      | Auth DNS server     | 
   +---------------+ leave as is & Resolve      | (Canonicalize,      | 
           |                                    | Case Fold & Lookup) | 
           |  Pass Along without                +---------------------+ 
           |  Altering Case or Canonicalization         | 
           |                                            | 
           |   <-----   DNS service interface  ----->   | 
   +------------------------------------------------------------------+ 
   |  DNS service                                                     | 
   |  +-----------------------+         +--------------------+        | 
   |  | Forwarding DNS server |         | Caching DNS server |        | 
   |  +-----------------------+         +--------------------+        | 
   |                                                                  | 
   |                 +-------------------------+                      | 
   |                 | Parent-zone DNS servers |                      | 
   |                 +-------------------------+                      | 
   |                                                                  | 
   |                 +-------------------------+                      | 
   |                 | Root DNS servers        |                      | 
   |                 +-------------------------+                      | 
   |                                                                  | 
   +------------------------------------------------------------------+ 
    
   Please note that at each level, the domain name is being 
   canonicalized.  This is to ensure that at the end, characters that 
   can be represented by a single code point will not be otherwise 
   compared resulting in inconsistent reply to a humanly identical name.  
   It is RECOMMENDED that applications SHOULD conduct canonicalization 
   while servers MUST.  Duplicating the process is fine because if a 
   character is already composed, it will not compose again with another 
   character. 
    
   This arrangement is very similar to the ASCII case folding 
   experienced in the DNS today.  In the original specifications, it was 
   RECOMMENDED that query sent be left as they are and case folding done 
   only at the server end.  Some application implementations however do 
   perform the case folding at the user end.  As the query arrives at 
   the server, it is still case folded. 
    


  
DNSII-MDNR       Multilingual Domain Name Resolution        August 2000  
 
   Case folding for multilingual domain names should follow the existing 
   implementations for ASCII names, where the application SHOULD and the 
   server MUST. 
    
 
3. The Resolution Process 
    
   It is inevitable that at the end of the day, the entire DNS chain 
   SHOULD be updated in order for multilingual domain names to be as 
   efficiently resolved as names under the current DNS.  DNSII strives 
   to provide a schema that ultimately brings the system to a desirable 
   steady state while carefully giving considerations to all the 
   transition issues.  These include the considerations that at the 
   application end, there is already a preference and an installed base 
   of character encoding that may or may not conform to the desires of 
   the server end operations.  The use of ILET is therefore highly 
   desirable and essential. 
    
    
3.1 Steady State Resolution 
    
   At steady state, the resolution process of multilingual domain names 
   SHOULD be identical to the existing system.  Additional steps of 
   going through alphanumeric translation are unnecessary and 
   undesirable. 
    
   With DNSII, the contemplated steady state process resembles the well-
   known DNS model laid out in RFC1035. 
    
    
                   Local Host                          |    Foreign 
                                                       | 
    +---------+                   +----------+         |  +---------+ 
    |         | user queries      |          |queries  |  |         | 
    |         |(DNSII identifier  |          |         |  |         | 
    |         | ILET=UCS without  |          |         |  |         | 
    |  User   | Transformation)   |          |         |  | Foreign | 
    | Program |------------------>| Resolver |---------|->| Name    | 
    |         |                   |          |         |  | Server  | 
    |         |<------------------|          |<--------|--|         | 
    |         | user responses    |          |responses|  |         | 
    |         |                   |          |         |  |         | 
    +---------+                   +----------+         |  +---------+ 
                                    |     ^            | 
                    cache additions |     | references | 
                                    v     |            | 
                                  +----------+         | 
                                  |  cache   |         | 
                                  +----------+         | 
    
    
   Eventually, an ISO 10646 UCS without transformation is desired as the 
   common format.  The benefits of having a uniform byte length encoding 
  
DNSII-MDNR       Multilingual Domain Name Resolution        August 2000  
 
   far exceeds the seemingly easier transformation solution.  Especially 
   considering that the DNS requires a label count that should reflect 
   the number of characters in a label.  Of course there exists 
   combination characters in the ISO 10646 specifications as well, but 
   after canonicalization, only the ones that must use combinations 
   remain and they are usually meaningful depictions. 
    
   The importance of this count value is further demonstrated by 
   scrambling efforts to extend the size of this field or to compress 
   character encoding to accommodate multilingual characters.  With 
   DNSII, this no longer constitutes an issue because any language will 
   be able to share the same number of characters thanks to the use of 
   ISO 10646.  As a matter of fact, the desire to use uniform byte 
   length characters formed part of the original intent of the ISO 10646 
   initiative anyway. 
    
3.2 Client-End or Inquirer Transitional Fall-Back Strategy 
    
   For a DNSII aware Client, it will be able to create DNSII packets 
   which provides precise character data of the domain name in question.  
   However, if it encounters a non-compliant resolver, it MUST be able 
   to fallback to a format acceptable by current resolvers. 
    
    
    +---------+                        +----------+  
    |         | (1) user queries       |          | (2) if Resolver is  
    |         | (DNSII identifier      |          |  DNSII compliant,  
    |         |  ILET=UCS without      |          |  Packet is resolved  
    |  User   |  Transformation)       |          |  accordingly.  If  
    | Program |----------------------->| Resolver |  not fallback to (3) 
    |         |                        |          |  
    |         |<-----------------------|          |  
    |         | (3) Upon the detection |          |  
    |         |  of the DNSII Flag     |          | 
    |         |  resolver will reply   |          | 
    |         |  with _Format Error_   |          | 
    |         |                        |          |  
    |         |----------------------->|          | (5) Current resolu-  
    |         | (4) Send QNAME using   |          |  tion process begins 
    |         |  local encoding or     |          |  with the DNSII RR 
    |         |  UTF-8 with or without |          |  passed along as an 
    |         |  Additional DNSII RR   |          |  Additional RR 
    +---------+                        +----------+  
    
    
3.2.1 Tunneling MDNP through DNSII RR 
    
   An additional DNSII RR would be tunneled through using the format of 
   a TXT RR with the RDATA part containing the multilingual labels in a 
   DNSII compliant format.  The TTL of the RR MUST be set to zero to 
   avoid caching. 
    

  
DNSII-MDNR       Multilingual Domain Name Resolution        August 2000  
 
   It is not feasible to have a new RR type just for DNSII because the 
   resolver might reject RRs with unknown types.  For the name used in 
   the QNAME as well as the NAME field of the DNSII RR UTF-8 MAY be used 
   as the default fallback encoding.  However, an arbitrary ASCII name 
   MAY also be used just for the purpose of tunneling.  The TTL for 
   responses to tunneled requests MUST be set to zero to avoid caching 
   at any level in the DNS.  More detailed description in Section 3.4. 
    
   For older DNS servers, requests with a non-empty additional 
   information section MAY produce error returns, however since the 
   deployment of DNSSEC, especially for TSIG considerations, this no-
   longer constitutes a problem.  Basic security prepared servers such 
   as BIND 4 or 8 is already capable of bearing the tunneled DNSII RR. 
    
   It is possible to use ACE/RACE type translations at this level, 
   however it is more advisable to use a truly arbitrary label such as 
   _-for-tunneling-only-_.  So doing requires only reserving one 
   arbitrary name while ACE/RACE creates one more arbitrary name for 
   each new multilingual name registered, which will eventually 
   contribute to the fracturing of the DNS. 
    
   As an example, a tunneling packet for the domain name: host. —ŒªW¿t™ð
   .tld. (4host4—ŒªW¿t™ð3 tld0) will be represented as: 
    
   (in the QNAME field) 
    
                          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 
     +---------------------------------------------------------------+ 
   12|0 0|     4     |       h       |       o       |       s       | 
     +---------------------------------------------------------------+ 
   16|       t       |      20       |       -       |       f       | 
     +---------------------------------------------------------------+ 
   20|       0       |       r       |       -       |       t       | 
     +---------------------------------------------------------------+ 
   24|       u       |       n       |       n       |       e       | 
     +---------------------------------------------------------------+ 
   28|       l       |       i       |       n       |       g       | 
     +---------------------------------------------------------------+ 
   32|       -       |       o       |       n       |       l       | 
     +---------------------------------------------------------------+ 
   36|       y       |       -       |       3       |       t       | 
     +---------------------------------------------------------------+ 
   40|       l       |       d       |       0       |... 
     +-----------------------------------------------+ 
    







  
DNSII-MDNR       Multilingual Domain Name Resolution        August 2000  
 
   (The Additional DNSII RR Tunneled in TXT RR form) 
    
      :                                                               : 
      /                                                               / 
      +---------------------------------------------------------------+ 
    80|1 1|             12            |        TYPE = TXT = 16        | 
      +---------------------------------------------------------------+ 
    84|        CLASS = IN = 1         |              TTL              | 
      +---------------------------------------------------------------+ 
    88|              = 0              |        RDLENGTH = 22          | 
      +---------------------------------------------------------------+ 
    92|0 0|     4     |       h       |       o       |       s       | 
      +---------------------------------------------------------------+ 
    96|       t       |1 0|0 0|       UCS-2=1000      |       4       | 
      +---------------------------------------------------------------+ 
   100|1 1|             13            |1 0|z|  ILET=2 |       4       | 
      +---------------------------------------------------------------+ 
   104|          —Œ   (U+57DF)        |          ªW    (U+540D)         | 
      +---------------------------------------------------------------+ 
   108|          ¿t   (U+7CFB)        |          ™ð    (U+7D71)         | 
      +---------------------------------------------------------------+ 
   112|1 1|             38            | 
      +-------------------------------+ 
    
    
   The reason a DNSII RR is attached is to alert the authoritative DNS 
   server that the query is DNSII compliant while being able to tunnel 
   the request through non-compliant resolvers without any loss of 
   information. 
    
3.2.2 Tunneling ILET RRs 
    
   Another fallback strategy is to tunnel just the ILET instead of the 
   entire DNSII label.  If UTF-8 or a local encoding is used as the 
   QNAME, then the arbitrary ASCII label is no longer necessary.  The 
   tunneled RR therefore need only consist of an ILET indicating the 
   encoding format used. 
    
   Within the RDATA of an ILET RR masked as a TXT RR the first 4 bytes 
   will be used to indicate that it is an ILET and the following 4 bytes 
   to reflect the MIBenum of the encoding used. 
    











  
DNSII-MDNR       Multilingual Domain Name Resolution        August 2000  
 
   Following the example given in 3.2.1, the QNAME would be in UTF-8 
   (MIBenum = 106), while the additional ILET RR would be in the form: 
    
      :                                                               : 
      /                                                               / 
      +---------------------------------------------------------------+ 
    80|1 1|             12            |        TYPE = TXT = 16        | 
      +---------------------------------------------------------------+ 
    84|        CLASS = IN = 1         |              TTL              | 
      +---------------------------------------------------------------+ 
    88|              = 0              |        RDLENGTH = 22          | 
      +---------------------------------------------------------------+ 
    92|       I       |       L       |       E       |       T       | 
      +---------------------------------------------------------------+ 
    96|       0       |       1       |       0       |       6       | 
      +---------------------------------------------------------------+ 
    
    
3.3 Resolvers & Server-End Transitional Fallback Strategy 
    
   The tunneling scheme described in Section 3.2 assumes that the 
   authoritative server is fully DNSII compliant.  This assertion is 
   laid out in Section 4.3 where it is discussed that only fully 
   compliant servers SHOULD serve multilingual names directly under 
   their authoritative zone.  In any other case, the arbitrary domain  
   "-for-tunneling-only-" should result in an NXDomain response. 
    
   For security aware servers, an NXT RR of the last name wrapped by its 
   first name in the zone records will be returned because of the 
   leading "-" for the tunneling label.  
    
   If the application end is not DNSII compliant, the fallback 
   resolution strategy for resolvers would simply be to pass along the 
   labels in their 8-bit format and determine the existence of the 
   requested name as usual.  If a tunneled DNSII RR is detected, by way 
   of a label constituting entirely of _-for-tunneling-only-_ and the 
   existence of a valid DNSII RR, the resolver should attempt to resolve 
   the name according to the DNSII specification and tunnel the answer 
   back to the inquirer. 
    
    
3.3.1 Tunneling MDNP Responses through DNSII ANS RR 
    
   To tunnel a DNSII compliant answer through a non-compliant resolver, 
   another DNSII ANS RR is tunneled.  Also using the TXT RR format as a 
   mask.  TXT RRs are best used because it is a valid RR and its RDATA 
   is an unrestricted byte stream determined only by the RDLENGTH.  The 
   RDATA for a DNSII ANS RR would be the entire content of a regular 
   response RR attached to a DNSII format name. 
    
   Continuing on the example given in Section 3.2, suppose an A record 
   is requested and the IP address returned for the domain host.—ŒªW¿t™ð

  
DNSII-MDNR       Multilingual Domain Name Resolution        August 2000  
 
   .tld. is 123.4.5.6, then an additional DNSII ANS RR (TXT) in the 
   following form will be included: 
    
      :                                                               : 
      /                                                               / 
      +---------------------------------------------------------------+ 
   114|1 1|             12            |        TYPE = TXT = 16        | 
      +---------------------------------------------------------------+ 
   118|        CLASS = IN = 1         |              TTL              | 
      +---------------------------------------------------------------+ 
   122|              = 0              |         RDLENGTH = 16         | 
      +---------------------------------------------------------------+ 
   126|1 1|             92            |          TYPE = A = 1         | 
      +---------------------------------------------------------------+ 
   130|        CLASS = IN = 1         |              TTL              | 
      +---------------------------------------------------------------+ 
   134|            = 3600             |         RDLENGTH = 4          | 
      +---------------------------------------------------------------+ 
   138|      123      |       4       |       5       |       6       | 
      +---------------------------------------------------------------+ 
    
   Note that compression is available in the DNSII RRs.  While the 
   tunneling TXT mask uses the ASCII tunneling name and therefore points 
   back to the QNAME at offset 12, the tunneled A Record response uses 
   the offset corresponding to the DNSII compliant labels at 92.  While 
   the TTL of the TXT mask MUST be zero, the tunneled A Record RR 
   contains a regular TTL, in this case 3600. 
    
    
3.3.2 Reinsertion of ILET and DNSII Identifier 
    
   When a resolver receives an incoming query with a tunneled DNSII/ILET 
   RR, it SHOULD reconfigure the query into a fully compliant format 
   before engaging in further resolution.  If a "00" query is received, 
   the resolver should convert the label into UTF-8, set the DNSII 
   identifier "10" on and set the ILET to UTF-8. 
    
   In the scenario where the client end is not DNSII compliant, either a 
   local encoding 8-bit stream or a UTF-8 encoded stream without the 
   DNSII flag nor ILET will be transported.  During the transition 
   period, should this occur, the above forced UTF-8 conversion and ILET 
   insertion would take place and it would be up to the authoritative 
   server to determine the existence of the requested domain.  InZone 
   DNSII handling mechanism will serve to take care of these 
   transitional exceptions. 
    
    
4. DNSII Conformance Levels 
    
   DNSII is designed for a smooth transition from the existing ASCII 
   based DNS to a multilingual capable DNS.  Therefore, it is not 
   necessary for all servers and applications to be switched to 
   multilingual capable before starting the deployment. 
  
DNSII-MDNR       Multilingual Domain Name Resolution        August 2000  
 
    
    
4.1 Application Conformance Levels 
    
   The BASIC compliancy for applications would be to remove validity 
   checks for domain names.  The resolution process will determine a 
   non-existing domain name, so there really is no need to prevent a DNS 
   packet with multilingual labels to be sent through the wires. 
    
   The INTERMEDIATE compliancy for applications involves the insertion 
   of the DNSII identifier as well as the ILET according to the local 
   inputting and screen scheme.  If a user is using a JIS format scheme, 
   it should set the ILET to reflect it being used.  At the same time, 
   the tunneling mechanism discussed in Section 3.2 MUST also be in 
   place. 
    
   FULLY compliant applications will send all DNS packets with the DNSII 
   identifier and the ILET set to UCS-2/4. The fallback scheme discussed 
   in Section 3.2 MUST also be in place.  InZone DNSII mechanisms SHOULD 
   also be available to deal with local encoding exceptions. 
    
    
4.2 Resolver Conformance Levels 
    
   The BASIC compliancy for resolvers would be to allow an 8-bit clean 
   approach to name resolution.  Also, it should be made sure that the 
   additional DNSII RR (TXT) will not be truncated during resolution. 
    
   The INTERMEDIATE compliant resolvers MUST understand how to process 
   the DNSII identifier as well as not reject the ILET.  Interpretation 
   of the name is not required so it is NOT necessary for the resolvers 
   to be able to map all or any of the ILET values (with the alternative 
   approach in DNSII-MDNP, the ILET value corresponds to the byte length 
   of the characters contained in the label, which makes the count 
   workable even if the ILET value is not known by the resolver).  In 
   this scenario caching will be for exact comparison only (label to 
   label with ILET intact).  The important criteria is for the resolver 
   to be able to pass along the DNS query to the corresponding 
   authoritative server and obtain a correct response. 
    
   FULLY compliant resolvers will be able to process the DNSII identifer 
   and know all the ILET values for full function name mapping.  Cache 
   name lookup will be fully enabled and inquiry fallback mechanism 
   discussed in Section 3.2.2 SHOULD be performed in the event of 
   encountering a non-compliant server. 
    
    
4.3 Authoritative Server Conformance Levels 
    
   Authoritative servers MUST be fully compliant before attempting to 
   serve multilingual sub-domains under its authoritative zone.  They 
   should however prepare for the transition towards a multilingual name 
   space even if they do not intend to deploy it right away. 
  
DNSII-MDNR       Multilingual Domain Name Resolution        August 2000  
 
    
   The BASIC compliancy for authoritative name servers is to allow an 8-
   bit clean approach towards sub-domains that are not directly under 
   its authority (i.e. sub-sub-domains). 
    
   The INTERMEDIATE compliant name server will be able to process the 
   DNSII identifier and ILET without rejecting the query.  The 
   authoritative zone as well as its direct sub-domains however SHOULD 
   not include the use of the DNSII flags because ILET values are not 
   understood at this compliancy level. 
    
   FULLY compliant name servers will be able to handle DNSII compliant 
   label formats at its sub-domain levels.  That is, fully compliant 
   root servers will be able to serve multilingual TLDs, fully compliant 
   TLD servers will be able to serve multilingual SLDs, etc. 
    
    
5. Transition Schedule & Strategy 
    
   DNSII is designed to allow a gradual adoption of multilingual domain 
   names on the Internet.  The transition strategy is therefore geared 
   to be demand-pull instead of a technology-push incentive.  However, 
   to provide a platform for a demand-pull approach, it is required for 
   operators to first safeguard their system.  The simple approach as 
   laid out in Section 4 is to propose that servers take a 8-bit clean 
   approach on name resolution. 
    
   As discussed in DNSII-MDNP, it is reasonable for the deployment of 
   DNSII-MDNP at the registry level first to draw demand for the service 
   and let the host level DNSs with multilingual names to begin 
   migration first.  DNS operators around the world should however 
   prepare for the transition and begin the deployment of DNSII 
   depending on their interest in serving multilingual domain names, 
   according to the conformance levels laid out in Section 4, beginning 
   from BASIC compliancy for operators that are least interested to a 
   FULLY compliant server for operators who wishes to provide 
   multilingual capabilities for their users. 
    
   The root servers could easily be adjusted to be a BASIC compliant 
   authoritative name server.  Once the demand is proven and the 
   stability of the system tested, they too could transition to fully 
   compliant authoritative servers so that multilingual TLDs could be 
   rolled out. 
    
    
6. Summary of Discussion 
    
   This document introduces the contemplated transition and steady state 
   resolution process for multilingual domain names with a DNSII 
   compliant format.  Two tunneling mechanisms using the TXT RR was 
   introduced for the preservation of information during transitional 
   resolution. 
    
  
DNSII-MDNR       Multilingual Domain Name Resolution        August 2000  
 
6.1 Client/Application Resolution Strategy 
    
   Send Query in DNSII format 
   IF RCODE = Format Error 
        THEN send query in UTF-8/Local Encoding AND append DNSII RR 
        IF RCODE = Format Error 
             THEN send Query in ASCII with _-for-tunneling-only-_ label 
             AND append DNSII RR 
             AND check for DNSII ANS RR in response 
        ELSE proceed and check for DNSII ANS RR in response 
   ELSE proceed as usual 
    
    
6.2 Resolver Resolution Strategy 
    
   (*)IF incoming request is in pure DNSII format 
        THEN resolve according to ILET in cache and by recursive lookup 
        IF encounter RCODE = Format Error 
             THEN send query in UTF-8 AND append DNSII RR 
             IF RCODE = Format Error 
                  THEN send query in ASCII with _-for-tunneling-only-_  
                       label 
                  AND append DNSII RR 
                  AND check for DNSII ANS RR in response 
             ELSE proceed and check for DNSII ANS RR in response 
        ELSE proceed as usual with pure DNSII Format (*) 
        AND respond in pure DNSII format 
   ELSE IF incoming request has tunneled MDNP information 
        THEN resolve using the information in the appended DNSII RR 
             Reset Query using DNSII Format and go through (*) 
        AND convert back to tunneling format before responding to query 
             With DNSII ANS RR appended to response 
        AND set TTL for regular RRs in the Answer field to be = 0 
   ElSE IF incoming request is in the original "00" label format 
        AND no tunneled information is included 
        AND the label contains characters beyond A-z, 0-9 or "-" 
        THEN force convert all labels to UTF-8 
        AND query using DNSII Format and go through (*) 
   ELSE proceed as usual (existing ASCII based names) 
    
    
6.3 Authoritative Name Server Resolution Strategy 
    
   IF incoming request is in pure DNSII format 
        THEN resolve according to ILET 
        AND respond in pure DNSII format 
   ELSE IF incoming request has tunneled MDNP information 
        THEN resolve using the information in the appended DNSII RR 
        AND convert back to tunneling format before responding to query 
             With DNSII ANS RR appended to response 
        AND set TTL for regular RRs in the Answer field to be = 0 
   ELSE use InZone DNSII mechanisms AND use 8-bit clean approach 
    
  
DNSII-MDNR       Multilingual Domain Name Resolution        August 2000  
 
7. Security Considerations 
    
   DNSII RRs will be secured through transaction authentication, while 
   DNSII ANS RRs could have their own SIG RRs.  In general, the DNSII-
   MDNR should not constitute any extra burden on DNS security. 
    
    
8. 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. 
    
   Other DNSII related documents and discussions could be found at 
   http://www.dnsii.org. 
    
9. References 
 
   [DNSII-MDNP] E. Chung & D. Leung "DNSII Multilingual Domain Name 
              Protocol", August 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) 
    
   [RFC1034]  Mockapetris, P., "Domain Names - Concepts and  
              Facilities," STD 13, RFC 1034, USC/ISI, November 1987 
       
   [RFC1035]  Mockapetris, P., "Domain Names - Implementation and  
              Specification," STD 13, RFC 1035, USC/ISI, November  
              1987 
    
   [RFC2119]  S. Bradner, "Key words for use in RFCs to Indicate  
              Requirement Levels," RFC 2119, March 1997 
    
    
    
    
    
    
  
DNSII-MDNR       Multilingual Domain Name Resolution        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 
    







































  
