SRV record

From Wikipedia, the free encyclopedia

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. Client implementations of older protocols (e.g. LDAP, SMTP) may have SRV support added to it.

1 Record format
2 Load balancing with SRV
3 Usage
4 See also
5 External links

[edit] Record format

An SRV record holds the following information:

Service: the symbolic name of the desired service.
Protocol: this is usually either TCP or UDP.
Domain name: the domain 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.
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 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.

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.

[edit] Load balancing with SRV

The priority field is similar to an MX record's priority value. Clients always use the SRV record with the lowest 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 20 5060 smallbox2.example.com.
_sip._tcp.example.com. 86400 IN SRV 20 0 5060 backupbox.example.com.

The first three records share a priority 10, so the weight field's value will be used by clients to determine which host to contact. The sum of all three values is 100, so bigbox.example.com will be used 60% of the time. The other two hosts, smallbox1 and smallbox2, will be used for 20% of requests each. 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 three hosts 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 three 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.