| DNSOP Working Group | R. Bellis |
| Internet-Draft | ISC |
| Intended status: Standards Track | November 04, 2018 |
| Expires: May 8, 2019 |
A DNS Resource Record for HTTP
draft-bellis-dnsop-http-record-00
This document specifies an “HTTP” resource record type for the DNS to facilitate the lookup of the server hostname of HTTP(s) URIs. It is intended to replace the use of CNAME records for this purpose, and in the process provides a solution for the inability of the DNS to allow a CNAME to be placed at the apex of a domain name.
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 8, 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.
It is very common for HTTP(s) URIs to contain a domain name that is not the same as the hostname of the actual server that hosts the content.
This is typically achieved via a CNAME record where the owner name of that record (the “Alias”) is the domain name from the URI and the Canonical name field in its RDATA corresponds with the target hostname (although it should be noted that this strictly a violation of the original design semantics of the CNAME record).
It is also impossible to store a CNAME at the apex of a domain name, which causes signficant difficulties if you wish to redirect your domain name without a “www” prefix to a content delivery network (CDN). The only portable solution at the moment is to determine the IP address records of the content host and insert them directly at the apex of the zone, but this is brittle, and prevents the correct operation of typical CDN features.
While there have been previous attempts to promote the use of the SRV record instead of CNAME records, there have been concerns raised about the performance impact of the additional DNS lookup an SRV record would typically require.
To achieve equivalent end-user performance as existing CNAME-based solutions, this document permits recursive resolvers to pre-emptively look up the target of an HTTP Record and return the corresponding records to the client. While this feature is not mandatory it is hoped that support would over time become near ubiquitous.
Also, the presence of the Port field in an SRV record is incompatible with the “Same Origin” security policy enforced by web browsers and in practise the load-balancing / fallback capabilities of the SRV record are not widely used either, and non-DNS based solutions for this are already widely deployed for HTTP traffic.
This document therefore specifies a minimal “HTTP” resource record type for the DNS to facilitate the redirection from the domain name portion of an HTTP(s) URI to the server hostname and thence to A or AAAA records. It is specifically intended to replace the use of CNAME records for this purpose, and in the process provides a solution for the inability of the DNS to allow a CNAME to be placed at the apex of a domain name.
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.
The owner name of an HTTP RR is the domain name portion of an HTTP(s) URI.
The use of underscore label prefixes (e.g. _http._tcp) was considered, but rejected since it prohibits the use of wildcard records which us a valuable technique for offering per-customer domain prefixes without requiring that every prefix be individually provisioned.
The RDATA of an HTTP RR is a domain name in uncompressed wire format.
The RDATA of an HTTP RR is presented as a domain name in standard master file format.
Recursive resolvers MAY on receiving a request for an HTTP record look up the A and AAAA records for the target (either from cache, or via new iterative queries) and include the results in the Additional Section of the response.
If the recursive resolver is performing DNSSEC resolution but is unable to validate the A or AAAA responses it MUST NOT include them in the response unless the client has specified the +CD (checking disabled) flag.
Where EDNS Client Subnet [RFC7871] is configured on the resolver those A and AAAA lookups MUST be performed as if the client had made those queries directly to the resolver.
HTTP clients supporting this specification MUST issue parallel DNS requests for the A, AAAA and HTTP records for the domain portion of an http: or https: URI.
If an HTTP record is returned, the client MUST either use the A and AAAA records contained in the Additional Section of the response, or issue further parallel requests for the A and AAAA records corresponding to the domain name in the RDATA of the HTTP record and then use those IP addresses to access the URI.
If the original A and AAAA lookups return IP addresses these MUST only be used if no HTTP record is returned.
« the above needs more text around timing, happy eyeballs, etc. »
TBD
« RFC Editor Note: Please remove this entire section prior to publication as an RFC. »
TBD (if any)
« a copy of the RFC 6895 IANA RR TYPE application template will appear here »
| [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. |
| [RFC7871] | Contavalli, C., van der Gaast, W., Lawrence, D. and W. Kumari, "Client Subnet in DNS Queries", RFC 7871, DOI 10.17487/RFC7871, May 2016. |