idnits 2.17.1 draft-ietf-idn-dnsii-mdnr-00.txt: -(310): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(352): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(354): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(425): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. == There are 5 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 13 form feeds but 15 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: 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. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 2000) is 8652 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'DNSII-MDNP' is defined on line 656, but no explicit reference was found in the text == Unused Reference: 'RFC1700' is defined on line 659, but no explicit reference was found in the text == Unused Reference: 'ISO10646' is defined on line 662, but no explicit reference was found in the text == Unused Reference: 'RFC1034' is defined on line 666, but no explicit reference was found in the text == Unused Reference: 'RFC1035' is defined on line 669, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'DNSII-MDNP' ** Obsolete normative reference: RFC 1700 (Obsoleted by RFC 3232) -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO10646' Summary: 5 errors (**), 0 flaws (~~), 11 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IDN Working Group Edmon Chung & David Leung 2 Internet Draft Neteka Inc. 3 August 2000 5 DNSII Multilingual Domain Name Resolution 7 STATUS OF THIS MEMO 9 This document is an Internet-Draft and is in full conformance with 10 all provisions of Section 10 of RFC2026. 12 Internet-Drafts are working documents of the Internet Engineering 13 Task Force (IETF), its areas, and its working groups. Note that 14 other groups may also distribute working documents as Internet- 15 Drafts. Internet-Drafts are draft documents valid for a maximum of 16 six months and may be updated, replaced, or obsoleted by other 17 documents at any time. It is inappropriate to use Internet-Drafts as 18 reference material or to cite them other than as "work in progress." 20 The reader is cautioned not to depend on the values that appear in 21 examples to be current or complete, since their purpose is primarily 22 educational. Distribution of this memo is unlimited. 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Abstract 31 The Internet-Draft for DNSII-MDNP was focused purely on discussing 32 the ultimate packet protocol that is being sent around the Internet 33 for multilingual domain names. This paper complements the previous 34 paper by outlining the contemplated resolution process with the DNSII 35 protocol throughout the DNS name resolution process. 37 The DNSII-MDNR outlines a resolution process that forms a framework 38 for the resolution of multilingual domain names. Whether the DNSII 39 protocol is implemented exactly as specified in DNSII-MDNP is less 40 relevant, rather it is the idea of having a multilingual packet 41 identifier and the fall back process that matters. The DNSII-MDNR 42 successfully addresses the transitional issues at each node of the 43 DNS resolution process providing a clear migration path and strategy 44 for the deployment of a multilingual enabled DNS system. It also 45 outlines the conformance levels required for basic or complete 46 implementations for applications, resolvers and name servers. 48 This document also introduces a tunneling mechanism for the short-run 49 to transition the system through to a truly multilingual capable name 50 space. 52 Table of Contents 54 1. Introduction....................................................2 55 1.1 Terminology....................................................2 56 1.2 Multilingual Domain Name Resolution............................3 57 1.2 DNSII-MDNR.....................................................3 58 2. DNSII Proposal with respect to the DNS Layers...................3 59 3. The Resolution Process..........................................5 60 3.1 Steady State Resolution........................................5 61 3.2 Client-End or Inquirer Transitional Fall-Back Strategy.........6 62 3.2.1 Tunneling MDNP through DNSII RR..............................6 63 3.2.2 Tunneling ILET RRs...........................................8 64 3.3 Resolvers & Server-End Transitional Fallback Strategy..........9 65 3.3.1 Tunneling MDNP Responses through DNSII ANS RR................9 66 3.3.2 Reinsertion of ILET and DNSII Identifier....................10 67 4. DNSII Conformance Levels.......................................10 68 4.1 Application Conformance Levels................................11 69 4.2 Resolver Conformance Levels...................................11 70 4.3 Authoritative Server Conformance Levels.......................11 71 5. Transition Schedule & Strategy.................................12 72 6. Summary of Discussion..........................................12 73 6.1 Client/Application Resolution Strategy........................13 74 6.2 Resolver Resolution Strategy..................................13 75 6.3 Authoritative Name Server Resolution Strategy.................13 76 7. Security Considerations........................................14 77 8. Intellectual Property Considerations...........................14 78 9. References.....................................................14 80 1. Introduction 82 This Internet-Draft describes details of the contemplated resolution 83 process after the deployment of DNSII-MDNP, or other multilingual 84 domain name efforts containing a bit flag multilingual packet 85 identifier or otherwise InPacket identifications for that matter. 87 The reader is assumed to be familiar with the concepts discussed in 88 the DNSII-MDNP Internet-Draft . 90 1.1 Terminology 92 The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED", 93 and "MAY" in this document are to be interpreted as described in RFC 94 2119 [RFC2119]. 96 A number of multilingual characters are used in this document for 97 examples. Please select your view encoding type to Big-5 98 (Traditional Chinese) for them to be displayed properly. 100 1.2 Multilingual Domain Name Resolution 102 The original specifications for the DNS were designed to be open 103 enough for simple implementation of a multilingual naming system with 104 slight adjustments as laid out in DNSII-MDNP. The transition and 105 especially its resolution process during migration is however a 106 tricky problem. Several things that MUST be kept in mind is that 107 there is a initial phase, an intermediate phase and an ultimate 108 steady state phase. DNSII-MDNP only described the ideal protocol at 109 steady state, with incorporated flexibility for transition from the 110 present to multilingual as well as again towards future unknown 111 grounds. 113 It is important to remember that the ultimate form SHOULD be 114 determined and then the transition scheme laid out. While an ASCII 115 translation system might seem favorable in the short-run, it 116 effectively creates an alternative universe which is counter to the 117 spirit of the DNS. However an ASCII translation is implemented, it 118 immediately creates a "human-multilingual" universe and a "machine- 119 ASCII" universe. This document introduces a tunneling mechanism to 120 transition the DNS from today's monolingual system, through an 8-bit 121 or 7-bit migration scheme towards a truly sustainable multilingual 122 name space, arriving at a DNSII type system. 124 1.2 DNSII-MDNR 126 While DNSII-MDNP describes the framework for the ultimate protocol 127 format of a multilingual DNS, DNSII-MDNR will discuss how the packet 128 SHOULD be transported and interpreted throughout the DNS. The 129 document will describe both the intended resolution process as well 130 as part of the transition strategy from the existing DNS to a DNSII 131 enabled system. 133 2. DNSII Proposal with respect to the DNS Layers 135 The following diagram illustrates the use of DNSII-MDNP at a steady 136 state. Section 3 will discuss the fallback strategies while Section 137 4 will talk about issues on conformance levels. 139 +---------------+ 140 | | NamePrep: 141 | Application | Canonicalize in Form C/KC 142 | | Insert DNSII Identifier +---------------------+ 143 | | Insert appropriate ILET | (Base data) | 144 +---------------+ +---------------------+ 145 | | 146 | DNS Packet with DNSII | (no standard) 147 | Identifier & ILET | RECOMMENDS 148 | | UCS-2/4 149 +---------------+ | 150 | Resolver | Canonicalize, Case Fold +---------------------+ 151 | | (for cache lookup) or | Auth DNS server | 152 +---------------+ leave as is & Resolve | (Canonicalize, | 153 | | Case Fold & Lookup) | 154 | Pass Along without +---------------------+ 155 | Altering Case or Canonicalization | 156 | | 157 | <----- DNS service interface -----> | 158 +------------------------------------------------------------------+ 159 | DNS service | 160 | +-----------------------+ +--------------------+ | 161 | | Forwarding DNS server | | Caching DNS server | | 162 | +-----------------------+ +--------------------+ | 163 | | 164 | +-------------------------+ | 165 | | Parent-zone DNS servers | | 166 | +-------------------------+ | 167 | | 168 | +-------------------------+ | 169 | | Root DNS servers | | 170 | +-------------------------+ | 171 | | 172 +------------------------------------------------------------------+ 174 Please note that at each level, the domain name is being 175 canonicalized. This is to ensure that at the end, characters that 176 can be represented by a single code point will not be otherwise 177 compared resulting in inconsistent reply to a humanly identical name. 178 It is RECOMMENDED that applications SHOULD conduct canonicalization 179 while servers MUST. Duplicating the process is fine because if a 180 character is already composed, it will not compose again with another 181 character. 183 This arrangement is very similar to the ASCII case folding 184 experienced in the DNS today. In the original specifications, it was 185 RECOMMENDED that query sent be left as they are and case folding done 186 only at the server end. Some application implementations however do 187 perform the case folding at the user end. As the query arrives at 188 the server, it is still case folded. 190 Case folding for multilingual domain names should follow the existing 191 implementations for ASCII names, where the application SHOULD and the 192 server MUST. 194 3. The Resolution Process 196 It is inevitable that at the end of the day, the entire DNS chain 197 SHOULD be updated in order for multilingual domain names to be as 198 efficiently resolved as names under the current DNS. DNSII strives 199 to provide a schema that ultimately brings the system to a desirable 200 steady state while carefully giving considerations to all the 201 transition issues. These include the considerations that at the 202 application end, there is already a preference and an installed base 203 of character encoding that may or may not conform to the desires of 204 the server end operations. The use of ILET is therefore highly 205 desirable and essential. 207 3.1 Steady State Resolution 209 At steady state, the resolution process of multilingual domain names 210 SHOULD be identical to the existing system. Additional steps of 211 going through alphanumeric translation are unnecessary and 212 undesirable. 214 With DNSII, the contemplated steady state process resembles the well- 215 known DNS model laid out in RFC1035. 217 Local Host | Foreign 218 | 219 +---------+ +----------+ | +---------+ 220 | | user queries | |queries | | | 221 | |(DNSII identifier | | | | | 222 | | ILET=UCS without | | | | | 223 | User | Transformation) | | | | Foreign | 224 | Program |------------------>| Resolver |---------|->| Name | 225 | | | | | | Server | 226 | |<------------------| |<--------|--| | 227 | | user responses | |responses| | | 228 | | | | | | | 229 +---------+ +----------+ | +---------+ 230 | ^ | 231 cache additions | | references | 232 v | | 233 +----------+ | 234 | cache | | 235 +----------+ | 237 Eventually, an ISO 10646 UCS without transformation is desired as the 238 common format. The benefits of having a uniform byte length encoding 239 far exceeds the seemingly easier transformation solution. Especially 240 considering that the DNS requires a label count that should reflect 241 the number of characters in a label. Of course there exists 242 combination characters in the ISO 10646 specifications as well, but 243 after canonicalization, only the ones that must use combinations 244 remain and they are usually meaningful depictions. 246 The importance of this count value is further demonstrated by 247 scrambling efforts to extend the size of this field or to compress 248 character encoding to accommodate multilingual characters. With 249 DNSII, this no longer constitutes an issue because any language will 250 be able to share the same number of characters thanks to the use of 251 ISO 10646. As a matter of fact, the desire to use uniform byte 252 length characters formed part of the original intent of the ISO 10646 253 initiative anyway. 255 3.2 Client-End or Inquirer Transitional Fall-Back Strategy 257 For a DNSII aware Client, it will be able to create DNSII packets 258 which provides precise character data of the domain name in question. 259 However, if it encounters a non-compliant resolver, it MUST be able 260 to fallback to a format acceptable by current resolvers. 262 +---------+ +----------+ 263 | | (1) user queries | | (2) if Resolver is 264 | | (DNSII identifier | | DNSII compliant, 265 | | ILET=UCS without | | Packet is resolved 266 | User | Transformation) | | accordingly. If 267 | Program |----------------------->| Resolver | not fallback to (3) 268 | | | | 269 | |<-----------------------| | 270 | | (3) Upon the detection | | 271 | | of the DNSII Flag | | 272 | | resolver will reply | | 273 | | with "Format Error" | | 274 | | | | 275 | |----------------------->| | (5) Current resolu- 276 | | (4) Send QNAME using | | tion process begins 277 | | local encoding or | | with the DNSII RR 278 | | UTF-8 with or without | | passed along as an 279 | | Additional DNSII RR | | Additional RR 280 +---------+ +----------+ 282 3.2.1 Tunneling MDNP through DNSII RR 284 An additional DNSII RR would be tunneled through using the format of 285 a TXT RR with the RDATA part containing the multilingual labels in a 286 DNSII compliant format. The TTL of the RR MUST be set to zero to 287 avoid caching. 289 It is not feasible to have a new RR type just for DNSII because the 290 resolver might reject RRs with unknown types. For the name used in 291 the QNAME as well as the NAME field of the DNSII RR UTF-8 MAY be used 292 as the default fallback encoding. However, an arbitrary ASCII name 293 MAY also be used just for the purpose of tunneling. The TTL for 294 responses to tunneled requests MUST be set to zero to avoid caching 295 at any level in the DNS. More detailed description in Section 3.4. 297 For older DNS servers, requests with a non-empty additional 298 information section MAY produce error returns, however since the 299 deployment of DNSSEC, especially for TSIG considerations, this no- 300 longer constitutes a problem. Basic security prepared servers such 301 as BIND 4 or 8 is already capable of bearing the tunneled DNSII RR. 303 It is possible to use ACE/RACE type translations at this level, 304 however it is more advisable to use a truly arbitrary label such as 305 "-for-tunneling-only-". So doing requires only reserving one 306 arbitrary name while ACE/RACE creates one more arbitrary name for 307 each new multilingual name registered, which will eventually 308 contribute to the fracturing of the DNS. 310 As an example, a tunneling packet for the domain name: host. ���W�t�� 311 .tld. (4host4���W�t��3 tld0) will be represented as: 313 (in the QNAME field) 315 1 1 1 1 1 1 1 1 1 1 1 1 316 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 317 +---------------------------------------------------------------+ 318 12|0 0| 4 | h | o | s | 319 +---------------------------------------------------------------+ 320 16| t | 20 | - | f | 321 +---------------------------------------------------------------+ 322 20| 0 | r | - | t | 323 +---------------------------------------------------------------+ 324 24| u | n | n | e | 325 +---------------------------------------------------------------+ 326 28| l | i | n | g | 327 +---------------------------------------------------------------+ 328 32| - | o | n | l | 329 +---------------------------------------------------------------+ 330 36| y | - | 3 | t | 331 +---------------------------------------------------------------+ 332 40| l | d | 0 |... 333 +-----------------------------------------------+ 335 (The Additional DNSII RR Tunneled in TXT RR form) 337 : : 338 / / 339 +---------------------------------------------------------------+ 340 80|1 1| 12 | TYPE = TXT = 16 | 341 +---------------------------------------------------------------+ 342 84| CLASS = IN = 1 | TTL | 343 +---------------------------------------------------------------+ 344 88| = 0 | RDLENGTH = 22 | 345 +---------------------------------------------------------------+ 346 92|0 0| 4 | h | o | s | 347 +---------------------------------------------------------------+ 348 96| t |1 0|0 0| UCS-2=1000 | 4 | 349 +---------------------------------------------------------------+ 350 100|1 1| 13 |1 0|z| ILET=2 | 4 | 351 +---------------------------------------------------------------+ 352 104| �� (U+57DF) | �W (U+540D) | 353 +---------------------------------------------------------------+ 354 108| �t (U+7CFB) | �� (U+7D71) | 355 +---------------------------------------------------------------+ 356 112|1 1| 38 | 357 +-------------------------------+ 359 The reason a DNSII RR is attached is to alert the authoritative DNS 360 server that the query is DNSII compliant while being able to tunnel 361 the request through non-compliant resolvers without any loss of 362 information. 364 3.2.2 Tunneling ILET RRs 366 Another fallback strategy is to tunnel just the ILET instead of the 367 entire DNSII label. If UTF-8 or a local encoding is used as the 368 QNAME, then the arbitrary ASCII label is no longer necessary. The 369 tunneled RR therefore need only consist of an ILET indicating the 370 encoding format used. 372 Within the RDATA of an ILET RR masked as a TXT RR the first 4 bytes 373 will be used to indicate that it is an ILET and the following 4 bytes 374 to reflect the MIBenum of the encoding used. 376 Following the example given in 3.2.1, the QNAME would be in UTF-8 377 (MIBenum = 106), while the additional ILET RR would be in the form: 379 : : 380 / / 381 +---------------------------------------------------------------+ 382 80|1 1| 12 | TYPE = TXT = 16 | 383 +---------------------------------------------------------------+ 384 84| CLASS = IN = 1 | TTL | 385 +---------------------------------------------------------------+ 386 88| = 0 | RDLENGTH = 22 | 387 +---------------------------------------------------------------+ 388 92| I | L | E | T | 389 +---------------------------------------------------------------+ 390 96| 0 | 1 | 0 | 6 | 391 +---------------------------------------------------------------+ 393 3.3 Resolvers & Server-End Transitional Fallback Strategy 395 The tunneling scheme described in Section 3.2 assumes that the 396 authoritative server is fully DNSII compliant. This assertion is 397 laid out in Section 4.3 where it is discussed that only fully 398 compliant servers SHOULD serve multilingual names directly under 399 their authoritative zone. In any other case, the arbitrary domain 400 "-for-tunneling-only-" should result in an NXDomain response. 402 For security aware servers, an NXT RR of the last name wrapped by its 403 first name in the zone records will be returned because of the 404 leading "-" for the tunneling label. 406 If the application end is not DNSII compliant, the fallback 407 resolution strategy for resolvers would simply be to pass along the 408 labels in their 8-bit format and determine the existence of the 409 requested name as usual. If a tunneled DNSII RR is detected, by way 410 of a label constituting entirely of "-for-tunneling-only-" and the 411 existence of a valid DNSII RR, the resolver should attempt to resolve 412 the name according to the DNSII specification and tunnel the answer 413 back to the inquirer. 415 3.3.1 Tunneling MDNP Responses through DNSII ANS RR 417 To tunnel a DNSII compliant answer through a non-compliant resolver, 418 another DNSII ANS RR is tunneled. Also using the TXT RR format as a 419 mask. TXT RRs are best used because it is a valid RR and its RDATA 420 is an unrestricted byte stream determined only by the RDLENGTH. The 421 RDATA for a DNSII ANS RR would be the entire content of a regular 422 response RR attached to a DNSII format name. 424 Continuing on the example given in Section 3.2, suppose an A record 425 is requested and the IP address returned for the domain host.���W�t�� 426 .tld. is 123.4.5.6, then an additional DNSII ANS RR (TXT) in the 427 following form will be included: 429 : : 430 / / 431 +---------------------------------------------------------------+ 432 114|1 1| 12 | TYPE = TXT = 16 | 433 +---------------------------------------------------------------+ 434 118| CLASS = IN = 1 | TTL | 435 +---------------------------------------------------------------+ 436 122| = 0 | RDLENGTH = 16 | 437 +---------------------------------------------------------------+ 438 126|1 1| 92 | TYPE = A = 1 | 439 +---------------------------------------------------------------+ 440 130| CLASS = IN = 1 | TTL | 441 +---------------------------------------------------------------+ 442 134| = 3600 | RDLENGTH = 4 | 443 +---------------------------------------------------------------+ 444 138| 123 | 4 | 5 | 6 | 445 +---------------------------------------------------------------+ 447 Note that compression is available in the DNSII RRs. While the 448 tunneling TXT mask uses the ASCII tunneling name and therefore points 449 back to the QNAME at offset 12, the tunneled A Record response uses 450 the offset corresponding to the DNSII compliant labels at 92. While 451 the TTL of the TXT mask MUST be zero, the tunneled A Record RR 452 contains a regular TTL, in this case 3600. 454 3.3.2 Reinsertion of ILET and DNSII Identifier 456 When a resolver receives an incoming query with a tunneled DNSII/ILET 457 RR, it SHOULD reconfigure the query into a fully compliant format 458 before engaging in further resolution. If a "00" query is received, 459 the resolver should convert the label into UTF-8, set the DNSII 460 identifier "10" on and set the ILET to UTF-8. 462 In the scenario where the client end is not DNSII compliant, either a 463 local encoding 8-bit stream or a UTF-8 encoded stream without the 464 DNSII flag nor ILET will be transported. During the transition 465 period, should this occur, the above forced UTF-8 conversion and ILET 466 insertion would take place and it would be up to the authoritative 467 server to determine the existence of the requested domain. InZone 468 DNSII handling mechanism will serve to take care of these 469 transitional exceptions. 471 4. DNSII Conformance Levels 473 DNSII is designed for a smooth transition from the existing ASCII 474 based DNS to a multilingual capable DNS. Therefore, it is not 475 necessary for all servers and applications to be switched to 476 multilingual capable before starting the deployment. 478 4.1 Application Conformance Levels 480 The BASIC compliancy for applications would be to remove validity 481 checks for domain names. The resolution process will determine a 482 non-existing domain name, so there really is no need to prevent a DNS 483 packet with multilingual labels to be sent through the wires. 485 The INTERMEDIATE compliancy for applications involves the insertion 486 of the DNSII identifier as well as the ILET according to the local 487 inputting and screen scheme. If a user is using a JIS format scheme, 488 it should set the ILET to reflect it being used. At the same time, 489 the tunneling mechanism discussed in Section 3.2 MUST also be in 490 place. 492 FULLY compliant applications will send all DNS packets with the DNSII 493 identifier and the ILET set to UCS-2/4. The fallback scheme discussed 494 in Section 3.2 MUST also be in place. InZone DNSII mechanisms SHOULD 495 also be available to deal with local encoding exceptions. 497 4.2 Resolver Conformance Levels 499 The BASIC compliancy for resolvers would be to allow an 8-bit clean 500 approach to name resolution. Also, it should be made sure that the 501 additional DNSII RR (TXT) will not be truncated during resolution. 503 The INTERMEDIATE compliant resolvers MUST understand how to process 504 the DNSII identifier as well as not reject the ILET. Interpretation 505 of the name is not required so it is NOT necessary for the resolvers 506 to be able to map all or any of the ILET values (with the alternative 507 approach in DNSII-MDNP, the ILET value corresponds to the byte length 508 of the characters contained in the label, which makes the count 509 workable even if the ILET value is not known by the resolver). In 510 this scenario caching will be for exact comparison only (label to 511 label with ILET intact). The important criteria is for the resolver 512 to be able to pass along the DNS query to the corresponding 513 authoritative server and obtain a correct response. 515 FULLY compliant resolvers will be able to process the DNSII identifer 516 and know all the ILET values for full function name mapping. Cache 517 name lookup will be fully enabled and inquiry fallback mechanism 518 discussed in Section 3.2.2 SHOULD be performed in the event of 519 encountering a non-compliant server. 521 4.3 Authoritative Server Conformance Levels 523 Authoritative servers MUST be fully compliant before attempting to 524 serve multilingual sub-domains under its authoritative zone. They 525 should however prepare for the transition towards a multilingual name 526 space even if they do not intend to deploy it right away. 528 The BASIC compliancy for authoritative name servers is to allow an 8- 529 bit clean approach towards sub-domains that are not directly under 530 its authority (i.e. sub-sub-domains). 532 The INTERMEDIATE compliant name server will be able to process the 533 DNSII identifier and ILET without rejecting the query. The 534 authoritative zone as well as its direct sub-domains however SHOULD 535 not include the use of the DNSII flags because ILET values are not 536 understood at this compliancy level. 538 FULLY compliant name servers will be able to handle DNSII compliant 539 label formats at its sub-domain levels. That is, fully compliant 540 root servers will be able to serve multilingual TLDs, fully compliant 541 TLD servers will be able to serve multilingual SLDs, etc. 543 5. Transition Schedule & Strategy 545 DNSII is designed to allow a gradual adoption of multilingual domain 546 names on the Internet. The transition strategy is therefore geared 547 to be demand-pull instead of a technology-push incentive. However, 548 to provide a platform for a demand-pull approach, it is required for 549 operators to first safeguard their system. The simple approach as 550 laid out in Section 4 is to propose that servers take a 8-bit clean 551 approach on name resolution. 553 As discussed in DNSII-MDNP, it is reasonable for the deployment of 554 DNSII-MDNP at the registry level first to draw demand for the service 555 and let the host level DNSs with multilingual names to begin 556 migration first. DNS operators around the world should however 557 prepare for the transition and begin the deployment of DNSII 558 depending on their interest in serving multilingual domain names, 559 according to the conformance levels laid out in Section 4, beginning 560 from BASIC compliancy for operators that are least interested to a 561 FULLY compliant server for operators who wishes to provide 562 multilingual capabilities for their users. 564 The root servers could easily be adjusted to be a BASIC compliant 565 authoritative name server. Once the demand is proven and the 566 stability of the system tested, they too could transition to fully 567 compliant authoritative servers so that multilingual TLDs could be 568 rolled out. 570 6. Summary of Discussion 572 This document introduces the contemplated transition and steady state 573 resolution process for multilingual domain names with a DNSII 574 compliant format. Two tunneling mechanisms using the TXT RR was 575 introduced for the preservation of information during transitional 576 resolution. 578 6.1 Client/Application Resolution Strategy 580 Send Query in DNSII format 581 IF RCODE = Format Error 582 THEN send query in UTF-8/Local Encoding AND append DNSII RR 583 IF RCODE = Format Error 584 THEN send Query in ASCII with "-for-tunneling-only-" label 585 AND append DNSII RR 586 AND check for DNSII ANS RR in response 587 ELSE proceed and check for DNSII ANS RR in response 588 ELSE proceed as usual 590 6.2 Resolver Resolution Strategy 592 (*)IF incoming request is in pure DNSII format 593 THEN resolve according to ILET in cache and by recursive lookup 594 IF encounter RCODE = Format Error 595 THEN send query in UTF-8 AND append DNSII RR 596 IF RCODE = Format Error 597 THEN send query in ASCII with "-for-tunneling-only-" 598 label 599 AND append DNSII RR 600 AND check for DNSII ANS RR in response 601 ELSE proceed and check for DNSII ANS RR in response 602 ELSE proceed as usual with pure DNSII Format (*) 603 AND respond in pure DNSII format 604 ELSE IF incoming request has tunneled MDNP information 605 THEN resolve using the information in the appended DNSII RR 606 Reset Query using DNSII Format and go through (*) 607 AND convert back to tunneling format before responding to query 608 With DNSII ANS RR appended to response 609 AND set TTL for regular RRs in the Answer field to be = 0 610 ElSE IF incoming request is in the original "00" label format 611 AND no tunneled information is included 612 AND the label contains characters beyond A-z, 0-9 or "-" 613 THEN force convert all labels to UTF-8 614 AND query using DNSII Format and go through (*) 615 ELSE proceed as usual (existing ASCII based names) 617 6.3 Authoritative Name Server Resolution Strategy 619 IF incoming request is in pure DNSII format 620 THEN resolve according to ILET 621 AND respond in pure DNSII format 622 ELSE IF incoming request has tunneled MDNP information 623 THEN resolve using the information in the appended DNSII RR 624 AND convert back to tunneling format before responding to query 625 With DNSII ANS RR appended to response 626 AND set TTL for regular RRs in the Answer field to be = 0 627 ELSE use InZone DNSII mechanisms AND use 8-bit clean approach 629 7. Security Considerations 631 DNSII RRs will be secured through transaction authentication, while 632 DNSII ANS RRs could have their own SIG RRs. In general, the DNSII- 633 MDNR should not constitute any extra burden on DNS security. 635 8. Intellectual Property Considerations 637 It is the intention of Neteka to submit the DNSII protocol and other 638 elements of the multilingual domain name server software to IETF for 639 review, comment or standardization. 641 Neteka Inc. has applied for one or more patents on the technology 642 related to multilingual domain name server software and multilingual 643 email server software suite. If a standard is adopted by IETF and 644 any patents are issued to Neteka with claims that are necessary for 645 practicing the standard, any party will be able to obtain the right 646 to implement, use and distribute the technology or works when 647 implementing, using or distributing technology based upon the 648 specific specifications under fair, reasonable and non-discriminatory 649 terms. 651 Other DNSII related documents and discussions could be found at 652 http://www.dnsii.org. 654 9. References 656 [DNSII-MDNP] E. Chung & D. Leung "DNSII Multilingual Domain Name 657 Protocol", August 2000 659 [RFC1700] J. Reynolds, J. Postel, "ASSIGNED NUMBERS", RFC 660 1700, October 1994. 662 [ISO10646] ISO/IEC 10646-1:2000. International Standard -- 663 Information technology -- Universal Multiple-Octet Coded 664 Character Set (UCS) 666 [RFC1034] Mockapetris, P., "Domain Names - Concepts and 667 Facilities," STD 13, RFC 1034, USC/ISI, November 1987 669 [RFC1035] Mockapetris, P., "Domain Names - Implementation and 670 Specification," STD 13, RFC 1035, USC/ISI, November 671 1987 673 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 674 Requirement Levels," RFC 2119, March 1997 676 DNSII-MDNR Multilingual Domain Name Resolution August 2000 678 Authors: 680 Edmon Chung 681 Neteka Inc. 682 2462 Yonge St. Toronto, 683 Ontario, Canada M4P 2H5 684 edmon@neteka.com 686 David Leung 687 Neteka Inc. 688 2462 Yonge St. Toronto, 689 Ontario, Canada M4P 2H5 690 david@neteka.com