In DNS an SRV record really is a pretty generic form of telling a remote client where a specific service is hosted. At this moment I use it for allowing people to call me using a SIP client over the internet (works quite nicely).

One of the advantages of the SRV record is that you can specify a different port for the service and you can have multiple systems for the same (or the same system and multiple instances on a different port). So IFF it works you can have several webservers on a single system without any interferences.

So you could have this in your DNS:

_http._tcp SRV 10 50 8080 myserver.basjes.nl
_http._tcp SRV 10 50 8081 myserver.basjes.nl

There is however one tiny snag to all this goodness ... I've not been able to find any HTTP, FTP, SMTP, ... clients that support it.

So other than SIP and the few other protocols mentioned in the Wikipedia page: Will the SRV record ever become really useful?

Or have I missed something?

Is there something better out there that does work?

15 Answers 15


I think you'll only see it used for new protocols.

The MX records that SMTP uses are equivalent to SRV records with a fixed port and no weight. In other words, they've already adequately solved the same problem.

Since, for example, HTTP has to preserve backwards compatibility with the current mechanisms, anybody that started using SRV for HTTP would still have to provide an alternate mechanism anyways, and nobody wants to maintain two ways of doing the same thing. (say, some load balancers and some DNS SRV records...) And if sites aren't going to publish SRV records (because it just creates unnecessary work), there's no motivation for clients to support SRV records nobody is publishing.


They're pretty useful in an Active Directory domain.

  • 3
    Agreed. Until developers start using them, though, they're not going to be useful for much else. It's a shame, really. The idea behind SRV RR's is a good one. Jun 24, 2009 at 15:55

SRV records are also in use by many Kerberos-enabled services and clients. This is especially true on a particular machine where /etc/krb5.conf (or it's equivalent) is either not readable or missing; a SRV record lookup will be performed to find the KDC.


Apple's Bonjour technology (aka zeroconf) makes extensive use of this. If you haven't seen it in action -- check it out. It allows you to auto-discover printers, routers, bonjour-enabled webpages, etc.

There is a BSD-licensed Apache module called mod_bonjour which allows you to advertise websites via multicast DNS. You can also advertise sites via SRV records and regular DNS, but I believe that only Safari will be able to detect them.

The Zeroconf webpage has a pretty good explanation about how it works -- I'd recommend checking out the book too if you're interested in the technology.

One of the big problems with this in general is that DNS people don't consider themselves to be in the service discovery business, and paranoid security people consider the ability to discover services to be a security risk.


Indeed, most applications don't yet support it.

Those that do are those where it's common for the domain in the target user's identity to be different from the hostname to which the client software must connect. Hence why it's used in SIP, and also in Jabber (XMPP).

SMTP doesn't need it because that always had MX records from the outset.

The benefit of being able to use a different port is relatively minor, so other protocols haven't started using it much.

There's an Internet Draft that proposes an http+srv: URI scheme, but note that there's no current proposals to add SRV lookups to standard http: URI requests.


Outlook 2007 and Exchange 2007 make use of SRV records http://technet.microsoft.com/en-us/library/bb332063.aspx


I believe SRV records are one of the underlying structures in DNS Service Discovery (DNS-SD) so will be increasingly important.

There is also no reason that they can't be used in with existing technologies, in conjunction with DNS-SD aware clients, e.g. network browsers, such as iStumbler for mac which can find bonjour/zeroconf resources on the network.


In my opinion, SRV records will only become more common when dynamic-update DNS becomes more available. MS-DNS has dynamic-update turned on by default in very large part due to the requirements of Active Directory. There have been many resource advertising directories out there over the years, including the Service Location Protocol, Service Advertising Protocol (IPX networks), Bonjour/Avahi, and even DHCP to some extent.

Of these, only DNS has true potential for an internet-spanning resource directory. Public DNS servers tend to be static things for a reason. Adoption of SRV records will come when there is a defined need for them, much like the adoption of TXT records came about for the SPF protocol. SIP using SRV's could be the first step in opening the door to wider, non-MS adoption.


SRV records are used to direct Windows Vista/2008 Servers to your KMS server for activation in the Enterprise.


XMPP is using them.

But existing protocols won't change to support them, especially redirecting a request to a different port. That would be unexpected, and undoubtedbly break some security-related assumptions.


SRV records offer a mechanism for implementing communication services without requiring everyone to use the same provider. In other words, what the A and MX records do for web and email, the SRV records do for any service.

This idea is outlined in a blog post "The Power of Free Addressing" http://e-caller.com/?p=4

The rise of Twitter and Facebook owes to the lack of SRV enabled alternatives.


Fedora/Red Hat project freeipa uses them, as well as puppet labs puppet for load balancing and scalability reasons. the more i learn about its use cases and how they are used extensively the more i am in love with it. it is the best thing that happened to dns, and infrastructures. check out how spotify uses them https://labs.spotify.com/2013/02/25/in-praise-of-boring-technology/


They're quite useful for application stacks that need a service locator, as DNS doesn't need to be implemented from scratch and is much lighter weight than something like zookeeper or etcd. Also there's the added convenience that is can be made quite secure. I'm not sure why hardly anyone besides Spotify uses it in this manner, I suspect just ignorance. I've seen lots of people roll their own vastly inferior custom service location software. DNS is a fast, reliable key value store and already organizes its keys by zone. The big problem is very few DNS servers have any sort of API, so automating RR creation/updating is not doable, although cloud implementations of DNS do.


SRV records are CRUCIAL for the hosting industry, as they allow you to save IPv4 space.

We use them to help the transition of our customers toward IPv6 in a transparently matter.

  • I'm intrigued by this; care to add a little more detail?
    – nickgrim
    Jan 10, 2013 at 13:26
  • we give a dedicated ipv6 and some ports on IPv4. This way we greatly reduce our ipv4 footprint. Ports are hidden via SRV, with an apache patch
    – Mascarpone
    Feb 16, 2013 at 0:18

Service discovery (with Nomad and Kubernetes for instance) uses SRV records.

SRV records are helpful with any type of stateless connection.

You can still use Consul and Kube-DNS without using their SRV records, but you lack several functionalities: dynamic port assignment, and SRV weight.

Reverse proxies like Haproxy and Nginx can use SRV records (with weight and dynamic ports).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.