SRV Records Explained: How DNS Handles Service Discovery

Most of the record types on this blog map a name to an address (A, AAAA), an alias (CNAME), or arbitrary text (TXT). SRV records solve a different problem: given a service, not just a hostname, which host and port should a client actually connect to. It's a record type most people never touch directly, but it quietly powers service discovery for protocols like SIP, XMPP, and Active Directory.

What an SRV record specifies

An SRV record's name isn't a plain hostname. It's structured to identify a specific service and protocol:

_service._proto.name.  TTL  IN  SRV  priority  weight  port  target

A real example, for a SIP service on example.com:

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

Reading this left to right: clients looking for SIP over TCP on example.com should connect to sipserver.example.com on port 5060, with a priority of 10 and a weight of 60. The _sip and _tcp labels aren't decorative. The leading underscore is a convention (defined in the SRV spec, RFC 2782) that keeps service names from colliding with real hostnames, since no legitimate host is named _sip.

What each field means

Priority works like MX priority: lower numbers are tried first. A client should attempt every target at the lowest priority before falling back to a higher one, the same way mail servers fall back to a secondary MX host.

Weight breaks ties between targets that share the same priority, used for load balancing. A target with weight 60 should receive roughly twice the traffic of one with weight 30 at the same priority level, selected at random in proportion to weight.

Port is the actual TCP or UDP port the service is listening on. This is the part A and CNAME records can't express at all. They tell you where to connect; SRV also tells you on what port, which matters for services that don't run on a well-known default.

Target is the hostname to connect to, which then needs its own A or AAAA lookup to resolve to an address. An SRV record is one more hop, not a replacement for address records.

Where SRV records actually get used

SRV is common for protocols where the client software is written to look one up before connecting: SIP and XMPP servers (chat and VoIP), Minecraft servers (mapping a friendly hostname to a nonstandard port without the player typing :25566), Microsoft Active Directory (locating domain controllers and Kerberos servers), and the Matrix federation protocol.

The common thread is that the client application already knows to query _service._proto.domain for that specific protocol. It's baked into how the client resolves where to connect, not something a general-purpose tool discovers on its own.

Why most web traffic never uses them

HTTP and HTTPS are the obvious exception. Browsers connect to a plain hostname on port 80 or 443 and have never adopted SRV lookups for ordinary web traffic, even though nothing about the DNS spec would prevent it. That's mostly historical: HTTP predates wide SRV support, the ports were fixed by convention from the start, and changing browser resolution behavior at this point would break enormous amounts of existing infrastructure for a marginal benefit. A newer record type, HTTPS/SVCB, is starting to fill a related but different role (advertising things like HTTP/3 support), but it isn't a like-for-like replacement for what SRV does for other protocols.

Checking a domain's SRV records

dig SRV _sip._tcp.example.com

If nothing is configured for that particular service, you'll get an empty answer rather than an error. That's expected. Not every domain runs every service, and there's no requirement to publish SRV records for services you don't offer.

How DNS monitoring fits in

SRV is one of the record types OneDollarDNS monitors directly against your authoritative nameservers. If you're running a service that depends on SRV records, whether that's internal directory infrastructure or a public-facing chat or VoIP endpoint, an unexpected change (a priority flip, a target pointing somewhere new, or the record disappearing entirely) shows up the same way a change to any other monitored record would: compared against what was there last time, not against a cached answer that might be minutes or hours out of date.