idnits 2.17.1 draft-bortzmeyer-bundled-signaling-alias-00.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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 14, 2016) is 2717 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 255 Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Bortzmeyer 3 Internet-Draft AFNIC 4 Intended status: Informational November 14, 2016 5 Expires: May 18, 2017 7 Signaling that a domain name is an alias of another one 8 draft-bortzmeyer-bundled-signaling-alias-00 10 Abstract 12 This document suggests a light-weight and semantics-free way to 13 signal, in the DNS itself, that a domain name is actually an alias of 14 another one (and therefore that they are member of the same bundle). 16 REMOVE BEFORE PUBLICATION: this document should be discussed in the 17 dnsbundled maiing list . The source of the document, as well as a list 19 of open issues, is currently kept at Github [1]. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on May 18, 2017. 38 Copyright Notice 40 Copyright (c) 2016 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction and background . . . . . . . . . . . . . . . . . 2 56 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. The ALIAS RR type . . . . . . . . . . . . . . . . . . . . . . 3 58 3. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 4. Reverse aliasing . . . . . . . . . . . . . . . . . . . . . . 4 60 5. Deployability . . . . . . . . . . . . . . . . . . . . . . . . 4 61 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 62 7. Security Considerations . . . . . . . . . . . . . . . . . . . 4 63 8. Implementation status - RFC EDITOR: REMOVE BEFORE PUBLICATION 5 64 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5 65 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 10.1. Normative References . . . . . . . . . . . . . . . . . . 5 67 10.2. Informative References . . . . . . . . . . . . . . . . . 5 68 10.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 6 69 Appendix A. A TXT alternative to the new RR type . . . . . . . . 6 70 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 72 1. Introduction and background 74 There are often requests that a domain name be regarded as a mere 75 alias for another one, so it can be substituted by this another 76 domain. The reasons to do so are many 77 [I-D.yao-bundled-name-problem-statement] and not discussed here. 79 The problem is much more complicated than it seems and it is 80 difficult to imagine a solution that will satisfy every use case. We 81 do not attempt to define such a solution. Instead, we choose the 82 path of least resistance and propose just to signal, in the DNS, this 83 "aliasing" relationship. This signaling is not accompanied by a 84 specification of the semantics of this relationship, and this is a 85 deliberate design decision. 87 Existing solutions are insufficient: CNAMEs ([RFC1034], section 88 3.6.2) only alias one domain name, not a subtree, and cannot be at 89 the apex of a domain, where most people would want it (TODO 90 Cloudflare article). DNAMEs ([RFC6672]) alias a subtree but not the 91 owner name, only its subdomains. BNAMEs ([I-D.yao-dnsext-bname]) are 92 not yet standardized and raise several issues (TODO describe). 94 1.1. Terminology 96 "Client": any program that will act on the basis of the DNS 97 information described in this document. 99 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 100 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 101 document are to be interpreted as described in [RFC2119]. 103 2. The ALIAS RR type 105 We define a new RR type, ALIAS. Its owner name is the apex of a 106 domain, and its RDATA is the name of the domain which is 107 substitutable to this one. For instance, this says that foo.example 108 is actually an alias of bar.example: 110 $ORIGIN foo.example. 111 @ IN ALIAS bar.example. 113 TODO formal presentation format 115 TODO binary format 117 The new RR type has no special processing requirment. An 118 authoritative name server MAY send it in the additional section of a 119 response, when the QNAME is a domain name which has such an ALIAS. 121 An alternative to a new record type is described in Appendix A. 123 3. Usage 125 The alias is for a subtree, that's why it is always at the apex of a 126 domain. TODO what if there is a subdelegation? 128 The general idea is that clients will use this aliasing information 129 as they please. By "clients", we mean any program using this DNS 130 resource record. It can be a Web browser trying to visit a site, an 131 EPP server trying to determine if a transfer is possible (or if it 132 would break a bundle), a HTTP server trying to find out the list of 133 values it will accept in the Host: header, etc. 135 This lack of semantics is a deliberate feature; there are so many use 136 cases for "bundled" domain names that it is difficult, at the present 137 time, to design a solution to satisfy them all. We therefore limit 138 ourselves to signaling an intent, not to specify what to do with it. 140 4. Reverse aliasing 142 Some persons may want to have "reverse aliasing", either to easily 143 find out the domains aliasing to them, or to "authorize" the 144 aliasing. (It is not clear yet if it is a good idea. In the current 145 DNS, decentralized and loosely coupled, nothing prevents someone to 146 point a CNAME at you, and you cannot even know it.) 148 To do so, we define a second RR type, SAILA, to specify a domain 149 pointing at you: 151 $ORIGIN bar.example. 152 @ IN SAILA foo.example. 154 5. Deployability 156 Because this document does not change the behavior of the name 157 servers (either recursive or authoritative), it can be deployed on 158 the existing infrastructure, providing name servers and DNS 159 provisioning systems follow [RFC3597]. If they don't, the 160 alternative in Appendix A may be considered. 162 Adding this aliasing information to the DNS is extremely cheap and 163 without any drawbacks. The author hope it will be done, even without 164 waiting clients that wil consume this information. 166 It remains to be seen if it will be easier to upgrade the clients (to 167 use this information) or the name servers (which is a requirment of 168 other proposals like BNAME [I-D.yao-dnsext-bname]). 170 6. IANA Considerations 172 TODO register one (or two new RR types). 174 7. Security Considerations 176 No DNS security issues are expected since no specific action is 177 mandated for the client. 179 A client is responsible of what it decides to do with the aliasing 180 information. 182 A security-conscious client MAY decide to act on this aliasing 183 information only if it is validated with DNSSEC. 185 8. Implementation status - RFC EDITOR: REMOVE BEFORE PUBLICATION 187 This section records the status of known implementations of the 188 protocol defined by this specification at the time of posting of this 189 Internet-Draft, and is based on a proposal described in [RFC7942]. 190 The description of implementations in this section is intended to 191 assist the IETF in its decision processes in progressing drafts to 192 RFCs. Please note that the listing of any individual implementation 193 here does not imply endorsement by the IETF. Furthermore, no effort 194 has been spent to verify the information presented here that was 195 supplied by IETF contributors. This is not intended as, and must not 196 be construed to be, a catalog of available implementations or their 197 features. Readers are advised to note that other implementations may 198 exist. 200 According to [RFC7942], "this will allow reviewers and working groups 201 to assign due consideration to documents that have the benefit of 202 running code, which may serve as evidence of valuable experimentation 203 and feedback that have made the implemented protocols more mature. 204 It is up to the individual working groups to use this information as 205 they see fit". 207 No implementation known at this time. 209 9. Acknowledgments 211 Thanks to the "Sichuan house" restaurant in Seoul for a nice place to 212 start the discussion, and to CNNIC for the invitation. 214 10. References 216 10.1. Normative References 218 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 219 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 220 . 222 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 223 Requirement Levels", BCP 14, RFC 2119, 224 DOI 10.17487/RFC2119, March 1997, 225 . 227 10.2. Informative References 229 [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record 230 (RR) Types", RFC 3597, DOI 10.17487/RFC3597, September 231 2003, . 233 [RFC6672] Rose, S. and W. Wijngaards, "DNAME Redirection in the 234 DNS", RFC 6672, DOI 10.17487/RFC6672, June 2012, 235 . 237 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 238 Code: The Implementation Status Section", BCP 205, 239 RFC 7942, DOI 10.17487/RFC7942, July 2016, 240 . 242 [I-D.yao-dnsext-bname] 243 Yao, J., Lee, X., and P. Vixie, "Bundled DNS Name 244 Redirection", draft-yao-dnsext-bname-06 (work in 245 progress), May 2016. 247 [I-D.yao-bundled-name-problem-statement] 248 Yao, J., Lee, X., and J. Levine, "Problem Statement for 249 Fully Mapping One Name to Another Name", draft-yao- 250 bundled-name-problem-statement-03 (work in progress), 251 October 2016. 253 10.3. URIs 255 [1] https://github.com/bortzmeyer/ietf-signaling-alias 257 Appendix A. A TXT alternative to the new RR type 259 In theory, a new RR type such as ALIAS works everywhere, thanks to 260 [RFC3597]. In practice, while most name servers won't have any 261 problem with it, many domain name provisioning systems will have 262 trouble handling ALIAS. Therefore, we suggest here an alternative: a 263 TXT record under the subdomain _alias. The example above would 264 become: 266 $ORIGIN foo.example. 267 _alias IN TXT bar.example. 269 TODO IAB RFC on the proper use of TXT records 271 Author's Address 272 Stephane Bortzmeyer 273 AFNIC 274 1, rue Stephenson 275 Montigny-le-Bretonneux 78180 276 France 278 Phone: +33 1 39 30 83 46 279 Email: bortzmeyer+ietf@nic.fr 280 URI: http://www.afnic.fr/