SRV Lookup

An SRV record (service record, DNS type 33) tells a client which host and port provide a service for a domain. It lives at a name such as _sip._tcp.example.com and carries four values: priority, weight, port and target. Clients try the lowest priority first and share load by weight. SRV is defined in RFC 2782.

RFC 2782 was published in 2000. The newer SVCB and HTTPS records (RFC 9460, 2023) can also carry a port, but SRV is still the record type most protocols use for it. The port is what makes SRV useful. An A record can only say that a name is at an address, so every protocol that relies on A records has to hard-code a default port. An SRV record lets the domain owner move a service to a different host and port, or add and remove servers, without changing anything on the client side.

An SRV record has six meaningful parts. Four of them are the record data: priority, weight, port and target. The other two are the service and transport protocol labels at the front of the owner name.

_sip._tcp.example.com.  3600  IN  SRV  10 60 5060 sip1.example.com.
    |    |      |          |          |  |   |        |
 service proto  name      TTL   priority |  port    target
                                       weight

An SRV record is never published at the bare domain. Its owner name is built from three parts: an underscore-prefixed service label, an underscore-prefixed protocol label, and the domain the service belongs to. For SIP over TCP at example.com that is _sip._tcp.example.com.

The underscore prefix is deliberate. An underscore is not a legal character in a hostname under RFC 1123, so a label beginning with one can never collide with a real host in the same zone. That is what lets a zone publish _sip._tcp and a host called sip side by side without ambiguity.

The protocol label is almost always _tcp or _udp, and it is part of the query name rather than the record data. A client that wants TCP queries the _tcp name and never sees records published under _udp. Publishing a service under the wrong protocol label makes it invisible rather than broken, so the mistake is easy to miss.

Service labels are defined by whoever specifies the protocol, and there is no central rule beyond registered names. Common ones are shown in the examples table below.

Priority and weight do two different jobs, and mixing them up is the most common SRV configuration error. Priority controls failover, and weight controls load balancing among the targets that share one priority level.

A client must contact the reachable target with the lowest priority value. Only if every target at that priority fails does it move up to the next value. Priority 0 and priority 10 do not mean 90% and 10%. While priority 0 is answering, priority 10 receives no traffic.

Weight applies only among records that share a priority. RFC 2782 defines the selection as proportional: sum the weights in the group, pick a random number in that range, and walk the running total. With three targets at priority 10 and weights 60, 30 and 10, the split is roughly 60%, 30% and 10% of new connections.

A weight of 0 means the target should only be used when nothing else in the group is available, and when every record in a group has weight 0 the client picks at random among them. Setting all weights to 0 is the normal way to say the targets are equivalent and the client may balance them however it likes.

; Primary pair, load balanced 60/40. Backup only used if both are down.
_sip._tcp.example.com. IN SRV 10 60 5060 sip1.example.com.
_sip._tcp.example.com. IN SRV 10 40 5060 sip2.example.com.
_sip._tcp.example.com. IN SRV 20  0 5060 sip-dr.example.com.

Yes. An SRV record resolves to a hostname, not to an address, so the target is only useful if a second lookup can turn it into an IP. RFC 2782 states that the target must be a hostname with one or more address records in the same or another zone. A target with no A and no AAAA record is a dead SRV record, even though the SRV query itself succeeds.

This is the failure mode that makes SRV debugging frustrating. A dig SRV query returns a well-formed answer, so the record exists, and the client still cannot connect. Resolving every target is the only way to see it, so DNSX follows each target down to its addresses and shows the geolocation and ASN of what it lands on.

The target must also be fully qualified. A target written without a trailing dot in a zone file has the zone origin appended, so sip1.example.com silently becomes sip1.example.com.example.com. Check this first whenever a target does not resolve.

No. RFC 2782 requires the SRV target to be the canonical name of the host, and explicitly says the target must not be an alias. The same rule applies to MX and NS targets, and for the same reason: a resolver following a CNAME at that position adds a lookup that some clients do not perform.

In practice the outcome is inconsistent rather than uniformly broken. Many resolvers will chase the CNAME and the service works. Strict clients and some libraries treat the answer as invalid and fail. A service that works from your laptop and fails from a server is very often an SRV target pointing at a CNAME.

A target of a single dot is the one special case. A lone SRV record with a dot as its target is a positive declaration that the service is not available at this domain, and a client that sees it should stop rather than fall back to a default host and port.

An SRV query returning an answer proves only that the record was published. Every one of the following will produce a valid-looking SRV answer and a service that does not work:

• The client does not read SRV records. Web browsers ignore SRV records, so there is no way to move a website to a non-default port with DNS. Minecraft Bedrock Edition ignores them too, while Java Edition honours them.
• The target has no A or AAAA record, or has one only for the address family the client is using.
• The target is a CNAME, which strict clients reject.
• The target lost its trailing dot in the zone file and had the origin appended.
• The record is under the wrong protocol label, published at _udp while the client queries _tcp. The client sees NXDOMAIN, not a wrong answer.
• The port in the record is not the port the service listens on, or a firewall blocks it. SRV advertises a port. It does not open one.
• The record is published at the wrong name, at _sip._tcp.sip.example.com instead of _sip._tcp.example.com.
• An old answer is still cached. Resolvers hold the previous record until its TTL expires, so lower the TTL before making a change rather than after.

SIP is the odd one out in that table. A SIP client does not usually query SRV first. It queries NAPTR at the bare domain to find out which transports the domain supports, and the NAPTR record hands it the SRV name to query next. If you are debugging SIP, start at our NAPTR lookup page, which walks the whole NAPTR to SRV to A chain.

A Minecraft server publishes its SRV record at _minecraft._tcp followed by the name players type into the client. The default port is 25565, and the SRV record is what lets a server listen on a different port, or on a different host, while players still type a plain name. Only Java Edition reads SRV records. Bedrock Edition ignores them and connects to the typed name on port 19132. The target must be a name with an A or AAAA record, not a CNAME and not an IP address. Hypixel publishes one, and you can run the lookup on it with our SRV lookup for _minecraft._tcp.hypixel.net.

; What our SRV lookup returns for Hypixel
_minecraft._tcp.hypixel.net.      IN SRV 1 1 25565 mc.hypixel.net.

; Your own server on a non-default port: players type play.example.com
_minecraft._tcp.play.example.com. IN SRV 0 5 25566 mc.example.com.
mc.example.com.                   IN A   203.0.113.10

Microsoft 365 asks for two SRV records on a domain that uses Teams or Skype for Business Online. _sip._tls on port 443 points at sipdir.online.lync.com and is used by clients to find the sign-in service. _sipfederationtls._tcp on port 5061 points at sipfed.online.lync.com and is used for federation with other organisations and with consumer Skype. The published Microsoft 365 values are priority 100 and weight 1 for both records. A missing or mistyped record shows up as sign-in failures or as federated chats that never connect, so check both names after any DNS change.

_sip._tls.example.com.              IN SRV 100 1 443  sipdir.online.lync.com.
_sipfederationtls._tcp.example.com. IN SRV 100 1 5061 sipfed.online.lync.com.

Both nslookup and PowerShell's Resolve-DnsName can query SRV records on Windows, and both accept a resolver address so you can compare a public resolver with your local one. They stop at the SRV answer, so run a second query for the target hostname to confirm it has an A or AAAA record.

nslookup -type=SRV _sip._tcp.sip2sip.info
nslookup -type=SRV _sip._tcp.sip2sip.info 8.8.8.8
Resolve-DnsName _sip._tcp.sip2sip.info -Type SRV
Resolve-DnsName proxy.sipthor.net -Type A

macOS ships with dig, so an SRV query works from Terminal without installing anything. The +short option prints just the priority, weight, port and target, and an @ resolver address asks a specific public resolver instead of the system one.

dig SRV _sip._tcp.sip2sip.info +short
dig @1.1.1.1 SRV _minecraft._tcp.hypixel.net +short
dig A proxy.sipthor.net +short

On Linux, dig comes from the bind-utils package on Fedora and RHEL and the dnsutils package on Debian and Ubuntu. The host command from the same package gives a one-line answer per record. The DNSX API returns the record with every target already resolved, as JSON.

dig SRV _sip._tcp.sip2sip.info +short
host -t SRV _sip._tcp.sip2sip.info
curl "https://api.dnsx.dev/dns/srv/_sip._tcp.sip2sip.info?flow=1" | jq .