W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2013

Re: A mechanism to encode HTTP version information in DNS

From: Patrick McManus <mcmanus@ducksong.com>
Date: Sun, 17 Feb 2013 11:14:56 -0500
Message-ID: <CAOdDvNqL7JQG2YttKjPddYSwbEQvJD1ryK8T6ZbezXsQMQxrPw@mail.gmail.com>
To: Eliot Lear <lear@cisco.com>
Cc: Phillip Hallam-Baker <hallam@gmail.com>, "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
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/
Received on Sunday, 17 February 2013 16:15:26 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:10 UTC