draft-ietf-idn-dnsii-mdnr-01.txt

bind-3.2.

 
   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. 棇猈縯欚
   .tld. (4host4棇猈縯欚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)        |          猈    (U+540D)         | 
      +---------------------------------------------------------------+ 
   108|          縯   (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.棇猈縯欚

  
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