Re: A mechanism to encode HTTP version information in DNS

"Adrien W. de Croy" <adrien@qbik.com> Sun, 17 February 2013 22:33 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 82E4121E804A for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sun, 17 Feb 2013 14:33:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.29
X-Spam-Level:
X-Spam-Status: No, score=-10.29 tagged_above=-999 required=5 tests=[AWL=0.308, 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 o2tDyKZ-3HsR for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sun, 17 Feb 2013 14:33:10 -0800 (PST)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 04F5021E803A for <httpbisa-archive-bis2Juki@lists.ietf.org>; Sun, 17 Feb 2013 14:33:09 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1U7CmG-0002sF-81 for ietf-http-wg-dist@listhub.w3.org; Sun, 17 Feb 2013 22:32:08 +0000
Resent-Date: Sun, 17 Feb 2013 22:32:08 +0000
Resent-Message-Id: <E1U7CmG-0002sF-81@frink.w3.org>
Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <adrien@qbik.com>) id 1U7Clv-0002r4-Gf for ietf-http-wg@listhub.w3.org; Sun, 17 Feb 2013 22:31:47 +0000
Received: from smtp.qbik.com ([210.55.214.35]) by lisa.w3.org with esmtp (Exim 4.72) (envelope-from <adrien@qbik.com>) id 1U7Clt-0001I1-D1 for ietf-http-wg@w3.org; Sun, 17 Feb 2013 22:31:47 +0000
Received: From [192.168.0.10] (unverified [192.168.0.10]) by SMTP Server [192.168.0.1] (WinGate SMTP Receiver v7.5.0 (Build 3491)) with SMTP id <0019515427@smtp.qbik.com>; Mon, 18 Feb 2013 11:33:26 +1300
From: "Adrien W. de Croy" <adrien@qbik.com>
To: "Phillip Hallam-Baker" <hallam@gmail.com>
Cc: "Eliot Lear" <lear@cisco.com>, "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
Date: Sun, 17 Feb 2013 22:31:23 +0000
Content-Type: multipart/alternative; boundary="------=_MB923C84CC-2F24-49C1-A421-64FC8DB64A12"
In-Reply-To: <CAMm+Lwhdk0e-=6TEXR++ELTwmyBFsWN9LhBbpW7Y7ijW9Kn1Sg@mail.gmail.com>
Message-Id: <ema93fc065-474c-4ce7-99a5-4f5ee81e8858@bombed>
Mime-Version: 1.0
Reply-To: "Adrien W. de Croy" <adrien@qbik.com>
User-Agent: eM_Client/5.0.17263.0
Received-SPF: pass client-ip=210.55.214.35; envelope-from=adrien@qbik.com; helo=smtp.qbik.com
X-W3C-Hub-Spam-Status: No, score=-3.7
X-W3C-Hub-Spam-Report: AWL=-3.108, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.556, SPF_PASS=-0.001
X-W3C-Scan-Sig: lisa.w3.org 1U7Clt-0001I1-D1 a5c3b3c770357e1c3781885c2885ebd5
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/ema93fc065-474c-4ce7-99a5-4f5ee81e8858@bombed>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/16632
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>

basically anything in the name is not discoverable.

So if the name contains _tcp, we're not doing discovery on transport.  
We're presuming there is a _tcp deployment etc.

We should take a step back and ask what are we trying to discover.  It 
makes not much sense to me to leave transport out of that.


------ Original Message ------
From: "Phillip Hallam-Baker" <hallam@gmail.com>
To: "Adrien W. de Croy" <adrien@qbik.com>
Cc: "Eliot Lear" <lear@cisco.com>om>; "ietf-http-wg@w3.org Group" 
<ietf-http-wg@w3.org>
Sent: 18/02/2013 11:05:44 a.m.
Subject: Re: A mechanism to encode HTTP version information in DNS
>
>
>On Sun, Feb 17, 2013 at 4:31 PM, Adrien W. de Croy <adrien@qbik.com> 
>wrote:
>>
>>I've always thought one of the issues with SRV is the transport is in 
>>the wrong part - the name, so you can't specify that with the result.
>>
>>For something new, we should look at putting the transport into the RR 
>>data instead of the name
>>
>>then it makes it possible to deploy over multiple transports later on, 
>>e.g. SCTP, UDP whatever if desired.
>
>That is exactly what the URI RR does, the target is a URI which can of 
>course specify a new scheme.
>
>I think it best to treat _http._tcp as simply a code point 
>corresponding to the http URI scheme and the _tcp part as just a 
>default..
>
>If you wanted to specify a different transport then you would either 
>specify a different scheme or you would specify it as a discovery 
>parameter for that scheme.
>
>
>
>>------ Original Message ------
>>From: "Eliot Lear" <lear@cisco.com>
>>To: "Phillip Hallam-Baker" <hallam@gmail.com>
>>Cc: "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
>>Sent: 17/02/2013 11:59:24 p.m.
>>Subject: Re: A mechanism to encode HTTP version information in DNS
>>>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._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/
>>>
>
>
>
>--
>Website: http://hallambaker.com/