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

As a reminder, since it's been a while since we first had this discussion.

The main problem with SRV is that it uses sub-domains as the basis of
differentiating different protocols.  e.g., _http._tcp.example.com.
This might be an important feature.  This likely results in additional
latency, particularly since zone cuts appear here frequently and
retrieval might then require additional queries.  This is why Eliot
proposed a new RR type that includes service type as an additional
parameter, closer instead to NAPTR.

On 16 February 2014 21:01, Josh Goodall <joshua.goodall@gmail.com> wrote:
> On 12/02/2014 11:58 p.m., Salvatore Loreto wrote:
>> +1 x DNS SRV
>>
>> but I think it would be great to generalise its usage to discover if a domain support HTTP/1.1 or HTTP/2 or both
>> independently if they run on different ports or on the same port.
>
> A strong +1 for mandating SRV for HTTP/2.x discovery, because:
>
> * It is also the way to lookup both IPv4 and IPv6 simultaneously in a single query/response. Today we have unfortunate race conditions with dual-stack browsers issuing double queries. IPv6 needs your support!
>
> * It does away with the naked-domain-can’t-be-an-alias bug. Hosting providers everywhere will cheer for you.
>
> * No new protocol should be using A (host) records to find service endpoints, SRV is the proper and extensible way. “A” is for Archaic. Philosophically, we shouldn’t lookup a hostname at all, we should lookup a service and be told on which host(s) to find it.
>
> See RFC6186 for a worked example of how SRV records can be adopted for a specific application. Note also, IANA/IETF already expected HTTP to be using SRV, see RFC6335 (BCP165) sec.5 which deprecated “www”… but it just never took off. Well now’s the only chance to fix that.
>
>
>
> Josh.
>
>
> * discussed well in http://labs.apnic.net/presentations/store/2012-08-28-dual-stack-quality-apnic34.pdf
>
>

Received on Monday, 17 February 2014 19:49:18 UTC