Daren Matthews

Some protocols such as SIP and XMPP require SRV records. SRV records have the form
_service._proto.name TTL class SRV priority weight port target

Example DNS entry with A and SRV record:
host.yourdomain.com 86400 IN A 195.88.229.113
_sipfederationtls._tcp.yourdomain.com   86400 IN SRV 0 5 5061 sip.yourdomain.com.  < == (which can be the SIP/SIP-TLS service on host.yourdomain.com)

Meaning of “_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: The time interval (in seconds) that this record may be cached before the source of the information should again be consulted. Zero values are interpreted to mean that the record can only be used for the transaction in progress, and should not be cached.
class: Standard DNS class field (this is always IN).
priority: The priority of the target host, lower value means more preferred (similar to MX records).
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.

Example:
_sip._tcp.domain.com. 86400 IN SRV 0 5 5060 sipserver.domain.com. <====  (If you specify an FQDN, the name must end with a dot; if you specify just a hostname, it must not end with a dot)

SRV records allow you to achieve a basic form of high-availability and load-balancing (basic because information is static, i.e., current server loads are not taken into account). The priority field is similar the the one of MX record – clients use the server with the lowest priority value first and use other servers only if this server fails. This means oyu can have multiple SRV records and define a fallback server that is used only if the primary server fails by giving the fallback server a higher priority value than the primary server.

If there are multiple SRV records with the same priority, clients use the weight field to find out which host to use. The weight value is relevant only in among records with the same priority.

Here’s an example of basic high-availability and load-balancing with SRV records:

_sip._tcp.domain.com. 86400 IN SRV 10 60 5060 server1.domain.com.
_sip._tcp.domain.com. 86400 IN SRV 10 40 5060 server2.domain.com.
_sip._tcp.domain.com. 86400 IN SRV 20 0 5060 server3.domain.com.

In the above example, both server1.domain.com and server2.domain.com have a priority value of 10, so all requests will be shared by them, where server1.domain.com gets 60% of the requests and server2.domain.com gets the remaining 40% of the requests (because server1.domain.com has a weight value of 60 and server2.domain.com has a weight value of 40). If server1.domain.com fails, all requests will go to server2.domain.com. If both server1.domain.com and server2.domain.com fail, all requests will go to server3.domain.com which has a priority value of 20.