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

On Feb 17, 2014, at 3:08 PM, Josh Goodall <joshua.goodall@gmail.com> 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.
> 
> * 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).

We don't want to do that.  Imagine the advertisement on the side of a bus or the back of a magazine would need to read "for further information, visit: www.example.com or http-quic://www.example.com".  That is hard to remember, hard to type, and marketing folks won't be too keen on the advantage of including that new scheme name.  As another worse problem, imagine someone is viewing interesting content with a URL with the new scheme name and they tweet that URL or post it to Facebook or email it to their friends, etc., but their friend doesn't have a browser that understands the new scheme name (http-quic) or that new scheme name is blocked on the friend's network (e.g., UDP is blocked).  That won't work well.

We are stuck with the HTTP scheme, and we are stuck with the current service name ("www.").  It's up to the computer to figure out how to connect the user to that resource, rather than the user's problem to type in the correct scheme name for some new transport or new protocol.

-d


> 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 have mixed feelings about new record types, they erect barriers
> to entry, and given that I think the case for SRV remains strong.
> 
> (I’d go so far as to suggest that support for SRV is present in all
> name servers and NS management tools these days and this is the
> compelling reason to prefer them)
> 
> Josh
> 
>

Received on Wednesday, 19 February 2014 06:19:05 UTC