Editing SRV record (section)

== Provisioning for high service availability ==
The ''priority'' field determines the precedence of the use of the record's data. Clients should use the SRV records with the lowest-numbered priority value first, and fall back to records of higher value if the connection fails. If a service has multiple SRV records with the same priority value, clients should [[Load balancing (computing)|load balance]] them in proportion to the values of their ''weight'' fields. 
In the following example, both the ''priority'' and ''weight'' fields are used to provide a combination of load balancing and backup service. 
{{sxhl|2=zone|
; _service._proto.name.  TTL   class SRV priority weight port target.
_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 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 three weight values is 100, so <code>bigbox.example.com</code> will be used 60% of the time. The two hosts, <code>smallbox1</code> and <code>smallbox2</code> will be used for 40% of requests total, with half of them sent to <code>smallbox1</code>, and the other half to <code>smallbox2</code>. If <code>bigbox</code> is unavailable, these two remaining machines will share the load equally, since they will each be selected 50% of the time.

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

The load balancing provided by SRV records is inherently limited since the information is essentially static. The current load of servers is not taken into account unless TTL values are low enough (around a minute or lower) that the priority (or weight) values can be quickly updated.