47

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?

Jeremy
  • 1
  • 85
  • 340
  • 366
fadedbee
  • 42,671
  • 44
  • 178
  • 308

5 Answers5

26

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.

Teddy
  • 6,013
  • 3
  • 26
  • 38
  • 4
    How do we get that ball rolling? Is there already a 1.2 committee? – fadedbee Jan 30 '12 at 12:28
  • 1
    Are you referring to http://tools.ietf.org/html/rfc2782 ? I don't see a comment about pre-existing protocols. Help me find it? – Rob Starling May 28 '13 at 22:54
  • 1
    @RobStarling Yes, RFC 2782. See the "Applicability Statement" section. – Teddy May 31 '13 at 10:19
  • 2
    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. – maxschlepzig Sep 27 '14 at 20:11
  • @maxschlepzig That's irrelevant to the discussion of defining e.g., a new HTTP 1.2 or 3.0 which uses SRV by default… – JamesTheAwesomeDude Dec 03 '18 at 19:40
  • 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. – Kevin A. Naudé Feb 09 '20 at 00:22
12

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?

Community
  • 1
  • 1
Alnitak
  • 334,560
  • 70
  • 407
  • 495
  • 6
    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. – fadedbee Jan 31 '12 at 11:09
  • 3
    What was the objection to http://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. – fadedbee Feb 03 '12 at 13:41
  • 1
    @chrisdew I don't know, I wasn't active at the IETF back then. I'll ask the author when I see him next. – Alnitak Feb 03 '12 at 14:06
  • 3
    The Andrews/Kottelin was updated in 2014: http://tools.ietf.org/html/draft-andrews-http-srv-02 – maxschlepzig Sep 27 '14 at 20:17
  • 1
    `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. – Patrick Mevzek Jul 05 '19 at 18:26
  • @PatrickMevzek I'm working on it... https://tools.ietf.org/html/draft-bellis-dnsop-http-record-00 (new version due Monday) – Alnitak Jul 06 '19 at 15:23
  • 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 – Patrick Mevzek Jul 06 '19 at 20:29
  • @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) – Alnitak Jul 07 '19 at 20:36
  • 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... – Patrick Mevzek Jul 08 '19 at 18:14
  • @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. – Alnitak Jul 09 '19 at 16:46
11

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.

Chris J
  • 30,688
  • 6
  • 69
  • 111
richardw
  • 728
  • 5
  • 9
  • 2
    curiously, that page completely misses out XMPP (Jabber) and SIP, which utterly depend on `SRV` records. – Alnitak Jan 30 '12 at 20:44
  • oh, and the reason `_nicname._tcp.tld` isn't used more widely is because its security model is broken. – Alnitak Jan 30 '12 at 20:49
  • 2
    @Alnitak How is its security model broken? Or any less secure than connecting to anything else by name? – Nick Whaley Jan 14 '14 at 18:33
  • @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`. – Alnitak Jan 14 '14 at 22:06
  • 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. – Dwight Spencer Apr 22 '15 at 19:41
  • 1
    Email, calendar, and address book service providers seem to have [adopted SRV records](https://www.slightfuture.com/technote/dns-srv-usage). – Daniel Mar 04 '16 at 02:58
  • @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. – Alnitak Oct 05 '16 at 16:34
  • 4
    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) – Jasper Mar 03 '17 at 13:09
7

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.

Community
  • 1
  • 1
maxschlepzig
  • 35,645
  • 14
  • 145
  • 182
-1

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.

Striped
  • 2,544
  • 3
  • 25
  • 31
vlad
  • 43
  • 5