idnits 2.17.1 draft-yao-bundled-name-problem-statement-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 date (October 27, 2016) is 2736 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3490 (Obsoleted by RFC 5890, RFC 5891) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). 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 30, 2017 J. Levine 6 Taughannock Networks 7 October 27, 2016 9 Problem Statement for Fully Mapping One Name to Another Name 10 draft-yao-bundled-name-problem-statement-03.txt 12 Abstract 14 This document specifies the problems related to fully mapping one 15 name to another name. With the emergence of internationalized domain 16 names and new TLDs, it is often useful to redirect one domain name 17 tree fully to another domain name tree. Current DNS protocols have 18 not provided such ability to satisfy these requirements. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 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 This Internet-Draft will expire on April 30, 2017. 37 Copyright Notice 39 Copyright (c) 2016 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 1.1. Use Case 1: Bundled domain names . . . . . . . . . . . . 2 56 1.2. Usee Case 2: a company registers the same label in 57 different TLDs. . . . . . . . . . . . . . . . . . . . . . 3 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 60 3.1. Mapping a single name itself . . . . . . . . . . . . . . 3 61 3.2. Mapping a name's descendants . . . . . . . . . . . . . . 3 62 3.3. Mapping a name and and its descendants . . . . . . . . . 4 63 3.4. Cloning a zone . . . . . . . . . . . . . . . . . . . . . 4 64 4. Application handling of bundled names . . . . . . . . . . . . 4 65 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 66 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 67 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 68 8. Change History . . . . . . . . . . . . . . . . . . . . . . . 5 69 8.1. draft-yao-bundled-name-problem-statement: Version 00 . . 5 70 8.2. draft-yao-bundled-name-problem-statement: Version 01 . . 5 71 8.3. draft-yao-bundled-name-problem-statement: Version 02 . . 5 72 8.4. draft-yao-bundled-name-problem-statement: Version 03 . . 5 73 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 74 9.1. Normative References . . . . . . . . . . . . . . . . . . 6 75 9.2. Informative References . . . . . . . . . . . . . . . . . 6 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 78 1. Introduction 80 With the emergence of internationalized domain names and new TLDs, 81 two names may be used to identify the same thing. In this case, it 82 use useful to redirect one name space fully to another name space. 83 There are many use cases for it. Some examples are shown below. 85 1.1. Use Case 1: Bundled domain names 87 Bundled domain names share the same TLD but their second level labels 88 are variants, or have identical second level labels in specific TLDs. 89 For example, Public Interest Registry, has implemented technical 90 bundling of second level domains in .NGO and .ONG. So we have two 91 kinds of bundled domain names. The first one is of the form 92 "V-label.TLD" in which the second level labels (V-label) are varants 93 sharing the same TLD; The second one is of the form "LABEL.V-tld" in 94 which the second level labels (LABEL) are the same, but in different 95 TLDs (V-tld). Bundled domain names usually need to map themselves 96 and their descendants together. 98 For example: 100 example.com == example.net same label ending with different TLDs 102 color.com == colour.com different labels ending with the same TLD 104 1.2. Usee Case 2: a company registers the same label in different TLDs. 106 With the emergence growth of gTLDs, it is very common for a 107 registrant to register one label under many TLDs, but the registrant 108 may just use one label under one TLD as the primary domain name, with 109 others less important. The registrant may want to have all these 110 domain names share similar or the same DNS resolution. So the DNS 111 administrator wants a convenient method to configure these domain 112 names in DNS. 114 2. Terminology 116 All the basic terms used in this specification are defined in the 117 documents [RFC1034], [RFC1035], [RFC3490]and [RFC6672]. 119 3. Problem Statement 121 With the emergence of internationalized domain names and new TLDs, a 122 DNS operator often wishes to redirect one name space fully to another 123 name space. A CNAME record can in some cases map a single name to 124 another single name. If one domain name is mapped another domain 125 name, the CNAME will be used for that name. A DNAME can map a name's 126 descndants to descendants of another domain. If we want to map both 127 a name and its descendats, there's no way to do so with current 128 protocols. We need to design a mechanism to deal with this 129 requirement. 131 3.1. Mapping a single name itself 133 A host can have many names. The Internet users need these multiple 134 names to be resolved to the same IP address by a DNS server. CNAME 135 record [RFC1034], an abbreviation of Canonical Name Records, is 136 responsible for the aliases of the real host name of a computer. In 137 some cases, the CNAME can work for these bundled domain names. But 138 the CNAME only maps itself, not its descendants. The bundled names 139 need to map both the name and its variants. 141 3.2. Mapping a name's descendants 143 In order to maintain the address-to-name mappings in a context of 144 network renumbering, a DNAME record or Delegation Name record defined 145 by [RFC6672] creates an alias for all of a name's subdomains. In 146 contrast, the CNAME record creates an alias only of a single name 147 (and not of its subdomains). Like the CNAME record, the DNS lookup 148 will continue by retrying the lookup with the new name. 150 A DNAME record is very much like a CNAME record, but while the CNAME 151 record only applies for one name, with a DNAME record one can create 152 aliases for all the the names in its sudbomains. 154 3.3. Mapping a name and and its descendants 156 The bundle of variant domain names requires mapping of a whole tree 157 of the domain space to another domain. The current DNS protocols do 158 not support this function. 160 3.4. Cloning a zone 162 A mechanism for processing master files or their equivalent in a DNS 163 server could direct that server to exactly replicate the content of a 164 DNS zone into one or more other DNS zones so that the content is 165 reachable by multiple names at different zone apexes. A problem for 166 this method is that it cannot deal with child names that are 167 delegated. 169 4. Application handling of bundled names 171 Even if the DNS publishes records for all of the names in a bundle, 172 applications frequently do not work because they do not recognize the 173 names. One of the authors sampled names in the .CAT top-level- 174 domain, which uses DNAME records to map versions of domain names with 175 accented characters to the unaccented version. In most cases, web 176 servers returned an error page or a default page for the accented 177 versions of names, because they were not configured to recognize 178 those names. 180 It would be techincally straightforward in many cases for servers to 181 automatically configure themselves to handle variant names. for 182 example, if a web server received a request with an unrecognized 183 name, it could do a DNS lookup on the name and if it found, say, a 184 BNAME record, it could treat the request as equivalent to a request 185 to the target of the BNAME. 187 This introduces security issues, described below. 189 5. IANA Considerations 191 There is no IANA consideration. 193 6. Security Considerations 195 The CNAME, DNAME, and proposed BNAME records [BNAME] all provide the 196 ability to make a name or set of names "the same" as target names 197 without cooperation or permission from the target. This could allow 198 a malicious party to point a deceptive or misleading name at an 199 innocent victim name. If applications automatically configured 200 themselves to handle BNAMEs, this could create inadvertently 201 deceptive web sites. 203 The CLONE record largely avoids this problem, since the set of alias 204 names is under control of the owner of the target names. 206 7. Acknowledgements 208 Many ideas are from the discussion in the DNSOP and DNSEXT mailling 209 list. Thanks a lot to all in the list. Many important comments and 210 suggestions are contributed by many members of the DNSEXT and DNSOP 211 WG. Yoshiro YONEYA and Paul Hoffman help to review this document and 212 gives good comments. 214 8. Change History 216 [[CREF1: RFC Editor: Please remove this section.]] 218 8.1. draft-yao-bundled-name-problem-statement: Version 00 220 o Problem Statement for Fully Mapping One Name to Another Name 222 8.2. draft-yao-bundled-name-problem-statement: Version 01 224 o Adding section "Application handling of bundled names" 226 o Adding section "Security Considerations" 228 o Refine the text 230 8.3. draft-yao-bundled-name-problem-statement: Version 02 232 o Refine the text 234 8.4. draft-yao-bundled-name-problem-statement: Version 03 236 o Refine use cases and the text 238 9. References 240 9.1. Normative References 242 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 243 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 244 . 246 [RFC1035] Mockapetris, P., "Domain names - implementation and 247 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 248 November 1987, . 250 [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, 251 "Internationalizing Domain Names in Applications (IDNA)", 252 RFC 3490, DOI 10.17487/RFC3490, March 2003, 253 . 255 [RFC6672] Rose, S. and W. Wijngaards, "DNAME Redirection in the 256 DNS", RFC 6672, DOI 10.17487/RFC6672, June 2012, 257 . 259 9.2. Informative References 261 [BNAME] Yao, J., Lee, X., and P. Vixie, "Bundle DNS Name 262 Redirection", draft-yao-dnsext-bname-06.txt (work in 263 progress), 05 2016. 265 Authors' Addresses 267 Jiankang YAO 268 CNNIC 269 No.4 South 4th Street, Zhongguancun 270 Beijing 272 Phone: +86 10 58813007 273 Email: yaojk@cnnic.cn 275 Xiaodong LEE 276 CNNIC 277 No.4 South 4th Street, Zhongguancun 278 Beijing 280 Phone: +86 10 58813020 281 Email: xl@cnnic.cn 282 John Levine 283 Taughannock Networks 284 PO Box 727 285 Trumansburg, NY 14886 287 Phone: +1 831 480 2300 288 Email: standards@taugh.com