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

On 28/02/2014 8:21 a.m., Josh Goodall wrote:
> Hi,
> 
> On 19 Feb 2014, at 12:02 pm, William Chan (陈智昌) <willchan@chromium.org> wrote:
> 
>>> A strong +1 for mandating SRV for HTTP/2.x discovery, because:
>>
>> I'm open to speccing out SRV for HTTP/2 and potentially using it. But
>> I think mandating it is silly.
> 
> Ah, yes. To clarify in standards language: I think support for SRV
> lookup in clients is a MUST not a MAY, and for the hosting setup
> probably a SHOULD[1].

Ah no. Do not overlook that the SRV is *only* for optimizing the final
X->server hop in HTTP.

HTTP is an N-hop client<->middle...ware<->server protocol and SRV
records provided by the server domain has no reasonable way to indicate
what the middleware should be for any given client. Only for the final
hop is it at all useful.

> 
> I also think it should be preferred, that is, the raw IPv4 and IPv6
> address record queries should be tried only after a query for SRV
> records has failed - and yes this means hosting providers who don’t
> adopt SRV in their DNS will bear the burden of a triple, rather
> than a single lookup.
> 
> Note that this semantic has precedent - it is how the transition
> to MX records for email delivery was made and is called the “implicit
> MX” rule. I think HTTP/2.x should have a similar “implicit SRV”
> rule as the wise way to define the behaviour. See RFC5321 s5.1.
> 
> So the positive incentive is declarative DNS support for h2 upgrade,
> which conveniently also supplies adequate support at last for IPv6,
> apex naked domains, alternative ports and the other benefits of
> SRV[2]. And performance becomes a stick to drive the adoption
> donkey.[3]
> 

Perhapse. But it is a short stick. One with a big fuzzy ball on the end.

By that I mean that it looks very attractive, but the more it tempts
client implementations to support only SRV the more DNS interception
will be rolled out and break the DNSSEC and other security enhancing
efforts.

Amos

> 
>> It's not immediately clear to me the extent to switch you are pushing
>> back on A record use. Do you think in-band discovery (well,
>> advertisement) via TLS-ALPN or HTTP Upgrade are acceptable mechanisms?
> 
> Yes. I'm not suggesting those should be out.
> 
> 
> regards
> Josh.
> 
> 
> [1] This is a compromise. If one were designing a new protocol with
> no legacy concerns then I would strongly push for SRV as the only
> acceptable DNS record type for server discovery.
> 
> [2] Fallback server & weighted-round-robin if you want them.
> 
> [3] I know Eliot has expressed concerns about both future-proofing
> for h3, and for resolver performance at the <10% of sites that have
> zone cuts at _tcp.example.com in their public DNS. However, I think
> those are both manageable issues and do not outweigh the benefits
> of a DNS record that is immediately supported by practically all
> servers & hosting providers, and that solves several other lingering
> problems right off the bat.
> 
>

Received on Friday, 28 February 2014 06:18:03 UTC