Network Working Group J. Yao Internet-Draft X. Lee Intended status: Informational CNNIC Expires: January 2, 2017 July 1, 2016 Problem Statement for Fully Mapping One Name to Another Name draft-yao-bundled-name-problem-statement-00.txt Abstract This document specifies the problems related to fully mapping one name to another name. With the emergence of internationalized domain names and new TLDs, two names may require to redirect one name space fully to another name space. Current DNS protocols have not provided such ability to satisfy these requirements. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on January 2, 2017. Copyright Notice Copyright (c) 2016 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 (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 Simplified BSD License. Yao & Lee Expires January 2, 2017 [Page 1] Internet-Draft bname July 2016 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 3.1. Mapping itself . . . . . . . . . . . . . . . . . . . . . 3 3.2. Mapping its descendants . . . . . . . . . . . . . . . . . 4 3.3. Mapping itself and its descendants . . . . . . . . . . . 4 3.4. Zone Clone . . . . . . . . . . . . . . . . . . . . . . . 4 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 7. Change History . . . . . . . . . . . . . . . . . . . . . . . 5 7.1. draft-yao-bundled-name-problem-statement: Version 00 . . 5 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 8.1. Normative References . . . . . . . . . . . . . . . . . . 5 8.2. Informative References . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction With the emergence of internationalized domain names and new TLDs, two names used for the same purpose may require to redirect one name space fully to another name space. There are many use cases for it. Some examples are shown below. Use Case 1: Bundled domain names Bundled domain names are those who share the same TLD but whose second level labels are variants, or those who has identical second level labels for which certain parameters are shared in the different TLDs. For example, public Interest Registry, request to implement technical bundling of second level domains for .NGO and .ONG. So we have two kinds of bundled domain names. First one is in the form of "V-label.TLD" in which the second level labels (V-label) are varants sharing the same TLD; Second one is in the form of "LABEL.V-tld" in which the second level labels(LABEL) are same with the different TLDs Yao & Lee Expires January 2, 2017 [Page 2] Internet-Draft bname July 2016 (V-tld). Bundled domain names usually need to map itself and its descendants to another. for examples: example.com == example.net same label ending with different TLDs color.com == colour.com different labels ending with the same TLD Use Case 2: any two domain names One company registers 2 domain names, A and B. A needs to map itself and its descendants to B in order to have a easy manangement. for examples: example1.com == example2.net Use Case 3: a company register the same label in different TLDs. With the emergence growth of gTLDs, it is very common to register one label under many TLDs for the same purpose. but the comany may just use one label under one TLD as the primary domain name, others as the less important one. The company may want to have all these domain names share the similar/same DNS resolution results. So the DNS administrator hopes to have some convinient method to configure these domain names in DNS. 2. Terminology All the basic terms used in this specification are defined in the documents [RFC1034], [RFC1035], [RFC6672] and [RFC3490]. 3. Problem Statement With the emergence of internationalized domain names and new TLDs, two names require to redirect one name space fully to another name space. If one domain name wants to map itself to 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. We need to design a mechanism to deal with this requirement. 3.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 bundled domain names. But the CNAME only maps itself, not its descendants. The bundled names need to map both itself and its variants. Yao & Lee Expires January 2, 2017 [Page 3] Internet-Draft bname July 2016 3.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 [RFC6672] 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. 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.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. BNAME has been discussed a lot in the past years. One reason to be halted is how to make BNAME to be compatible with DNSSEC. Some experts from DNSEXT suggested that this document should be moved to the new WG for furhter discussion. The new version of BNAME has been updated to be compatible with DNSSEC. 3.4. Zone Clone Zone Clone was proposed in the past, which suggests to exactly replicate the content of a DNS zone into one or more other DNS zones so that the content is reachable by multiple names at different zone apexes. The problem for zone clone is that it can not deal with the children names which are delegated. 4. IANA Considerations There is no IANA consideration. 5. Security Considerations TBD 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. Yoshiro YONEYA helps to review this document and gives good comments. Yao & Lee Expires January 2, 2017 [Page 4] Internet-Draft bname July 2016 7. Change History [[CREF1: RFC Editor: Please remove this section.]] 7.1. draft-yao-bundled-name-problem-statement: Version 00 o Problem Statement for Fully Mapping One Name to Another Name 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. [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, . [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [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, DOI 10.17487/RFC3743, April 2004, . [RFC4290] Klensin, J., "Suggested Practices for Registration of Internationalized Domain Names (IDN)", RFC 4290, DOI 10.17487/RFC4290, December 2005, . Yao & Lee Expires January 2, 2017 [Page 5] Internet-Draft bname July 2016 [RFC6672] Rose, S. and W. Wijngaards, "DNAME Redirection in the DNS", RFC 6672, DOI 10.17487/RFC6672, June 2012, . 8.2. Informative References [BNAME] Yao, J., Lee, X., and P. Vixie, "Bundle DNS Name Redirection", draft-yao-dnsext-bname-06.txt (work in progress), 12 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 January 2, 2017 [Page 6]