A Service record (SRV record) is a specification of data in the Domain Name System defining the location, i.e. the hostname and port number, of servers for specified services. It is defined in RFC 2782, and its type code is 33. Some Internet protocols such as the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP) often require SRV support by network elements.
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 transport 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 in textual form that might be found in a zone file might be the following:
_sip._tcp.example.com. 86400 IN SRV 0 5 5060 sipserver.example.com.
This points to a server named sipserver.example.com listening on TCP port 5060 for Session Initiation Protocol (SIP) protocol services. The priority given here is 0, and the weight is 5.
Provisioning for high service availability 
The priority field determines the precedence of use of the record's data. Clients always use the SRV record with the lowest-numbered priority value first, and fallback to other records of equal or higher value if the connection to the host fails.
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.
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.
Retrieving a SRV record 
$ dig _sip._tcp.example.com SRV
$ host -t SRV _sip._tcp.example.com
$ nslookup -querytype=srv _sip._tcp.example.com
$ nslookup > set querytype=srv > _sip._tcp.example.com
- Teamspeak 3 (since version 3.0.8)
- Minecraft (since version 1.3.1)
- CalDAV and CardDAV
- Client SMTP Authorization
- DNS Service Discovery (DNS-SD)
- Mail submission, Post Office Protocol, and Internet Message Access Protocol
In Microsoft Windows 2000 clients use SRV records to find the domain controller for a given service. SRV Records are also used by Outlook 2007, 2010 and Macintosh 10.6 mail to locate the Exchange Autodiscover service. In Microsoft Windows networks, dynamic DNS is an integral part of Active Directory, because domain controllers register their network service types in DNS so that other computers in the Domain (or Forest) can access them.
See also 
- IETF draft using SRV records to locate whois servers
- List of DNS record types
- MX record - a DNS RR type used for locating the SMTP server
||This article uses bare URLs for citations. (May 2012)|
- "Hostnames for the Master and Slave KDCs". Web.mit.edu. Retrieved 2012-05-23.
- "RFC 3088 - OpenLDAP Root Service An experimental LDAP referral service". Faqs.org. Retrieved 2012-05-23.
- "Dns Srv". voip-info.org. Retrieved 2012-05-23.
- "XEP-0156: Discovering Alternative XMPP Connection Methods". Xmpp.org. Retrieved 2012-05-23.
- Cyrus Daboo (March 2011). Use of SRV Records for Locating Email Submission/Access Services. IETF. RFC 6186. https://tools.ietf.org/html/rfc6186. Retrieved 17 April 2013.
- "A new feature is available that enables Outlook 2007 to use DNS Service Location (SRV) records to locate the Exchange Autodiscover service". Support.microsoft.com. 2010-05-13. Retrieved 2012-05-23.
- "RFC 6335 - Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry". Faqs.org. 2009-08-05. Retrieved 2012-05-23.
- "draft-sanz-whois-srv-00 - Using DNS SRV records to locate whois servers". Tools.ietf.org. 2004-04-05. Retrieved 2013-05-20.
- RFC 2782 - definition of the SRV resource record
- Men & Mice's DNS Glossary - SRV Record
- Rick van Rein's articles on SRV resource records
- Comprehensive list of defined SRV service types
- draft-andrews-http-srv-01.txt - Use of SRV records in conjunction with HTTP and URIs (Expired Internet-Draft)
- PHP Client for HTTP+SRV - PHP class extending the Zend Framework to support SRV records in its HTTP client
- RFC 6186 - Use of SRV Records for Locating Email Submission/Access Services