The SRV record

Copy article link Updated March 28, 2023

The SRV or "service locator" DNS record type enables service discovery in the DNS. SRV records allow services to be advertised on specific ports and used in an order controlled by the owner of the service. SRV also provides a load balancing feature.

The SRV record type was proposed in the late 1990s in RFC 2782. The SRV record addresses limitations in the DNS around advertising and consuming services. Not all application protocols support SRV, but many do.

Service location in the DNS. By NsLookup.io. Licensed under CC By 4.0.

SRV record format

Each SRV record specifies one possible endpoint for a service. Each record also includes information on how clients should select among the available endpoints. The owner name of the SRV record is an essential part of the format. Like all other records in the DNS, each SRV record also has a Time-to-Live (TTL) value in seconds.

The SRV record format is:

_Service._Proto.Name TTL SRV Priority Weight Port Target

Let's examine each of the SRV record fields one by one.

_Service: This is a label in the DNS name that indicates the name of the service. It must begin with an underscore character.
_Protocol: This is a label in the DNS name that indicates the protocol used by the service. It must begin with an underscore character. Protocol is usually either "_tcp" or "_udp".
Name: The DNS name of the organization or site that is providing the service.
TTL: The TTL of this record in seconds. The TTL of all SRV records for a single owner name must be identical.
Priority: The priority of this endpoint as a 16-bit unsigned integer value. The SRV record or records with the lowest priority value among endpoints are used first.
Weight: A 16-bit unsigned integer value. Weights are relative. Clients use weight to select randomly among endpoints with identical priority values.
Port: The port number for this endpoint as a 16-bit unsigned integer.
Target: The DNS hostname for this endpoint. The target may resolve to a CNAME record.

Priority versus weight

Priority and weight determine how clients select one of the endpoints in a set of SRV records. Priority is similar to the preference field in MX records. But SRV also includes a random component through the weight field for more dynamic load balancing.

The endpoints with the lowest priority are used first. Weight specifies the relative amount of requests that each endpoint with the same priority should receive.

Clients randomly select one of the endpoints using their weights if multiple SRV records have the same priority. The client adds the weight values and generates a random number between 1 and the sum of the weights to select an endpoint.

An example of weights

If two SRV records have the same priority value and weight values of 100 and 900, a client would generate a random number between 1 and 1000. If the result is 1 through 100, the first endpoint would be used. If the result is 101 through 1000, the second endpoint would be used. The same load balancing would be achieved if the weight values were 10 and 90 because weights are relative.

The same value can be used for all weights if the service owner wants equal load balancing. A value of 1 is typical in this case.

Service names

Many applications have used SRV records over the years. Service names were first collected in a temporary registry operated by dns-sd.org. The Internet Assigned Numbers Authority (IANA) now maintains an official registry of service names. The IANA registry includes whether TCP or UDP is supported and a default port number.

Finding SRV records for a service

To find the set of endpoints for a service that uses SRV records, a client sends a DNS query of type SRV for a query name in the format _Service._Protocol.Name. The application protocol specifies the service and protocol values in the query name. For Minecraft, the first label is "_minecraft" and the second label is "_tcp".

Putting these values together, the query name to discover the example.org Minecraft servers would be _minecraft._tcp.example.org.

In-depth with a Minecraft SRV example

The SRV record set for the Minecraft servers for example.org might look like this:

_minecraft._tcp.example.org 3600 SRV 1 100 25565 mserver1.example.org.
_minecraft._tcp.example.org 3600 SRV 1  50 25565 mserver2.example.org.
_minecraft._tcp.example.org 3600 SRV 2 100 25565 mserver3.example.org.

As we've already seen, the service name is "_minecraft", and the protocol is "_tcp". The TTL for each record is one hour (3600 seconds).

The first two endpoints have a priority of 1. Clients contact these first. The third endpoint has a priority of 2 so clients only use it if the first two servers are down. "mserver3" is a fallback server.

The weight for the first server is 100, and the weight for the second server is 50. Clients randomly select between these two servers such that two-thirds of requests go to "mserver1" and one-third go to "mserver2".

Lastly comes the port and target. The target is the DNS name of the server hosting the endpoint. This example uses the default Minecraft port of 25565. A different port value can be used. The Minecraft server's port configuration must match the port value in the SRV record.

SRV records in Kubernetes

Kubernetes uses SRV records for named ports. A named port is an endpoint for a service. The owner name of the SRV record in the DNS is of the form: _my-port-name._my-port-protocol.my-svc.my-namespace.svc.my-zone.

An example SRV record for a Kubernetes HTTPS endpoint for example.org:

_https._tcp.kubernetes.default.svc.example.org. 3600 SRV 1 100 443 kubernetes.default.svc.example.org.

For more information on how Kubernetes uses the DNS, read our article on the life of a DNS query in Kubernetes.

Other SRV examples

Many application protocols use SRV records. A few examples:

SIP (Session Initiation Protocol): SIP uses a typical SRV record set with _sip as the service name. SIP can use either TCP or UDP.

_sip._udp.example.org 3600 SRV 1 100 5060 sip_server.example.org.

XMPP (Extensible Messaging and Presence Protocol): XMPP generally has two SRV record sets with different service names. "_xmpp-client" is used for client-to-server connections. "_xmpp-server" is used for server-to-server connections.

_xmpp-client._tcp.example.org 3600 SRV 1 100 5060 xmpp_server.example.org.
_xmpp-server._tcp.example.org 3600 SRV 1 100 5060 xmpp_server.example.org.

Kerberos: Several different SRV records can be defined for locating Kerberos KDCs (Key Distribution Centers). Kerberos supports both TCP and UDP so there will usually be SRV records for both protocols. A SRV for the master KDC can be included. Clients use the "_kpasswd" SRV records when changing passwords.

_kerberos._udp.example.org        3600 SRV 1 100 88  kdc1.example.org.
_kerberos._tcp.example.org        3600 SRV 1 100 88  kdc1.example.org.
_kerberos-master._tcp.example.org 3600 SRV 1 100 749 kdcm.example.org.
_kpasswd._tcp.example.org         3600 SRV 1 100 464 kdc1.example.org.

LDAP (Lightweight Direction Access Protocol): The service name "_ldap" is used, and only TCP is supported.

_ldap._tcp.example.org 3600 SRV 1 100 389 ldap1.example.org.
_ldap._tcp.example.org 3600 SRV 1 100 389 ldap2.example.org.

CalDAV/CardDAV (calendar and address book protocols): CalDAV and CardDAV each have two possible SRV record sets: one appended by "s" for SSL connections and one without "s" for non-SSL connections.

_caldav._tcp.example.org   3600 SRV 1 100 8008 cal_srv.example.org.
_caldavs._tcp.example.org  3600 SRV 1 100 8443 cal_secure_srv.example.org.
_carddav._tcp.example.org  3600 SRV 1 100 8008 card_srv.example.org.
_carddavs._tcp.example.org 3600 SRV 1 100 8443 card_secure_srv.example.org.

matrix (an open standard real-time communication protocol): If no SRV exists, the matrix protocol defines alternative DNS lookups used to locate servers.

_matrix._tcp.example.org 3600 SRV 1 100 8448 matrix_server.example.org.

Other service location record types

Before SRV, the only way to advertise a service was to publish a set of address records for a name. There was no way to provide a port number or order the endpoints.

Several other DNS record types exist for service location. These include:

SVCB and HTTPS: The Service Binding (SVCB) record type is a new standard emerging to address the shortcomings of SRV. HTTPS is a variant of SVCB specifically for HTTP clients. The SVCB-HTTPS draft specifies these types.
These records are a better version of SRV. They are extensible, can instruct clients to upgrade or switch protocols, and in general improve upon SRV. Even though they are new, they are becoming de facto standard. They are already used by iOS, Chrome, and Firefox.
MX: The Mail Exchange (MX) record type was part of the original DNS specifications. It includes a Preference field to order mail servers. Virtually all email transactions continue to use MX records.
URI: Introduced in RFC 7553, the URI record type was intended to improve on SRV by storing URIs in the DNS instead of hostnames. This record type is not in widespread use.
AFSDB: This is a DNS record type used to publish servers for AFS (the Andrew File System). RFC 1183 specifies AFSDB. It does not include a way to order endpoints.

Looking up SRV records for a name

The dig or nslookup command line tools can query SRV records for a DNS name. To find the LDAP SRV records for Google, use this command:

dig SRV _ldap._tcp.google.com

On operating systems that support nslookup, you can use the following:

nslookup -type=srv _ldap._tcp.google.com

You can also check the SRV records for any domain name in our SRV lookup tool or by entering it here: