An SRV record is a DNS entry that tells clients which server provides a specific service, such as Active Directory logon support. AD relies on these records so workstations can discover domain controllers automatically instead of hardcoding server names or addresses.
What an SRV record does in DNS
An SRV record lets a client discover which host provides a named service, along with the port to use and the priority or weight to prefer when multiple servers are available. That makes service location dynamic instead of hardcoded, which is especially useful in directory, messaging, voice, and clustered application environments.
In practice, SRV records reduce dependence on fixed server names in configuration files and client software. They give administrators a DNS-based way to steer clients toward the right service endpoint while still preserving flexibility for failover and scaling.
Why SRV records matter for service discovery
The main value of an SRV record is that clients can ask DNS for the service they need rather than being told a single address to contact. That is important when the service may move, when there are multiple servers behind one service name, or when the client must choose among several candidates based on preference and weight.
This model is common in environments such as Active Directory, where domain-joined clients use DNS service records to locate domain controllers automatically. The same pattern also appears in other protocols that need a reliable way to discover service endpoints without embedding infrastructure details into every client.
Because the record separates service identity from the underlying host, operators can change server placement, add capacity, or shift traffic without rewriting every consumer configuration. The trade-off is that correctness now depends on DNS being accurate, available, and tightly managed.
How SRV records are structured and interpreted
An SRV record normally expresses four key pieces of information: the target service name, the priority, the weight, and the port. Clients first filter by priority, then use weight to distribute requests among records at the same priority, and finally connect to the chosen target host on the advertised port.
That means SRV records are not just aliases. They are a service-routing signal that tells the client how to reach the service, not merely what hostname to resolve. If the target name or port is wrong, clients may resolve DNS successfully and still fail at the application layer.
The record format also makes SRV useful when one application family exposes several related services on different ports. A client can discover the correct endpoint for each service type from DNS instead of relying on a manual mapping buried in documentation or scripts.
Operational limits and failure modes
SRV records are only as reliable as the zone data and the client implementation that consumes them. If records are missing, stale, or published with the wrong priority or target, clients may fail over poorly, connect to the wrong server, or experience intermittent authentication and service-discovery problems.
They also depend on DNS availability and integrity. If DNS is poisoned, misconfigured, or poorly delegated, service discovery can be redirected away from the intended endpoint. In directory-centric environments, that can disrupt logon flows, service binding, and other domain-dependent operations.
For that reason, SRV records should be treated as operational control points, not passive metadata. Their correctness directly affects availability, resiliency, and whether clients can reach the service they were designed to use.
Risk and Threat Considerations
SRV records create a small but important trust boundary inside DNS-based service discovery. When they are missing, stale, or manipulated, clients may be sent to the wrong host, lose access to a critical directory service, or follow attacker-controlled infrastructure that looks legitimate at the DNS layer.
Failure mechanism: An adversary or misconfiguration can alter service records, exploit weak DNS governance, or rely on stale entries so that clients resolve a service name to an unintended endpoint, causing redirection, denial of service, or service impersonation.
Impact: The result can be authentication failure, degraded application availability, failed domain join or logon workflows, and in the worst case traffic being steered toward a hostile server that can harvest or interfere with client requests.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SC-20 — Secure Name / Address Resolution Service (Authoritative Source Only) | SRV records depend on trustworthy DNS-based service resolution. |
| SC-7 — Boundary Protection | SRV-driven endpoint selection can shift traffic across trust boundaries. | |
| CM-2 — Baseline Configuration | SRV records are part of the approved service-discovery configuration baseline. | |
| Recommendation — Protect service records with authoritative DNS controls and validate name resolution paths. Constrain DNS and service-discovery flows so clients only reach approved endpoints. Keep SRV entries under configuration control and review them as part of the DNS baseline. | ||
| NIST CSF 2.0 | PR.AA-01 — Identity Management, Authentication and Access Control | Directory service discovery via SRV records supports authentication-dependent access flows. |
| DE.CM-09 — Malicious Code is Detected | DNS misuse and endpoint redirection often surface through monitoring and anomaly detection. | |
| Recommendation — Ensure service-discovery records reliably point clients to the correct authentication services. Monitor for unexpected DNS resolution patterns that indicate service-record tampering. | ||
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 31, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org