idnits 2.17.1 draft-york-dnsop-cname-at-apex-publisher-view-01.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 : ---------------------------------------------------------------------------- == There are 2 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (November 06, 2018) is 1991 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-04) exists of draft-ietf-dnsop-aname-02 -- Obsolete informational reference (is this intentional?): RFC 2052 (Obsoleted by RFC 2782) Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DNSOP Working Group D. York 3 Internet-Draft Internet Society 4 Intended status: Informational November 06, 2018 5 Expires: May 10, 2019 7 CNAME at apex - a website publisher perspective 8 draft-york-dnsop-cname-at-apex-publisher-view-01 10 Abstract 12 There has been a large amount of discussion about the "CNAME at apex" 13 issue within the DNSOP Working Group. This draft provides the 14 perspective of one publisher of multiple websites about why CNAME- 15 like functionality is desirable at the apex of a domain zone. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at https://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on May 10, 2019. 34 Copyright Notice 36 Copyright (c) 2018 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (https://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. The Challenge . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2.1. Note . . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 3. CNAME works for subdomains . . . . . . . . . . . . . . . . . 4 55 4. CNAME at apex does not work . . . . . . . . . . . . . . . . . 4 56 5. Proprietary solutions . . . . . . . . . . . . . . . . . . . . 4 57 5.1. Proprietary lockin . . . . . . . . . . . . . . . . . . . 4 58 5.2. Restriction on using multiple CDNs . . . . . . . . . . . 5 59 6. Existing and proposed solutions . . . . . . . . . . . . . . . 5 60 7. Author opinion . . . . . . . . . . . . . . . . . . . . . . . 5 61 8. Past discussion . . . . . . . . . . . . . . . . . . . . . . . 5 62 9. Conventions and Definitions . . . . . . . . . . . . . . . . . 6 63 10. Security Considerations . . . . . . . . . . . . . . . . . . . 6 64 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 65 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 66 12.1. Normative References . . . . . . . . . . . . . . . . . . 6 67 12.2. Informative References . . . . . . . . . . . . . . . . . 6 68 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 7 69 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 71 1. Introduction 73 From the early days of the Web, publishers of websites generally 74 operated their main public website using the "www" subdomain, as in 75 "www.example.com". 77 In recent years many organizations have moved to dropping the "www" 78 and referring to their main website by simply the domain name, as in 79 "example.com". There are numerous reasons for this change, including 80 the simplicity of saying or writing the name and also smaller address 81 bars on mobile browsers. If you are designing a large advertisement 82 to display in, say, an airport hallway, you can make the domain name 83 address larger and more visibile if you simply use "example.com" and 84 drop the "www". Additionally, some web browsers are no longer 85 showing the full URL (or even any of the URL) and so the "www" is no 86 longer visible. 88 Regardless of the reasons, the fact is that many website publishers 89 and marketing/communications teams are moving to using only the 90 domain name without the "www" or other subdomains to reference their 91 public website. 93 The expectations from the marketing / communications teams are that: 95 1. users will be able to simply enter "example.com" into their 96 browser; and 98 2. users will only see "example.com" in their address bar (if URLs 99 are even displayed). 101 2. The Challenge 103 If the organization's website is a simple web server with specific A 104 and AAAA records, this change can be easily implemented by adding the 105 appropriate A and AAAA records at the zone apex. 107 However, most larger site publishers (and many smaller publishers) 108 now use content distribution networks (CDNs), global load balancers, 109 or some other form of a caching / load balancing network in front of 110 their website. The result is that there is no single "A" or "AAAA" 111 record for the organization's website. 113 Publishers use CDNs for a variety of reasons, including: 115 o Performance - connecting users to an edge server with the lowest 116 latency 118 o Geo-location - connecting users to edge servers appropriate for 119 their geography 121 o DDoS / security - using various security mechanisms provided by 122 CDNs 124 o IPv6 - using a CDN to offer IPv6 access when the origin server is 125 only on IPv4 127 o TLS - using a CDN to offer higher levels of TLS usage than 128 possible with origin server 130 While there may be many non-CDN mechanisms to address those reasons, 131 website publishers in 2018 are increasingly using CDNs as a simple 132 business solution. 134 The DNS issue is that the website publisher is told to simply 135 redirect all traffic to some address within the CDN along the lines 136 of one of these: 138 o a123qkt5y7xxb3df8.example-cdn.net 140 o (companyname).example-cdn.net 142 o (companyname).(location).example-cdn.net 144 o some-random-string.example-cdn.net 145 The CDN then performs its service of providing the requesting client 146 with the A or AAAA record most appropriate for the client's network/ 147 geographic location. 149 2.1. Note 151 Some CDNs require that they manage the DNS services for the target 152 domain name. The publisher must designate the CDN's DNS servers as 153 the authoritative name servers (NS records) for the domain. At that 154 point the CDN handles all of the name resolution directly and 155 dynamically returns the A and AAAA records back to the client web 156 browser. The browser has no idea that a CDN is in usage. 158 However, this document is discussing CDNs where the publisher retains 159 control of serving out DNS records for the domain. 161 3. CNAME works for subdomains 163 For websites using a subdomain such as "www", this is simply done in 164 DNS using CNAME and pointing to a target URL provided by the CDN: 166 www.example.com 300 IN CNAME a123qkt5y7xxb3df8.example-cdn.net 168 Now all web traffic to www.example.com is redirected to the CDN 169 address. The CDN returns the appropriate A and AAAA records. This 170 all works and the browser connects to the site hosted on one of the 171 CDN edge servers. 173 4. CNAME at apex does not work 175 For reasons outlined in Appendix C of [I-D.ietf-dnsop-aname] CNAME 176 does not work at the apex of a domain. A primary reason is section 177 3.6.2 of [RFC1034]. 179 5. Proprietary solutions 181 To respond to this business demand, various DNS operators (including 182 CDN providers who also act as DNS operators) have developed 183 proprietary solutions (also referred to as "stupid DNS tricks" within 184 the DNSOP community). Under various names such as "URL flattening" 185 or "CNAME flattening", these techniques do work and allow the sites 186 to be accessible on the CDN via the simple domain name. 188 5.1. Proprietary lockin 190 However, because of the proprietary nature, they then lock the 191 website publisher into using that DNS operator / CDN. The website 192 publisher does not have an easily ability to move to a different DNS 193 operator / CDN unless the new DNS operator / CDN can also provide a 194 mechanism to allow the non-www domain usage. 196 5.2. Restriction on using multiple CDNs 198 Additionally, many large web site publishers use (or want to use) 199 multiple CDNs to achieve various business objectives, including 200 resiliency / availability. The lack of a standard mechanism to do 201 this "CNAME at apex" functionality limits the ability to explore 202 multi-CDN options. 204 6. Existing and proposed solutions 206 Various email discussions have indicated that existing mechanisms can 207 address this issue, although deployment/adoption concerns have been 208 raised. Existing solutions include: 210 o SRV record - [RFC2052] 212 o URI record - [RFC7553] 214 o NAPTR-based solutions (need to understand more) 216 Multiple solutions have been proposed for discussion at IETF 103, 217 including: 219 o [I-D.ietf-dnsop-aname] 221 o [I-D.bellis-dnsop-http-record] 223 7. Author opinion 225 As a website publisher, I have a business objective to meet - make 226 the site accessible over "example.com" versus "www.example.com". As 227 long as this can happen in a manner that can be widely deployed, I am 228 not partial to any specific solution. I just want it to work and not 229 lock me in to specific proprietary solutions. 231 8. Past discussion 233 There was a lengthy discussion of this topic in the DNSOP session at 234 IETF 102 in Montreal in 2018. Slides from that session are useful 235 for more context: 237 o https://datatracker.ietf.org/meeting/102/materials/slides-102- 238 dnsop-somethingapex-02 240 o https://datatracker.ietf.org/meeting/102/materials/slides-102- 241 dnsop-cnameapex-00 243 9. Conventions and Definitions 245 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 246 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 247 "OPTIONAL" in this document are to be interpreted as described in BCP 248 14 [RFC2119] [RFC8174] when, and only when, they appear in all 249 capitals, as shown here. 251 10. Security Considerations 253 TODO add any security considerations. 255 11. IANA Considerations 257 This document has no IANA actions. 259 12. References 261 12.1. Normative References 263 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 264 Requirement Levels", BCP 14, RFC 2119, 265 DOI 10.17487/RFC2119, March 1997, 266 . 268 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 269 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 270 May 2017, . 272 12.2. Informative References 274 [I-D.bellis-dnsop-http-record] 275 Bellis, R., "A DNS Resource Record for HTTP", draft- 276 bellis-dnsop-http-record-00 (work in progress), November 277 2018. 279 [I-D.ietf-dnsop-aname] 280 Finch, T., Hunt, E., Dijk, P., and A. Eden, "Address- 281 specific DNS aliases (ANAME)", draft-ietf-dnsop-aname-02 282 (work in progress), October 2018. 284 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 285 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 286 . 288 [RFC2052] Gulbrandsen, A. and P. Vixie, "A DNS RR for specifying the 289 location of services (DNS SRV)", RFC 2052, 290 DOI 10.17487/RFC2052, October 1996, 291 . 293 [RFC7553] Faltstrom, P. and O. Kolkman, "The Uniform Resource 294 Identifier (URI) DNS Resource Record", RFC 7553, 295 DOI 10.17487/RFC7553, June 2015, 296 . 298 Acknowledgments 300 TODO acknowledge. 302 Author's Address 304 Dan York 305 Internet Society 307 Email: york@isoc.org