idnits 2.17.1 draft-yao-dnsop-idntld-implementation-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == 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). == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 22, 2009) is 5293 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'EDNS0' is defined on line 388, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 397, but no explicit reference was found in the text == Unused Reference: 'RFC3629' is defined on line 411, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2671 (ref. 'EDNS0') (Obsoleted by RFC 6891) ** Obsolete normative reference: RFC 2672 (Obsoleted by RFC 6672) ** Obsolete normative reference: RFC 2870 (Obsoleted by RFC 7720) ** Obsolete normative reference: RFC 3490 (Obsoleted by RFC 5890, RFC 5891) -- Duplicate reference: RFC2672, mentioned in 'RFC2672bis', was also mentioned in 'RFC2672'. -- Obsolete informational reference (is this intentional?): RFC 2672 (Obsoleted by RFC 6672) Summary: 5 errors (**), 0 flaws (~~), 6 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Yao 3 Internet-Draft X. Lee 4 Intended status: Informational CNNIC 5 Expires: April 25, 2010 October 22, 2009 7 IDN TLD Variants Implementation Guideline 8 draft-yao-dnsop-idntld-implementation-01.txt 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. This document may contain material 14 from IETF Documents or IETF Contributions published or made publicly 15 available before November 10, 2008. The person(s) controlling the 16 copyright in some of this material may not have granted the IETF 17 Trust the right to allow modifications of such material outside the 18 IETF Standards Process. Without obtaining an adequate license from 19 the person(s) controlling the copyright in such materials, this 20 document may not be modified outside the IETF Standards Process, and 21 derivative works of it may not be created outside the IETF Standards 22 Process, except to format it for publication as an RFC or to 23 translate it into languages other than English. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt. 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 This Internet-Draft will expire on April 25, 2010. 43 Copyright Notice 45 Copyright (c) 2009 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents in effect on the date of 50 publication of this document (http://trustee.ietf.org/license-info). 51 Please review these documents carefully, as they describe your rights 52 and restrictions with respect to this document. 54 Abstract 56 ICANN is pushing the IDN TLD into the root server. Some IDN TLD has 57 the variants. Currently, there are two proposals to implement the 58 IDN TLD variants in the root servers:1, implement it with the DNAME 59 record; 2, implement it with NS record. The IDN TLD variants may be 60 reserved or activated. If the IDN TLD variants are activated, these 61 variants will be allocated to the same TLD manager in order to avoid 62 the possible phishing problems. How to deal with the IDN TLD variant 63 issue is a big challenge ahead of us. This document discusses the 64 IDN TLD variants implementation issues related with DNAME and NS 65 resource record way. This memo also gives a proposal about how to 66 avoid the possible phishing problem after putting the IDN TLD 67 variants into the root. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 72 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 73 2. IDN TLD Variant . . . . . . . . . . . . . . . . . . . . . . . 4 74 3. The principle of IDN TLD variants implementation . . . . . . . 5 75 4. IDN TLD variants implementation guideline . . . . . . . . . . 5 76 4.1. The requirement of the root server operation . . . . . . . 5 77 4.2. Apply DNAME to IDN TLD variants in the root . . . . . . . 5 78 4.2.1. DNAME issues . . . . . . . . . . . . . . . . . . . . . 6 79 4.2.2. DNAME should be scrutinized before being put into 80 the root . . . . . . . . . . . . . . . . . . . . . . . 7 81 4.3. Apply NS to IDN TLD variants in the root . . . . . . . . . 7 82 4.3.1. NS issues . . . . . . . . . . . . . . . . . . . . . . 7 83 4.3.2. Apply DNAME or NS to the second level names in the 84 IDN TLD variants . . . . . . . . . . . . . . . . . . . 7 85 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 86 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 87 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 88 8. Change History . . . . . . . . . . . . . . . . . . . . . . . . 9 89 8.1. draft-yao-dnsop-idntld-implementation: Version 00 . . . . 9 90 8.2. draft-yao-dnsop-idntld-implementation: Version 01 . . . . 10 91 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 92 9.1. Normative References . . . . . . . . . . . . . . . . . . . 10 93 9.2. Informative References . . . . . . . . . . . . . . . . . . 11 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 96 1. Introduction 98 ICANN is pushing the IDN TLD into the root server. Some IDN TLD has 99 the variants. Currently, there are two proposals to implement the 100 IDN TLD variants in the root servers:1, implement it with the DNAME 101 record; 2, implement it with NS record. The IDN TLD variants may be 102 reserved or activated. If IDN TLD variants are activated, these 103 variants will be allocated to the same TLD manager in order to avoid 104 the possible phishing problems. How to deal with the IDN TLD variant 105 issue is a big challenge ahead of us. This document discusses the 106 IDN TLD implementation issues related with DNAME and NS resource 107 record way. This memo also gives a proposal about how to avoid the 108 possible phishing problem after putting the IDN TLD variants into the 109 root. 111 1.1. Terminology 113 All the basic terms used in this specification are defined in the 114 documents [RFC1034], [RFC1035], [RFC2672], [RFC3490] and [RFC3743]. 115 Understanding of the [RFC2672] and [RFC3743] is necessary to 116 understand this document. In particular, the term "variant" is 117 defined in section 1.3.2 of [RFC4290]. the "normal domain name" is 118 the domain name which can be configured with the DNS Resource Record 119 directly. 121 2. IDN TLD Variant 123 In ASCII [ASCII] letters, the upper case "A" and lower case 'a' are 124 same in the meaning. In many cases, the upper case "A" and lower 125 case 'a' are exchangeable. We can regard the upper case "A" as the 126 variant of the lower case 'a'. In some languages, some characters 127 has the variants, which look differently or very similar but are 128 identical in the meaning. For example, Chinese character U+56FD and 129 its variant U+570B look differently, but are identical in the 130 meaning. If Internationalized Domain Label" or "IDL" [RFC3743] are 131 composed of variant characters, we regard this kind of IDL as the IDL 132 variant. If these IDL variants are put into the root, they are 133 regarded as the IDN TLD variants. For example, if the IDL "China" 134 (U+4E2D U+56FD) and its IDL variant (U+4E2D U+570B) are put into the 135 root, the first one (U+4E2D U+56FD) is called as the original IDN TLD 136 and the second one (U+4E2D U+570B) is called as the IDN TLD variant. 137 In ideal way, the original IDN TLD and its IDN TLD variant SHOULD be 138 identical in the DNS resolution. For example, the ".com" is 139 identical to ".COM" in the DNS resolution. Currently, we can not 140 find the ideal solution for the IDN TLD variants. Two proposals are 141 suggested to solve the problem: DNAME record and NS record. 143 3. The principle of IDN TLD variants implementation 145 Two principle of IDN TLD variants implementation are: 146 o Same DNS resolution to the names under the original IDN TLD and 147 its variants 148 o the same names under the original IDN TLD and its variants belong 149 to the same registrant 150 Any policy or technology SHOULD be used to guarantee that the IDN TLD 151 and its variant SHOULD belong to the same registry; the DNS 152 administrators SHOULD try their best to make the IDN TLD and its 153 variants be identical in the DNS resolution. There have 2 ways to 154 deal with it. In technique, the DNS operators may use some 155 technology to implement it; In policy, the DNS administrators can use 156 some management policy or some guideline to make the original IDN TLD 157 and its variants be identical in the DNS resolution. If the IDN TLD 158 and its variants are delegated to different registry, it will cause 159 phishing problems. In order to avoid the possible phishing, these 160 IDN TLDs SHOULD be delegated to the same registry. Based on the 161 current technology, there are two techniques: DNAME and NS records 162 which can be used in the IDN TLD variants implementation. The 163 following section will discuss the usage of DNAME and NS resource 164 records, and its relative policy to manage the IDN TLD and its 165 variants. 167 4. IDN TLD variants implementation guideline 169 4.1. The requirement of the root server operation 171 [RFC2870] points out that the resolution of domain names on the 172 internet is critically dependent on the proper, safe, and secure 173 operation of the root domain name servers while the root domain name 174 servers are seen as a crucial part of the correct, safe, reliable, 175 and secure operation of the internet infrastructure. The Internet 176 Corporation for Assigned Names and Numbers (ICANN) are responsible 177 for making the total system performance, robustness, and reliability 178 in the root name servers. So the root server should guarantee that 179 the server can run as stable as possible. Any change or update to 180 the root servers should be done in caution. 182 4.2. Apply DNAME to IDN TLD variants in the root 184 A DNAME record is defined in [RFC2672]. The main function of the 185 DNAME is to provide the redirection from a part of the DNS name tree 186 to another part of the DNS name tree. The following two characters 187 of DNAME can be considered to be two good arguments to support DNAME 188 to be applied to the IDN TLD variants in the root. 190 o redirection the whole sub-tree of the domain name tree to another 191 one 192 o DNAME does not direct itself (the owner name). 193 We can use the following configuration form: 195 < the IDN TLD variants > TTL IN DNAME < its original one > 197 If this model can be workable, DNAME can be considered as the 198 simplest mechanism to make the DNS resolution of the names in the 199 original IDN TLD and its variants to be same or identical. For the 200 IDN TLD operators, only one ZONE is needed to be kept instead of 201 multiple zones for the IDN TLD variants. The root helps the 202 direction of the DNS resolution of the IDN TLD variants to the 203 original IDN TLD. This method makes the DNS resolution of the 204 original IDN TLD and its variants to be identical via the root 205 solution. If DNAME is put into the root, some issues should be 206 considered. The following section will discuss these issues. 208 4.2.1. DNAME issues 210 4.2.1.1. DNAME is a new technology 212 The basic DNS documents [RFC1034] and [RFC1035] were defined in the 213 year of 1987 while the DNAME [RFC2672] was defined in the year of 214 1999. There are 12 years gap between them. So there are a lot of 215 legacy DNS applications which are unaware of DNAME. Some interesting 216 things may happen if DNAME is used. 218 4.2.1.2. Zero TTL 220 The section 4.1 of [RFC2672] specifies that the synthesized CNAME RR, 221 if provided, MUST have TTL equal to zero. It means that the DNAME- 222 unaware resolver will not cache this resource record. The DNAME- 223 unaware resolver will go to other servers to lookup the relative 224 answers every time when the DNAME record is involved. This will 225 cause much load to the servers which provide the DNAME service. The 226 [RFC2672bis] has updated it to " A CNAME RR with TTL equal to the 227 corresponding DNAME RR is synthesized and included in the answer 228 section for resolvers that did not indicate understanding of DNAME in 229 queries." In the current implementation based on [RFC2672], the TTL 230 for synthesized CNAME Resource record is 0, which means there will be 231 no cache in the resolvers. So every query from DNAME-unaware 232 resolvers has to go to the DNS servers which provide the DNAME 233 service. This will cause a big load to the DNAME DNS servers. 235 4.2.1.3. Mis-configuration 237 DNAME RFC specifies that resource records MUST NOT exist at any sub- 238 domain of the owner of a DNAME RR. Some DNS administrators may not 239 know it and still configure the RR in the sub-domain of the owner of 240 a DNAME RR, which may lead the failure resolving. The DNAMEed domain 241 name is not a normal domain name. The normal domain name itself can 242 be configured with the DNS resource record such as A or MX record. 243 Many DNS administrators will mis-configure it. The registrant of 244 this domain name may not understand the DNAME and regard the DNAMEed 245 domain name as the normal domain name. 247 4.2.2. DNAME should be scrutinized before being put into the root 249 If the DNAME is put into the root for the IDN TLD variants, the 250 synthesized CNAME RR for the DNAME has the TTL Zero according to 251 [RFC2672], which will cause too much load to the root servers since 252 many DNAME-unaware resolvers will not cache the synthesized CNAME RR 253 for the DNAME and lookup the messages from the root when they receive 254 the requests related to DNAME. The easy mis-configuration problem by 255 the DNS administrator is also a problem to make the DNS 256 administrators and the registrant be confused about the domain name 257 availability. Whether the issues discussed above will make the root 258 server running unreliable or unstable is unclear. So the ICANN 259 should scrutinize all the DNAME issues and consider whether these 260 will impact the stable running of the internet before deciding to put 261 the DNAME into the root. 263 4.3. Apply NS to IDN TLD variants in the root 265 4.3.1. NS issues 267 The NS record is defined in the basic DNS documents [RFC1034] and 268 [RFC1035]. NS resource record is deployed widely. The practice in 269 the root has proven that the NS resource record in the root is safe 270 and reliable. Putting the NS records in the root does not impact the 271 root much. If the IDN TLD variants are delegated via the NS resource 272 record way, the original IDN TLD and its variants can be delegated to 273 totally different servers. In the DNS zone, they are the different 274 delegation. In registration policy, the original IDN TLD and its IDN 275 TLD variants SHOULD be allocated to the same registry. 277 4.3.2. Apply DNAME or NS to the second level names in the IDN TLD 278 variants 280 If the NS resources records are used in the root for the IDN TLD 281 variants, some technology combined with some policy should be 282 applied. Whether DNAME or NS is used for the second level names in 283 the IDN TLD and its variants, the DNS administrator can consider the 284 three factors: 285 o Are IDN TLD variants often used or resolved by the internet users? 286 o IDN TLD DNS servers' performance? 287 o The DNS administrators' knowledge of DNAME? 289 4.3.2.1. Apply DNAME to the second level names in the IDN TLD variants 291 If some of the following criterias are satisfied, we can consider to 292 use the DNAME in the second level domain names. 293 o The names in the IDN TLD variants are seldom used or resolved by 294 the internet users 295 o The DNS servers' performance is good enough to support a lot of 296 resolution from the DNAME-unaware resolvers 297 o The DNS administrator has the knowledge of DNAME, and can 298 configure it properly 299 There are two ways to apply DNAME to the second level names in the 300 IDN TLD variants zone. 302 **Apply DNAME to all names 304 We can use the following configuration form in the zone apex of the 305 IDN TLD variants: 307 TTL IN DNAME 309 **Apply DNAME to the name which the registrant wants to be DNAMEed 311 We can use the following configuration form in the zone of the IDN 312 TLD variants: 314 TTL IN DNAME 316 If the second method is used, the other resource records except NS 317 DNAME records under the IDN TLD variants SHOULD be same with the 318 original IDN TLD in the DNS administration since the owner of DNAME 319 does not redirect itself. 321 4.3.2.2. Apply NS to the second level names in the IDN TLD variants 323 If some of the following criterias are satisfied, we can consider to 324 use the NS in the second level domain names. 325 o The IDN TLD variants are often used or resolved by the internet 326 users 327 o The DNS servers' performance is not good enough to support a lot 328 of resolution from the DNAME-unaware resolvers 330 o The DNS administrator has not the knowledge of DNAME, and can not 331 configure it properly 332 The same name under the original IDN TLD and its variants should 333 belong to the same registrant via some policy. In order to avoid the 334 possible phishing or confusing, the configuration of names under the 335 original IDN TLD and its variants SHOULD be same in the DNS 336 administration. That is that any parameters or configuration applied 337 to the names of the original IDN TLD SHOULD be available to the names 338 of its variants. This can guarantee that the resolutions in the IDN 339 TLD and its variants are identical. 341 5. IANA Considerations 343 There is no IANA consideration. 345 6. Security Considerations 347 If IDN TLD variants are implemented, this guideline is suggested to 348 be used to avoid the possible phishing. If we apply NS to the second 349 level names in the IDN TLD variants, we can not guarantee that every 350 level of domain names under the IDN TLD and its variants are 351 configured to be same. We can only specify some policy to make the 352 same name under the IDN TLD and its variants to be owned by the same 353 registrant. The registrant is unlikely to phishing itself via the 354 name under the IDN TLD and its variants. 356 7. Acknowledgements 358 Some ideas are discussed in the ICANN IDN variant working group. 359 Some nice comments are from Harald Alvestrand in this group. Thanks 360 a lot to Sun Guonian for his helpful discussion with me about DNAME 361 technology. The authors thanks the following experts for the kind 362 comments and suggestions to this draft: Andrew Sullivan, Paul 363 Hoffman, Alfred Hones and more. 365 8. Change History 367 [[anchor19: RFC Editor: Please remove this section.]] 369 8.1. draft-yao-dnsop-idntld-implementation: Version 00 371 o IDN TLD variants implementation guidelines 373 8.2. draft-yao-dnsop-idntld-implementation: Version 01 375 o adjust the sections arrangement 376 o change the category from BCP to INFO 377 o refine some contents based on the comments from DNSOP and DNSEXT 378 mailing list 380 9. References 382 9.1. Normative References 384 [ASCII] American National Standards Institute (formerly United 385 States of America Standards Institute), "USA Code for 386 Information Interchange", ANSI X3.4-1968, 1968. 388 [EDNS0] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", 389 RFC 2671, August 1999. 391 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 392 STD 13, RFC 1034, November 1987. 394 [RFC1035] Mockapetris, P., "Domain names - implementation and 395 specification", STD 13, RFC 1035, November 1987. 397 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 398 Requirement Levels", BCP 14, RFC 2119, March 1997. 400 [RFC2672] Crawford, M., "Non-Terminal DNS Name Redirection", 401 RFC 2672, August 1999. 403 [RFC2870] Bush, R., Karrenberg, D., Kosters, M., and R. Plzak, "Root 404 Name Server Operational Requirements", BCP 40, RFC 2870, 405 June 2000. 407 [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, 408 "Internationalizing Domain Names in Applications (IDNA)", 409 RFC 3490, March 2003. 411 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 412 10646", RFC 3629, November 2003. 414 [RFC3743] Konishi, K., Huang, K., Qian, H., and Y. Ko, "Joint 415 Engineering Team (JET) Guidelines for Internationalized 416 Domain Names (IDN) Registration and Administration for 417 Chinese, Japanese, and Korean", RFC 3743, April 2004. 419 [RFC4290] Klensin, J., "Suggested Practices for Registration of 420 Internationalized Domain Names (IDN)", RFC 4290, 421 December 2005. 423 9.2. Informative References 425 [RFC2672bis] 426 Rose, S. and W. Wijngaards, "Update to DNAME Redirection 427 in the DNS", Internet-Draft ietf-dnsext-rfc2672bis-dname- 428 17.txt, 6 2009. 430 Authors' Addresses 432 Jiankang YAO 433 CNNIC 434 No.4 South 4th Street, Zhongguancun 435 Beijing 437 Phone: +86 10 58813007 438 Email: yaojk@cnnic.cn 440 Xiaodong LEE 441 CNNIC 442 No.4 South 4th Street, Zhongguancun 443 Beijing 445 Phone: +86 10 58813020 446 Email: lee@cnnic.cn