What Is an SRV Record

An SRV (Service) record specifies the location of servers for specific services. Unlike A records that simply map names to IPs, SRV records provide the hostname, port, priority, and weight for a service — enabling sophisticated service discovery and load balancing through DNS.

How SRV Records Work

SRV records use a special naming convention defined in RFC 2782:

_service._protocol.domain.    TTL    SRV    priority weight port target

Example:

_sip._tcp.example.com.    3600    SRV    10 60 5060 sipserver.example.com.

This tells clients: "To reach the SIP service over TCP for example.com, connect to sipserver.example.com on port 5060."

The client application must know to look up SRV records for the service it wants. The application queries _service._protocol.domain, receives the target hostname and port, then connects to the service. This separates the service location from the domain name, letting you move services between servers without changing what users type.

Record Components

Service Discovery Explained

SRV records solve a fundamental problem: how does a client find the right server and port for a service? Without SRV records, clients need hardcoded server addresses and ports. With SRV records, the client only needs the domain name.

Here's the discovery flow:

1. A SIP client wants to call user@example.com
2. It queries DNS for _sip._tcp.example.com SRV
3. DNS returns: 10 60 5060 sipserver.example.com.
4. The client resolves sipserver.example.com via A or AAAA records
5. The client connects to the resulting IP on port 5060

This is similar to how MX records work for email — the MX record tells mail clients where to deliver mail for a domain. SRV records generalize this concept to any service.

The newer HTTPS and SVCB record types provide similar service discovery capabilities for HTTPS and other services, with additional features like ALPN negotiation and encrypted client hello parameters. For web services, consider HTTPS/SVCB records instead of SRV.

Priority and Weight Explained

Priority (Preference)

Lower values are tried first. This enables failover — clients attempt servers in priority order:

_sip._tcp.example.com.    SRV    10 50 5060 primary.example.com.
_sip._tcp.example.com.    SRV    20 50 5060 backup.example.com.

Clients try primary.example.com first (priority 10), then backup.example.com (priority 20) if the primary fails.

Leave gaps between priority values (10, 20, 30 instead of 1, 2, 3) so you can insert new servers at intermediate priorities later without renumbering everything.

Weight (Load Distribution)

Among servers with the same priority, weight determines the proportion of traffic each server receives:

_sip._tcp.example.com.    SRV    10 70 5060 server1.example.com.
_sip._tcp.example.com.    SRV    10 30 5060 server2.example.com.

Server1 receives approximately 70% of traffic, server2 receives approximately 30%. The weight is relative — 70 and 30 would produce the same distribution as 7 and 3.

A weight of 0 has special meaning: servers with weight 0 should be used as a last resort when all other servers of the same priority are unavailable. This is useful for emergency fallback servers.

Combining Priority and Weight

For a production setup with primary and backup data centers, each with load-balanced servers:

; Primary data center — two servers, split 60/40
_sip._tcp.example.com.    SRV    10 60 5060 sip1-dc1.example.com.
_sip._tcp.example.com.    SRV    10 40 5060 sip2-dc1.example.com.
 
; Backup data center — equal weight
_sip._tcp.example.com.    SRV    20 50 5060 sip1-dc2.example.com.
_sip._tcp.example.com.    SRV    20 50 5060 sip2-dc2.example.com.

Clients will use the primary DC exclusively until both servers there are unreachable, then fail over to the backup DC.

Common Use Cases

VoIP / SIP

_sip._tcp.example.com.     3600    SRV    10 100 5060 sip1.example.com.
_sip._tcp.example.com.     3600    SRV    20 100 5060 sip2.example.com.
_sip._udp.example.com.     3600    SRV    10 100 5060 sip1.example.com.

SIP is one of the most common SRV use cases. RFC 3263 defines exactly how SIP clients use SRV records, along with NAPTR records for protocol selection.

XMPP (Jabber) Messaging

_xmpp-client._tcp.example.com.    3600    SRV    5 0 5222 xmpp.example.com.
_xmpp-server._tcp.example.com.    3600    SRV    5 0 5269 xmpp.example.com.

XMPP requires two sets of SRV records: _xmpp-client for client connections and _xmpp-server for server-to-server federation. This enables your XMPP server to communicate with other XMPP domains.

Microsoft 365 / Teams

_sipfederationtls._tcp.example.com.    3600    SRV    100 1 5061 sipfed.online.lync.com.
_sip._tls.example.com.                 3600    SRV    100 1 443 sipdir.online.lync.com.

LDAP Directory Services

_ldap._tcp.example.com.        3600    SRV    0 100 389 ldap.example.com.
_ldaps._tcp.example.com.       3600    SRV    0 100 636 ldap.example.com.
_ldap._tcp.dc._msdcs.example.com.  3600    SRV    0 100 389 dc1.example.com.

Active Directory relies heavily on SRV records for domain controller discovery. Windows clients query _ldap._tcp.dc._msdcs.domainname to find domain controllers. Without these SRV records, AD authentication fails.

CalDAV / CardDAV

_caldav._tcp.example.com.      3600    SRV    0 0 80 calendar.example.com.
_caldavs._tcp.example.com.     3600    SRV    0 0 443 calendar.example.com.
_carddav._tcp.example.com.     3600    SRV    0 0 80 contacts.example.com.
_carddavs._tcp.example.com.    3600    SRV    0 0 443 contacts.example.com.

Apple devices and other CalDAV/CardDAV clients use these SRV records for automatic account setup. When a user enters their email address, the client discovers the calendar and contacts server automatically.

Minecraft Servers

_minecraft._tcp.example.com.    3600    SRV    0 5 25565 mc.example.com.

SRV records let Minecraft players connect to example.com even if the server runs on a non-standard port. Without the SRV record, players would need to type mc.example.com:25565.

Matrix/Element Chat

_matrix._tcp.example.com.    3600    SRV    10 0 8448 matrix.example.com.

Record Format

Adding an SRV Record

Using the Dashboard

1. Navigate to your zone in the DNScale dashboard
2. Click Add Record
3. Configure the record:
   • Name: Enter _service._protocol (e.g., _sip._tcp)
   • Type: Select SRV
   • Priority: Set priority value (e.g., 10)
   • Weight: Set weight value (e.g., 50)
   • Port: Set the service port (e.g., 5060)
   • Value: Enter the target hostname
   • TTL: Set the cache duration (default: 3600)
4. Click Create Record

Using the API

Create an SRV record:

curl -X POST "https://api.dnscale.eu/v1/zones/{zone_id}/records" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "_sip._tcp",
    "type": "SRV",
    "content": "sipserver.example.com",
    "ttl": 3600,
    "priority": 10,
    "weight": 50,
    "port": 5060
  }'

Set up XMPP records:

# Client connections
curl -X POST "https://api.dnscale.eu/v1/zones/{zone_id}/records" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "_xmpp-client._tcp",
    "type": "SRV",
    "content": "xmpp.example.com",
    "ttl": 3600,
    "priority": 5,
    "weight": 0,
    "port": 5222
  }'
 
# Server-to-server federation
curl -X POST "https://api.dnscale.eu/v1/zones/{zone_id}/records" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "_xmpp-server._tcp",
    "type": "SRV",
    "content": "xmpp.example.com",
    "ttl": 3600,
    "priority": 5,
    "weight": 0,
    "port": 5269
  }'

API Response:

{
  "status": "success",
  "data": {
    "message": "Record created successfully",
    "record": {
      "id": "encoded-record-id",
      "name": "_sip._tcp.example.com.",
      "type": "SRV",
      "content": "10 50 5060 sipserver.example.com.",
      "ttl": 3600,
      "disabled": false
    }
  }
}

Disabling a Service

To indicate a service is not available at a domain, use a target of .:

_sip._tcp.example.com.    3600    SRV    0 0 0 .

This explicitly tells clients "this service does not exist here" rather than leaving them to time out. It's the SRV equivalent of a negative answer — similar to how an empty CAA record with ; denies all certificate issuance.

Testing SRV Records

Verify your SRV records with dig:

# Basic SRV query
dig SRV _sip._tcp.example.com
 
# Short output showing priority, weight, port, and target
dig SRV _xmpp-client._tcp.example.com +short
 
# Check against a specific nameserver
dig SRV _sip._tcp.example.com @ns1.dnscale.eu
 
# Verify the target hostname resolves
dig SRV _sip._tcp.example.com +short | awk '{print $4}' | xargs -I{} dig A {} +short
 
# Check all XMPP records at once
dig SRV _xmpp-client._tcp.example.com +short
dig SRV _xmpp-server._tcp.example.com +short

Troubleshooting SRV Records

Service Not Discovered

If clients can't find your service:

1. Verify the SRV record exists — the service name and protocol must match exactly what the application expects
2. Check the target resolves — SRV targets must have A or AAAA records
3. Confirm the application supports SRV — not all applications use SRV lookups
4. Check TTL caching — clients may have cached the old (or missing) SRV response
5. Verify DNS propagation — new records may not be visible to all resolvers yet

Common Mistakes

Best Practices

1. Use meaningful priorities - Keep gaps between priority values (10, 20, 30) for future flexibility

2. Target must have A/AAAA records - SRV targets should resolve to IP addresses, not CNAMEs

3. Use weight for load balancing - Distribute traffic among same-priority servers using weight

4. Weight 0 means last resort - A weight of 0 means the server should be used only when no other servers of the same priority are available

5. Test with applications - Not all applications respect SRV records; verify with your specific software

6. Set appropriate TTL values - Lower TTLs for services that change frequently; higher TTLs for stable services

7. Keep target hostnames within your zone - This makes management easier and avoids cross-zone dependencies

Related Record Types

• A - IPv4 address for the target server
• AAAA - IPv6 address for the target server
• HTTPS - Modern service binding for HTTPS
• SVCB - General service binding
• MX - Email service discovery (similar concept to SRV)
• CNAME - Canonical name aliasing
• DNS Record Types - Overview of all DNS record types
• SSHFP - SSH fingerprint records for server verification

Conclusion

SRV records are essential for service discovery, enabling applications to automatically find the right servers, ports, and failover options. They're critical for VoIP, instant messaging, directory services, and many enterprise protocols. The priority and weight system provides built-in failover and load balancing without any application-level configuration. DNScale's support for SRV records lets you configure sophisticated service architectures with priority-based failover and weighted load balancing, all manageable through the dashboard or API.