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/
- Re: A mechanism to encode HTTP version informatio… Patrick McManus
- Re: A mechanism to encode HTTP version informatio… Adrien W. de Croy
- A mechanism to encode HTTP version information in… Phillip Hallam-Baker
- Re: A mechanism to encode HTTP version informatio… Amos Jeffries
- Re: A mechanism to encode HTTP version informatio… Amos Jeffries
- Re: A mechanism to encode HTTP version informatio… Adrien W. de Croy
- Re: A mechanism to encode HTTP version informatio… Phillip Hallam-Baker
- Re: A mechanism to encode HTTP version informatio… Eliot Lear
- Re: A mechanism to encode HTTP version informatio… Phillip Hallam-Baker
- Re: A mechanism to encode HTTP version informatio… Phillip Hallam-Baker
- Re: A mechanism to encode HTTP version informatio… Adrien W. de Croy
- Re: A mechanism to encode HTTP version informatio… Phillip Hallam-Baker
- Re: A mechanism to encode HTTP version informatio… Adrien W. de Croy
- Re: A mechanism to encode HTTP version informatio… Amos Jeffries