SRV Record: syntax, examples, and troubleshooting

What does an SRV record do?

SRV is record type 33, defined in RFC 2782. It solves a problem A records cannot: an A record gives you an address but says nothing about which port a service listens on, how to distribute load across several servers, or which ones to prefer. SRV puts all four pieces in DNS.

The catch is that the client application has to know to look. A browser fetching https://example.com will never query SRV; it assumes port 443. SRV works only for protocols whose clients were designed to use it — SIP, XMPP, LDAP, Kerberos, Minecraft, Matrix, Microsoft Active Directory service location, and a handful of others. Adding an SRV record for a protocol that does not consult it accomplishes nothing.

The _service._proto.name naming rule

SRV is unusual in encoding meaning into the owner name. It has three parts, and getting any of them wrong makes the record invisible:

• `_service` — the symbolic service name, underscore-prefixed. _sip, _xmpp-server, _xmpp-client, _ldap, _kerberos, _minecraft, _matrix, _autodiscover. The underscore prevents collision with real hostnames and is mandatory.
• `_proto` — the transport, almost always _tcp or _udp. Some specifications define others, such as _tls.
• `name` — the domain the service belongs to. For [email protected] on XMPP, this is example.com.

Assembled: _xmpp-server._tcp.example.com. Provider forms differ wildly here — some ask for the full name in the host field, some ask only for _xmpp-server._tcp and append the zone, and some give you separate "service" and "protocol" fields with the underscore added for you. Always verify with dig after saving rather than trusting the form.

SRV syntax and fields

How clients select a server

RFC 2782 specifies the algorithm precisely, and it is worth knowing because it is more subtle than MX:

1. Collect every SRV record for the name and group them by priority.
2. Take the lowest priority group first.
3. Within that group, perform a weighted random selection: sum the weights, pick a random number in that range, and walk the list until the running total exceeds it. A record with weight 70 in a group summing to 100 receives roughly 70% of selections.
4. Try the selected target. On failure, remove it and repeat the weighted selection among the remainder of the group.
5. Only when every record in the group has failed does the client move to the next priority level.

So priority is failover and weight is load distribution — two different jobs in one record set. Records at equal priority with equal weight share traffic evenly, which is what the Cisco example above does: six gateways, all priority 1, all weight 50.

; 80/20 split across two primaries, with a cold standby behind them
_sip._tcp.example.com.  3600  IN  SRV  10 80 5060 sip1.example.com.
_sip._tcp.example.com.  3600  IN  SRV  10 20 5060 sip2.example.com.
_sip._tcp.example.com.  3600  IN  SRV  20  0 5060 sip-dr.example.com.

; Explicitly declare that a service is not offered
_sip._tcp.legacy.example.com.  3600  IN  SRV  0 0 0 .

Where SRV is actually used

Note what is absent: HTTP and SMTP. Web clients do not query SRV, and mail routing uses MX records, which predate SRV and do the same job for that one protocol. Publishing _http._tcp records is harmless but nothing will read them.

TTL guidance

3600 is the common resting value, as in both examples above. Two adjustments are worth making. If you rely on SRV priority for failover, a lower TTL (300–900) shortens the window in which clients keep a cached set that no longer reflects reality — though note that failover in SRV is client-driven, so clients do move on from a dead target without waiting for the TTL. And drop to 300 before changing ports or targets, since a stale SRV set sends clients to a port nothing is listening on, which produces connection refused rather than a graceful retry.

Common SRV mistakes

• Missing underscores. sip._tcp.example.com is a different name from _sip._tcp.example.com and no client will find it.
• Duplicating the domain in the host field. Entering _sip._tcp.example.com in a form that already appends the zone gives _sip._tcp.example.com.example.com. Verify with dig after saving.
• Target is a CNAME. RFC 2782 requires the target to have address records directly. Some clients follow the alias, others give up.
• Target is an IP address. The field is a hostname. Create an A record and point at that.
• Assuming lower priority number means lower importance. As with MX, lower is tried *first*.
• Expecting weight to work across priority levels. It does not — weight is only compared inside a single priority group.
• Publishing SRV for a protocol that ignores it. No browser queries SRV; adding _https._tcp will not move your site off port 443.
• Wrong port. The port in the record is authoritative for clients that use it, so a typo here fails even when the host is perfectly healthy. Confirm with the port checker.
• Forgetting the firewall. SRV advertises a port; it does not open one.

Check it with dig

# SRV records for a service
dig +short _sip._tcp.cisco.com SRV

# Full answer with TTLs
dig +noall +answer _xmpp-server._tcp.jabber.org SRV

# Priority weight port target — confirm the target resolves
dig +short scarlet.jabber.org A

# The target must NOT be a CNAME (this should be empty)
dig +short scarlet.jabber.org CNAME

# Straight from the authoritative servers
dig +noall +answer @$(dig +short cisco.com NS | head -1) _sip._tcp.cisco.com SRV

# Is anything actually listening on the advertised port?
nc -zv scarlet.jabber.org 5269

For the broader zone picture use the DNS Lookup, and confirm reachability of the advertised port with the port checker or a ping test against the target host.