Skip to main content

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

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Author Patrik Fältström
Last updated 2016-08-09
RFC stream (None)
Formats
Additional resources
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-faltstrom-httpbis-dns-00
Network Working Group                                       P. Faltstrom
Internet-Draft                                                    Netnod
Intended status: Informational                           August 08, 2016
Expires: February 9, 2017

                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.

Faltstrom               Expires February 9, 2017                [Page 1]
Internet-Draft               HTTP and URI RR                 August 2016

Table of Contents

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

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].

Faltstrom               Expires February 9, 2017                [Page 2]
Internet-Draft               HTTP and URI RR                 August 2016

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

Faltstrom               Expires February 9, 2017                [Page 3]
Internet-Draft               HTTP and URI RR                 August 2016

      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.

Faltstrom               Expires February 9, 2017                [Page 4]
Internet-Draft               HTTP and URI RR                 August 2016

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.

Faltstrom               Expires February 9, 2017                [Page 5]
Internet-Draft               HTTP and URI RR                 August 2016

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

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC7553]  Faltstrom, P. and O. Kolkman, "The Uniform Resource
              Identifier (URI) DNS Resource Record", RFC 7553,
              DOI 10.17487/RFC7553, June 2015,
              <http://www.rfc-editor.org/info/rfc7553>.

9.2.  Informative References

   [I-D.ietf-dnsop-attrleaf]
              Crocker, D., "DNS Scoped Data Through '_Underscore'
              Attribute Leaves", draft-ietf-dnsop-attrleaf-00 (work in
              progress), March 2016.

   [RFC2782]  Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
              specifying the location of services (DNS SRV)", RFC 2782,
              DOI 10.17487/RFC2782, February 2000,
              <http://www.rfc-editor.org/info/rfc2782>.

   [RFC6195]  Eastlake 3rd, D., "Domain Name System (DNS) IANA
              Considerations", RFC 6195, DOI 10.17487/RFC6195, March
              2011, <http://www.rfc-editor.org/info/rfc6195>.

Author's Address

   Patrik Faltstrom
   Netnod

   Email: paf@netnod.se

Faltstrom               Expires February 9, 2017                [Page 6]