Re: A mechanism to encode HTTP version information in DNS

[Phillip Hallam-Baker <[e-mail]>]

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 <[e-mail]>wrote:

> That's the right goal :)
>
>
>
> On Sun, Feb 17, 2013 at 5:59 AM, Eliot Lear <[e-mail]> 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/