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

[Eliot Lear <[e-mail]>]

Replying to myself, I'd like to make one point clear:

It is ABSOLUTELY okay to use SRV so long as we accept that in some
circumstances there will be some performance degradation, and that we
will need to sort versioning beyond h2.  That latter issue implies some
IN BAND upgrade mechanism for h2->hN.  In the case of TLS, we might
simply handle this with ALPN, but someone from the TLS side should think
about this in the context of a fast restart.

Eliot

On 2/18/14, 6:43 AM, Eliot Lear wrote:
> Josh,
>
> On 2/18/14, 12:08 AM, Josh Goodall wrote:
>> Hi,
>>
>> On 18 Feb 2014, at 8:29 am, Eliot Lear <[e-mail]> 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
>
>
>