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 [RFC72

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.