An SRV record is a service locator record in the Domain Name System that tells a client which host and which port provide a named service for a domain, together with a priority and a weight that control failover and load distribution. Among the DNS records of the Internet, it is the general mechanism for service discovery: instead of assuming a fixed host name and a well-known port, a client asks the domain where a service lives.
The record type is defined in RFC 2782 and carries the type code 33. It is widely used by SIP telephony, XMPP messaging, LDAP and Kerberos in Active Directory, Minecraft servers, CalDAV and CardDAV, and by mail client autoconfiguration. Web browsers, by contrast, have never adopted SRV for ordinary HTTP, which is one of the main reasons the newer SVCB and HTTPS records were created.
How an SRV record locates a service
An SRV record works by placing the service and protocol labels in front of the domain name, so a lookup asks a precise question such as “where is the SIP service over TCP for example.com”. The owner name follows the pattern _service._proto.name, for example _sip._tcp.example.com or _xmpp-server._tcp.example.org. The leading underscores keep these labels apart from ordinary host names.
The record data contains four fields: priority, weight, port and target. A typical entry reads _sip._tcp.example.com. 3600 IN SRV 10 60 5060 sip1.example.com. The target must be a host name that itself has A or AAAA records; it may not be an IP address and, by specification, must not be a CNAME alias.
The following table explains each field of the SRV record data and the range of values it accepts.
| Field | Value range | Meaning |
|---|---|---|
| Priority | 0 to 65535 | Lower value is tried first |
| Weight | 0 to 65535 | Relative share among equal priorities |
| Port | 0 to 65535 | TCP or UDP port of the service |
| Target | Host name or “.” | Server that provides the service |
| TTL | Usually 300 to 86400 s | How long resolvers may cache the answer |
A target consisting of a single dot has a special meaning: it states that the service is decidedly not available at this domain. This lets an administrator answer the question explicitly instead of leaving clients to time out.
Priority and weight in SRV selection
The client algorithm first groups records by priority and always contacts the group with the lowest number before any other group. Only when every server in that group fails does it move on to the next priority level, which gives SRV a built-in active-standby failover model without any external load balancer.
Within one priority group, the weight sets a proportional chance of selection. Two records with weights 60 and 40 should receive roughly 60 and 40 percent of new connections over time. A weight of zero means the record is chosen only when no record with a positive weight remains, so it is suited to a server that should receive traffic rarely.
The table below shows how one set of SRV records produces a primary pair with load sharing and a single backup.
| Target | Priority | Weight | Resulting role |
|---|---|---|---|
| sip1.example.com | 10 | 60 | Primary, about 60% of traffic |
| sip2.example.com | 10 | 40 | Primary, about 40% of traffic |
| sip-dr.example.net | 20 | 0 | Backup used only if both primaries fail |
The weighting is statistical, not exact. Each client performs its own random selection and caches the result, so short observation periods can look uneven, and the distribution depends on clients actually implementing the RFC 2782 algorithm rather than always taking the first answer.
SRV compared with MX, CNAME and HTTPS records
SRV belongs to a family of DNS records that redirect clients to other hosts, and its closest relatives each solve a narrower problem. The comparison below clarifies where SRV fits among the neighboring record types.
| Record type | What it points to | Port included | Selection controls |
|---|---|---|---|
| SRV | Host for a named service and protocol | Yes | Priority and weight |
| MX | Mail exchanger for a domain | No, SMTP port 25 implied | Preference only |
| CNAME | Another domain name (alias) | No | None |
| HTTPS / SVCB | Endpoint with connection parameters | Optional | Priority and parameters |
| A / AAAA | IPv4 or IPv6 address | No | None |
MX can be seen as a specialized predecessor of SRV: it has a preference value but no port and no weight. The HTTPS and SVCB records extend the SRV idea with parameters such as supported ALPN protocols, Encrypted Client Hello keys and address hints, and they are the path browsers chose instead of SRV.
Protocols and applications that rely on SRV
SRV adoption is decided per protocol: a client only performs SRV lookups if its protocol specification tells it to. The following table lists common service labels and the default ports they usually advertise.
| Owner name prefix | Protocol or application | Typical port |
|---|---|---|
_sip._udp / _sip._tcp | SIP voice over IP signaling | 5060 |
_sips._tcp | SIP over TLS | 5061 |
_xmpp-client._tcp | XMPP client connections | 5222 |
_ldap._tcp.dc._msdcs | Active Directory domain controllers | 389 |
_kerberos._udp | Kerberos key distribution center | 88 |
_minecraft._tcp | Minecraft Java Edition server | 25565 |
_imaps._tcp / _submission._tcp | Mail client autoconfiguration | 993 / 587 |
In Active Directory, SRV records are not optional: domain-joined computers locate domain controllers, Kerberos and the global catalog through them. Missing or stale SRV entries are a classic cause of logon and replication failures, which is why Windows DNS servers register them dynamically.
Common SRV record mistakes
Most SRV problems come from syntax details that DNS management interfaces handle inconsistently. Some panels expect the full owner name, others only the _service._proto prefix, and some add the zone name automatically, which produces doubled names such as _sip._tcp.example.com.example.com.
- Pointing the target at a CNAME or an IP address, which violates the specification and breaks some clients.
- Forgetting the trailing dot in zone files, so the target becomes relative to the zone.
- Using the wrong transport label, for example
_tcpwhen the client queries_udp. - Assuming every client reads SRV, while many applications still connect to a fixed host and port.
- Setting long TTLs before a migration, which delays failover to new targets for hours.
Verification is straightforward with standard tools: dig _sip._tcp.example.com SRV or nslookup -type=SRV shows exactly what resolvers return, and checking the A and AAAA records of each target confirms that the chain resolves completely.
Understanding it simply
An SRV record is like a sign at a building entrance. It says which office handles a particular task and which door to use. A program may want a voice call, a chat connection or a game server. It asks the domain for that exact service. The answer gives the machine name and the door number, called the port.
The record can also list several offices in order of preference. Visitors try the preferred offices first and spread out among them. They only walk to the backup office when the main ones are closed. In this way, one small DNS entry gives a service automatic backup and sharing of work.
Applied in practice
A company with offices in two cities runs its internal telephone system on SIP. The administrator publishes two SRV records for _sip._tcp.company.example with priority 10 and weights 50 and 50, pointing to call servers in each office on port 5060, and a third record with priority 20 pointing to a hosted backup service. The TTL is set to 300 seconds.
Desk phones are configured only with the domain name. During normal operation, they spread registrations evenly across both office servers. When a power outage takes down one site, the phones there retry and land on the remaining primary server; when a later network failure isolates both offices, phones fall back to the hosted service. The result is failover without reconfiguring a single device, achieved entirely through DNS.