SRV Resource Record

from Wikipedia, the free encyclopedia

Using SRV (Service) Resource Records , DNS can be used to propagate which IP-based services are offered in a domain. Additional information is provided for each service, such as the server name that provides this service.

A service is identified by its name and the protocol appended with a period. Both components are _preceded by a to prevent confusion with other domain names.

construction

service
Service + protocol + domain
TTL (time to live)
indicates how long this RR ( Resource Record ) can be kept in the cache
IN
Internet
SRV
The string "SRV"
priority
if several identical services are offered, the lowest priority has priority (the services with a higher priority value serve as a substitute in the event of a failure)
Weight
within the same priority, the probability of selecting a service should be relative to its weight (for a service with weight 3 and one with weight 2, on average 60% of the first service should be selected - this serves to distribute the load )
port
TCP or UDP port number
server
Server that provides this service (this must not be an IP address or an alias, i.e. a domain with a CNAME RR)

example

_ldap._tcp.example.com. 3600 IN SRV 10 0 389 ldap01.example.com.

In this example, a client can use DNS to determine that the LDAP server ldap01 exists in the DNS domain example.com , which can be reached via TCP port 389.

Example of a highly available configuration

The Priority field defines the ranking between records of the same service. Clients should first use the SRV records with the lowest numerical priority and only use the records with the higher priority value if the connection attempts fail. If a service has multiple SRV records with the same priority value, clients should distribute the load proportionally to the value of the Weight field . In the example below, the Priority and Weight fields are used together to provide a combination of load distribution and reserve. 

# _dienst._proto.name.   TTL   Klasse SRV Priorität Gewicht Port Ziel.
_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 all have priority 10, so the clients will use the weight field to select one of the three destinations (host and port). The sum of all three weight values is 100, so bigbox.example.com is used for 60% of all connections. The two hosts smallbox1 and smallbox2 are used for 40% of the connections; half of it goes to smallbox1 and the other half to smallbox2 . If bigbox cannot be reached, the load is divided equally between the two remaining machines, since both are then contacted each time 50% of all connection attempts.

If none of the three servers with priority 10 is available, the entry with the next lowest priority value is selected, i.e. backupbox.example.com . This could be a machine in a different location that is beyond the control of the problem that made the first three servers inaccessible.

Load balancing across SRV records is inherently limited because the information is effectively static. The current load on the servers is not taken into account, unless the TTL values ​​are low enough (about a minute or less) that a change in priority (or weight) quickly pays off.

use

SRV entries are also common for the following standardized protocols :

From Microsoft - Windows 2000 clients SRV RRs are used for a service they need the appropriate domain controller to determine.

Web links

Individual evidence