Re: A mechanism to encode HTTP version information in DNS

Phillip Hallam-Baker <hallam@gmail.com> Sun, 17 February 2013 22:07 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 4058521F844C for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sun, 17 Feb 2013 14:07:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.172
X-Spam-Level:
X-Spam-Status: No, score=-9.172 tagged_above=-999 required=5 tests=[AWL=1.426, 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 TsqaNkbE1BJr for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sun, 17 Feb 2013 14:07:33 -0800 (PST)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id C627C21F844A for <httpbisa-archive-bis2Juki@lists.ietf.org>; Sun, 17 Feb 2013 14:07:32 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1U7CNL-00080R-0C for ietf-http-wg-dist@listhub.w3.org; Sun, 17 Feb 2013 22:06:23 +0000
Resent-Date: Sun, 17 Feb 2013 22:06:23 +0000
Resent-Message-Id: <E1U7CNL-00080R-0C@frink.w3.org>
Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <hallam@gmail.com>) id 1U7CNB-0007zh-H3 for ietf-http-wg@listhub.w3.org; Sun, 17 Feb 2013 22:06:13 +0000
Received: from mail-wi0-f172.google.com ([209.85.212.172]) by maggie.w3.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <hallam@gmail.com>) id 1U7CN9-0005HJ-I9 for ietf-http-wg@w3.org; Sun, 17 Feb 2013 22:06:13 +0000
Received: by mail-wi0-f172.google.com with SMTP id ez12so2838403wid.11 for <ietf-http-wg@w3.org>; Sun, 17 Feb 2013 14:05:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=6KCl/pqNVs5Vps0y8Lb+RAOsddEl79HeuEFj7cnadRU=; b=LxURXbNJypepcsbaB/dIUHQmXqhSd52Lj53Ve92iM/q8KO/qL3PvcvbeugHsgJrLc0 WCyS2WJKhoTe7HipxsslmRmBUZrdfvIYCJ3H+Vt/1ef7JcKcdQXm+/HQzbzE/a3ER35E wCSZ3ze6VD3GNfVV44oonvAbKgbOv8c/Itf/pOugG6YoHmVZeM5GSNxGtfC+WDVKQZR2 4zfZPGWwnF4ctTSSqWEgBcQTRDthiQMnoSyZ7nDVez67mTbov1U5mQw5ww55o0AQG4l0 Us0acNhcJ0OcmnHEBqQKZspMVHRxSo3OZ6wR8GtZiT+wkD2A1IEAh2R0mctlmbtRdzpo m4zg==
MIME-Version: 1.0
X-Received: by 10.180.105.232 with SMTP id gp8mr16378968wib.33.1361138744937; Sun, 17 Feb 2013 14:05:44 -0800 (PST)
Received: by 10.194.176.169 with HTTP; Sun, 17 Feb 2013 14:05:44 -0800 (PST)
In-Reply-To: <em19001c37-6187-47f9-abbf-616f745bbdfa@bombed>
References: <5120B80C.5070809@cisco.com> <em19001c37-6187-47f9-abbf-616f745bbdfa@bombed>
Date: Sun, 17 Feb 2013 17:05:44 -0500
Message-ID: <CAMm+Lwhdk0e-=6TEXR++ELTwmyBFsWN9LhBbpW7Y7ijW9Kn1Sg@mail.gmail.com>
From: Phillip Hallam-Baker <hallam@gmail.com>
To: "Adrien W. de Croy" <adrien@qbik.com>
Cc: Eliot Lear <lear@cisco.com>, "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary=f46d044402d061cb8b04d5f2cf97
Received-SPF: pass client-ip=209.85.212.172; envelope-from=hallam@gmail.com; helo=mail-wi0-f172.google.com
X-W3C-Hub-Spam-Status: No, score=-4.5
X-W3C-Hub-Spam-Report: AWL=-1.754, BAYES_00=-1.9, 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: maggie.w3.org 1U7CN9-0005HJ-I9 588ab6740e1a529b5a1c3505f5cfc2cd
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/CAMm+Lwhdk0e-=6TEXR++ELTwmyBFsWN9LhBbpW7Y7ijW9Kn1Sg@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/16631
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>

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/