Re: A mechanism to encode HTTP version information in DNS
Eliot Lear <lear@cisco.com> Sun, 17 February 2013 11:02 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 1C15F21F8800 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sun, 17 Feb 2013 03:02:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.559
X-Spam-Level:
X-Spam-Status: No, score=-10.559 tagged_above=-999 required=5 tests=[AWL=0.039, 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 as322oXd6HAO for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sun, 17 Feb 2013 03:02:14 -0800 (PST)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 4698121F87F9 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Sun, 17 Feb 2013 03:02:14 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1U71yZ-00017L-VE for ietf-http-wg-dist@listhub.w3.org; Sun, 17 Feb 2013 11:00:07 +0000
Resent-Date: Sun, 17 Feb 2013 11:00:07 +0000
Resent-Message-Id: <E1U71yZ-00017L-VE@frink.w3.org>
Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <lear@cisco.com>) id 1U71yL-0006zc-DI for ietf-http-wg@listhub.w3.org; Sun, 17 Feb 2013 10:59:53 +0000
Received: from ams-iport-4.cisco.com ([144.254.224.147]) by maggie.w3.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <lear@cisco.com>) id 1U71yK-0005MT-1P for ietf-http-wg@w3.org; Sun, 17 Feb 2013 10:59:53 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13117; q=dns/txt; s=iport; t=1361098792; x=1362308392; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=JRMv34GAoGdmVHda2JbV+ATj01jGXX1Ofv1raV/5TXk=; b=S1q1LDNo9uG0y6ujx5yuPCTkB+Y+37u+qjqW6hozvgvV5jg+FU76tUgW s86Q+siMIKzcPMLO/rmVvS/npUl0qXCkfz69KwvF8zcW5Yhx36/sbxjhZ P4X93kuxH4nKsBNLT1we47BAhXBeheL2aLmfrd+Hp4n1Zer2BL1HdjMpi k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgEFANq2IFGQ/khN/2dsb2JhbABFhkm5U38Wc4IfAQEBBCNVARALGAkWCwICCQMCAQIBRQYNAQcBAYgODKtkkUiPNwcJgiSBEwOWLIEdjzuDCA
X-IronPort-AV: E=Sophos; i="4.84,682,1355097600"; d="scan'208,217"; a="11852924"
Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-4.cisco.com with ESMTP; 17 Feb 2013 10:59:25 +0000
Received: from ams3-vpn-dhcp5055.cisco.com (ams3-vpn-dhcp5055.cisco.com [10.61.83.190]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r1HAxOSu003966 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 17 Feb 2013 10:59:24 GMT
Message-ID: <5120B80C.5070809@cisco.com>
Date: Sun, 17 Feb 2013 11:59:24 +0100
From: Eliot Lear <lear@cisco.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: Phillip Hallam-Baker <hallam@gmail.com>
CC: "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
References: <CAMm+Lwgawnwaybqf9vfTNbC3OZHGaQN0tkPWT8UAW-taj+1gQQ@mail.gmail.com>
In-Reply-To: <CAMm+Lwgawnwaybqf9vfTNbC3OZHGaQN0tkPWT8UAW-taj+1gQQ@mail.gmail.com>
X-Enigmail-Version: 1.5
Content-Type: multipart/alternative; boundary="------------090802070102030804060304"
Received-SPF: pass client-ip=144.254.224.147; envelope-from=lear@cisco.com; helo=ams-iport-4.cisco.com
X-W3C-Hub-Spam-Status: No, score=-14.4
X-W3C-Hub-Spam-Report: AWL=0.610, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.556, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5
X-W3C-Scan-Sig: maggie.w3.org 1U71yK-0005MT-1P 74de8f52d76c6222138dde43d77de4c3
X-Original-To: ietf-http-wg@w3.org
Subject: Re: A mechanism to encode HTTP version information in DNS
Archived-At: <http://www.w3.org/mid/5120B80C.5070809@cisco.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/16624
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>
Phillip, You're hitting at the heart of a key issue, and rather than focus on mechanisms, I urge folk to take a look at the very beginning of draft-lear-httpbis-svcinfo-rr where I state design goals. One of those goals is to not harm latency. What you describe below introduces a dependency of QNAME on target, forcing an additional query, which is one of the key issues with SRV. Now, I am not saying that's the wrong thing to do. But I am saying that it violates that stated design goal. Maybe the goal is the wrong one to have? Eliot On 2/14/13 9:16 PM, Phillip Hallam-Baker wrote: > 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://example.com>' > _http._tcp.example.com <http://tcp.example.com> URI 10 10 > "http://www1.example.com/" > _http._tcp.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 <http://tcp.example.com> URI 10 10 > "https://www1.example.com/" > _http._tcp.example.com <http://tcp.example.com> URI 10 10 > "https://www2.example.com/" > > Or to advertise multiple protocols: > > _http._tcp.example.com <http://tcp.example.com> URI 10 10 > "http://www1.example.com/" > _http._tcp.example.com <http://tcp.example.com> URI 10 10 > "coap://www1.example.com/ <http://www1.example.com/>" > > Or to map a domain to a path on another server: > > _http._tcp.old.example.com <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 <http://tcp.example.com> URI 10 10 > "http://www1.example.com/ ipv4 ipv6" > _http._tcp.example.com <http://tcp.example.com> URI 10 10 > "http://www2.example.com/ http2" > _http._tcp.example.com <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