Why do browsers not use SRV records?

Question

Why do browsers not use SRV records?

It seems like a minimal amount of work and it will make the server-side implementation of reliable websites much simpler.

For example, you can specify tiers, such that www.example.com resolves to 1.2.3.4 and 2.3.4.5, and only if neither of those are available, try 4.5.6.7.

SRV records have been around for years...

Is there something I'm missing here?

Answer 1

Jonathan de Boyne Pollard provides the following Frequently Given Answer.

You've come to this page because you've said something similar to the following:

SRV record support hasn't even made it into web browsers yet, let alone clients of less-common protocols.

This is the Frequently Given Answer to such statements.

Answer 2

The RFC for SRV records specifies that it may not be used by pre-existing protocols which did not already specify the use of SRV records in their specifications. I.e. no SRV in the HTTP spec - browsers are, by the SRV standard, prohibited from using it.

This does not prohibit a new HTTP 1.2 standard from specifying the use of SRV records, though. However, Mark Andrews proposed this in April 2007 to the IETF HTTP working group, but got no response.

Answer 3

There have been two efforts to introduce this that I know of:

1. draft-andrews-http-srv (2002)

2. draft-jennings-http-srv (2009)

The "Open Issues" paragraph of the latter draft is illuminating:

The big open issue seems to be if one should just update the HTTP
scheme to do this SRV lookup and not create a new scheme.  The 00
version of this draft did that.  A new scheme makes this somewhat
unusable for general web surfing while using the old scheme results
in a very long transition times where different clients resolve URLs
in different ways.

and that is the crux of the matter. If your site relies on SRV records to be found, it won't work for some users until every browser supports it.

Would you take that risk, without some sort of transition mechanism?

Answer 4

Because:

1. The current HTTP RFC does not specify a symbolic service name for use in SRV records and does not specify that SRV records should be used (cf. RFC 2782, Applicability Statement).
2. It may negatively impact the latency in browsers and browser vendors want to first see it standardized for http by the IETF (cf. chromium bug report)
3. It may be kind of complex to integrate it into existing browsers (cf. firefox bug report)
4. Vendors don't want to say why (cf. webkit bug report)

The latest draft for adding SRV records to HTTP is andrews-http-srv-02 from 2014 which includes security and transitional considerations. It is more complete than the jennings-http-srv-05 draft from 2009. For example, it specifies a security relevant algorithm for choosing the port when it is given in the URL and there is a SRV record (which also includes a port field) - where the jennings draft does not look into this issue.

Answer 5

I was hoping they would standardize SRV for years, but no luck. For most, this would be essential, only scalability outweighs the disadvantages, everything they say about speed and compatibility is just a bad excuse. If the server wants SRV records to be analyzed and applied, why not provide this option to users? About compatibility and other issues - we live in the era of DoH, DoQ, DoT, which are not super-compatible, fast, but very useful, forge metal when it's hot, find no excuses, just do it.