SRV record

An SRV record or Service record is a category of data in the Internet Domain Name System specifying information on available services. It is defined in RFC 2782. Newer internet protocols such as SIP and XMPP often require SRV support from clients.

Record format

An SRV record has the form:

_Service._Proto.Name TTL Class SRV Priority Weight Port Target

* Service: the symbolic name of the desired service.
* Proto: the protocol of the desired service; this is usually either TCP or UDP.
* Name: the domain name for which this record is valid.
* TTL: standard DNS time to live field.
* Class: standard DNS class field (this is always "IN").
* Priority: the priority of the target host, lower value means more preferred.
* Weight: A relative weight for records with the same priority.
* Port: the TCP or UDP port on which the service is to be found.
* Target: the canonical hostname of the machine providing the service.

An example SRV record might look like this:

_sip._tcp.example.com. 86400 IN SRV 0 5 5060 sipserver.example.com.

Or like this using the non-standard djbdns syntax:

S_sip._tcp.example.com:::5060:5:0:86400:

This points to a server named sipserver.example.com listening on TCP port 5060 for SIP protocol connections. The priority given here is 0, and the weight is 5.

As with PTR records, SRV records must point to the canonical name of the host. Aliases or CNAMEs cannot be used as valid targets.

High Availability with SRV

The priority field is similar to an MX record's priority value. Clients always use the SRV record with the lowest-numbered priority value first, and only fall back to other records if the connection with this record's host fails. Thus a service may have a designated "fallback" server, which will only be used if the primary server fails. Only another SRV record, with a priority field value higher than the primary server's record, is needed.

If a service has multiple SRV records with the same priority value, clients use the weight field to determine which host to use. The weight value is relevant only in relation to other weight values for the service, and only among records with the same priority value.

In the following example, both the priority and weight fields are used to provide a combination of load balancing and backup service.

_sip._tcp.example.com. 86400 IN SRV 10 60 5060 bigbox.example.com. _sip._tcp.example.com. 86400 IN SRV 10 20 5060 smallbox1.example.com. _sip._tcp.example.com. 86400 IN SRV 10 10 5060 smallbox2.example.com. _sip._tcp.example.com. 86400 IN SRV 10 10 5066 smallbox2.example.com. _sip._tcp.example.com. 86400 IN SRV 20 0 5060 backupbox.example.com.

The first four records share a priority of 10, so the weight field's value will be used by clients to determine which server (host and port combination) to contact. The sum of all four values is 100, so bigbox.example.com will be used 60% of the time. The two hosts smallbox1 and smallbox2 will be used for 20% of requests each, with half of the requests that are sent to smallbox2 (i.e. 10% of the total requests) going to port 5060 and the remaining half to port 5066. If bigbox is unavailable, these two remaining machines will share the load equally, since they will each be selected 50% of the time.

If all four servers with priority 10 are unavailable, the record with the next highest priority value will be chosen, which is backupbox.example.com. This might be a machine in another physical location, presumably not vulnerable to anything that would cause the first four hosts to become unavailable.

It should be noted that the load balancing provided by SRV records is inherently limited, since the information is essentially static. Current load of servers is not taken into account.

Verifying that a SRV record is created

In Linux or UNIX operating systems you can use dig to verify that the SRV record is created. Example: dig -t SRV _sip._tcp.example.com

Usage

SRV records are often used by Microsoft Windows 2000 clients to find the domain controller for a given service.

Further, SRV records are common in conjunction with the following standardised protocols:
* Client SMTP Authorization
* IMPS [http://baraza.im/userguide_pre.htm]
* Kerberos [ [http://web.mit.edu/Kerberos/krb5-1.5/krb5-1.5.4/doc/krb5-install/Hostnames-for-the-Master-and-Slave-KDCs.html Hostnames for the Master and Slave KDCs] ]
* LDAP [ [http://www.faqs.org/rfcs/rfc3088.html RFC 3088 - OpenLDAP Root Service An experimental LDAP referral service] ]
* SIP [ [http://www.voip-info.org/wiki-DNS+SRV DNS SRV - voip-info.org] ]
* XMPP (Jabber) [ [http://www.xmpp.org/extensions/xep-0156.html XEP-0156: Discovering Alternative XMPP Connection Methods] ]

ee also

* MX record - an older DNS RR type used for locating the SMTP server
* List of DNS record types

References

External links

* RFC 2782 - definition of the SRV resource record
* [http://www.menandmice.com/online_docs_and_faq/glossary/glossarytoc.htm?srv.record.htm Men & Mice's DNS Glossary - SRV Record]
* [http://dns.vanrein.org/srv/ Rick van Rein's articles on SRV resource records]
* [http://www.dns-sd.org/ServiceTypes.html Comprehensive list of defined SRV service types]
* [http://www.anta.net/nic/draft-andrews-http-srv-01.shtml draft-andrews-http-srv-01.txt] - Use of SRV records in conjunction with HTTP and URIs (Expired Internet-Draft)
* [http://www.dns.net/dnsrd/programming.html Resources for DNS Programmers] - Libraries for client-side DNS programming with support for SRV records