SRV Record Lookup

An SRV record is a DNS resource record that advertises the location of a service: which host runs it, which port it listens on, and in what order clients should try the available hosts. It is defined in RFC 2782, published in 2000, and it is the only standard DNS record type that can carry a port number.

That port number is the whole point. An A record can only say "this name is at this 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 touching 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.

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 allows a zone to 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 _tcpname and never sees records published under _udp. Publishing a service under the wrong protocol label makes it invisible rather than broken, which is why the mistake is so 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.

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: dig SRV returns a perfectly formed answer, so the record "exists", and the client still cannot connect. Resolving every target is the only way to see it, which is why this tool 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 simply do not perform.

In practice the outcome is inconsistent rather than uniformly broken, which makes it worse. 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 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.