The SRV Record

A record that answers where a service runs

An SRV record tells a client two things an address record cannot: which host runs a named service for a domain, and which port it listens on. IANA registers the type under value 33 with the meaning server selection, and RFC 2782 defines it.

Everything before SRV assumed the port was already known: a client had to be told the exact host, or had to guess a well-known port. SRV separates the service from the machine, so a domain can put its directory service on one host and port and its calendar service on another, and move either by editing DNS.

The whole record reads as one line: _Service._Proto.Name TTL Class SRV Priority Weight Port Target. Two of those parts are the name being looked up. Four are the answer.

The name encodes the service and the protocol

The distinguishing feature of an SRV record is that half of it is in the name. A lookup for the XMPP client service on example.com is a query for _xmpp-client._tcp.example.com, and a client looking for a Kerberos server in a Windows domain queries _kerberos._tcp under the domain name. The service label comes first, the protocol label second, and both carry a leading underscore.

The underscore is deliberate. RFC 2782 says it is prepended to avoid collisions with DNS labels that occur in nature, and RFC 8552, which later formalized the convention across record types, gives the mechanical reason: the rules for a host name do not allow an underscore, so an underscored name is distinguishable from all legal host names. A host can never be called _tcp, so the branch is safe to reserve for machine-readable attributes of the domain above it.

Those labels are not free-form. RFC 8552 established an IANA registry of underscored node names precisely to avoid collisions resulting from the use of the same underscored name for different services, and RFC 2782 is stricter still about the service half: if Assigned Numbers names the service indicated, that name is the only name which is legal for SRV lookups. In practice you copy the exact labels from the documentation of whatever you are configuring. Inventing one produces a record nothing queries.

The four values in the answer

Priority is the first-choice mechanism, and it runs the same way round as MX preference: lower wins. A client must attempt to contact the target host with the lowest-numbered priority it can reach, and only moves to a higher number when the lower group cannot be reached.

Weight distributes selections among records that share one priority value. It does nothing else, and it never compares across priority levels.

Port is the TCP or UDP port on the target host, and it is the field that makes the record worth having. The service does not have to sit on a well-known number, which is why service discovery protocols describe SRV as removing the need for preassigned port numbers.

Target is the domain name of the target host. Being a domain name, it cannot be an IP address, and it needs address records of its own published at that name, because the client's next step after choosing a record is an address lookup on the target. One special value is defined: a target of a single dot means that the service is decidedly not available at this domain, which is how a domain says no rather than saying nothing.

How weight actually splits the traffic

Weight is described wrongly more often than any other field in DNS, usually as a percentage or as a second tiebreaker ranking. It is neither. RFC 2782 says only that larger weights should be given a proportionately higher probability of being selected, and the algorithm it specifies is a weighted random draw: sum the weights of the records in the group, pick a uniform random number between zero and that sum, and take the first record whose running total reaches it.

Three consequences fall out of the arithmetic, and each of them corrects a common assumption:

• The denominator is the sum of the weights in that priority group, so weights of 1 and 3 behave exactly like 25 and 75. The ratio is what matters, not the numbers.
• Weight is meaningless across priority levels. A record with weight 65535 at priority 20 does not compete with a record of weight 1 at priority 10; the priority 10 record is tried first regardless.
• The draw happens per client, per lookup. It is a statistical split across many clients, not a scheduler, and it knows nothing about how loaded any server is.

The legal range is 0 to 65535 for both priority and weight. Where there is no distribution to express, RFC 2782 recommends weight 0 so the record reads more easily, and a single SRV record with priority 0 and weight 0 is a perfectly ordinary configuration.

The services that read them

SRV records are common in exactly the places their protocols specified them, and absent everywhere else. Real examples worth recognizing in a zone file:

• Active Directory. Domain controllers register a family of names such as _ldap._tcp and _kerberos._tcp under the domain, plus site-scoped and _msdcs variants, and Windows clients use them to find a controller. This is the largest deployment of SRV records in existence and almost all of it is invisible, inside private networks.
• XMPP. RFC 6120 defines the service labels xmpp-client and xmpp-server, with clients falling back to port 5222 and servers to 5269 when no SRV answer is returned.
• Calendar and contacts. RFC 6764 defines _caldavs._tcp and _carddavs._tcp, with plain-text variants, so a client can bootstrap from an email address alone.
• Instant messaging federation. Microsoft 365 publishes a documented SRV record for SIP federation on port 5061, which is why an otherwise unremarkable business domain sometimes carries one.
• Service discovery. DNS-based service discovery builds on the same underscored pair and uses SRV to supply the port and target host for each advertised instance.

The pattern is consistent. Each is a protocol whose specification instructed its clients to perform an SRV lookup, and the record works because that instruction exists.

Why a website never has one

Browsers do not query SRV records, and no amount of publishing will make them. RFC 2782 is explicit that SRV records are expected to be used by clients for applications where the relevant protocol specification indicates that clients should use the SRV record, and adds that they should not be used in the absence of such a specification. HTTP never gained one, so a record for a web service is read by nothing.

The consequence is a class of support ticket that has no fix: you cannot use SRV to move a website to a non-standard port, to load balance a site by weight, or to give the bare domain the aliasing that CNAME cannot provide at the apex. The reason those requests recur is that SRV looks like it should solve all three.

The gap was eventually addressed with different records. RFC 9460 defines the SVCB and HTTPS types, registered by IANA under values 64 and 65, and names its own goal as enabling SRV-like benefits for HTTP, where SRV has not been widely adopted. Browsers do query the HTTPS type. If you arrived looking for SRV to solve a web problem, that is the record family to read about instead.