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

From: Josh Goodall <[email-masked]>
Date: Mon, 17 Feb 2014 16:01:50 +1100

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

---

From: Martin Thomson <[email-masked]>
Date: Mon, 17 Feb 2014 11:48:50 -0800

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.

---

From: Eliot Lear <[email-masked]>
Date: Mon, 17 Feb 2014 22:29:29 +0100

Hi,

> parameter, closer instead to NAPTR.

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.

Eliot

---

From: Josh Goodall <[email-masked]>
Date: Tue, 18 Feb 2014 10:08:34 +1100

Hi,

> be the same as for the A or AAAA.  On the other hand, then you have to

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

---

From: Eliot Lear <[email-masked]>
Date: Tue, 18 Feb 2014 06:43:45 +0100

Josh,

>   saying it can’t happen, but I haven’t seen it in ten years of

It happens with great regularity in enterprise environments and is the
preferred method for scaling Microsoft AD.  Typically the zone is
delegated to the directory server.  In fact, one enterprise
administrator I spoke with about this didn't realize you had the option
to NOT delegate the _TCP zone.

>   explicit in URL e.g. I think the Diameter protocol includes this).

It is possible to use a new scheme name, but that has been rejected in
the past due to the so-called "side of the bus" problem.  Eg, what do
you do when you see "Go to MyFavoriteExampleDentist.com"?  I think Mark
just wrote a draft entitled draft-nottingham-uri-get-off-my-lawn that
says not to encode too much semantics in the URI itself.
> records get special treatment that way. That's *fewer* queries.

I agree the use of the SRV record to get the AAAA record in additional
data is attractive when the information is authoritatively available
(e.g., in the same zone), but there are problems with that as well,
because that information can't be signed.
> to entry, and given that I think the case for SRV remains strong.

And my own thinking about this is that you shouldn't have a single path
to success.  Michael Welzl just presented a very strong argument about
this sort of thing at the ITAT workshop.  Use whatever gets you there. 
But I would caution that use of multiple records would be a bad idea. 
Let's pick one (or fewer) and get on with it.

There are a few other issues with SRV.  For one thing, it cannot provide
protocol version information in the RDATA.  That means you would have to
do multiple queries once we get beyond h2.  And we have all but
eliminated any protocol extension mechanism at the http level in
Zürich.  Bad combination.
Eliot

---

From: Eliot Lear <[email-masked]>
Date: Tue, 18 Feb 2014 10:52:54 +0100

Replying to myself, I'd like to make one point clear:

It is ABSOLUTELY okay to use SRV so long as we accept that in some
circumstances there will be some performance degradation, and that we
will need to sort versioning beyond h2.  That latter issue implies some
IN BAND upgrade mechanism for h2->hN.  In the case of TLS, we might
simply handle this with ALPN, but someone from the TLS side should think
about this in the context of a fast restart.

Eliot

---

From: William Chan (陈智昌) <[email-masked]>
Date: Tue, 18 Feb 2014 17:02:42 -0800

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

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

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?
Because that's what we have today, with a potential for also using SRV
records or a new RR type. If you're saying that we can't use the
in-band advertisement mechanisms and MUST ONLY rely on SRV records,
then I'm afraid this is completely unacceptable.

---

From: Dan Wing <[email-masked]>
Date: Tue, 18 Feb 2014 22:18:36 -0800

>  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

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 20 Feb 2014 20:23:41 +1100

> about this in the context of a fast restart.

This is what’s concerned me in the past. We’ve made a lot of decisions based upon the assumption that introducing h3…hn (as well as other protocol identifiers) won’t require adding more round trips.

Now, with ALPN, that may be OK, but it doesn’t help for non-TLS deployments, such as they are.

Cheers,

--
Mark Nottingham   http://www.mnot.net/

---

From: Eliot Lear <[email-masked]>
Date: Thu, 20 Feb 2014 17:26:59 +0100

> Now, with ALPN, that may be OK, but it doesn’t help for non-TLS deployments, such as they are.

Well, the round trip is hidden in a TLS capabilities exchange and I
really would like to hear how it plays in the context of fast restart. 
An Upgrade header can accomplish the same goal in non-TLS. 

But let's remember how we got here: we got here because we wanted to NOT
have to have exchanges for ANY of this.  SRV doesn't solve that problem,
but the WG thus far has not decided that it is a problem they want to
solve.  Okay by me.  I put the first draft out there because of the
initial expression of interest.  Maybe there's interest now?  I don't know.

Eliot

---

From: Martin Thomson <[email-masked]>
Date: Thu, 20 Feb 2014 09:15:15 -0800

> This is what’s concerned me in the past. We’ve made a lot of decisions based upon the assumption that introducing h3…hn (as well as other protocol identifiers) won’t require adding more round trips.

In the general case, I don't think that this is a concern.  There is
an expectation that somewhere you are able to select between nothing
(i.e. HTTP/1.1) and "h2".  As long as that is general enough,
selecting "h3" instead should be no concern.  ALPN does that
trivially.

That doesn't mean that it can't be screwed up somehow.  Anything that
was serialized somehow (nothing -> h2 -> h3 -> h4 ...) would be an
issue, but then that's also an issue for HTTP/2, because it puts
HTTP/2 at a disadvantage.

I'm confident that, once we are aware of this constraint (which may
happen in time), we won't allow a solution that doesn't have such
undesirable properties.

---

From: Martin Thomson <[email-masked]>
Date: Thu, 20 Feb 2014 09:21:17 -0800

> really would like to hear how it plays in the context of fast restart.

I don't know what you mean by "fast restart" here, but looking at some
of the proposed TLS 1.3 cases for fast handshakes, and session
resumption, you end up in a state where the choice from the last
session is maintained by default.  A client can of course opt to use
the longer handshake form in an attempt to move to another selection;
similarly the server can reject the resumption/fast handshake and fall
back to a complete negotiation.

There's a risk there that any choice becomes excessively "sticky" over
time, by which I mean that a choice to use "h2" could persist longer
than would otherwise be ideal.  I'm inclined to rely on operational
guidance (deploy "h3", reject resumptions or shortened handshakes from
prior to when the deployment occurred) rather than build additional
protocol machinery.  After all, that same guidance is going to be
necessary for cipher suite selection and other things as well.

---

From: Eliot Lear <[email-masked]>
Date: Thu, 20 Feb 2014 18:48:02 +0100

> necessary for cipher suite selection and other things as well.

Thanks, Martin.  This captured and addressed my concern.

Eliot

---

From: Josh Goodall <[email-masked]>
Date: Fri, 28 Feb 2014 06:21:01 +1100

Hi,

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

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]

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

---

From: William Chan (陈智昌) <[email-masked]>
Date: Thu, 27 Feb 2014 11:34:36 -0800

On Thu, Feb 27, 2014 at 11:15 AM, Josh Goodall <[email-masked]>wrote:

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

It'd be curious to see which client would respect this MUST and the
preference ordering you described. Let's review the game theory behind
moving first here. If I own a popular client and I switch to mandatory SRV
lookup, and don't issue A and AAAA queries until the SRV lookup fails, then
for the services and paths where SRV lookup doesn't work, user experience
will be vastly degraded. I'm not sure how long a timeout would be, but if
you hit the timeout, that's probably a horrible user experience. This is
probably enough, at least for browser users, for them to switch to other
browsers which don't feel as slow. I don't think any browser vendor would
want to move first here. Indeed, I think the user experience cost is
terrible enough that I don't see any browser vendor moving at all here.

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.

>
> 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]
>
>
> [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.
>
> [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.
>
>

---

From: Patrick McManus <[email-masked]>
Date: Thu, 27 Feb 2014 20:01:40 +0000

I'm with will on this one - but even more so than it being a competitive
non-starter, adding latency to existing http/1 use cases is also something
to be avoided. The interactive web is a different beast than smtp.

On Thu, Feb 27, 2014 at 7:34 PM, William Chan (陈智昌)
<[email-masked]>wrote:

>> which conveniently also supplies adequate support at last for IPv6, apex
>> naked domains, alternative ports and the other benefits of SRV[2]. And
>> [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

---

From: Josh Goodall <[email-masked]>
Date: Fri, 28 Feb 2014 08:52:26 +1100

On 28 Feb 2014, at 6:34 am, William Chan (陈智昌) <[email-masked]> 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.

---

From: Amos Jeffries <[email-masked]>
Date: Fri, 28 Feb 2014 19:17:32 +1300

> lookup in clients is a MUST not a MAY, and for the hosting setup

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.

> SRV[2]. And performance becomes a stick to drive the adoption

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

---

From: Amos Jeffries <[email-masked]>
Date: Fri, 28 Feb 2014 19:46:13 +1300

> to be NXDOMAIN before proceeding to use address records?

Squid has for the past year or so been using pretty much this algorithm
of parallel queries with a response barrier to reduce latency over the
IPv6 rollout. In our case the response barrier is having both A and AAAA
back instead of a SRV response.

For overall latency reduction and the common case it has been a great
benefit compared to serial lookups.

However, we are still facing complaints that for some URLs a whole
timeout span (seconds/minutes) is waited for even though one of the
results has been returned in a few ms. This has been directly tracked
down to DNS resolvers simply not responding to one query out of the
pair. Usually the IPv6 response from broken DNS resolvers.

In practice the barrier waiting makes this algorithm *worse* in
performance than the happy-eyeballs algorthim for the case where the
timing difference of lookups matters most.

Of course that is not going to be the whole story for your proposal
since the overhead latency from determining HTTP version is also varying
between each query type.

/2c
Amos

---

From: Cory Benfield <[email-masked]>
Date: Fri, 28 Feb 2014 08:59:36 +0000

> timing difference of lookups matters most.

This seems like a key problem to me. UAs that are browser-like will be
able to mitigate the latency involved here by doing things like DNS
prefetching, but non-browser UAs and proxies don't have that luxury.
In particular, a mandate that conforming HTTP/2.0 clients MUST wait
for an SRV lookup to timeout before proceeding will kill clients like
mine stone-dead by providing a gargantuan potential performance hit.
This will mean that either we choose not to conform, or we give up and
get our lunch eaten by non-conforming implementations.

If we're determined to use SRV for discovery (and I see no reason not
to), happy-eyeballs seems like the better route to me.

Cory