A mechanism to encode HTTP version information in DNS

Phillip Hallam-Baker <hallam@gmail.com> Thu, 14 February 2013 20:21 UTC

Return-Path: <ietf-http-wg-request@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B4BE21F882E for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 14 Feb 2013 12:21:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.37
X-Spam-Level:
X-Spam-Status: No, score=-9.37 tagged_above=-999 required=5 tests=[AWL=1.228, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rl2DGpEGvdTs for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 14 Feb 2013 12:21:39 -0800 (PST)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id AE87621F84C8 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Thu, 14 Feb 2013 12:21:39 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1U65F5-0002pM-MJ for ietf-http-wg-dist@listhub.w3.org; Thu, 14 Feb 2013 20:17:15 +0000
Resent-Date: Thu, 14 Feb 2013 20:17:15 +0000
Resent-Message-Id: <E1U65F5-0002pM-MJ@frink.w3.org>
Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <hallam@gmail.com>) id 1U65En-0002oV-Sw for ietf-http-wg@listhub.w3.org; Thu, 14 Feb 2013 20:16:57 +0000
Received: from mail-wg0-f44.google.com ([74.125.82.44]) by lisa.w3.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <hallam@gmail.com>) id 1U65El-0004qx-Ov for ietf-http-wg@w3.org; Thu, 14 Feb 2013 20:16:57 +0000
Received: by mail-wg0-f44.google.com with SMTP id dr12so2172304wgb.23 for <ietf-http-wg@w3.org>; Thu, 14 Feb 2013 12:16:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=uKUpssm2LFbmLoEmev+Fy11OGjjwt9O52EmnKdFB1YQ=; b=lPUJzXPmWSbY2MIpHt5zNnWak0JoYkfeHqIuvxYp721AZe3i1mCxQj9GTbgHUfV0Y3 X8hZkwx79Z7mCqmCNtX58GSqsk4bnNyVHNw7pYh6fr1cGOiJLV2TzTY7OHvHMIFqw9UP L/a9VQdGhZ6MjxPGAmDAxZGTTE4zq8xz3MZPdu4pDRRm4BmCGu4ojRB4ZNVl/yN8wCou VhfLSGSMbmd/D57xZVWS3DDRb+iCAewLKE3zt+wOXbarh4NmYQK6DldwdEijz59C/qhX YllQiMson9NdfLgmJadSGWFL/m6rQscMKqydhAcZZ4hVfn3M/qqNmN6vintK/kTb751u 2Pww==
MIME-Version: 1.0
X-Received: by 10.180.105.232 with SMTP id gp8mr1680804wib.33.1360872989440; Thu, 14 Feb 2013 12:16:29 -0800 (PST)
Received: by 10.194.19.226 with HTTP; Thu, 14 Feb 2013 12:16:28 -0800 (PST)
Date: Thu, 14 Feb 2013 15:16:28 -0500
Message-ID: <CAMm+Lwgawnwaybqf9vfTNbC3OZHGaQN0tkPWT8UAW-taj+1gQQ@mail.gmail.com>
From: Phillip Hallam-Baker <hallam@gmail.com>
To: "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary=f46d044402d01ebca504d5b4ef3e
Received-SPF: pass client-ip=74.125.82.44; envelope-from=hallam@gmail.com; helo=mail-wg0-f44.google.com
X-W3C-Hub-Spam-Status: No, score=-3.5
X-W3C-Hub-Spam-Report: AWL=-2.665, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001
X-W3C-Scan-Sig: lisa.w3.org 1U65El-0004qx-Ov d152a00cab607df7d061fb6f924c18f0
X-Original-To: ietf-http-wg@w3.org
Subject: A mechanism to encode HTTP version information in DNS
Archived-At: <http://www.w3.org/mid/CAMm+Lwgawnwaybqf9vfTNbC3OZHGaQN0tkPWT8UAW-taj+1gQQ@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/16605
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

Encoding HTTP version information in DNS is easy if you don't particularly
care about using DNS properly or want to do anything more than encode HTTP
version information.

Doing it well gets rather more complex. A DNS query costs a round trip so
you would ideally like to make it pay. Also the process of deploying DNS
records takes some time and it is better to reuse an existing record but
only if that will not create ambiguity.

Looking again at the URI record, I think that we could use it to provide a
HTTP version flag and other useful features in the DNS. In particular we
can use the URI record to effect a HTTP redirect in DNS (a UDP round trip)
rather than require a TCP round trip. It also provides for fault tolerance
and load balancing and works well with Web Services.


The format of the URI record is currently: <priority> <weight> <Target>

Priority - uint16
Weight - uint16
Target - string

While Target is technically a list of string entries it is not a good idea
to depend on the string boundaries for technical reasons and so multiple
strings should probably be considered equivalent to the result of
concatenating them together.

For example: two servers offering HTTP service for 'example.com'
_http._tcp.example.com  URI 10 10 "http://www1.example.com/"
_http._tcp.example.com  URI 10 10 "http://www2.example.com/"

OK so that is not very interesting but the existing but the URI scheme also
permits services to be advertised under a different scheme such as https or
coap (or ftp if you must!)

So to force an upgrade to TLS we might specify the following:

_http._tcp.example.com  URI 10 10 "https://www1.example.com/"
_http._tcp.example.com  URI 10 10 "https://www2.example.com/"

Or to advertise multiple protocols:

_http._tcp.example.com  URI 10 10 "http://www1.example.com/"
_http._tcp.example.com  URI 10 10 "coap://www1.example.com/"

Or to map a domain to a path on another server:

_http._tcp.old.example.com  URI 10 10 "https://www1.example.com/old-stuff"


All those capabilities are useful in the context of HTTP discovery. They
allow a redirect to be effected through the DNS rather than require a
server deployment. But it would be much nicer if we could encode both a
target URI and some description of that target to allow client selection.
For example:

* IP version
* HTTP protocol version
* HSTS data

We don't always need this data but when we do it is very useful. But it
turns out that the existing URI record might already meet this need since a
URI cannot have a space inside it and so we can use that as a delimeter
between the target URI and any parameters. We are currently discussing the
details of this on DNSEXT but it looks like it works fine.

_http._tcp.example.com  URI 10 10 "http://www1.example.com/ ipv4 ipv6"
_http._tcp.example.com  URI 10 10 "http://www2.example.com/ http2"
_http._tcp.example.com  URI 10 10 "http://www3.example.com/ sts"

The same mechanism can be used to effect pinning or to alert the client to
the existence of a DANE record.

Knowing whether the site supports IPv4 or IPv6 or both allows us to
optimize any A record lookup.

We could even specify the ASN number of the server IP address in the URI
record. Why might you want to know that? Well it allows a client to select
a server likely to be closer


The same mechanism can be used for a Web Service only there we would use
the protocol prefix of the Web Service rather than HTTP.

-- 
Website: http://hallambaker.com/