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?

Hoggard

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.

Abad

curiously, that page completely misses out XMPP (Jabber) and SIP, which utterly depend on SRV records. – Festinate

oh, and the reason _nicname._tcp.tld isn't used more widely is because its security model is broken. – Festinate

@Festinate How is its security model broken? Or any less secure than connecting to anything else by name? – Lingua

@NickWhaley the problem relates to the DNS hierarchy. Should, for example, _nicname._tcp.mydomain.com be able to override the real whois registry for .com for queries for mydomain.com. – Festinate

Hence for dnssec. But the interesting thing is not so much a broken security model but a broken understanding of what has been fixed and what is available. If not enough people know to use a feature then it withers away into obscurity (whois as directory servers, archie, and finger come to mind). Let alone a port scan is more effective than dns discovery anyways so most crackers will not bother with dns records other than to find vhosts. But staying on topic.. dnssec can validate the domain records and should also be supported on top of dns-sd by default. – Amphibolous

Email, calendar, and address book service providers seem to have adopted SRV records. – Occasion

@DwightSpencer my comment about the security model had nothing to do with DNSSEC or protocol security per se, but with domain delegation policies. With the different ways domains are sold in different TLDs, a whois client has no automatic way of knowing at what point in the DNS tree to find the _nicname._tcp label, short of using the Public Suffix List, which itself is a gross hack. – Festinate

This answer completely fail to explain things to me. Is the error page intentional? Is the incorrect certificate intentional? Should the link be something that is currently just broken? The answer just states the answer is "this", which doesn't help me any further. Please try actually giving the answer in the answer, instead of relying on some link (for which the error behavior may or may not be intentional) – Psoas

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.

Valedictory

How do we get that ball rolling? Is there already a 1.2 committee? – Hoggard

Are you referring to tools.ietf.org/html/rfc2782 ? I don't see a comment about pre-existing protocols. Help me find it? – Shcherbakov

@RobStarling Yes, RFC 2782. See the "Applicability Statement" section. – Valedictory

The summarize the 'Applicability Statement' section - clients SHOULD NOT use SRV records when the application protocol does not specify that SRV records SHOULD be used. See BCP 14 for a definition of SHOULD/SHOULD NOT. – Frauenfeld

@Frauenfeld That's irrelevant to the discussion of defining e.g., a new HTTP 1.2 or 3.0 which uses SRV by default… – Exasperation

Teddy and @RobStarling: I think the "Applicability Statement" has to be read in conjunction with the "Domain administrator advice" section, which states "SRV would have to coexist with address record lookups for existing protocols". I think the only way to reconcile these statements is to say that SRV should not be used until the associated protocol specification is updated to permit such use. At that point, both SRV and conventional A record should be provided, the latter for compatibility. It is a great pity we don't have this yet. It would make development on a single machine easier. – Compressor

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?

Festinate

No, I wouldn't take the risk now, but I want it not to be a risk in five years. I will be happy if, in five years, my SRV-enabled site works in all browsers, but the SRV failover doesn't work for those 1% of users still stuck on IE12. – Hoggard

What was the objection to tools.ietf.org/html/draft-andrews-http-srv-01 ? It seems extremely sane. No-one is forced to use SRV records and those who want to use them will just need a fall-back A record until the old browsers are retired. – Hoggard

@chrisdew I don't know, I wasn't active at the IETF back then. I'll ask the author when I see him next. – Festinate

The Andrews/Kottelin was updated in 2014: tools.ietf.org/html/draft-andrews-http-srv-02 – Frauenfeld

MX records exist and could have been implemented with SRV records if they existed back then. MX records work nicely: they are the standard default first mechanism to lookup for the MTA and if this fails then the emitting MTA can do A and AAAA records. Browsers could have the exact same mechanism and that would be a smooth transition. – Osteoporosis

@PatrickMevzek I'm working on it... tools.ietf.org/html/draft-bellis-dnsop-http-record-00 (new version due Monday) – Festinate

I know. TBH I was never convinced about the argument on performance against SRV. The fact is nowadays any single webpages needs dozens if not hundreds of DNS lookups, counting for all external resources in fonts, stylesheets, scripts, etc. So adding one lookup to this list won't drastically change anything. Also in the era of HTTP/2 (and hence multiplexing) and DOH, I am really really not convinced that SRV is not fitted for this use, and hence not really happy with anything that tries to basically redo SRV to make it happen on ports 80/443 – Osteoporosis

@PatrickMevzek the browser folks tell me that SRV won't work for them. In my draft I'm really just trying to make a CNAME analog that doesn't have the other issues that CNAME causes in the DNS (i.e. failure to co-exist alongside other records) – Festinate

One part of the newer proposal has this: "Issue parallel AAAA/A and HTTPSSVC queries for the name HOST." . Why browsers couldn't do AAAA/A + SRV in parallel just escapes me. I guess the new stuff will have more chance to go forward just based on who pushes it... – Osteoporosis

@PatrickMevzek there's more to it than that - the HTTPSSVC record proposal includes additional bootstrapping for HTTPS that you couldn't do with an SRV record. That's added value, which gives them a real incentive to deploy it. – Festinate

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.

Frauenfeld

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.

Cockadoodledoo