SRV Resource Record
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.
- Service + protocol + domain
- TTL (time to live)
- indicates how long this RR ( Resource Record ) can be kept in the cache
- The string "SRV"
- 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)
- 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 )
- TCP or UDP port number
- Server that provides this service (this must not be an IP address or an alias, i.e. a domain with a CNAME RR)
_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.
- Autodiscover (email)
- Minecraft (since full version 1.3.1)
- SMTP , POP , IMAP
- TeamSpeak3 (since client version 3.0.8)
- XMPP (Jabber)
- RFC 2782 - A DNS RR for specifying the location of services (DNS SRV)
- Service Name Registry (RFC 6335) - List of services, associated SRV records and ports
- DNS SRV (RFC 2782) Service Types - Old list of services and the associated SRV entries