Re: issue 381: Discovery of the support of the HTTP2 protocol: DNS-based Upgrade

Josh,

On 2/18/14, 12:08 AM, Josh Goodall wrote:
> Hi,
>
> On 18 Feb 2014, at 8:29 am, Eliot Lear <lear@cisco.com> wrote:
>
>> Right.  I optimized for fewer queries.  The record format that I had was
>> one approach.  The key issue is that one should not have levels of
>> indirection in the RDATA, and even better that the QNAME for the record
>> be the same as for the A or AAAA.  On the other hand, then you have to
>> deploy a new RRtype.
> May I specifically address the issue of more queries? Yes it can
> happen - but I’m not sure it’s going to be a problem in the wild.
> I imagine that would only happen in two unlikely cases:
>
> * someone were to separately delegate the “_tcp” subdomain. Not
>   saying it can’t happen, but I haven’t seen it in ten years of
>   deploying SRV records.

It happens with great regularity in enterprise environments and is the
preferred method for scaling Microsoft AD.  Typically the zone is
delegated to the directory server.  In fact, one enterprise
administrator I spoke with about this didn't realize you had the option
to NOT delegate the _TCP zone.

>
> * If HTTP/2.x changes to specify more transports than TCP. Even
>   then, mechanisms exist to handle that too (new scheme names, or
>   explicit in URL e.g. I think the Diameter protocol includes this).

It is possible to use a new scheme name, but that has been rejected in
the past due to the so-called "side of the bus" problem.  Eg, what do
you do when you see "Go to MyFavoriteExampleDentist.com"?  I think Mark
just wrote a draft entitled draft-nottingham-uri-get-off-my-lawn that
says not to encode too much semantics in the URI itself.
>
> and one slightly more likely case:
>
> * using an alias in the RDATA of a SRV record is a common
>   misconfiguration that causes additional processing.
>
> In practise, most clients using SRV records see one DNS query packet,
> one response, job done. When properly configured, in-zone A and
> AAAA records come back in the Additional Data section, because SRV
> records get special treatment that way. That's *fewer* queries.

I agree the use of the SRV record to get the AAAA record in additional
data is attractive when the information is authoritatively available
(e.g., in the same zone), but there are problems with that as well,
because that information can't be signed.
>
> I have mixed feelings about new record types, they erect barriers
> to entry, and given that I think the case for SRV remains strong.

And my own thinking about this is that you shouldn't have a single path
to success.  Michael Welzl just presented a very strong argument about
this sort of thing at the ITAT workshop.  Use whatever gets you there. 
But I would caution that use of multiple records would be a bad idea. 
Let's pick one (or fewer) and get on with it.

There are a few other issues with SRV.  For one thing, it cannot provide
protocol version information in the RDATA.  That means you would have to
do multiple queries once we get beyond h2.  And we have all but
eliminated any protocol extension mechanism at the http level in
Zürich.  Bad combination.
Eliot

Received on Tuesday, 18 February 2014 05:44:14 UTC