SRV Records: Service Discovery in DNS

An SRV record maps a named service on a domain to the server (and port) that provides it. Where an A or AAAA record answers "what IP is this hostname?", an SRV record answers "for service X on this domain, which host and port should I talk to?"

The key thing SRV adds over a plain address record is the port number. A client doesn't have to assume the service sits on a fixed, hardcoded port — the record tells it. That lets you move a service to a different machine, run it on a non-standard port, list backups, and load-balance, all by editing DNS rather than reconfiguring every client.

SRV is defined by RFC 2782. A protocol has to be designed to use SRV for it to matter — the client must know to perform the SRV lookup. Many do; ordinary web browsers do not (see below).

SRV records don't sit on the bare domain name. They live at a structured, prefixed name in the form:

_service._proto.name

• _service — the symbolic name of the service, such as _sip, _xmpp-client, or _ldap.
• _proto — the transport protocol, almost always _tcp or _udp.
• name — the domain the lookup applies to, e.g. example.com.

So a SIP service over TCP for example.com is published at _sip._tcp.example.com.

The leading underscores are literal characters, not placeholders. They are required by the spec, and they serve a practical purpose: underscores aren't legal in normal hostnames, so prefixing the labels with _ guarantees these service labels can never collide with a real host's A/AAAA name. Other DNS conventions use the same trick — for example DKIM's _domainkey and DMARC's _dmarc labels.

The right-hand side (the record's data) has exactly four fields, in this order:

Field	Type	Meaning
Priority	16-bit unsigned (0–65535)	Which target to prefer. Lower is preferred — clients use the lowest-priority targets first and only fall back to higher numbers if those fail.
Weight	16-bit unsigned (0–65535)	A relative share for load-balancing among targets that share the same priority. Higher weight means a proportionally larger share of connections.
Port	16-bit unsigned (0–65535)	The TCP or UDP port the service listens on at the target host.
Target	Hostname	The fully qualified hostname of the server providing the service, ending in a dot. It must have A/AAAA records. A single . means the service is explicitly not available.

A couple of these deserve emphasis. Priority works like MX preference: the smallest number wins, and higher numbers are backups. Weight only matters within a single priority level — if two targets are both priority 10 with weights 60 and 40, they'll receive roughly 60% and 40% of connections respectively. And a target of . (just a dot) is the spec's way of saying "this service is deliberately not offered here," which a client should treat as definitive.

Suppose example.com wants to publish where its SIP (VoIP) service lives. It runs on sipserver.example.com, port 5060, over TCP. The record is published at the prefixed name and looks like this in a zone file:

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

Reading the data fields left to right: priority 10, weight 60, port 5060, target sipserver.example.com. (note the trailing dot marking a fully qualified name).

Here is how a SIP client uses it:

1. It needs to reach SIP for example.com, so it queries DNS for the SRV records at _sip._tcp.example.com.
2. It groups the returned records by priority and starts with the lowest number. If several share that priority, it picks among them in proportion to their weights.
3. It takes the chosen target's hostname — sipserver.example.com — and resolves its A/AAAA record to an IP address.
4. It connects to that IP on the port from the record — 5060 — rather than guessing a default.
5. If that target fails, the client falls back to the next target by priority and tries again.

The client never had to assume which machine or port runs SIP; DNS told it both.

SRV is used by protocols whose clients are built to look it up. Common examples:

• SIP / VoIP — _sip._tcp, _sip._udp, and _sips._tcp point phones and softphones at the right call server.
• XMPP (chat) — _xmpp-client._tcp and _xmpp-server._tcp let chat clients and federated servers find each other.
• LDAP — _ldap._tcp advertises directory servers.
• Microsoft Active Directory — AD leans heavily on SRV. Domain-joined machines locate domain controllers via records like _ldap._tcp.dc._msdcs.example.com and _kerberos._tcp. Mail clients also use _autodiscover._tcp to find Exchange/Outlook settings.
• Minecraft (Java edition) — a _minecraft._tcp SRV record lets a server run on a custom port while players still connect using just the domain name.

In each case the appeal is the same: the operator can move the service or change its port by editing one DNS record, and every compliant client follows automatically.

The most important rule mirrors the one for MX records: the target must be a real hostname that resolves through an A or AAAA record.

• Never an IP literal. The target field holds a hostname, not an address. ... 5060 198.51.100.10 is invalid — point it at a name like sipserver.example.com that itself has an A/AAAA record.
• Never a CNAME. RFC 2782 requires the SRV target to be a hostname with address records directly, not an alias. Pointing an SRV target at a CNAME is non-conformant and can cause clients to fail.
• End the target with a dot. In a raw zone file sipserver.example.com. is fully qualified; without the trailing dot some DNS hosts will append the zone and produce sipserver.example.com.example.com.
• A target of . means "no service." If you genuinely want to advertise that a service is not offered, that's the way — but make sure you didn't enter it by accident, because clients treat it as a hard "don't bother."

SRV and MX are easy to confuse because both list a preference/priority and a target hostname. The differences that matter:

• MX is mail-specific; SRV is general-purpose. MX only ever directs inbound email for a domain. SRV can advertise the location of any service that's designed to use it.
• SRV carries a port; MX does not. MX has no port field — server-to-server mail delivery is always assumed to use SMTP on port 25. An SRV record explicitly names the port, so the service can live anywhere.
• SRV uses a prefixed name. MX sits on the bare domain (example.com); SRV lives at the structured _service._proto.name label.
• SRV adds weight. MX balances same-preference servers in a simple balanced/random order, while SRV gives you an explicit weight field to set the proportion of traffic among equal-priority targets.

The shared rule is the target one: in both records the hostname must have A/AAAA records and must not be an IP or a CNAME.

SRV is opt-in by protocol. A service is only discoverable this way if its clients are written to perform the SRV lookup first. If they aren't, publishing an SRV record does nothing.

The most common surprise: ordinary web browsers do not use SRV for normal HTTP/HTTPS. A browser loading https://example.com resolves the domain's A/AAAA record and connects on the standard port (443) — it never consults an _http or _https SRV record. So you can't relocate a website to a different host or port with an SRV record; for the web you use A/AAAA, CNAME, and where supported newer mechanisms, not SRV.

The practical takeaway: add SRV records for the services that actually rely on them (SIP, XMPP, AD, Minecraft, and so on), and don't expect them to influence protocols — like plain web browsing — that were never designed to read them.

You can inspect the live SRV records for a domain with the who.is DNS lookup tool. Because SRV records live at prefixed names rather than the bare domain, you'll query the specific service label — for example _sip._tcp.example.com — and read back the four fields: priority, weight, port, and target.

Use it to confirm the priorities and weights are what you intended, that the port is correct, and that the target is a real hostname with A/AAAA records rather than an IP or a CNAME. It's also worth checking the WHOIS and nameserver data to make sure you're editing DNS at the provider that's actually authoritative for the domain — otherwise your SRV changes won't take effect.