SRV Records: Service Discovery

DNS was built to answer one question: given a name, what's the IP address? SRV records ask it to answer a different question entirely: given a service I need, how do I connect to it?

When a VoIP phone powers on and needs to find your company's phone server, when a chat client needs to locate the XMPP server for a domain, when a Minecraft player types a server address—something has to tell them not just where to connect, but how. What port? What protocol? And if there are multiple servers, which one should they try first?

SRV records pack all of this into DNS.

The Structure of an SRV Record

An SRV record follows a specific format:

_service._protocol.name TTL class SRV priority weight port target

Each component serves a purpose:

• _service: The service name (_sip, _xmpp, _ldap, _minecraft)
• _protocol: The transport protocol (_tcp or _udp)
• name: The domain offering the service
• priority: Lower values are tried first (like MX records)
• weight: Distributes load among same-priority servers
• port: The TCP or UDP port to connect to
• target: The actual hostname providing the service

A real example for a SIP phone system:

_sip._tcp.example.com. 86400 IN SRV 10 60 5060 sipserver1.example.com.
_sip._tcp.example.com. 86400 IN SRV 10 40 5060 sipserver2.example.com.
_sip._tcp.example.com. 86400 IN SRV 20 100 5060 sipbackup.example.com.

Three servers. Two priorities. Automatic failover and load balancing—all discovered through a single DNS query.

Priority and Weight: Two-Tier Selection

Priority creates a hierarchy. Clients always try the lowest-numbered priority first. In the example above, both sipserver1 and sipserver2 have priority 10, so they're the primary servers. The backup at priority 20 only receives traffic when both primaries are down.

Weight distributes traffic within the same priority level. When sipserver1 (weight 60) and sipserver2 (weight 40) are both available, clients randomly select between them—weighted so sipserver1 receives roughly 60% of connections and sipserver2 receives 40%.

A weight of 0 is special: these servers are deprioritized but not excluded. Per RFC 2782, they receive "a very small chance of being selected" when other weighted servers exist¹. Use weight 0 when you want a server available but rarely chosen—perhaps a slower backup that should only handle overflow.

This two-tier system—priority for failover, weight for distribution—gives administrators precise control over traffic patterns without touching client configurations.

Where SRV Records Shine

SIP (VoIP): When your desk phone boots up, it queries _sip._tcp.company.com to discover the phone server. IT can run multiple servers, move services between machines, change ports—and phones find the new location automatically.

XMPP (Chat): Federated chat depends on SRV records. When you message someone@example.com, your client queries _xmpp-client._tcp.example.com to find their server². Different organizations can run their own servers while still communicating seamlessly.

LDAP (Directory Services): Windows Active Directory uses SRV records extensively. Domain controllers advertise themselves through records like _ldap._tcp.company.com, so workstations discover authentication servers automatically.

Minecraft: Game servers often run on non-standard ports. An SRV record at _minecraft._tcp.play.example.com lets operators point to any port while players just type play.example.com. Clean URLs, flexible infrastructure.

CalDAV/CardDAV: Calendar and contact sync clients use SRV records to discover the right servers without manual configuration.

Why Not Web Traffic?

SRV records work beautifully for protocols like SIP and XMPP. Why doesn't your browser use them?

HTTPS certificates are bound to specific domain names. If an SRV record directed your browser from www.example.com to webserver1.example.com, the certificate wouldn't match the URL you typed, triggering security warnings.

The web solves these problems differently: load balancers, CDNs, GeoDNS, anycast. All work within the constraints of certificate validation.

A Complete Example

A company with datacenters in the US and EU might configure XMPP like this:

; Primary servers in US (priority 10, load balanced 50/50)
_xmpp-client._tcp.example.com. 3600 IN SRV 10 50 5222 xmpp-us1.example.com.
_xmpp-client._tcp.example.com. 3600 IN SRV 10 50 5222 xmpp-us2.example.com.

; EU failover (priority 20)
_xmpp-client._tcp.example.com. 3600 IN SRV 20 100 5222 xmpp-eu1.example.com.

; The actual IP addresses
xmpp-us1.example.com. 3600 IN A 203.0.113.10
xmpp-us2.example.com. 3600 IN A 203.0.113.11
xmpp-eu1.example.com. 3600 IN A 198.51.100.20

Under normal conditions, traffic splits between the two US servers. If both fail, the EU server takes over. No client reconfiguration required.

The Deeper Value

SRV records transform DNS from a phone book into a service directory. The client doesn't need to know which server, which port, or what to do when something fails. It asks DNS, and DNS provides everything needed to connect.

This means infrastructure can evolve without client changes. Move a service to a new server? Update the SRV record. Add capacity? Add another record with the same priority. Take a server offline for maintenance? Remove its record temporarily. Clients adapt automatically.

For protocols that support them, SRV records are how you build infrastructure that can change without breaking everything that depends on it.

Sources