SRV record
A Service record (SRV record) is a specification of data in the Domain Name System (DNS) that defines the hostname and port number of servers for specified services using a given protocol within a particular domain.[1] It enables clients to locate and connect to services dynamically without hardcoding server details, supporting features like load balancing and failover.[2] SRV records were formalized in RFC 2782, published by the Internet Engineering Task Force (IETF) in February 2000, as a way to extend DNS capabilities beyond simple address mappings to include service-specific discovery.[1] The record format follows the structure_Service._Proto.Name [TTL](/page/TTL) [Class](/page/Class) SRV Priority Weight Port Target, where _Service is the symbolic name of the service (e.g., _sip for Session Initiation Protocol), _Proto indicates the protocol (e.g., _tcp or _udp), Name is the domain, Priority (0-65535) determines selection order with lower values preferred, Weight (0-65535) enables proportional load distribution among equal-priority targets, Port specifies the service port (0-65535), and Target is the canonical hostname with associated address records (A or AAAA).[1] Clients query using the pattern _service._protocol.domain to retrieve these records, sorting the records by ascending priority and, for equal-priority targets, using weighted random selection based on their weights to determine connection order.[2]
SRV records are essential for protocols requiring flexible service location, such as Session Initiation Protocol (SIP) for voice over IP (VoIP), Extensible Messaging and Presence Protocol (XMPP) for instant messaging, and Lightweight Directory Access Protocol (LDAP) for directory services.[2] They facilitate high availability by allowing multiple server designations with priorities for backups and weights for traffic balancing, reducing administrative overhead when relocating services across hosts or ports.[1] While not universally supported in web browsers, SRV records are widely implemented in enterprise and application-layer protocols to enhance reliability and scalability in distributed systems.[3]
Fundamentals
Definition and Purpose
SRV records, designated with DNS type code 33, are a type of resource record in the Domain Name System (DNS) that specify the location of servers providing a particular service by mapping a service name and protocol to a target hostname and port number.[1] This structure allows clients to discover service endpoints dynamically through DNS queries without relying on hardcoded details.[1] The primary purpose of SRV records is to decouple service locations from fixed IP addresses, enabling administrators to redirect clients to appropriate hosts that can then be resolved via standard A or AAAA records.[1] This flexibility supports dynamic network environments, such as those involving load-balanced server clusters or deployments across multiple transport protocols like TCP or UDP.[1] By pointing to hostnames rather than IPs, SRV records accommodate changes in infrastructure, such as server migrations or failover configurations, without requiring updates to client applications.[1] Key benefits include simplified configuration for client software in protocols that mandate server discovery, for instance, locating Session Initiation Protocol (SIP) servers through targeted DNS SRV lookups.[4] Similarly, Extensible Messaging and Presence Protocol (XMPP) implementations use SRV records to identify relay or federation servers, reducing the need for manual endpoint specification.[5] In the broader DNS context, SRV records extend the capabilities of A and AAAA records by incorporating service-specific details, including port numbers, to facilitate precise targeting for application-layer protocols.[1] This extension promotes scalability and resilience in distributed systems by allowing multiple SRV entries per service for basic load distribution via priority and weight attributes.[1]Historical Development
The SRV record was initially proposed in 1996 as part of efforts within the IETF's Service Location Protocol (SVRLOC) working group to enable dynamic service discovery in distributed networks. The first formal specification appeared in RFC 2052, published in October 1996 by Arnt Gulbrandsen and Paul Vixie, which defined a new DNS resource record type for locating servers offering specific services, including fields for priority, weight, port, and target host.[6] This experimental RFC introduced the basic wire format and resolution algorithm but focused primarily on integration with the SVRLOC protocol, limiting its initial scope to service advertisement in local environments.[6] The specification evolved significantly with RFC 2782 in February 2000, authored by Arnt Gulbrandsen, Paul Vixie, and Levon Esibov, which obsoleted RFC 2052 and established the SRV record (type 33) as a Proposed Standard.[7] Key refinements included prepending underscores to service and protocol names to prevent naming conflicts, enhanced load-balancing rules, and broader applicability beyond SVRLOC to general DNS usage for protocols like SIP and XMPP.[7] Subsequent clarifications have come through errata published by the RFC Editor, addressing ambiguities in the selection algorithm.[8][9] In 2011, RFC 6335 formalized the IANA registry for service names and transport protocols used in SRV records, standardizing assignments to ensure interoperability across implementations.[10] RFC 8553 in March 2019 further updated the specification by addressing issues with underscored DNS node names used in SRV records, ensuring compatibility with existing implementations.[11] This shifted emphasis from SVRLOC-specific integration toward seamless DNS-wide adoption, supporting diverse applications in enterprise and internet-scale environments post-2000. No major updates to the core SRV specification have occurred since, but discussions in the IETF DNSOP working group have highlighted growing adoption in cloud-native systems, such as container orchestration platforms. For instance, draft efforts leading to RFC 9460 in 2023 introduced the related SVCB record type with alias support, extending SRV-like functionality for modern service binding without altering the original format.Technical Specification
Record Format
The SRV record adheres to the DNS resource record syntax and is defined in zone files as_Service._Proto.name TTL IN SRV Priority Weight Port Target.[1]
In this format, _Service represents the symbolic name of the desired service, such as _sip for Session Initiation Protocol, and is prefixed with an underscore to distinguish it from other DNS labels. _Proto specifies the underlying transport protocol, typically _tcp or _udp in lowercase, also prefixed with an underscore. name is the domain name (e.g., example.com) to which the record applies, forming the full owner name _Service._Proto.name. TTL indicates the standard time-to-live value in seconds for caching the record. IN denotes the Internet address class. Priority is a 16-bit unsigned integer ranging from 0 to 65535, determining the order of preference among multiple records for the same service. Weight is another 16-bit unsigned integer (0-65535) that enables proportional selection of targets sharing the same priority. Port is a 16-bit unsigned integer (0-65535) identifying the specific port on the target host, which may override the default port assigned by the Internet Assigned Numbers Authority (IANA) for the service. Target is the canonical hostname of the endpoint server, which must resolve directly to A or AAAA records and cannot be a CNAME alias.[1]
A representative example for a SIP service is _sip._tcp.example.com. 3600 IN SRV 10 60 5060 sip1.example.com., where the record has a TTL of 3600 seconds, priority 10, weight 60, and directs to port 5060 on sip1.example.com. A complementary record might be _sip._tcp.example.com. 3600 IN SRV 10 40 5060 sip2.example.com., using the same priority and port but a lower weight for sip2.example.com.[1]
The Service and Proto fields are case-insensitive per DNS conventions but are conventionally lowercase; the mandatory underscore prefixes on both prevent conflicts with unqualified DNS names.[1]
Resolution Process
Clients initiate the resolution of SRV records by constructing a fully qualified domain name (FQDN) in the format_service._proto.targetdomain, where _service represents the symbolic name of the service (e.g., _sip for Session Initiation Protocol), _proto specifies the underlying transport protocol (e.g., _tcp or _udp), and targetdomain is the domain name under which the service is offered. The client then sends a DNS query specifically requesting records of type SRV for this constructed name.
The authoritative DNS server responds with a resource record set containing zero or more SRV records, which are returned in no particular order. If the response includes SRV records, the client proceeds to parse them; however, if no SRV records are present, the client falls back to issuing a standard A (for IPv4) or AAAA (for IPv6) query directly on the targetdomain to obtain IP addresses for service endpoints. This fallback ensures compatibility with environments lacking SRV support while adhering to the protocol defined in RFC 2782.
Upon receiving the SRV records, the client sorts them in ascending order of priority, preferring those with the lowest numerical priority value to direct traffic to primary servers first. For any group of records sharing the same priority, the client applies a weight-based random selection mechanism, equivalent to weighted round-robin, where the relative weights determine the selection probability for each target hostname, thereby distributing load proportionally among available servers. Details on the priority and weight algorithms are further elaborated in the mechanisms for load balancing.
In cases of errors during resolution, an NXDOMAIN response indicates that the queried name does not exist, signaling service unavailability, while an empty answer section with no SRV records triggers the fallback query; failure of both typically results in the client deeming the service inaccessible. If individual target hostnames within valid SRV records cannot be resolved to IP addresses—such as due to non-existent domains or resolution chain issues—the client cannot establish connections to those specific endpoints, leading to partial resolution failure.
To optimize performance and reduce network load, clients cache the entire SRV response, including all records and their associated targets, for the duration specified by the TTL (Time to Live) field in the DNS records, after which a fresh query is required.
Load Balancing and Availability
Priority and Weight Mechanisms
The priority field in an SRV record, a 16-bit unsigned integer ranging from 0 to 65535, governs the sequence in which client applications attempt connections to target hosts. Clients must exhaust all records with the lowest priority value—such as 0 for primary targets—before proceeding to records with incrementally higher priorities. This mechanism ensures ordered access, prioritizing more preferred servers while providing fallback options only after primary ones are deemed unreachable.[1] For SRV records sharing the same priority, the weight field facilitates probabilistic load distribution among targets. This 16-bit unsigned integer assigns a relative selection probability proportional to its value; higher weights increase the likelihood of a target being chosen. Records with a weight of 0 indicate no weighting preference and are recommended when all targets at that priority are equivalent. In the selection algorithm, weight 0 records are placed at the beginning of the ordered list in arbitrary order, followed by weighted records selected via the random process. However, the RFC specifies that in the presence of records with weights greater than 0, weight 0 records should have a very small chance of being selected, though the algorithm may lead to them being tried first; mixing weights is generally avoided.[1] In practice, for records with non-zero weights, the probability of selecting a given record is its weight divided by the total weight of all records at that priority—for example, weights of 1, 2, and 3 yield selection chances of approximately 17%, 33%, and 50%, respectively. Note that the algorithm introduces a slight bias favoring earlier-listed records.[1][9] RFC 2782 specifies the algorithm for selecting among equal-priority records to enforce this proportionality. First, records with weight 0 are ordered arbitrarily as a group. For the remaining weighted records, a uniform random integer R is generated in the range 0 to (total weight - 1). The list is then traversed, cumulatively subtracting each record's weight from R; the first record where the remainder falls below its weight is selected. This process repeats, removing selected records until none remain, ensuring weighted random ordering without bias toward list position, though a minor positional bias exists.[1][12] Weights and priorities are inherently static, as they are defined directly within the DNS records and do not change without administrative intervention. To enable dynamic load balancing responsive to varying server conditions, such as real-time capacity adjustments, short TTL values can be set on SRV records to encourage frequent re-queries, combined with dynamic DNS update protocols (e.g., RFC 2136) to modify weights or priorities periodically.[1][13] A concrete example illustrates this: two SRV records both with priority 10, one bearing weight 5 and the other weight 3, result in a total weight of 8. The first record is thus selected with probability 5/8 (62.5%), and the second with 3/8 (37.5%), distributing load accordingly over repeated client selections.[1]Client Selection and Fallback
Clients query the DNS for SRV records associated with a specific service, protocol, and domain, receiving a list of resource records that they sort in ascending order of priority value, starting with the lowest (preferred) group.[14] Within this lowest-priority group, the client selects a target host probabilistically based on the relative weights of the records, as a mechanism for load distribution among equally preferred servers; higher weights indicate greater preference for selection. The algorithm orders the targets for sequential attempts, starting with weight 0 if present.[14] The selected target hostname is then resolved to IP addresses using A or AAAA records, after which the client attempts a connection to the specified port on one of those addresses.[14] If the connection attempt to a target in the current priority group fails—due to reasons such as timeout, connection refusal, or protocol-specific errors—the client proceeds to the next target within the same group, exhausting all options before advancing to the subsequent higher-priority group.[14] This sequential failover process continues across priority levels until a successful connection is established or all SRV records are depleted, at which point the client may fall back to querying A records directly for the original domain if no viable SRV targets remain.[14] Retry behaviors beyond immediate failover are protocol-dependent; for instance, implementations may incorporate exponential backoff for overall transaction retries, but SRV-specific retries focus on sequential target attempts rather than timed delays. Clients must respect the TTL values in SRV records, caching the results for the specified duration before re-querying DNS to account for changes in server availability.[14] To provision high availability, administrators configure multiple SRV records where primary servers receive a priority of 0 for immediate preference, while backup servers are assigned higher values such as 10, ensuring clients automatically shift to redundants during outages without manual intervention.[14] This setup promotes redundancy across geographically distributed or replicated servers, enhancing service reliability in environments like VoIP or messaging systems. A key limitation of SRV records is the absence of built-in health checks or real-time status indicators; target viability is assessed solely through client-side connection probes, necessitating external monitoring tools or application-layer verification to proactively detect and remove unhealthy servers from consideration.[14]Applications and Usage
Supported Protocols
The Session Initiation Protocol (SIP), defined in RFC 3263, utilizes SRV records to enable dynamic discovery of SIP servers, including registrars and proxies, primarily through queries for _sip._udp and _sip._tcp services.[4] This integration is essential for Voice over IP (VoIP) and IP Multimedia Subsystem (IMS) deployments, allowing clients to locate optimal servers based on priority and weight without hardcoding hostnames or ports.[4] The Extensible Messaging and Presence Protocol (XMPP), specified in RFC 6120, employs SRV records for federated server discovery in chat and presence applications, using _xmpp-server._tcp to resolve domain-based connections.[5] This mechanism supports seamless interoperability across domains by directing clients to the appropriate XMPP servers, enhancing scalability in distributed messaging systems.[5] Several other protocols registered with the Internet Assigned Numbers Authority (IANA) also leverage SRV records for service location. The Lightweight Directory Access Protocol (LDAP) commonly uses _ldap._tcp queries to identify directory servers, as exemplified in RFC 2782, facilitating authentication and directory services in enterprise environments.[7] Kerberos, as described in RFC 4120, uses _kerberos._tcp and _kerberos._udp for locating Key Distribution Centers (KDCs), enabling secure authentication across realms. Similarly, Calendaring Extensions to WebDAV (CalDAV) and vCard Extensions to WebDAV (CardDAV), per RFC 6764, rely on _caldavs._tcp and _carddavs._tcp for secure discovery of calendar and contact servers, often in conjunction with DNS TXT records for additional configuration details.[15] More recent adoptions include the Message Queuing Telemetry Transport (MQTT) protocol over TLS, where implementations post-2020 utilize _mqtt._tcp SRV records for broker discovery in IoT scenarios, though this remains implementation-dependent rather than a core standard requirement.[16] For WebRTC-based media servers, signaling protocols like SIP can incorporate SRV records as described in RFC 5766 for TURN servers, allowing flexible location of TURN/STUN relays during peer-to-peer sessions.[17] The IANA Service Name and Transport Protocol Port Number Registry, governed by RFC 6335, catalogs over 100 services applicable to SRV records, providing a centralized reference for protocol-specific service names and their DNS integration. For example, the Matrix protocol uses matrix-fed.tcp SRV records for discovering federation servers in decentralized chat systems.[18][16] This registry ensures standardized naming, such as those prefixed with underscores (e.g., _service._proto), to avoid conflicts and promote interoperability across diverse applications.System Implementations
In Microsoft Active Directory, SRV records are essential for service location, particularly in identifying domain controllers through entries like _ldap._tcp.dc._msdcs.dig SRV _sip._tcp.example.com to retrieve SIP server details including port and priority.[28] In programming contexts, Python's dnspython library provides robust SRV resolution via the dns.resolver.resolve function, parsing responses into structured objects with priority, weight, port, and target attributes for application integration.[29]
SRV records see widespread adoption in enterprise settings, particularly for SIP and VoIP deployments where they enable failover and load distribution across trunks, as standardized in RFC 3263.[30] Their use remains limited in web applications, however, due to reliance on HTTP-based alternatives like API gateways and service meshes that bypass traditional DNS mechanisms.[31]