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.
In fact, it is the other way around.
The clients of the less-common protocols sometimes make good use of SRV
lookups.
Indeed, SRV
lookups are in widespread real-world successful use, in systems such as Microsoft Windows NT Server networking.
Microsoft Windows NT Server networking is indeed one of the most widespread, but yet little known, examples of the successful use of SRV
resource records, which it uses extensively for auto-locating LDAP (_ldap._tcp
) servers, kerberos password change (_kpasswd._tcp
) servers, kerberos KDC (_kerberos._tcp
) servers, and Global Catalogue (_gc._tcp
) servers.
Even that is knocked into a cocked hat by Zero Configuration DNS Service Discovery, available as a production system in Mac OS from version 10.4 onwards, which uses SRV
resource records to advertise a lengthy array of services on LANs and WANs, allowing machines to locate such services when all that they have to start from is a domain name given to them in a DHCP lease.
ZeroConf DNS-SD locates everything from LPR printer servers to iTunes servers using SRV
resource records.
It is the HTTP clients (web browsers and proxy HTTP servers) that are, to their authors' embarrassment and shame, and despite the efforts of Rick van Rein and others, lagging behind here.
SRV
lookups
Clients of many services do make use of SRV
lookups.
(Rick van Rein maintains an independent list.)
SRV
lookups
Old NICNAME clients come with lengthy configuration files that associate domain names with NICNAME servers, which eventually become out of date.
In contrast, Modern NICNAME (a.k.a. "whois") clients make (_nicname._tcp
) SRV
resource record set lookups to find the correct NICNAME server, and need no such configuration files.
SRV
lookups
The LDAP clients in Microsoft and Linux softwares perform (_ldap._tcp
) SRV
resource record set lookups to locate LDAP servers.
SRV
lookups
Several modern SMTP Relay and SMTP Submission clients use (_smtp._tcp
and _submission._tcp
) SRV
resource record set lookups to locate servers.
(_submission._tcp
is a simple use of the IANA assigned name for the protocol, and its use in several softwares pre-dated the existence of §3.1 of RFC 6186 by about a decade.)
These include:
the SMTP Relay clients (smtprc
and etrn
) in The Internet Utilities for OS/2
the SMTP Submission client (sendmail
) in The Internet Utilities for OS/2
exim (since at least version 4.50 in 2005, apparently)
SRV
lookups
A few modern HTTP clients use (_http._tcp
) SRV
resource record set lookups to locate HTTP servers.
These include:
the various HTTP clients (httpget
, httpgetn
, and so forth) in The Internet Utilities for OS/2
the proxy HTTP server (httppd
) in The Internet Utilities for OS/2
the HTTP client in LFTP (since version 2.0.2 in July 1999, apparently!)
The HTTP/HTTPS client in the FreeBSD package manager, pkg
.
As standard since 2013, this has been configured with mirror_type: "srv"
for the official FreeBSD package repositories.
SRV
lookups
A few modern NNTP clients use (_nntp._tcp
) SRV
resource record set lookups to locate NNTP servers.
These include:
the NNTP clients (nnfeedg
and nnfeedn
) in The Internet Utilities for OS/2
SRV
lookups
A few modern TELNET clients use (_telnet._tcp
) SRV
resource record set lookups to locate TELNET servers.
These include:
telnetsrv from Milk Farm Software
SRV
lookups
A few modern FTP clients use (_ftp._tcp
) SRV
resource record set lookups to locate FTP servers.
These include:
the FTP client in LFTP (since version 2.0.2 in July 1999, apparently!)
SRV
lookups
Jabber clients use SRV
resource record set lookups to locate Jabber servers.
This is, in fact, the preferred main mechanism for finding Jabber servers, per §3.2.1 of RFC 6120.
These clients include, amongst many others:
Cisco Jabber, which performs _cisco-uds._tcp
, _cuplogin._tcp
, and _collab-edge._tcp
SRV
lookups to find Cisco's various proprietary messaging servers.
Prosody IM, which performs RFC6120 _xmpp-server._tcp
SRV
lookups to find XMPP servers.
SRV
lookups
SIP clients use SRV
resource record set lookups to locate SIP servers.
This has been a documented mechanism since RFC 2543 in 1999, and was elevated out of an optional mechanism documented in an appendix into the mainstream protocol with §4.2 of RFC 3263 in 2002.
There are lots of SIP clients that use SRV
lookups, this having been the norm in the SIP world for most of the 21st century.
SRV
lookups
Minecraft clients have used (_minecraft._tcp
) SRV
resource record set lookups to locate Minecraft game servers since version 1.3.1 of the Java Edition in 2012.
SRV
lookups
As with SMTP Submission, CalDAV and CardDAV clients had actually been using _caldav._tcp
, _carddav._tcp
, _caldavs._tcp
, and _carddavs._tcp
, SRV
resource record set lookups to locate servers some years before the publication of §11 of RFC 6352 and §3 of RFC 6764.
The DaviCAL wiki, for example, documented how to construct SRV
resource records for CalDAV and CardDAV clients from 2010 onwards.
SRV
Lookup Laggards' Hall of Shame
It is amazingly hard to convince the authors of certain particular application client softwares to use SRV
lookups, even those authors that give examples of such lookups in their own documentation.
In fact, there's really only one class of applications softwares in the laggards category: web browsers and proxy HTTP servers.
Even mail softwares (witness exim above) are capable of using SRV
lookups nowadays.
To the shame and embarrassment of their authors, web browsers and proxy HTTP servers still do not perform SRV
lookups.
Web browser software authors have still, 20 years (as of 2018) after the idea was first proposed, to add SRV
lookup to their web browsers.
The work item for having SRV
lookups added to Mozilla has languished for over 19 years, as of 2018.
This Frequently Given Answer has been published for 14 of them.
There are some quite ridiculous excuses given in the decade and a half of Bugzilla discussion, based upon some utter tripe. (Those who want to excuse the lack of progress are seemingly overlooking the fact that the code has even been written, twice over, and simply needs proper incorporation into the main source tree.) For the record:
No, you'll find that in fact WWW site administrators would pounce on this quite rapidly if only WWW browsers supported it. This one would, for example. As would this one, and this one.
No, the claim that this is "not standardized" is nonsense.
The RFCs have been around for years, SRV
resource records have been in widespread real world use on production systems for many other protocols for years, and _http
is the accepted shortname for what HTTP clients should be using.
HTTP has in fact been in most examples of how to use SRV
resource records for 22 years (as of 2018).
It's given as an example on page 517 of the the Cricket book 4th Edition, published in 2001.
Indeed, it was one of the examples in RFC 2052 all the way back in October 1996.
We are not exactly wanting for either agreement upon or documentation of _http._tcp
at this point.
The only good reasons for holding off SRV
resource record use (involving what to do when there's an explicit port number in the URL) were addressed by Mark Andrews and Thor Kottelin in 2000, eighteen years ago.
(What Andrews and Kottelin stated is pretty much the obvious thing to do, moreover.)
No, this does not increase the number of DNS queries.
In reality, the number of back-end DNS queries to perform an A
or an AAAA
lookup can vary enormously, and can number in the tens or hundreds of queries already.
It's not generally true that the number of back-end lookups will increase, because the number of back-end lookups varies wildly by time (depending from what is cached from momement to moment) by domain name (depending from the amount of gluelessness) and by country.
There is so much variation in there already that the variation caused by a two-step SRV
lookup can quite often be lost in the noise.
SRV
lookups do not even have to be two-step in the first place.
A proxy or content DNS server is free to add the requisite A
and AAAA
resource record sets as additional section data in its response, meaning that the client obtains both pieces of information in a single transaction.
And of course several real world DNS server softwares do exactly this.
The FreeBSD packaging system, happily using SRV
resource record lookup in its HTTP client for 5 years (as of 2018), is a case in point.
The real world DNS servers can and do send all of the data in one transaction using the additional section.
The FreeBSD people have even made it in-bailiwick:
JdeBP % dnsq srv _http._tcp.pkg.freebsd.org. ns1.isc-sns.net. 33 _http._tcp.pkg.freebsd.org: 510 bytes, 1+5+3+8 records, response, authoritative, noerror query: 33 _http._tcp.pkg.freebsd.org answer: _http._tcp.pkg.freebsd.org 300 SRV 50 10 80 pkg0.isc.freebsd.org answer: _http._tcp.pkg.freebsd.org 300 SRV 50 10 80 pkg0.nyi.freebsd.org answer: _http._tcp.pkg.freebsd.org 300 SRV 10 10 80 pkgmir.geo.freebsd.org answer: _http._tcp.pkg.freebsd.org 300 SRV 50 10 80 pkg0.bme.freebsd.org answer: _http._tcp.pkg.freebsd.org 300 SRV 50 10 80 pkg0.ydx.freebsd.org authority: freebsd.org 3600 NS ns1.isc-sns.net authority: freebsd.org 3600 NS ns3.isc-sns.info authority: freebsd.org 3600 NS ns2.isc-sns.com additional: pkg0.bme.freebsd.org 3600 A 213.138.116.73 additional: pkg0.bme.freebsd.org 3600 AAAA 2001:41c8:112:8300:0:0:50:1 additional: pkg0.isc.freebsd.org 3600 A 149.20.1.201 additional: pkg0.isc.freebsd.org 3600 AAAA 2001:4f8:1:11:0:0:50:1 additional: pkg0.nyi.freebsd.org 3600 A 96.47.72.71 additional: pkg0.nyi.freebsd.org 3600 AAAA 2610:1c1:1:606c:0:0:50:1 additional: pkg0.ydx.freebsd.org 3600 A 77.88.40.109 additional: pkg0.ydx.freebsd.org 3600 AAAA 2a02:6b8:b010:1001:0:0:50:1 JdeBP %
SRV
resource records have been in use for coming up to 20 years, as of 2018.
And yet one never hears of actual problems with a range of different protocols that mirror the supposed projected problems of using SRV
lookups in HTTP clients.
A lot of what one hears about why this would not work is simply bad analysis and excuse making.
Squid doesn't yet employ SRV
lookups.
Whilst Microsoft Windows Server networking is an exemplar that many point to when discussing the use of SRV
resource records, whilst Microsoft's Windows 2000 Resource Kit even gives examples of _http._tcp
SRV
resource records, and whilst the suggestion had been on Microsoft's suggestions list for several years, Microsoft's own Internet Explorer never did perform SRV
lookups.
The
work item for having SRV
lookups added to WebKit has languished for 6 years, and in fact is a copy of a bug originally filed in June 2004 with Apple.
This is long enough that the domain name given in the bug report has now expired.
(For what it's worth, one can use http://pantz.org./ and http://butter.eu./ as tests, instead.)
The Mac OS developers' early excuse was that "Mozilla hasn't done it, yet.". Then they closed the bug report after 6 years because "this would be Safari functionality".
The work item for having SRV
lookups added to Google Chrome was filed in September 2009.
It will be interesting to see how much, if at all, Google Chrome lives up to the marketing slogan in the top-left corner of that very WWW page, in this case. "An open source browser project to help move the web forward" says the slogan. It would be rather sad if the Google Chrome developers presented the same excuses and showed the same inertia in "moving forward" with an idea that has been widely acknowledged as a good thing that would ease the pain of WWW server administrators with small and medium sized hosting services, for almost 14 years, now.
In 2013 the bug was derailed by a discussion of the same fallacies about queries, causing a Chrome developer to think that the idea needed to be referred to the IETF, even though the relevant RFC was right there in the title of the bug report.