SRV Record Lookup

Service names you will actually meet

• _sip._tcp and _sip._udp — SIP signalling. _sips._tcp for TLS-protected SIP.
• _xmpp-client._tcp and _xmpp-server._tcp — XMPP client and server-to-server connections.
• _ldap._tcp and _kerberos._tcp — directory and authentication. Active Directory publishes a large set under _msdcs, and domain join fails outright when they are missing.
• _autodiscover._tcp — Microsoft Exchange and Microsoft 365 client configuration.
• _caldavs._tcp and _carddavs._tcp — calendar and contacts autodiscovery for Apple and other clients.
• _minecraft._tcp — lets players connect without typing a port number.
• _matrix._tcp (now largely superseded by the .well-known delegation method) — Matrix homeserver discovery.

How to read the results

• Records returned — read the priority column first. That is the order clients will try, and it is where a failover misconfiguration shows up.
• No records at the underscore name — either the service is not published, or you have the service/protocol label wrong. Try both _tcp and _udp before concluding anything.
• NXDOMAIN — the underscore name itself does not exist. That is the same as "no SRV published" for practical purposes, though it means no record of any type exists at that name.
• A target that does not resolve — the SRV record is valid but useless. Always follow up with an A record lookup on the target.
• A port nothing is listening on — DNS cannot tell you this. Confirm with the port checker; an SRV record pointing at a closed port is the most common "the record is right but it does not work" case.

Common failures and fixes

1. Underscores stripped or rejected by the control panel. Some panels refuse underscore labels or add the domain twice, producing _sip._tcp.example.com.example.com. Query the exact name here to see what was really published.
2. Target is a CNAME. RFC 2782 forbids it. Some clients follow it anyway, others fail; you get intermittent, client-dependent breakage. Point the target at a name with real A/AAAA records.
3. A port number in the target field. The target is a hostname only. The port belongs in its own field — that is the entire point of SRV.
4. All records at the same priority when you wanted failover. Equal priorities mean load sharing, not failover. Give the backup a higher number.
5. Provider expects separate fields. Many panels split priority, weight, port, and target into four inputs, and pasting the whole record into one field yields garbage. Check the result here after saving.
6. Client ignores SRV entirely. Plenty of software never looks up SRV records — web browsers, notably, do not. SRV only works when the client implements it.

Querying SRV from the command line

# The SRV records themselves
dig +short _sip._tcp.tel.t-online.de SRV

# With TTLs and the full answer section
dig +noall +answer _xmpp-server._tcp.jabber.org SRV

# Resolve each target to an address
for t in $(dig +short _sip._tcp.example.com SRV | awk '{print $4}'); do
  echo -n "$t -> "; dig +short "$t" A | tr '\n' ' '; echo
done

# Confirm something is actually listening on the advertised port
nc -vz sipserver.example.com 5060

If you are debugging a service that will not connect, work the chain in order: does the SRV name resolve, does the target resolve, is the port open. Each step has a different owner and a different fix, and skipping straight to the application logs wastes time. The full DNS lookup accepts underscore names too if you want to see every record type at once.