Re: A mechanism to encode HTTP version information in DNS

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.


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