| DNSOP Working Group | D. York |
| Internet-Draft | Internet Society |
| Intended status: Informational | November 06, 2018 |
| Expires: May 10, 2019 |
CNAME at apex - a website publisher perspective
draft-york-dnsop-cname-at-apex-publisher-view-01
There has been a large amount of discussion about the “CNAME at apex” issue within the DNSOP Working Group. This draft provides the perspective of one publisher of multiple websites about why CNAME-like functionality is desirable at the apex of a domain zone.
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 https://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 May 10, 2019.
Copyright (c) 2018 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 (https://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.
From the early days of the Web, publishers of websites generally operated their main public website using the “www” subdomain, as in “www.example.com”.
In recent years many organizations have moved to dropping the “www” and referring to their main website by simply the domain name, as in “example.com”. There are numerous reasons for this change, including the simplicity of saying or writing the name and also smaller address bars on mobile browsers. If you are designing a large advertisement to display in, say, an airport hallway, you can make the domain name address larger and more visibile if you simply use “example.com” and drop the “www”. Additionally, some web browsers are no longer showing the full URL (or even any of the URL) and so the “www” is no longer visible.
Regardless of the reasons, the fact is that many website publishers and marketing/communications teams are moving to using only the domain name without the “www” or other subdomains to reference their public website.
The expectations from the marketing / communications teams are that:
If the organization’s website is a simple web server with specific A and AAAA records, this change can be easily implemented by adding the appropriate A and AAAA records at the zone apex.
However, most larger site publishers (and many smaller publishers) now use content distribution networks (CDNs), global load balancers, or some other form of a caching / load balancing network in front of their website. The result is that there is no single “A” or “AAAA” record for the organization’s website.
Publishers use CDNs for a variety of reasons, including:
While there may be many non-CDN mechanisms to address those reasons, website publishers in 2018 are increasingly using CDNs as a simple business solution.
The DNS issue is that the website publisher is told to simply redirect all traffic to some address within the CDN along the lines of one of these:
The CDN then performs its service of providing the requesting client with the A or AAAA record most appropriate for the client’s network/geographic location.
Some CDNs require that they manage the DNS services for the target domain name. The publisher must designate the CDN’s DNS servers as the authoritative name servers (NS records) for the domain. At that point the CDN handles all of the name resolution directly and dynamically returns the A and AAAA records back to the client web browser. The browser has no idea that a CDN is in usage.
However, this document is discussing CDNs where the publisher retains control of serving out DNS records for the domain.
For websites using a subdomain such as “www”, this is simply done in DNS using CNAME and pointing to a target URL provided by the CDN:
www.example.com 300 IN CNAME a123qkt5y7xxb3df8.example-cdn.net
Now all web traffic to www.example.com is redirected to the CDN address. The CDN returns the appropriate A and AAAA records. This all works and the browser connects to the site hosted on one of the CDN edge servers.
For reasons outlined in Appendix C of [I-D.ietf-dnsop-aname] CNAME does not work at the apex of a domain. A primary reason is section 3.6.2 of [RFC1034].
To respond to this business demand, various DNS operators (including CDN providers who also act as DNS operators) have developed proprietary solutions (also referred to as “stupid DNS tricks” within the DNSOP community). Under various names such as “URL flattening” or “CNAME flattening”, these techniques do work and allow the sites to be accessible on the CDN via the simple domain name.
However, because of the proprietary nature, they then lock the website publisher into using that DNS operator / CDN. The website publisher does not have an easily ability to move to a different DNS operator / CDN unless the new DNS operator / CDN can also provide a mechanism to allow the non-www domain usage.
Additionally, many large web site publishers use (or want to use) multiple CDNs to achieve various business objectives, including resiliency / availability. The lack of a standard mechanism to do this “CNAME at apex” functionality limits the ability to explore multi-CDN options.
Various email discussions have indicated that existing mechanisms can address this issue, although deployment/adoption concerns have been raised. Existing solutions include:
Multiple solutions have been proposed for discussion at IETF 103, including:
As a website publisher, I have a business objective to meet - make the site accessible over “example.com” versus “www.example.com”. As long as this can happen in a manner that can be widely deployed, I am not partial to any specific solution. I just want it to work and not lock me in to specific proprietary solutions.
There was a lengthy discussion of this topic in the DNSOP session at IETF 102 in Montreal in 2018. Slides from that session are useful for more context:
The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
TODO add any security considerations.
This document has no IANA actions.
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. |
| [RFC8174] | Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017. |
| [I-D.bellis-dnsop-http-record] | Bellis, R., "A DNS Resource Record for HTTP", Internet-Draft draft-bellis-dnsop-http-record-00, November 2018. |
| [I-D.ietf-dnsop-aname] | Finch, T., Hunt, E., Dijk, P. and A. Eden, "Address-specific DNS aliases (ANAME)", Internet-Draft draft-ietf-dnsop-aname-02, October 2018. |
| [RFC1034] | Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987. |
| [RFC2052] | Gulbrandsen, A. and P. Vixie, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2052, DOI 10.17487/RFC2052, October 1996. |
| [RFC7553] | Faltstrom, P. and O. Kolkman, "The Uniform Resource Identifier (URI) DNS Resource Record", RFC 7553, DOI 10.17487/RFC7553, June 2015. |
TODO acknowledge.