Skip to content
Control Plane Labs

SRV record

Publishes the host and port of a named service, with priority and weight for selection.

Last updated July 27, 2026

Zone-file example

_sip._tcp.example.com.   3600   IN   SRV   10 60 5060 sip1.example.com.

Typical uses

  • Locating SIP, XMPP, LDAP, and Kerberos servers without hardcoding hostnames
  • Active Directory domain controller discovery, which depends on SRV entirely
  • Publishing a service on a non-standard port without touching client config
  • Minecraft and other game servers that let players type a bare domain

When it breaks, check

  • The owner name needs both underscore labels: _service._proto.name, not service.name
  • Weight only breaks ties inside one priority band; it is not a second priority
  • A target of a single dot means the service is deliberately not offered here
  • The target must be a hostname with its own A/AAAA records, never a CNAME or an address

What the SRV record does

An SRV record binds an abstract service name to a concrete endpoint. The owner name carries the service identity in underscore-prefixed labels, so _ldap._tcp.example.com asks where this domain runs LDAP over TCP. The port field is the real advance over MX: a service can move to 8443 and clients follow.

Selection happens in two stages, and conflating them is the usual mistake. Clients try the lowest priority first and fall back only when every server in that band is unreachable. Within a band, weight distributes load proportionally: 60 and 20 mean a three-to-one split, not a preference order.

Zone-file and wire format

The RDATA is four fields in fixed order: priority weight port target, three 16-bit integers then an uncompressed domain name. The owner name must be _service._proto.name, the protocol label normally _tcp or _udp. A target of . explicitly signals the service is unavailable here, which beats NXDOMAIN for being unambiguous. The target must resolve to addresses directly; a CNAME there is not permitted.

; _service._proto.name    TTL  class type  prio weight port target
_sip._tcp.example.com.    3600 IN    SRV   10   60     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 backup.example.com.

; priority 10 is used first; inside it sip1 takes ~75% of traffic.
; priority 20 is only tried when both priority-10 hosts fail.

; explicitly refusing to offer the service:
_sip._udp.example.com.    3600 IN    SRV   0    0      0    .

Common uses

SRV is load bearing in enterprise protocols and almost absent from the public web. Active Directory cannot find a domain controller without it, SIP proxies use it to locate the next hop, and XMPP, LDAP, and Kerberos all specify SRV lookups. Browsers never adopted it for HTTP: by then port 80 was universal, an extra lookup per navigation was unwelcome, and the change could not be negotiated without breaking existing clients. The HTTPS record fills that gap now.

Troubleshooting

Nearly every SRV bug is in the owner name. Underscore labels are easy to drop in a provider UI that already appends the zone, producing _sip._tcp.example.com.example.com, and protocol-label typos return a clean NXDOMAIN that looks like the service is simply absent. Query the full underscore name first.

Then check the target. If it is a CNAME, or a name with no address records, a strict client fails while a lenient one works — the worst kind of intermittent report.

# the full underscore name is the query — nothing else resolves
dig _sip._tcp.example.com SRV +noall +answer

# confirm each target actually has address records
for t in $(dig +short _sip._tcp.example.com SRV | awk '{print $4}'); do
  printf '%s -> %s\n' "$t" "$(dig +short "$t" A)"
done

# Active Directory domain controller discovery
dig _ldap._tcp.dc._msdcs.example.com SRV +short

The defining RFC

SRV is type 33, defined in RFC 2782, which replaced the experimental RFC 2052 and specifies the selection algorithm in full. The underscore convention it popularised is generalised by RFC 8552; label names come from the IANA Service Name and Transport Protocol Port Number Registry. RFC 6763 builds DNS-SD on SRV, and RFC 3263 defines SIP server location, its most demanding consumer. Query one with the DNS lookup tool.

Reference and tooling

Every record type and its assigned numeric value is listed in theIANA DNS Parameters registry. To query a live zone from the browser, use theDNS lookup tool. If the record you are chasing is TLS-related, the TLS inspector andCertificate Transparency lookup are usually the next two stops.

Other record types