SRV record

A Service record (SRV record) is a specification of data in the Domain Name System defining the location, i.e., the hostname and port number, of servers for specified services. It is defined in RFC 2782, and its type code is 33. Some Internet protocols such as the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP) often require SRV support by network elements.

Record format

A SRV record has the form:

_service._proto.name. TTL class SRV priority weight port target.
  • service: the symbolic name of the desired service.
  • proto: the transport protocol of the desired service; this is usually either TCP or UDP.
  • name: the domain name for which this record is valid, ending in a dot.
  • TTL: standard DNS time to live field.
  • class: standard DNS class field (this is always IN).
  • SRV: Type of Record (this is always SRV).
  • priority: the priority of the target host, lower value means more preferred.
  • weight: A relative weight for records with the same priority, higher value means higher chance of getting picked.
  • port: the TCP or UDP port on which the service is to be found.
  • target: the canonical hostname of the machine providing the service, ending in a dot.

An example SRV record in textual form that might be found in a zone file might be the following:

_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 Session Initiation Protocol (SIP) protocol services. The priority given here is 0, and the weight is 5.

As in MX records, the target in SRV records must point to hostname with an address record (A or AAAA record). Pointing to a hostname with a CNAME record is not a valid configuration.

Provisioning for high service availability

The priority field determines the precedence of 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 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. 

# _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 values is 100, so bigbox.example.com will be used 60% of the time. The two hosts, smallbox1 and smallbox2 will be used for 40% of requests total, with half of them sent to smallbox1, and the other half to smallbox2. 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 servers with priority 10 are unavailable, the record with the next lowest 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.

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, unless TTL values are low enough (around a minute or lower) that the priority (or weight) values can be quickly updated.

Usage

SRV records are common in conjunction with the following standardized communications protocols:

In Microsoft Windows 2000 clients query for SRV records to determine the domain controller for a given service. SRV records are also used by Outlook 2007, 2010 and Macintosh 10.6 mail to locate the Exchange Autodiscover service.[14] In Microsoft Windows networks domain controllers register their network service types for Active Directory in the DNS.

A registry of service names for SRV records & protocols is maintained by the Internet Assigned Numbers Authority (IANA) as defined in RFC 6335.[15]

gollark: Er, not out, unsick
gollark: ```dDW** | hatchling | 3 | 813 | 9250 | 157 | t | 2018-09-04 20:14:24.368+00 | 2018-09-05 12:06:34.858+00```now. `2eV**` is out.
gollark: Er... yes.
gollark: I'm going to lunch and might actually start using the EATW formula thing when I return.
gollark: Some others are near 156h (I think that's 6d12h or so) which is more worrying.

See also

References
  1. "DNS SRV record support in apt". Debian. 4 May 2018. Archived from the original on 17 November 2019. Retrieved 17 November 2019.
  2. "Looking up Monitors through DNS – Ceph Documentation". Ceph Documentation. Archived from the original on 5 December 2017. Retrieved 4 December 2017.
  3. "Hostnames for the Master and Slave KDCs". Massachusetts Institute of Technology. Archived from the original on 21 October 2012. Retrieved 23 May 2012.
  4. Zeilenga, K. (April 2001). OpenLDAP Root Service - An experimental LDAP referral service. IETF. doi:10.17487/RFC3088. RFC 3088. Retrieved 5 July 2020.
  5. Daboo, C. (March 2011). Use of SRV Records for Locating Email Submission/Access Services. IETF. doi:10.17487/RFC6186. RFC 6186. Retrieved 17 April 2013.
  6. "Federation API". Matrix.org. Archived from the original on 5 July 2020. Retrieved 5 January 2018.
  7. "Java Edition 1.3.1". Minecraft Wiki. Archived from the original on 5 July 2020. Retrieved 5 July 2020.
  8. "Add DNS SRV record support - mumble-voip/mumble". GitHub. Archived from the original on 5 July 2020. Retrieved 5 July 2020.
  9. "Baraza - Userguide". Archived from the original on 22 August 2008.
  10. "Puppet Docs: Scaling Puppet with compile masters, Using DNS SRV Records". Puppet Labs. Archived from the original on 11 October 2019. Retrieved 17 December 2019.
  11. "[Suggestion] TS DNS". Teamspeak Forum. Archived from the original on 14 November 2016. Retrieved 25 October 2013.
  12. "TeamSpeak 3 Client Version 3.0.8 Released". Teamspeak Forum. Archived from the original on 27 September 2016. Retrieved 5 July 2020.
  13. "XEP-0156: Discovering Alternative XMPP Connection Methods". XMPP.org. Archived from the original on 7 May 2012. Retrieved 23 May 2012.
  14. "A new feature is available that enables Outlook 2007 to use DNS Service Location (SRV) records to locate the Exchange Autodiscover service". Microsoft Support. 13 May 2010. Archived from the original on 20 April 2012. Retrieved 23 May 2012.
  15. Cotton, M.; Eggert, L.; Touch, J.; Westerlund, M.; Cheshire, S. (August 2011). Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry. IETF. doi:10.17487/RFC6335. RFC 6335. Retrieved 6 July 2020.
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.