How to use URI Resource Records for HTTP
draft-faltstrom-httpbis-dns-00

Abstract

This document describes the reasons why it would be a good thing to use SRV [RFC2782] or URI [RFC7553] resource records for HTTP protocol instead of (as of today) just relying on redirects and other mechanisms in the HTTP protocol itself. It also explains how to do it as there are conflicting instructions on how to do it.

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 http://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 February 9, 2017.

Copyright Notice

Copyright (c) 2016 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 (http://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.

Table of Contents

• 1. Introduction
• 2. URI resource Record
• 3. HTTP of today
• 4. The URI Resource Record
• 5. HTTP using URI Resource Records
• 6. IANA Considerations
• 7. Security Considerations
• 8. Acknowledgements
• 9. References
• 9.1. Normative References
• 9.2. Informative References
• Author's Address

1. Introduction

The HTTP protocol have historically been a relatively simple protocol based on TCP by which a client opens a connection to an IP address, sends a request and get a response. Further evolution of the HTTP protocol have introduced the ability to carry multiple transactions over the same TCP connection and further evolution have made the use of the TCP connection even more efficient. Experimental deployment also exists where UDP is the protocol used.

In all cases the IP address used for the peer of the connection is discovered by a lookup of the hostname in the URI that identifies the resource to be accessed, and further the hostname in URIs that within the HTTP protocol there is redirects to (or of course in the HTML or similar formatting in the data returned via HTTP).

This implies there are a number of issues with deployment of HTTP based services that do not exist in other popular protocols like SMTP (for electronic mail) and SIP (for VoIP).

This document tries to explain a few of these weaknesses and why use of URI and SRV resource record types as a first step before the HTTP connection is established would make deployment easier and because of that not only life easier for the domain name holder, but also make the over all connection faster and the experience better.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, [RFC2119].

2. URI resource Record

After an expert review in February 2011 (see Appendix A in RFC7553 [RFC7553]) IANA allocated RRTYPE 256 for the URI Resource Record Type in the registry named Resource Record (RR) TYPEs and QTYPEs as defined in BCP 42 (at the time [RFC6195]), located at http://www.iana.org/assignments/dns-parameters.

Later, in June 2015, [RFC7553] was published to explain how the URI resource record could be used.

3. HTTP of today

HTTP is a protocol that originally was very simple with single transactions over a TCP connection. The client opened the connection, requested a resource and got information back. This has evolved over time and the new HTTP/2 protocol has even more ability to for example have multiple resources be fetched over the same TCP flow using a mechanism that can be viewed as asynchronous.

The basic functionality is though the same. A URI is used as an identifier for the resource to be fetched. From the URI a hostname is extracted, an address record (A or AAAA) is fetched and a TCP connection is opened to the address in question. So called Happy Eyeballs mechanisms is further used to open multiple connections in parallel and simply use the one that works the best (from the clients perspective) to maximize the end users experience.

In many cases the resource that is actually to be fetched is though not the one that is named with the original URI. If that is the case the HTTP response is a 3xx for a redirect to a different URI which is then fetched over the same (if possible) or different TCP connection.

The reasons for such redirects can be many but common issues are:

• The URI in question do not end with a '/' but in reality the resource (or web server) do require it.
• The URI in question do not start with 'www' but the user did type it (or the other way around). Specifically in cases where the CMS in use can only use one domain name for it.
• The resource is in reality hosted by some cloud service, and instead of a reverse proxy a redirect is used to the resource location within the cloud service itself.
• The exact URI for the resource is not known, but the identification of the resource is known so that so called "well known URI" can be used to explicitly trigger a redirect to the resource itself.
• The resource was fetched using HTTP while the resource is accessible only over HTTPS.
• The resource is hosted by a 2nd party and a CNAME is used for the hostname in question. But, as CNAME can not be used for owners that already have data, one can not have CNAME at a zone apex, only address records. Often address records then are missing at the apex (while the www record is a CNAME) or the address record is later not updated when the IP address changes. Such situations require often multiple address lookups and HTTP redirects before the resource is fetched using the correct intended URI:

In many of these cases it would have been better to be able to fetch the resource directly, given one know what the URI of the resource is. The URI resource record is supposed to help with finding out what the exact and correct URI is for a specific resource.

4. The URI Resource Record

The URI resource record was approved by the IETF using the then new approval mechanism that did not require an RFC. Later an informational RFC was created that explains the format and usage.

A few things to note:

• It looks like if the URI resource record do use the same format for text in RDATA as the TXT resource record. In fact it does not. The text in the RDATA (that is the URI) is not a length prefixed string (that would limit the length). Instead it is the rest of the RDATA field from where the URI starts.
• URI inherit prefixes from the ENUM Registry that is hosted by IANA. That, like the registry over ports and services, is not unique which makes it unknown what prefix to use to find out (for example) the prefix to use for "web services". This document is clarifying this, see below.
• The priority field is used for ordering in what order URIs should be fetched. If the first (lowest number) is not reachable, the 2nd is to be tried etc.
• The weight is very seldom used and SHOULD have value 0.

5. HTTP using URI Resource Records

There are multiple ways to set the prefix for the URI resource record if one look at the various tables IANA has. There are initiatives to create an ultimate table, for example [I-D.ietf-dnsop-attrleaf]. This document is to clarify what prefix to use when fetching web pages using the HTTP protocol as the URI specification is ambigious.

The URI record to look up for the domain example.com is:

• _web._http.example.com.

When resolving a URI for the web before the HTTP protocol specification is applied to the URI, the URI MUST be rewritten according to the RDATA in the response to the lookup of the URI resource record. If the RRSet returned include more than one resource record, the records MUST be sorted and tried in accordance with the URI resource record specification.

If no resource record is returned when the URI record is looked up, the HTTP client MUST continue to resolve the URI as it is, without it being rewritten.

Note that it does not say whether for example TCP or UDP is to be used. That is to be used according to the HTTP specification. The URI resource record only say what the correct URI is to fetch if the goal was to get the web page related to example.com using http.

6. IANA Considerations

Given the registry discussed in [I-D.ietf-dnsop-attrleaf] is created, the value _web._http is to be registered for use for normal web services using the HTTP protocol.

7. Security Considerations

Using the URI resource record together with security mechanisms that relies on verification of authentication of hostnames, like TLS, makes it important to choose the correct domain name when doing the comparison, and that the change in what hostname to use is secured by DNSSEC so that it can be trusted in a similar way as a redirect in HTTP using TLS.

It is specifically the case that although HTTP and HTTPS are different ENUM Service Registrations, only _web._http MUST be used for the lookup of the URI resource record for a domain. If HTTPS is the preferred protocol to use, a HTTPS URI is to be returned to the lookup and not a HTTP URI.

8. Acknowledgements

The key person that triggered creation of this Internet-Draft is Daniel Stenberg. He clearly pointed out to me that what is really needed for him to add support for the URI resource record is a well written definition of how to use it and why it should be used.

9. References

9.1. Normative References

9.2. Informative References

Author's Address