SRV Record Lookup
Look up SRV records for any service name and read the target host, port, priority and weight advertised for SIP, XMPP, LDAP, Microsoft 365 autodiscover or Minecraft, with TTLs.
About SRV Record Lookup
The SRV Record Lookup queries a service record and shows the four fields it carries: priority, weight, port and target host, together with the record TTL. SRV names are structured, taking the form _service._proto.domain, so a SIP over TCP record for example.eu lives at _sip._tcp.example.eu. Getting that underscore prefix wrong is the most common reason a client reports no service found, and querying the name directly is the quickest way to see whether the record exists at all and what it points at.
RFC 2782 defines both the format and the selection algorithm. A client sorts the answers by priority and only moves to a higher number when every target in the lower group has failed, so priority expresses failover. Within one priority group the client picks at random in proportion to weight, which is how load is shared - a 70/30 pair sends roughly seven connections in ten to the first target, and a weight of 0 marks a target of last resort. A target consisting of a single dot means the service is deliberately not offered, and targets must be real hostnames with address records, never CNAMEs.
The record type is fixed to SRV and the input carries a _sip._tcp.example.eu placeholder, so you only supply the service name; the query runs server-side through our own European resolver rather than from your browser. Every record in the set is listed with its owner name, TTL and rdata in RFC 2782 order, which is what you need to reproduce a client's choice by hand. The lookup is DNS only: it does not open a connection to the target, so pair it with the Port Checker to confirm the advertised port is reachable.
How to use it
- 1Enter the full SRV name including the underscore labels, for example _sip._tcp.example.eu or _minecraft._tcp.example.eu.
- 2Select Lookup to query that exact name through our European resolver.
- 3Read the Value column, which lists priority, weight, port and target in RFC 2782 order.
- 4Identify the lowest priority number: those records are tried first, with traffic split between them in proportion to their weights.
- 5Resolve each target with the DNS Lookup tool to confirm it has an A or AAAA record and is not a CNAME.
- 6Note the TTL before changing a record, since it sets how long clients can keep using the old target and port.
Common use cases
- -Troubleshooting a SIP client that cannot register because _sip._tcp or _sips._tcp is missing or advertises the wrong port.
- -Confirming Microsoft 365 autodiscover records such as _autodiscover._tcp resolve to the expected Microsoft host after a tenant migration.
- -Auditing XMPP or LDAP service discovery records across a set of domains before decommissioning a server.
- -Planning a weighted rollout by checking the priority and weight values clients will actually act on.
- -Verifying that a Minecraft or game server SRV record advertises the correct non-standard port to players.
Frequently asked questions
- What is the difference between priority and weight in an SRV record?
- Priority is failover, weight is load sharing. Clients group records by priority, try the lowest number first and only fall through to the next group when all of its targets fail. Inside a single priority group they choose at random in proportion to weight, so values of 100 and 200 send about a third of connections to the first target. A weight of 0 means use this only when nothing else is available.
- What does the SRV record format _service._proto.domain mean?
- The first label is the symbolic service name with an underscore prefix, such as _sip or _ldap; the second is the transport protocol, _tcp or _udp; the rest is the domain the service belongs to. RFC 2782 uses underscores precisely so these names cannot collide with real hostnames. Querying the plain domain returns nothing, which is why the exact prefixes matter so much.
- Can an SRV record point to a CNAME?
- No. RFC 2782 requires the target to be a hostname with A or AAAA records, so a CNAME there is not compliant. Some clients follow the alias, others fail outright, which produces intermittent and hard to diagnose breakage. Point the SRV target at a name that carries address records directly, and handle any aliasing you need with separate A or AAAA records on that name.
- Why does my SRV lookup return no records?
- Usually the name is wrong. The underscore labels are case-insensitive but must be present and correct, and the record must sit under the right domain, so _sip._tcp.example.eu and not sip.tcp.example.eu. Other causes are a record published on the wrong subdomain, or a change that has not yet reached the authoritative servers. A record whose target is a single dot does resolve, but it declares the service unavailable.