You've come to this page because you've said something similar to the following:
SRVrecord 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.
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. 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!)
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 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, 11 years 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 10 years, as of 2009. This Frequently Given
Answer has been published for 5 of them.
There are some quite ridiculous excuses given in the 10 years 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 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. 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 13
years. 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, nine
years ago. (What Andrews and Kottelin stated is pretty much the obvious
thing to do, moreover.)
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 having been on Microsoft's suggestions list for
a couple of years now, Microsoft's own Internet Explorer still
does not perform SRV lookups.
The
work item for having SRV lookups added to WebKit
has languished for 3 years, as of 2009, 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' excuse is that "Mozilla hasn't done it, yet.".
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.