4 ms·

> 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

• nl 12y ago
  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/0788.html http://lists.w3.org/Archives/Public/ietf-http-wg/2014JanMar/...
  • Lukasa 12y ago
    Correct, but you don't need the RFC to make SRV optional. If you'd like to use it, use it.
    • teddyh 12y ago
      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.
  • belorn 12y ago
    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 https://www.ietf.org/rfc/rfc1035.txt
  • teddyh 12y ago
    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.)
• teddyh 12y ago
  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).
  • jamespo 12y ago
    Agreed, additionally in the common case of users behind http proxies, dns caches would commonly be populated.
  • Lukasa 12y ago
    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.
    • teddyh 12y ago
      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.)
• inopinatus 12y ago
  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.