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://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/