Network Working Group J. Yao Internet-Draft X. Lee Intended status: Informational CNNIC Expires: August 5, 2010 February 1, 2010 Problem Statement for Identical DNS Resolution of Bundle Names draft-yao-dnsext-identical-resolution-00.txt Abstract This document specifies the problems related to the identical resolution of bundle DNS names. With the emergence of internationalized domain names, two names with the same meaning or visual similarity sometimes require the identical resolution. Current DNS protocols have not provided such ability to satisfy these requirements. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. 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 August 5, 2010. Copyright Notice Copyright (c) 2010 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 Provisions Relating to IETF Documents Yao & Lee Expires August 5, 2010 [Page 1] Internet-Draft bname February 2010 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. 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. Yao & Lee Expires August 5, 2010 [Page 2] Internet-Draft bname February 2010 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Character Variants . . . . . . . . . . . . . . . . . . . . 3 2.2. Registration of Domain Name Variants . . . . . . . . . . . 4 2.3. Identical DNS Resolution for Bundle DNS Names . . . . . . . 4 3. Possible Solutions . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Mapping or Redirection of Domain Names . . . . . . . . . . 5 3.1.1. Mapping itself . . . . . . . . . . . . . . . . . . . . 5 3.1.2. Mapping its descendants . . . . . . . . . . . . . . . . 5 3.1.3. Mapping itself and its descendants . . . . . . . . . . 5 3.2. Zone Clone . . . . . . . . . . . . . . . . . . . . . . . . 6 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 7. Change History . . . . . . . . . . . . . . . . . . . . . . . . 6 7.1. draft-yao-dnsext-identical-resolution-problem-statement Version 00 . . . . . . . . . . . . . . . . . . . . . . . . 6 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 8.1. Normative References . . . . . . . . . . . . . . . . . . . 6 8.2. Informative References . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 Yao & Lee Expires August 5, 2010 [Page 3] Internet-Draft bname February 2010 1. Introduction If one domain name is the alias of another domain name, the CNAME will be used for that name. If the name wants to map its descendants to other domain, the DNAME will be used. If the name wants to map itself and its descendants to another domain, what should we do. The current protocols do not support to do so. There can have a lot of names under the DNS zones. Some of these names are very similar. The DNS was designed under the environment of ASCII characters, but the naming similarity in English is not very popular; the requirements of identical resolution of these names does not cause the attentions of the IETF DNS engineers. With the internationalized domain names protocols publishing in 2006 and updating in 2008, more and more internationalized domain name labels [RFC3490] appear in the DNS trees. Some labels [RFC3743] are equivalent in some languages. For examples: For English speak users, color and colour are same; For Chinese speak users, Chinese character U+56FD and its variant U+570B look differently, but are identical in the meaning. The Internet users hope them to be identical in the DNS resolution. For example, color.exmaple.com==colour.example.com. On the other hand, ICANN's "Final Implementation Plan for IDN ccTLD Fast Track Process" said that the desired IDN TLD variants will be allocated, and may be put into the root. ICANN currently does not find the perfect technical solution to put 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] and [RFC3490]. 2. Problem Statement 2.1. Character Variants Many languages have the character variants. Although there is no uniform definition of variants, the variants are popular in many languages. The definition of variant characters in the JET Guidelines [RFC3743]: One conceptual character can be identified with several different Code Points in character sets for computer use. In UNICODE, Some characters can be identified as the compatibility variants of another character, which usually implies that the first can be remapped to the second without the loss of any meaning. In this document, variant characters are two or more characters that may be similar in appearance or identical in meaning. ICANN is pushing the IDN TLD into the root server. Some IDN TLD has the variants. How to deal with the IDN TLD variant issue is a big challenge ahead of us. For example, if the IDN TLD "China" (U+4E2D U+56FD) and its Yao & Lee Expires August 5, 2010 [Page 4] Internet-Draft bname February 2010 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 an ideal way, the original IDN TLD and its IDN TLD variant SHOULD be identical in the DNS resolution. If case mapping is regarded as the variant, the uppercase A is the variant of lowercase a. For example, the ".COM" is the variant of ".com". These variants need to be identical in the DNS resolution, which has been done so in the DNS protocols. However, we can not find the ideal solution of identical DNS resolution for the IDN TLD variants. 2.2. Registration of Domain Name Variants With the development of internationalized domain names protocols, more and more domain names and their variants appear in the Internet. Without careful management of the domain name variants, there will have more phising related security problems. [RFC3743] developed by JET (Joint Engineering Team) gives a solution of how to manage the registration of domain name and its variants. [RFC3743] proposed an algorithm which will allocate the domain name and its variants to the same domain holder. It means that the domain holder will get the bundle of the domain name and its variants. [RFC4290] suggests the practice in [RFC3743] to be used in registrations of internationalized domain names. But [RFC3743] and [RFC4290] do not define how these bundle of names get the identical DNS resolution. [RFC4690] said that the "variant" model introduced in [RFC3743] and [RFC4290] can be used by a registry to prevent the worst consequence of the possible confusion, by ensuring either that both names are registered to the same party in a given domain or that one of them is completely prohibited. The principle of [RFC3743], [RFC4290] and [RFC4690] have been accepted by many registries. In the technology level, we can not guarantee that these bundle of domain names get the identical DNS resolution. 2.3. Identical DNS Resolution for Bundle DNS Names Identical DNS Resolution means that two domain names will finally get the same result, in most cases the same IP address. The Internet users hope that the domain names and its variants to be identical in DNS resolution. In the history of DNS protocol development, there has already two kinds of identical resolution:CNAME[RFC1034] which maps or redirects itself and DNAME[RFC2672] which maps or redirects its descendants. In the case of bundle Names, identical DNS resolution of all levels' domain names including the domain name itself and its descendants are expected. Current technologies do not allow to do so. Some suggestions trying to use the current technology are proposed in the draft of "IDN TLD Variants Implementation Guideline" [IDN-TLD-Variants], but this is a mechanism Yao & Lee Expires August 5, 2010 [Page 5] Internet-Draft bname February 2010 of combination of both technology and policy, which is not a perfect solution. 3. Possible Solutions Currently, there are two possible solutions to the identical DNS resolution of bundle names: Bundle Names direction[BNAME] and Zone clone. Both solutions have their advantages and disadvantages. The implementers may select one of them to be used 3.1. Mapping or Redirection of Domain Names 3.1.1. Mapping itself A host can have many names. The Internet users need these multiple names to be resolved to the same IP address by a DNS server. CNAME record [RFC1034], an abbreviation of Canonical Name Records, is responsible for the aliases of the real host name of a computer. In some cases, the CNAME can work for these bundle of variant domain names. But the CNAME only maps itself, not its descendants. In the case of IDN TLD variants, IDN TLD variants need to map itself and its variants. 3.1.2. Mapping its descendants In order to maintain the address-to-name mappings in a context of network renumbering, a DNAME record or Delegation Name record defined by [RFC2672] creates an alias for all its subdomains. In contrast, the CNAME record creates an alias only of a single name (and not of its subdomains). Like the CNAME record, the DNS lookup will continue by retrying the lookup with the new name. If a DNS resolver sends a query without EDNS[EDNS0], or with EDNS version 0, then a name server synthesizes a CNAME record to simulate the semantics of the DNAME record. A DNAME record is very much alike the CNAME record, but while the CNAME record only applies for one name, with a DNAME record one can create alias for all the records for its sudbomain. 3.1.3. Mapping itself and its descendants The bundle of variant domain names requires to map the whole tree of the domain space to another domain. The current DNS protocols do not support this function. A new DNS resource record [BNAME] may be invented to deal with this problem. Yao & Lee Expires August 5, 2010 [Page 6] Internet-Draft bname February 2010 3.2. Zone Clone Zone Clone proposed by Paul Vixie from Internet Software Consortium is an alternative solution to getting the identical DNS resolution of bundle domain names. 4. IANA Considerations There is no IANA consideration. 5. Security Considerations There may have more disscussions related to DNSSEC [RFC4033], [RFC4034] and [RFC4035]in the future version. 6. Acknowledgements Many ideas are from the discussion in the DNSOP and DNSEXT mailling list. Thanks a lot to all in the list. Many important comments and suggestions are contributed by many members of the DNSEXT and DNSOP WG. 7. Change History [[anchor15: RFC Editor: Please remove this section.]] 7.1. draft-yao-dnsext-identical-resolution: Version 00 o Domain Name Identical Resolution Problem Statement 8. References 8.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", Yao & Lee Expires August 5, 2010 [Page 7] Internet-Draft bname February 2010 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. [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April 1997. [RFC2672] Crawford, M., "Non-Terminal DNS Name Redirection", RFC 2672, August 1999. [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, "Internationalizing Domain Names in Applications (IDNA)", RFC 3490, March 2003. [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record (RR) Types", RFC 3597, September 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. [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005. [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, March 2005. [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, March 2005. [RFC4290] Klensin, J., "Suggested Practices for Registration of Internationalized Domain Names (IDN)", RFC 4290, December 2005. [RFC4690] Klensin, J., Faltstrom, P., Karp, C., and IAB, "Review and Recommendations for Internationalized Domain Names Yao & Lee Expires August 5, 2010 [Page 8] Internet-Draft bname February 2010 (IDNs)", RFC 4690, September 2006. 8.2. Informative References [BNAME] Yao, J., Lee, X., and P. Vixie, "Bundle DNS Name Redirection", draft-yao-dnsext-bname-01.txt (work in progress), 12 2009. [IDN-TLD-Variants] Yao, J. and X. Lee, "IDN TLD Variants Implementation Guideline", draft-yao-dnsop-idntld-implementation-01.txt (work in progress), 11 2009. [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 August 5, 2010 [Page 9]