SRV record (SRV record or Service record) is a category of DNS data providing information about available services.
For AD DS to function correctly, clients must be able to query records identifying the location of system services, allowing authentication against DCs and operation of services such as Exchange. A DNS server integrated with a DC provides this information through SRV records.
Record format:
An SRV record contains the following information:
- The: the symbolic name of the requested service.
- Protocol: usually TCP or UDP.
- Domain name: the domain to which the record applies.
- TTL: the standard DNS time to live field.
- Class: the standard DNS class field (always IN).
- Priority: the target host's priority.
- Weight: the relative weight for records with the same priority.
- Port: the TCP or UDP port on which the service is available.
- 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 port 5060 for connections using the SIP protocol. The priority is 0 and the weight is 5.
Load balancing using SRV
Priority is similar to the priority of an MX record. Clients always use the SRV record with the lowest priority and use records with another priority only if the host connection fails. A service can therefore specify a fallback server used only if the primary server fails. This requires another SRV record with a higher priority value than the primary record.
If a service has multiple records with the same priority, clients use the weight to decide which host to use. Weight is relevant only relative to the other weights for that service and only among records with the same priority.
In the following example, the priority and weight values provide load balancing and a 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. ;different instances may use different ports
_sip._tcp.example.com. 86400 IN SRV 20 0 5060 backupbox.example.com.
The first four records share priority 10, so clients use weight to decide which host to connect to. All four weights total 100, so bigbox.example.com will be used for 60% of queries. The other two, smallbox1 and smallbox2, will be used for 20% of queries each, with smallbox2 splitting its load between two instances, each used for 10% of queries. If bigbox becomes unavailable, the other two hosts share the load equally, each serving 50% of queries.
If all three hosts with priority 10 are unavailable, the record with the highest priority (lowest number) is used, namely backupbox.example.com. It should be located separately from the other three and be resilient to failures that could disable them (for example, a different electrical circuit or network path).
Note that this load balancing is quite limited because the information provided is static. Actual server load is not taken into account.
Komentáře