A DNS SRV record tells a supporting client where to find a particular network service and which port to contact. It is not simply a different version of an A record: it publishes service-discovery information that a client must explicitly understand and request. This matters for protocols whose clients need to locate several possible service hosts without configuring every destination manually. It does not mean that all web browsers, mail systems or cloud applications automatically rely on SRV records.
SRV records have been standardized for decades, yet the format is often explained too loosely. Their priority and weight values have specific, limited meanings, and the record does not test endpoint health or know which server is least congested. Understanding those limits helps administrators design sensible redundancy, avoid misleading failover promises, and debug a client that cannot discover a required service.
Read the complete SRV name and answer correctly
RFC 2782 describes an SRV owner name in the form _service._protocol.example.com. The service identifies the application protocol whose location is being queried; the protocol label commonly identifies a transport such as _tcp or _udp. A DNS response includes priority, weight, port and target fields. The complete name matters: querying example.com for an A record is not the same operation as querying _sip._tcp.example.com for SRV records.
A schematic answer can be written as _sip._tcp.example.com. 300 IN SRV 10 20 5060 sip1.example.net. The TTL of 300 seconds belongs to DNS cache behavior; 10 is the priority, 20 is the weight, 5060 is the port and sip1.example.net is the target hostname. The target needs an appropriate address record so the client can reach it. The sample uses a documentation domain, not a service address that should be copied into production.
The exact service and transport name must follow the specification for the application. For instance, a client implementing an SRV-based discovery standard can query its defined owner names and then attempt the indicated targets. Inventing _http._tcp for an ordinary web browser does not make the browser consult those records. Always verify that the client software actually supports the relevant SRV discovery procedure.
Choose priorities before interpreting weights
Priority is the first selection level. As described in RFC 2782, clients prefer reachable targets with the lowest numerical priority value. A record with priority 10 is preferred to one with priority 20 when the same service is represented by both. Within the same priority group, the weight field influences the randomized ordering of alternatives. Greater weights generally increase selection likelihood relative to other members of that group; they are not absolute percentages across every target in the zone.
Weight is intended to express a relatively static distribution preference. It is not a real-time measurement of CPU load, network latency or the number of active requests. A DNS server returning SRV records is not thereby performing application-layer load balancing or detecting the server with the shortest queue. A client also needs to implement the selection and retry behavior specified for its service; different applications may impose additional discovery rules.
If two servers must be equally preferred, equal priority and appropriate weights can express that intention, but real traffic may not be evenly split. Client population, DNS caching, session length and the number of discovery attempts can skew the observed distribution. Use application and service monitoring to verify capacity planning rather than assuming that SRV weights guarantee a distribution under every workload.
Understand why DNS records alone cannot guarantee failover
An SRV answer is location information, not a health check. If it points to a service that is down, the DNS record can remain present and be returned from a cache. Depending on the client and service protocol, the client may try another target, wait, or fail. An administrator should therefore describe SRV as supporting alternative endpoint discovery, not as providing automatic uninterrupted service by itself.
A robust design combines working targets, sensible client retry behavior, service health monitoring and DNS change procedures. A lower-preference backup target is useful only if the relevant client will consider it when the first is unavailable. During outages, record the actual connection attempts: sometimes discovery succeeds but TLS, authentication, application availability or firewall policy prevents a connection to the advertised port.
DNS TTL also affects change visibility. A low TTL can reduce the time that compliant resolvers retain an old response, but it cannot compel every client or resolver to update instantly. Administrators should consider negative caching, resolver behavior and propagation of authoritative updates, and should not describe a DNS change as immediately visible to every client on the internet.
Use SRV where the application standard actually expects it
Directory and domain infrastructure are a familiar example: service-aware clients can locate particular directory-related services using defined DNS naming conventions. Some SIP and XMPP discovery procedures also use SRV records to identify a host and transport port. In each case, the reason SRV is helpful is that the application defines how the record is queried and interpreted, not because a generic DNS answer steers all packets.
Ordinary email delivery is an important counterexample. The standard mechanism for locating a destination domain’s receiving mail exchangers uses MX records, not arbitrary SRV records. An email client may use provider-specific discovery conventions, but that does not make SRV the universal mechanism for SMTP delivery. Similarly, major object-storage services should not be claimed to use SRV to select the nearest storage endpoint without vendor evidence supporting that specific claim.
The distinction applies to web services as well. Modern HTTP endpoint discovery increasingly includes mechanisms such as SVCB and HTTPS resource records, specified in RFC 9460, which are not the same as SRV. The DNS caching process also affects how quickly changes in records become visible. Understanding the exact record type and the client’s behavior prevents one-size-fits-all statements about DNS steering.
Publish valid records through the authoritative DNS operator
Create SRV records where the appropriate DNS zone is managed; that may be an enterprise DNS server, a managed authoritative DNS provider or another authorized zone operator, not necessarily a domain registrar. Identify the complete owner name, TTL, priority, weight, port and target. Check that the target is a DNS hostname with reachable addresses, not merely an IP literal placed into the target field.
If multiple targets are published, document what priority and weight values mean operationally, along with the intended fallback behavior. Coordinate DNS changes with the service owners so the target hosts are configured for the advertised service and port. A correctly formed SRV record cannot repair a service that is not listening, a firewall that blocks the connection or an authentication configuration that rejects clients.
For migration, lower the planned record TTL in advance where useful, allow previously cached values to age out, add or modify targets, and monitor both discovery and application connections. Keep the prechange zone values available for rollback. Avoid confusing DNS TTL changes with dynamic server-health switching: each mechanism addresses a different part of the problem.
Verify the answer and the subsequent connection independently
A command such as dig SRV _sip._tcp.example.com queries the record directly and can show the returned targets and fields. From an affected client network, compare answers from the resolver in use and, when appropriate, the authoritative nameserver. If the response is absent, confirm the exact owner name and service convention before assuming that DNS is broken.
If the record is present but clients still fail, resolve the target hostname’s A or AAAA records, check reachability to the published port, and inspect the application’s connection and discovery logs. Wrong targets, port mismatches, unexpected priority values and missing address records commonly create a situation where the zone appears populated but the service does not work. Inspect any local service-discovery cache in addition to the resolver cache.
For general DNS investigations, the difference between recursive and iterative DNS resolution helps explain why a client may see a cached result that differs temporarily from an authoritative update. DNSSEC can authenticate signed DNS data through a validating resolution path, but it does not authenticate the application server or replace transport security. The target application still needs its normal identity, encryption and access controls.
Handle unavailable services and security correctly
RFC 2782 provides a special representation for a service that is not offered: a single SRV record with a target of a single dot can explicitly indicate that the requested service is unavailable at that name. It should not be confused with a spare host or a placeholder that clients will try to resolve into an address. This distinction is useful when reviewing automated zone changes and service-discovery behavior across environments.
SRV information is also not an authorization policy. A client that learns a service endpoint through DNS still must establish the correct authenticated and encrypted connection for that application. A malicious or stale DNS response can direct a client toward an unexpected host if the resolution path is untrusted; DNSSEC can help validate signed DNS records when the client uses a validating resolver, but it does not make the endpoint trustworthy by itself. Application certificates, account permissions and transport protections remain necessary.
Treat records as configuration that needs lifecycle ownership. When a server is decommissioned, update the authoritative service records and monitor the client fleet for lingering cached references, connection failures and long-lived sessions. A discovery record that remains syntactically correct after its target is retired can be more difficult to diagnose than an obvious DNS syntax error.
Keep the record’s operational purpose narrow
SRV answers describe a service’s possible destinations and a static ordering policy. They do not inherently provide geographic routing, assess application latency, balance HTTP requests, enforce security segmentation or ensure a healthy backend. Those results require other components and service-specific client behavior. Avoid assigning SRV capabilities from unrelated DNS features or from a particular application provider’s private architecture.
For a new deployment, the practical sequence is to confirm service support, design priority and weight for real alternatives, publish reachable target hostnames and ports, query the exact owner name, test client behavior and rehearse an endpoint failure. This evidence-based process gives SRV records a clear role in service discovery without treating DNS as an automatic high-availability system.
