Re: A mechanism to encode HTTP version information in DNS

Phillip Hallam-Baker <hallam@gmail.com> Sun, 17 February 2013 18: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 7045F21F84E2 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sun, 17 Feb 2013 10:21:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.574
X-Spam-Level:
X-Spam-Status: No, score=-9.574 tagged_above=-999 required=5 tests=[AWL=1.024, 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 Q2qF+zUjphP3 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sun, 17 Feb 2013 10:21:27 -0800 (PST)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 0BC3121F8AC8 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Sun, 17 Feb 2013 10:21:26 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1U78pm-0003Xp-6v for ietf-http-wg-dist@listhub.w3.org; Sun, 17 Feb 2013 18:19:30 +0000
Resent-Date: Sun, 17 Feb 2013 18:19:30 +0000
Resent-Message-Id: <E1U78pm-0003Xp-6v@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 1U78pd-0003Wg-1Q for ietf-http-wg@listhub.w3.org; Sun, 17 Feb 2013 18:19:21 +0000
Received: from mail-wg0-f48.google.com ([74.125.82.48]) by lisa.w3.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <hallam@gmail.com>) id 1U78pb-00023x-PH for ietf-http-wg@w3.org; Sun, 17 Feb 2013 18:19:20 +0000
Received: by mail-wg0-f48.google.com with SMTP id 16so3974947wgi.3 for <ietf-http-wg@w3.org>; Sun, 17 Feb 2013 10:18:53 -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=wbbtkso0/F4mMrtdMs9S2avP70xfHWUknhVKfvqQqrw=; b=kw9HxYgM5+HsCYh72NTWcX/n9bCRkf8B6toYUL4MCLJXVSZCusRAdo1yPAJ9s5eul1 69VqEzbDpx3KKq4zWnYLxbPSYnY0KSQNu8eHCoJb/SSxdEX3qxu7gdLMXI9+oesqpw+u cEo7xlJ6O39UIryisLDwtfm2Ae3bY/XCksiYmePkePVl8FI2YFcH5CXy6+MlQyASw4p0 NvErLyg8IS/ymWMt+2gx21/5t6saxEq6FKDH4xjkvvxSwKp39TFve5ksROmVHKvjwPKn iiQvboVoneAA+nWZ8ga+voON97CDOuu6SJCYav1vlnW89kgQda+bRw0s1kE/teYIZWA9 V3mQ==
MIME-Version: 1.0
X-Received: by 10.180.105.232 with SMTP id gp8mr15804964wib.33.1361125133281; Sun, 17 Feb 2013 10:18:53 -0800 (PST)
Received: by 10.194.176.169 with HTTP; Sun, 17 Feb 2013 10:18:53 -0800 (PST)
In-Reply-To: <CAOdDvNqL7JQG2YttKjPddYSwbEQvJD1ryK8T6ZbezXsQMQxrPw@mail.gmail.com>
References: <CAMm+Lwgawnwaybqf9vfTNbC3OZHGaQN0tkPWT8UAW-taj+1gQQ@mail.gmail.com> <5120B80C.5070809@cisco.com> <CAOdDvNqL7JQG2YttKjPddYSwbEQvJD1ryK8T6ZbezXsQMQxrPw@mail.gmail.com>
Date: Sun, 17 Feb 2013 13:18:53 -0500
Message-ID: <CAMm+Lwi_JAwBqQn5wXimMM7qY9dr-LypfY61DqsrTMskUWZw7w@mail.gmail.com>
From: Phillip Hallam-Baker <hallam@gmail.com>
To: Patrick McManus <mcmanus@ducksong.com>
Cc: Eliot Lear <lear@cisco.com>, "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary=f46d044402d0106acf04d5efa4b6
Received-SPF: pass client-ip=74.125.82.48; envelope-from=hallam@gmail.com; helo=mail-wg0-f48.google.com
X-W3C-Hub-Spam-Status: No, score=-3.3
X-W3C-Hub-Spam-Report: AWL=-2.481, 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 1U78pb-00023x-PH ff0eac3994c2cf94be693dca3714752b
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+Lwi_JAwBqQn5wXimMM7qY9dr-LypfY61DqsrTMskUWZw7w@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/16627
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>

The answer I think the DNS folk will give is that A and AAAA should be the
only records that translate DNS names to IP addresses and that if a server
gets a request for a record like SRV then it should deliver any A/AAAA
records referenced as additional records.

I am not saying I agree with that analysis but it is the one I think they
will give...


The administrative issue I think they would worry about is the case where
there are multiple services on the same host and the desire is to change
the IP address of the host as an atomic action.

Again, I am not sure that is a necessary consideration. What might be more
of a consideration is wanting to ensure IPv4/v6 compatibility.


Is there any reason not to use the built in DNS additional records
mechanism? It only works when the server for the URI / SRV record is also
the server for the A record. BUT this is what you would want. in the rare
case that you would have the A record on a different DNS server it would be
because you wanted another admin to manage the mapping. That is the
argument for MX records at any rate (I think).


On Sun, Feb 17, 2013 at 11:14 AM, Patrick McManus <mcmanus@ducksong.com>wrote;wrote:

> That's the right goal :)
>
>
>
> On Sun, Feb 17, 2013 at 5:59 AM, Eliot Lear <lear@cisco.com> wrote:
> > 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/