A mechanism to encode HTTP version information in DNS

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/