Server location. SRV records specify the location of the server(s) for a specific protocol and domain. The Server Record field must contain three space-separated values. The first value is a number specifying the weight for this entry. The second field is a number specifying the port on the target host of this service. The last field is a name specifying the target host. The Priority field should contain the priority of this target host. Targets with a lower priority are preferred.

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

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.

E.g.

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

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:

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

For more information, read RFC 2782 and SRV Records on Wikipedia.

The form has the following fields:

Hostname: The name that this record describes. This field can contain an FQDN or just a hostname. 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.

Examples:
_sip._tcp.example.com.
_sip._tcp
Server Record: The Server Record field must contain three space-separated values. The first value is a number specifying the weight for this entry. The second field is a number specifying the port on the target host of this service. The last field is a name specifying the target host. The target host can be an FQDN or just a hostname. 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.

Examples:
0 9 server.example.com. (FQDN)
0 9 server (hostname only)
Priority: The Priority field should contain a preference for this SRV record, usually between 0 and 100. Records with lower values are preferred.
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.
Active: This defines whether this SRV record is active or not.