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

On 28 Feb 2014, at 6:34 am, William Chan (陈智昌) <willchan@chromium.org> wrote:
> It'd be curious to see which client would respect this MUST and the preference ordering you described.

The game-theoretic view of browser competition was an illuminating
unpack, thank you. It especially applies in the case where a user
has an unreliable connection and/or ISP DNS resolver. Then they
will choose a browser that minimises the pain. So browser vendors
will implement for that. I get it.

> Note that none of what I've said necessarily applies to optionally doing SRV and using it when the results are available. It's mostly the MUST requirement and the serial behavior you've outlined that looks troubling from an actual deployment viewpoint. 

Logically - this is similar but faster than serial and safer/more
deterministic than the current lookup race - how about allowing a
parallel query (as a MAY) but requiring the SRV (or SVCINFO) answer
to be NXDOMAIN before proceeding to use address records?

In the common case (which is what we should optimise for) the answers
should be returned from the resolver close enough to simultaneously
not to impact the user.

This could be specified as simply a refinement to RFC6555 “Happy
Eyeballs” which some browsers may already implement.

Note that in the worst case, i.e. a legacy site with no service
name records and unreliable authoritative nameservers, they are
already screwed by the unreliable nameservers. But ISP resolvers
will help with caching the service name NXDOMAIN to much the same
extent as they already do the address records. So this is not in
my view a case to worry about.

Note also also that in RFC 4472 “Considerations with IPv6 DNS” the
first recommendation to avoid nondeterministic race conditions is
“use service name records”, with ease of migration being a primary
reason. This process, now, is pretty much the only opportunity to
make that happen.


Josh.

Received on Thursday, 27 February 2014 21:52:59 UTC