What Is SRV Records?

At a glance

SRV allows clients to discover servers without fixed addresses. It is common in messaging, directory services and some enterprise collaboration systems.

Discovering a service endpoint through DNS

SRV advertises service targets and ports at names usually shaped as _service._transport.domain. Priority and weight let supported clients find messaging, directory, voice or collaboration services without hardcoding server addresses.

Unlike mail-specific MX, SRV is a general service-location mechanism. Targets still need A or AAAA records. Clients must implement the relevant SRV convention; ordinary browsers do not change website ports just because arbitrary SRV records exist.

How priority, weight and port work together

• Clients first select the records with the lowest numerical priority, trying higher-priority numbers when the preferred group is unavailable.
• Within one priority group, weights influence probabilistic selection. More capable nodes can receive a larger share, but weights do not guarantee exact request counts.
• The port field supports non-default service ports. A target of a single dot can explicitly indicate that the service is unavailable at this domain.
• TTL controls discovery caching. Removing a node also requires consideration of cached answers and whether clients actually retry healthy alternatives.

Common enterprise-service migration problems

Microsoft-related services, SIP, XMPP, Kerberos and LDAP may use different SRV owner names. Provider migrations require checking each service, transport, target, port and certificate, not just whether the domain's homepage loads.

Failures include targets without addresses, blocked ports, reversed priorities, misunderstood zero weights and clients without support for that SRV convention. Correct DNS is only the first step toward a working service.

Practical use and interpretation

A discovered SRV confirms published service-discovery configuration. Standard names may identify the service category. Current usage, open ports and authentication requirements need protocol-specific checks.

A missing result applies to the queried name only. SRV names cannot be exhaustively discovered through a few common queries, so broader coverage may remain unknown. Preserve priority, weight, port and target in displays to make scheduling relationships reviewable.

Points to consider

SRV reveals service-discovery configuration. Reachability and authentication still require validation through the actual protocol.

Frequently asked questions

Can SRV automatically move a webpage to another port?

Ordinary HTTP browsers generally do not use arbitrary SRV records for webpage ports. Behavior depends on application protocol and client support.

Does greater weight mean higher priority?

Priority is evaluated first, with smaller numbers preferred. Weight only distributes choices within the same priority group.

Why can a service fail despite correct SRV?

Address resolution, ports, firewalls, TLS, authentication or the application may still fail. Test the actual protocol connection.