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

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).

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 Tuesday, 18 February 2014 00:06:00 UTC