DNS SRV Record Explained — Service Discovery via DNS
Learn how DNS SRV records enable service discovery by advertising the host, port, priority, and weight for network services. Covers SIP, XMPP, LDAP, Active Directory, CalDAV, and more with dig examples.
What you'll learn
- Understand the SRV record naming convention (_service._proto.name) and its four data fields
- Configure SRV records for common protocols including SIP, XMPP, LDAP, and CalDAV
- Use priority and weight fields to implement failover and weighted load balancing
- Query and troubleshoot SRV records using dig and common diagnostic techniques
Most DNS record types map a name to an address. A records give you an IPv4 address. AAAA records give you an IPv6 address. MX records add a priority layer for mail delivery. But none of them tell a client which port to connect to, or how to distribute load across a pool of servers.
That is the job of the SRV record. Defined in RFC 2782, the SRV record provides a general-purpose mechanism for service discovery via DNS. It advertises the hostname, port number, priority, and weight for any service — allowing clients to locate, fail over, and load-balance services automatically.
The SRV Record Format
An SRV record follows a strict naming convention and carries four data fields:
_service._protocol.name. TTL IN SRV priority weight port targetHere is a concrete example:
_sip._tcp.example.com. 3600 IN SRV 10 60 5060 sip1.example.com.This tells any SIP client: "To reach the SIP service over TCP at example.com, connect to sip1.example.com on port 5060. This server has priority 10 and weight 60."
The Name: _service._protocol.domain
The record name is built from three parts:
| Part | Description | Examples |
|---|---|---|
_service | IANA-registered service name, prefixed with underscore | _sip, _xmpp-client, _ldap, _minecraft |
_protocol | Transport protocol, prefixed with underscore | _tcp, _udp, _tls |
name | The domain name the service belongs to | example.com. |
The underscore prefix is required by the specification. It prevents collisions with regular hostnames — you would never have a host called _sip.
The Four Data Fields
| Field | Description | Range |
|---|---|---|
| Priority | Lower values are preferred. Clients try servers in ascending priority order. | 0 – 65535 |
| Weight | Relative load-balancing weight among servers with the same priority. Higher values get more traffic. | 0 – 65535 |
| Port | The TCP or UDP port the service listens on. | 1 – 65535 |
| Target | The hostname of the server providing the service. Must have an A or AAAA record. | FQDN |
Tip: The target field must be a hostname, not an IP address. The client performs a separate A/AAAA lookup on the target to get the actual IP. The target should never be a CNAME — point it directly to a name with A/AAAA records.
How Service Discovery Works
When a client application needs to connect to a service, it performs the following steps:
- Construct the SRV query name — e.g.,
_xmpp-client._tcp.example.com - Query DNS for SRV records at that name
- Sort by priority — group servers by priority value, lowest first
- Select within priority group by weight — within each group, pick a server randomly but biased by weight (a server with weight 70 is chosen ~7x more often than one with weight 10)
- Connect to the chosen target on the specified port
- Fall back — if the connection fails, try the next server in the priority/weight order
This is the same conceptual model as MX record priority for email, but extended with port numbers and weighted load balancing.
Priority: Failover Between Tiers
Priority controls the order in which servers are tried. Lower values mean higher preference:
_sip._tcp.example.com. 3600 IN SRV 10 50 5060 primary.example.com.
_sip._tcp.example.com. 3600 IN SRV 20 50 5060 secondary.example.com.
_sip._tcp.example.com. 3600 IN SRV 30 50 5060 tertiary.example.com.Clients connect to primary.example.com first (priority 10). If it is unreachable, they try secondary.example.com (priority 20), then tertiary.example.com (priority 30).
Tip: Leave gaps between priority values (10, 20, 30 rather than 1, 2, 3). This makes it easy to insert new servers between tiers later without renumbering everything. This is the same advice that applies to MX record priorities.
Weight: Load Balancing Within a Tier
Among servers with the same priority, the weight field controls traffic distribution:
_sip._tcp.example.com. 3600 IN SRV 10 70 5060 server1.example.com.
_sip._tcp.example.com. 3600 IN SRV 10 20 5060 server2.example.com.
_sip._tcp.example.com. 3600 IN SRV 10 10 5060 server3.example.com.All three servers are priority 10, so they are all equally preferred. But server1 (weight 70) receives approximately 70% of connections, server2 (weight 20) gets ~20%, and server3 (weight 10) gets ~10%.
A weight of 0 has special meaning: servers with weight 0 should only be chosen when no other servers in that priority group are available. This is useful for "last resort" backends.
_sip._tcp.example.com. 3600 IN SRV 10 60 5060 fast.example.com.
_sip._tcp.example.com. 3600 IN SRV 10 0 5060 slow-backup.example.com.Use Cases
SIP / VoIP
SIP is one of the original drivers behind SRV records. VoIP clients query SRV to discover where to register and where to send calls:
_sip._tcp.example.com. 3600 IN SRV 10 100 5060 sip1.example.com.
_sip._tcp.example.com. 3600 IN SRV 20 100 5060 sip2.example.com.
_sip._udp.example.com. 3600 IN SRV 10 100 5060 sip1.example.com.
_sips._tcp.example.com. 3600 IN SRV 10 100 5061 sip1.example.com.Note the separate entries for TCP, UDP, and TLS (_sips) transports.
XMPP / Jabber
XMPP uses two service names — one for client connections and one for server-to-server federation:
_xmpp-client._tcp.example.com. 3600 IN SRV 5 0 5222 xmpp.example.com.
_xmpp-server._tcp.example.com. 3600 IN SRV 5 0 5269 xmpp.example.com.Clients connect on port 5222; other XMPP servers federate on port 5269.
LDAP and Active Directory
Microsoft Active Directory relies heavily on SRV records for domain controller discovery. Workstations and member servers find domain controllers, global catalog servers, and Kerberos KDCs by querying SRV names under _msdcs:
_ldap._tcp.example.com. 3600 IN SRV 0 100 389 dc1.example.com.
_ldap._tcp.dc._msdcs.example.com. 3600 IN SRV 0 100 389 dc1.example.com.
_kerberos._tcp.example.com. 3600 IN SRV 0 100 88 dc1.example.com.
_gc._tcp.example.com. 3600 IN SRV 0 100 3268 dc1.example.com.If Active Directory DNS is broken, domain joins, group policy processing, and user logins will all fail. These SRV records are critical infrastructure.
CalDAV / CardDAV
Calendar and contact clients (Apple Calendar, Thunderbird, DAVx5) use SRV to auto-discover the right server:
_caldavs._tcp.example.com. 3600 IN SRV 0 1 443 cal.example.com.
_carddavs._tcp.example.com. 3600 IN SRV 0 1 443 contacts.example.com.The s suffix in _caldavs and _carddavs indicates TLS-secured connections on port 443.
Game Servers (Minecraft)
Minecraft clients check SRV records so players can connect with just a domain name instead of needing to know the port:
_minecraft._tcp.example.com. 3600 IN SRV 0 5 25565 mc.example.com.A player types example.com in the Minecraft client, which queries _minecraft._tcp.example.com, discovers port 25565 on mc.example.com, and connects.
Matrix / Element Chat
The Matrix federation protocol uses SRV for server-to-server communication:
_matrix._tcp.example.com. 3600 IN SRV 10 0 8448 matrix.example.com.Microsoft 365 / Teams
Skype for Business and Teams federation relies on SRV records:
_sipfederationtls._tcp.example.com. 3600 IN SRV 100 1 5061 sipfed.online.lync.com.
_sip._tls.example.com. 3600 IN SRV 100 1 443 sipdir.online.lync.com.Disabling a Service via SRV
To explicitly declare that a service is not available at a domain, set the target to a single dot (.) with port 0:
_sip._tcp.example.com. 3600 IN SRV 0 0 0 .This is preferable to simply having no SRV record, because it gives a definitive "this service does not exist here" answer instead of leaving clients to time out.
Querying SRV Records with dig
Basic SRV Query
dig SRV _sip._tcp.example.comThis returns the full DNS response including the authority and additional sections (which often contain the A/AAAA records for the targets).
Short Output
dig SRV _sip._tcp.example.com +shortReturns just the data fields:
10 60 5060 sip1.example.com.
20 40 5060 sip2.example.com.Query the Authoritative Server
To bypass resolver caches and check what your nameserver is actually serving:
dig SRV _xmpp-client._tcp.example.com @ns1.dnscale.eu +shortCheck Multiple Service Types
# Check SIP, XMPP, and LDAP for a domain
for svc in _sip._tcp _xmpp-client._tcp _ldap._tcp; do
echo "=== $svc ==="
dig SRV $svc.example.com +short
doneVerify the Target Resolves
After confirming the SRV record exists, verify the target hostname has an address record:
dig SRV _sip._tcp.example.com +short
# Output: 10 60 5060 sip1.example.com.
dig A sip1.example.com +short
# Output: 198.51.100.10If the target has no A or AAAA record, clients will discover the service but fail to connect.
Common Mistakes
1. Missing A/AAAA Records for the Target
The SRV target must resolve to an IP address. If sip1.example.com has no A or AAAA record, the SRV record is useless. Always create the target's address records before or alongside the SRV record.
2. Using an IP Address as the Target
SRV targets must be hostnames, not IP addresses. This is invalid:
# Wrong
_sip._tcp.example.com. SRV 10 60 5060 198.51.100.10Create an A record for a hostname and point the SRV target at it instead.
3. Pointing the Target at a CNAME
While technically possible, pointing an SRV target at a CNAME adds an extra DNS lookup and can cause problems with some resolvers. Use a direct A/AAAA name.
4. Forgetting the Underscore Prefix
The service and protocol components must start with an underscore. sip._tcp is wrong; _sip._tcp is correct.
5. Wrong Protocol
SIP can run over both TCP and UDP. If you only create _sip._tcp records but your phones use UDP, they will not discover the server. Check your application's documentation for which protocol it queries.
6. Not Checking Application Support
Not all applications implement SRV lookup. Some older software hardcodes hostnames and ports. Always test with your specific client software to confirm it actually queries SRV records.
SRV vs. HTTPS and SVCB Records
The newer HTTPS and SVCB record types address some limitations of SRV for web traffic:
| Feature | SRV | HTTPS / SVCB |
|---|---|---|
| Port advertisement | Yes | Yes |
| Priority | Yes | Yes (via SvcPriority) |
| Weight | Yes | No (not directly) |
| ALPN negotiation | No | Yes (h2, h3) |
| ECH support | No | Yes |
| IP hints | No | Yes |
| Browser support | No | Yes (HTTPS type) |
| General service discovery | Yes | Yes (SVCB type) |
When to use which:
- Use SRV for protocols that were designed around it: SIP, XMPP, LDAP, CalDAV, Minecraft, Matrix, Active Directory
- Use HTTPS for web services that benefit from ALPN, HTTP/3, and ECH
- Use SVCB as the general-purpose successor to SRV for new protocol designs
SRV is not going away — it is deeply embedded in dozens of protocols — but new protocol specifications increasingly adopt SVCB instead.
Real-World Configuration Example
Here is a complete SRV setup for a company running self-hosted XMPP, SIP, and CalDAV services, with failover and load balancing:
; XMPP — client and server federation
_xmpp-client._tcp.example.com. 3600 IN SRV 10 70 5222 xmpp1.example.com.
_xmpp-client._tcp.example.com. 3600 IN SRV 10 30 5222 xmpp2.example.com.
_xmpp-server._tcp.example.com. 3600 IN SRV 10 50 5269 xmpp1.example.com.
_xmpp-server._tcp.example.com. 3600 IN SRV 20 50 5269 xmpp2.example.com.
; SIP — primary with hot standby
_sip._tcp.example.com. 3600 IN SRV 10 100 5060 sip1.example.com.
_sip._tcp.example.com. 3600 IN SRV 20 100 5060 sip2.example.com.
_sip._udp.example.com. 3600 IN SRV 10 100 5060 sip1.example.com.
; CalDAV — single server
_caldavs._tcp.example.com. 3600 IN SRV 0 1 443 cal.example.com.
_carddavs._tcp.example.com. 3600 IN SRV 0 1 443 cal.example.com.
; Supporting A records for all targets
xmpp1.example.com. 3600 IN A 198.51.100.10
xmpp2.example.com. 3600 IN A 198.51.100.11
sip1.example.com. 3600 IN A 198.51.100.20
sip2.example.com. 3600 IN A 198.51.100.21
cal.example.com. 3600 IN A 198.51.100.30XMPP client connections are load-balanced 70/30 between two servers at the same priority. XMPP federation has a primary (xmpp1, priority 10) and failover (xmpp2, priority 20). SIP has a hot standby. CalDAV runs on a single server.
Related Record Types
- A — IPv4 address for the SRV target
- AAAA — IPv6 address for the SRV target
- MX — similar priority-based discovery, but specific to email
- CNAME — canonical name alias (avoid as SRV target)
- HTTPS — modern service binding for web traffic
- SVCB — general-purpose service binding, the modern successor to SRV
- TXT — often used alongside SRV for service configuration metadata
- NS — delegates DNS zones to nameservers
For a complete overview of all record types, see the DNS Record Types guide.
Conclusion
SRV records solve a fundamental problem in networked computing: how does a client find the right server, on the right port, with the right fallback behavior, without hardcoding anything? By encoding priority, weight, port, and target into a single DNS record with a standardized naming convention, SRV enables automatic service discovery for SIP, XMPP, LDAP, Active Directory, CalDAV, game servers, and dozens of other protocols. While newer record types like HTTPS and SVCB are emerging for web-centric use cases, SRV remains the standard for the broad ecosystem of non-HTTP services. Use dig SRV to inspect your records, ensure every target has a corresponding A or AAAA record, and leave gaps between priority values for future flexibility.
Ready to manage your DNS with confidence?
DNScale provides anycast DNS hosting with a global network, real-time analytics, and an easy-to-use API.
Start free