Hacker News Reader

Comment by Lukasa | Hacker News Reader

> Why doesn't the HTTP/2 protocol use SRV DNS records?

This was discussed by the WG. The best rationale is given in the thread starting from this mail[0] from Will Chan at Google, followed up by this one[1] from Amos Jeffries (Squid Proxy). The summary is: waiting for SRV lookups can be slower than just doing straight-up A records, so no client in a competitive space is going to do it.

Everyone agrees that in an ideal world this would be great, but in practice no-one is going to be the first person to move on that front. The wins aren't big enough and the cost is too high.

[0]: http://lists.w3.org/Archives/Public/ietf-http-wg/2014JanMar/... [1]: http://lists.w3.org/Archives/Public/ietf-http-wg/2014JanMar/...

View on HN

I am not convinced. The same argument (“another round-trip makes it slow”) is sometimes made about Javascript libraries, and the corresponding counter-argument applies here, too: It’s usually cached, anyway, and DNS caches are also much better, since DNS record caching is much more deeply integrated in your OS, your ISP, etc, than HTTP caching, which is usually only in each individual HTTP client. The cache times are also longer for DNS (or could certainly be so, since with SRV handling redundancy there is no need to keep low TTLs anymore).

Agreed, additionally in the common case of users behind http proxies, dns caches would commonly be populated.

Notice that Amos was arguing for a happy-eyeballs approach, which removes the round trip. The issue isn't the wait for an extra round trip, it's making it mandatory to wait for an SRV result before using an A result.

If the language says "You MUST consult SRV records for _http2._tcp before you use the result of an A lookup", then anything that delays that SRV lookup will delay page resolution. Browsers are strongly disincentivised from making anything slow, so it's just safer not to add the extra delay point. If we specced that, no-one would do it.

Better to have what we have now, which is: do SRV if you want.

The SRV record should normally be cached, so it would not be slow just for existing.

What Amos was talking about is the problem of some resolvers not returning an answer at all, not even NXDOMAIN or an empty authoritative answer, due to the fact that he queried for AAAA records and some resolvers are buggy and can’t handle those queries. SRV is irrelevant to this problem, except that using “happy-eyeballs” and requiring A and AAAA has problems.

What William Chan (陈智昌) was talking about was where a query for SRV records fail, causing a long timeout. But this is not the normal case; normally you get an answer (perhaps an empty one) immediately. And since this has nothing to do with IPv6 and buggy resolvers, I don’t know why this situation should be considered common enough to optimize for. (Clients which really wanted to mitigate this could certainly detect this case when it happens and keep a blacklist.)

> […] anything that delays that SRV lookup will delay page resolution.

You keep implying that such things will happen. They won’t. There is no reason for an SRV record lookup to delay page resolution any more than an A (or AAAA) record lookup.

> If we specced that, no-one would do it.

Are you seriously saying that even if the HTTP/2 standard came out and it said “A client MUST lookup an SRV record and use it if one exists, and not use any A or AAAA records before the non-existence of an SRV record can be confirmed.”, that the browser vendors would simply ignore this? If that’s the case, why do we even have a standards process? Why do we even pretend to write RFCs if we can just assume that every implementer will ignore the standard and do whatever they feel like?

No, a thing which would be a net win for the Internet in general should go in the standard. RFC writers should not bow to fears of what Google, IBM, or General Motors might or might not do. Or, at least, wait until they make the threat of non-compliance openly.

Last I looked, the HTTP/2 RFC didn't even specify DNS at all.

I regard this as the worst-case scenario. It is a baffling omission. The HTTP URI scheme [RFC7230] does nothing to clarify matters:

"If host is a registered name, the registered name is an indirect identifier for use with a name resolution service, such as DNS..."

In my view the WG has the opportunity to definitively fix the problems of dual-stack discovery and of apex record service names, and the refusal to do so is exceedingly disappointing. We're left with implementations of Happy Eyeballs that have lookup race conditions and therefore nondeterministic behaviour.

All the arguments against using service records are actually complaints about artefacts arising from the current ambiguity in resolution practices, and thereby perpetuate the problem.

The proper choice should be that all IPv6 sites should be resolved via SRV rather than raw AAAA lookup - this is the soft introduction that over the years will ramp up to a global first preference for service records, and remains compatible as a variation on Happy Eyeballs.

But entrenched positions don't change and I have no clout with the WG or with browser product managers, so I gave up.

Interesting.

Reading that I'm not sure the problem is that SRV lookups are slower, but that forcing clients to do a SRV lookup, wait, and then a A/AAAA queries is slower:

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

However,it appears that making SRV optional remains a possibility:

Note that none of what I've said necessarily applies to optionally doing SRV and using it when the results are available.

[1] http://lists.w3.org/Archives/Public/ietf-http-wg/2014JanMar/...

Correct, but you don't need the RFC to make SRV optional. If you'd like to use it, use it.

No, on the contrary, the SRV standard specifies that clients SHOULD NOT use SRV records for protocols for which the standards do not explicitly allow for SRV records.

Multi-request resolving (QDCOUNT > 1) would solve that problem, which is a lesser known feature of the DNS protocol. Clients could ask for all A, AAAA, and SRV for a given domain, and get all the replies in a single round-trip.

Few if any resolvers support this feature, but it show that the problem we have is because of legacy assumption that are no longer true. Fix those, and the problem goes away.

: https://www.ietf.org/rfc/rfc1035.txt

The key words in your quote is “for the services and paths where SRV lookup doesn't work”. You get the same problem today where A lookup doesn’t work. This is an abnormal situation. As I wrote in another comment, normally you get an answer immediately (possibly an empty one where no SRV record exists). I don’t know why a situation with no reply should be considered common enough to optimize for. (Clients which really wanted to mitigate this could certainly detect this case when it happens and keep a blacklist.)

Reply on news.ycombinator.com