Internet DRAFT - draft-bellis-dnsop-http-record
draft-bellis-dnsop-http-record
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
Abstract
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.
Status of This Memo
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 Notice
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.
Bellis Expires May 8, 2019 [Page 1]
Internet-Draft A DNS Resource Record for HTTP November 2018
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Description . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Wire Format . . . . . . . . . . . . . . . . . . . . . . . 3
3.2. Presentation Format . . . . . . . . . . . . . . . . . . . 3
3.3. Server Operation . . . . . . . . . . . . . . . . . . . . 4
3.4. Client Operation . . . . . . . . . . . . . . . . . . . . 4
4. Security Considerations . . . . . . . . . . . . . . . . . . . 4
5. Implementation status . . . . . . . . . . . . . . . . . . . . 4
6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 4
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
9.1. Normative References . . . . . . . . . . . . . . . . . . 5
9.2. Informative References . . . . . . . . . . . . . . . . . 5
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5
1. Introduction
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
Bellis Expires May 8, 2019 [Page 2]
Internet-Draft A DNS Resource Record for HTTP November 2018
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.
2. Terminology
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.
3. Description
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.
3.1. Wire Format
The RDATA of an HTTP RR is a domain name in uncompressed wire format.
3.2. Presentation Format
The RDATA of an HTTP RR is presented as a domain name in standard
master file format.
Bellis Expires May 8, 2019 [Page 3]
Internet-Draft A DNS Resource Record for HTTP November 2018
3.3. Server Operation
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.
3.4. Client Operation
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. >>
4. Security Considerations
TBD
5. Implementation status
<< RFC Editor Note: Please remove this entire section prior to
publication as an RFC. >>
6. Privacy Considerations
TBD (if any)
Bellis Expires May 8, 2019 [Page 4]
Internet-Draft A DNS Resource Record for HTTP November 2018
7. IANA Considerations
<< a copy of the RFC 6895 IANA RR TYPE application template will
appear here >>
8. Acknowledgements
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
9.2. Informative References
[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,
<https://www.rfc-editor.org/info/rfc7871>.
Author's Address
Ray Bellis
Internet Systems Consortium, Inc.
950 Charter Street
Redwood City CA 94063
USA
Phone: +1 650 423 1200
Email: ray@isc.org
Bellis Expires May 8, 2019 [Page 5]
