Network Working Group J. Yao Internet-Draft X. Lee Intended status: Informational CNNIC Expires: April 25, 2010 October 22, 2009 IDN TLD Variants Implementation Guideline draft-yao-dnsop-idntld-implementation-01.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. 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 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. This Internet-Draft will expire on April 25, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Yao & Lee Expires April 25, 2010 [Page 1] Internet-Draft tld October 2009 Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract ICANN is pushing the IDN TLD into the root server. Some IDN TLD has the variants. Currently, there are two proposals to implement the IDN TLD variants in the root servers:1, implement it with the DNAME record; 2, implement it with NS record. The IDN TLD variants may be reserved or activated. If the IDN TLD variants are activated, these variants will be allocated to the same TLD manager in order to avoid the possible phishing problems. How to deal with the IDN TLD variant issue is a big challenge ahead of us. This document discusses the IDN TLD variants implementation issues related with DNAME and NS resource record way. This memo also gives a proposal about how to avoid the possible phishing problem after putting the IDN TLD variants into the root. Yao & Lee Expires April 25, 2010 [Page 2] Internet-Draft tld October 2009 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 2. IDN TLD Variant . . . . . . . . . . . . . . . . . . . . . . . 4 3. The principle of IDN TLD variants implementation . . . . . . . 5 4. IDN TLD variants implementation guideline . . . . . . . . . . 5 4.1. The requirement of the root server operation . . . . . . . 5 4.2. Apply DNAME to IDN TLD variants in the root . . . . . . . 5 4.2.1. DNAME issues . . . . . . . . . . . . . . . . . . . . . 6 4.2.2. DNAME should be scrutinized before being put into the root . . . . . . . . . . . . . . . . . . . . . . . 7 4.3. Apply NS to IDN TLD variants in the root . . . . . . . . . 7 4.3.1. NS issues . . . . . . . . . . . . . . . . . . . . . . 7 4.3.2. Apply DNAME or NS to the second level names in the IDN TLD variants . . . . . . . . . . . . . . . . . . . 7 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 8. Change History . . . . . . . . . . . . . . . . . . . . . . . . 9 8.1. draft-yao-dnsop-idntld-implementation: Version 00 . . . . 9 8.2. draft-yao-dnsop-idntld-implementation: Version 01 . . . . 10 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 9.1. Normative References . . . . . . . . . . . . . . . . . . . 10 9.2. Informative References . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 Yao & Lee Expires April 25, 2010 [Page 3] Internet-Draft tld October 2009 1. Introduction ICANN is pushing the IDN TLD into the root server. Some IDN TLD has the variants. Currently, there are two proposals to implement the IDN TLD variants in the root servers:1, implement it with the DNAME record; 2, implement it with NS record. The IDN TLD variants may be reserved or activated. If IDN TLD variants are activated, these variants will be allocated to the same TLD manager in order to avoid the possible phishing problems. How to deal with the IDN TLD variant issue is a big challenge ahead of us. This document discusses the IDN TLD implementation issues related with DNAME and NS resource record way. This memo also gives a proposal about how to avoid the possible phishing problem after putting the IDN TLD variants into the root. 1.1. Terminology All the basic terms used in this specification are defined in the documents [RFC1034], [RFC1035], [RFC2672], [RFC3490] and [RFC3743]. Understanding of the [RFC2672] and [RFC3743] is necessary to understand this document. In particular, the term "variant" is defined in section 1.3.2 of [RFC4290]. the "normal domain name" is the domain name which can be configured with the DNS Resource Record directly. 2. IDN TLD Variant In ASCII [ASCII] letters, the upper case "A" and lower case 'a' are same in the meaning. In many cases, the upper case "A" and lower case 'a' are exchangeable. We can regard the upper case "A" as the variant of the lower case 'a'. In some languages, some characters has the variants, which look differently or very similar but are identical in the meaning. For example, Chinese character U+56FD and its variant U+570B look differently, but are identical in the meaning. If Internationalized Domain Label" or "IDL" [RFC3743] are composed of variant characters, we regard this kind of IDL as the IDL variant. If these IDL variants are put into the root, they are regarded as the IDN TLD variants. For example, if the IDL "China" (U+4E2D U+56FD) and its IDL variant (U+4E2D U+570B) are put into the root, the first one (U+4E2D U+56FD) is called as the original IDN TLD and the second one (U+4E2D U+570B) is called as the IDN TLD variant. In ideal way, the original IDN TLD and its IDN TLD variant SHOULD be identical in the DNS resolution. For example, the ".com" is identical to ".COM" in the DNS resolution. Currently, we can not find the ideal solution for the IDN TLD variants. Two proposals are suggested to solve the problem: DNAME record and NS record. Yao & Lee Expires April 25, 2010 [Page 4] Internet-Draft tld October 2009 3. The principle of IDN TLD variants implementation Two principle of IDN TLD variants implementation are: o Same DNS resolution to the names under the original IDN TLD and its variants o the same names under the original IDN TLD and its variants belong to the same registrant Any policy or technology SHOULD be used to guarantee that the IDN TLD and its variant SHOULD belong to the same registry; the DNS administrators SHOULD try their best to make the IDN TLD and its variants be identical in the DNS resolution. There have 2 ways to deal with it. In technique, the DNS operators may use some technology to implement it; In policy, the DNS administrators can use some management policy or some guideline to make the original IDN TLD and its variants be identical in the DNS resolution. If the IDN TLD and its variants are delegated to different registry, it will cause phishing problems. In order to avoid the possible phishing, these IDN TLDs SHOULD be delegated to the same registry. Based on the current technology, there are two techniques: DNAME and NS records which can be used in the IDN TLD variants implementation. The following section will discuss the usage of DNAME and NS resource records, and its relative policy to manage the IDN TLD and its variants. 4. IDN TLD variants implementation guideline 4.1. The requirement of the root server operation [RFC2870] points out that the resolution of domain names on the internet is critically dependent on the proper, safe, and secure operation of the root domain name servers while the root domain name servers are seen as a crucial part of the correct, safe, reliable, and secure operation of the internet infrastructure. The Internet Corporation for Assigned Names and Numbers (ICANN) are responsible for making the total system performance, robustness, and reliability in the root name servers. So the root server should guarantee that the server can run as stable as possible. Any change or update to the root servers should be done in caution. 4.2. Apply DNAME to IDN TLD variants in the root A DNAME record is defined in [RFC2672]. The main function of the DNAME is to provide the redirection from a part of the DNS name tree to another part of the DNS name tree. The following two characters of DNAME can be considered to be two good arguments to support DNAME to be applied to the IDN TLD variants in the root. Yao & Lee Expires April 25, 2010 [Page 5] Internet-Draft tld October 2009 o redirection the whole sub-tree of the domain name tree to another one o DNAME does not direct itself (the owner name). We can use the following configuration form: < the IDN TLD variants > TTL IN DNAME < its original one > If this model can be workable, DNAME can be considered as the simplest mechanism to make the DNS resolution of the names in the original IDN TLD and its variants to be same or identical. For the IDN TLD operators, only one ZONE is needed to be kept instead of multiple zones for the IDN TLD variants. The root helps the direction of the DNS resolution of the IDN TLD variants to the original IDN TLD. This method makes the DNS resolution of the original IDN TLD and its variants to be identical via the root solution. If DNAME is put into the root, some issues should be considered. The following section will discuss these issues. 4.2.1. DNAME issues 4.2.1.1. DNAME is a new technology The basic DNS documents [RFC1034] and [RFC1035] were defined in the year of 1987 while the DNAME [RFC2672] was defined in the year of 1999. There are 12 years gap between them. So there are a lot of legacy DNS applications which are unaware of DNAME. Some interesting things may happen if DNAME is used. 4.2.1.2. Zero TTL The section 4.1 of [RFC2672] specifies that the synthesized CNAME RR, if provided, MUST have TTL equal to zero. It means that the DNAME- unaware resolver will not cache this resource record. The DNAME- unaware resolver will go to other servers to lookup the relative answers every time when the DNAME record is involved. This will cause much load to the servers which provide the DNAME service. The [RFC2672bis] has updated it to " A CNAME RR with TTL equal to the corresponding DNAME RR is synthesized and included in the answer section for resolvers that did not indicate understanding of DNAME in queries." In the current implementation based on [RFC2672], the TTL for synthesized CNAME Resource record is 0, which means there will be no cache in the resolvers. So every query from DNAME-unaware resolvers has to go to the DNS servers which provide the DNAME service. This will cause a big load to the DNAME DNS servers. Yao & Lee Expires April 25, 2010 [Page 6] Internet-Draft tld October 2009 4.2.1.3. Mis-configuration DNAME RFC specifies that resource records MUST NOT exist at any sub- domain of the owner of a DNAME RR. Some DNS administrators may not know it and still configure the RR in the sub-domain of the owner of a DNAME RR, which may lead the failure resolving. The DNAMEed domain name is not a normal domain name. The normal domain name itself can be configured with the DNS resource record such as A or MX record. Many DNS administrators will mis-configure it. The registrant of this domain name may not understand the DNAME and regard the DNAMEed domain name as the normal domain name. 4.2.2. DNAME should be scrutinized before being put into the root If the DNAME is put into the root for the IDN TLD variants, the synthesized CNAME RR for the DNAME has the TTL Zero according to [RFC2672], which will cause too much load to the root servers since many DNAME-unaware resolvers will not cache the synthesized CNAME RR for the DNAME and lookup the messages from the root when they receive the requests related to DNAME. The easy mis-configuration problem by the DNS administrator is also a problem to make the DNS administrators and the registrant be confused about the domain name availability. Whether the issues discussed above will make the root server running unreliable or unstable is unclear. So the ICANN should scrutinize all the DNAME issues and consider whether these will impact the stable running of the internet before deciding to put the DNAME into the root. 4.3. Apply NS to IDN TLD variants in the root 4.3.1. NS issues The NS record is defined in the basic DNS documents [RFC1034] and [RFC1035]. NS resource record is deployed widely. The practice in the root has proven that the NS resource record in the root is safe and reliable. Putting the NS records in the root does not impact the root much. If the IDN TLD variants are delegated via the NS resource record way, the original IDN TLD and its variants can be delegated to totally different servers. In the DNS zone, they are the different delegation. In registration policy, the original IDN TLD and its IDN TLD variants SHOULD be allocated to the same registry. 4.3.2. Apply DNAME or NS to the second level names in the IDN TLD variants If the NS resources records are used in the root for the IDN TLD variants, some technology combined with some policy should be applied. Whether DNAME or NS is used for the second level names in Yao & Lee Expires April 25, 2010 [Page 7] Internet-Draft tld October 2009 the IDN TLD and its variants, the DNS administrator can consider the three factors: o Are IDN TLD variants often used or resolved by the internet users? o IDN TLD DNS servers' performance? o The DNS administrators' knowledge of DNAME? 4.3.2.1. Apply DNAME to the second level names in the IDN TLD variants If some of the following criterias are satisfied, we can consider to use the DNAME in the second level domain names. o The names in the IDN TLD variants are seldom used or resolved by the internet users o The DNS servers' performance is good enough to support a lot of resolution from the DNAME-unaware resolvers o The DNS administrator has the knowledge of DNAME, and can configure it properly There are two ways to apply DNAME to the second level names in the IDN TLD variants zone. **Apply DNAME to all names We can use the following configuration form in the zone apex of the IDN TLD variants: TTL IN DNAME **Apply DNAME to the name which the registrant wants to be DNAMEed We can use the following configuration form in the zone of the IDN TLD variants: TTL IN DNAME If the second method is used, the other resource records except NS DNAME records under the IDN TLD variants SHOULD be same with the original IDN TLD in the DNS administration since the owner of DNAME does not redirect itself. 4.3.2.2. Apply NS to the second level names in the IDN TLD variants If some of the following criterias are satisfied, we can consider to use the NS in the second level domain names. o The IDN TLD variants are often used or resolved by the internet users o The DNS servers' performance is not good enough to support a lot of resolution from the DNAME-unaware resolvers Yao & Lee Expires April 25, 2010 [Page 8] Internet-Draft tld October 2009 o The DNS administrator has not the knowledge of DNAME, and can not configure it properly The same name under the original IDN TLD and its variants should belong to the same registrant via some policy. In order to avoid the possible phishing or confusing, the configuration of names under the original IDN TLD and its variants SHOULD be same in the DNS administration. That is that any parameters or configuration applied to the names of the original IDN TLD SHOULD be available to the names of its variants. This can guarantee that the resolutions in the IDN TLD and its variants are identical. 5. IANA Considerations There is no IANA consideration. 6. Security Considerations If IDN TLD variants are implemented, this guideline is suggested to be used to avoid the possible phishing. If we apply NS to the second level names in the IDN TLD variants, we can not guarantee that every level of domain names under the IDN TLD and its variants are configured to be same. We can only specify some policy to make the same name under the IDN TLD and its variants to be owned by the same registrant. The registrant is unlikely to phishing itself via the name under the IDN TLD and its variants. 7. Acknowledgements Some ideas are discussed in the ICANN IDN variant working group. Some nice comments are from Harald Alvestrand in this group. Thanks a lot to Sun Guonian for his helpful discussion with me about DNAME technology. The authors thanks the following experts for the kind comments and suggestions to this draft: Andrew Sullivan, Paul Hoffman, Alfred Hones and more. 8. Change History [[anchor19: RFC Editor: Please remove this section.]] 8.1. draft-yao-dnsop-idntld-implementation: Version 00 o IDN TLD variants implementation guidelines Yao & Lee Expires April 25, 2010 [Page 9] Internet-Draft tld October 2009 8.2. draft-yao-dnsop-idntld-implementation: Version 01 o adjust the sections arrangement o change the category from BCP to INFO o refine some contents based on the comments from DNSOP and DNSEXT mailing list 9. References 9.1. Normative References [ASCII] American National Standards Institute (formerly United States of America Standards Institute), "USA Code for Information Interchange", ANSI X3.4-1968, 1968. [EDNS0] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, August 1999. [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987. [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2672] Crawford, M., "Non-Terminal DNS Name Redirection", RFC 2672, August 1999. [RFC2870] Bush, R., Karrenberg, D., Kosters, M., and R. Plzak, "Root Name Server Operational Requirements", BCP 40, RFC 2870, June 2000. [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, "Internationalizing Domain Names in Applications (IDNA)", RFC 3490, March 2003. [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 3629, November 2003. [RFC3743] Konishi, K., Huang, K., Qian, H., and Y. Ko, "Joint Engineering Team (JET) Guidelines for Internationalized Domain Names (IDN) Registration and Administration for Chinese, Japanese, and Korean", RFC 3743, April 2004. [RFC4290] Klensin, J., "Suggested Practices for Registration of Yao & Lee Expires April 25, 2010 [Page 10] Internet-Draft tld October 2009 Internationalized Domain Names (IDN)", RFC 4290, December 2005. 9.2. Informative References [RFC2672bis] Rose, S. and W. Wijngaards, "Update to DNAME Redirection in the DNS", Internet-Draft ietf-dnsext-rfc2672bis-dname- 17.txt, 6 2009. Authors' Addresses Jiankang YAO CNNIC No.4 South 4th Street, Zhongguancun Beijing Phone: +86 10 58813007 Email: yaojk@cnnic.cn Xiaodong LEE CNNIC No.4 South 4th Street, Zhongguancun Beijing Phone: +86 10 58813020 Email: lee@cnnic.cn Yao & Lee Expires April 25, 2010 [Page 11]