A DNS SRV record is a service-location entry that tells clients which host provides a given service, such as LDAP or Kerberos. In Active Directory environments, these records are useful because they reveal where domain services live and help map the directory infrastructure quickly and reliably.
How DNS SRV records work
SRV records are DNS entries that point clients to the right host, port, and priority for a named service. They let service consumers discover where to connect without hard-coding infrastructure, which is especially useful when the service may move, scale, or have multiple endpoints.
Each record expresses a service name, protocol, target host, port, priority, and weight. Clients use that data to choose an endpoint, often preferring lower priority values first and using weight to spread traffic among equal-priority targets.
That makes SRV records a discovery mechanism, not an access-control mechanism. They do not prove the service is trustworthy, but they do determine which systems clients will attempt to reach, so the correctness of the DNS data directly affects service reachability and user experience.
Where SRV records are used
SRV records are common in directory services, messaging systems, VoIP, chat, and other protocols that benefit from service discovery. In Active Directory, for example, they help clients locate domain controllers and other directory services quickly, which reduces manual configuration and keeps service lookup resilient across infrastructure changes.
They are also useful when multiple servers can provide the same function. A client can use the SRV answer set to balance connections across replicas, fail over to another host, or select the closest or preferred service endpoint based on the record set returned.
In practice, SRV records are one of the cleaner ways to separate service naming from host naming. The client asks for the service, and DNS answers with the current location, which is easier to maintain than embedding server names throughout applications and configuration.
What makes SRV records security relevant
Because SRV records tell clients where to go, they can expose internal service topology and make critical hosts easier to map. In environments that publish directory, authentication, or messaging services broadly, the record set can reveal naming patterns, hostnames, ports, and the structure of the underlying infrastructure.
That visibility is not inherently bad, but it becomes sensitive when the record points to services that should be tightly controlled or when DNS integrity is weak. If an attacker can tamper with name resolution, they may redirect clients toward a hostile endpoint or a degraded target, which turns discovery data into a trust dependency.
For teams that want a deeper identity and access perspective on the surrounding ecosystem, NHIMG’s Ultimate Guide to Non-Human Identities is useful because service discovery often sits alongside service accounts, keys, and other machine-facing access paths. For a concrete example of how exposed credentials can surface through infrastructure change and offboarding gaps, see Coupang Signing Key Breach.
How to interpret SRV records in operations
Operationally, SRV records should be read as routing metadata that needs to stay accurate, current, and scoped to the right audience. If the record is stale, clients may fail to connect. If it is too broadly exposed, it can reveal service placement that defenders would rather keep internal.
Teams should also remember that the record alone does not validate the endpoint. The client still needs the usual trust controls for transport, authentication, and service authorization. SRV helps the client find the service, but it does not make that service legitimate, hardened, or safe by itself.
For DNS ownership and registry context, IANA is the authoritative reference point for protocol parameter registries, while IANA also reinforces the broader principle that DNS records are part of a globally coordinated namespace, not a local-only naming convenience.
Risk and Threat Considerations
SRV records can create real exposure when they reveal sensitive service endpoints or when their answers are tampered with. The main risk is not the record format itself, but the fact that clients will trust it to tell them where critical services live.
Failure mechanism: If the DNS data is stale, misconfigured, or maliciously altered, clients may connect to the wrong host, fail over poorly, or follow a path that exposes internal services to interception or denial of service.
Impact: The result can be service disruption, traffic redirection, topology disclosure, and a larger attack surface around directory or authentication infrastructure.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8, NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS 12 — Network Infrastructure Management | SRV records are network naming data that must be kept accurate and controlled. |
| Recommendation — Inventory and protect DNS records so service-location data stays accurate and approved. | ||
| NIST CSF 2.0 | ID.AM — Asset Management | SRV records expose service assets and help maintain an up-to-date service inventory. |
| PR.DS — Data Security | SRV records can expose internal topology and service-location information that should be protected. | |
| Recommendation — Map SRV-published services into your asset inventory and keep records current. Limit unnecessary exposure of service-location data and protect DNS integrity. | ||
| NIST Zero Trust (SP 800-207) | SC-3 — Continuous Diagnostics and Mitigation | DNS-based service discovery depends on trustworthy routing and ongoing validation of network trust paths. |
| Recommendation — Continuously validate service-routing paths and detect DNS manipulation or drift. | ||
Practitioner Guidance
What to watch for: Treat SRV records as part of the service inventory, not just DNS plumbing. Their value comes from accurate service discovery, so changes in hosts, ports, priority, or weight should be reviewed with the same care as other infrastructure changes.
Common misunderstanding: A valid SRV response does not mean the service is trustworthy or properly secured. It only means DNS can locate it, so authentication, transport protection, and access controls still need to be enforced separately.
Related resources from NHI Mgmt Group
- How should security teams plan for DNS outages that block record updates?
- What should identity and security teams review after a DNS record change?
- Why can DMARC policy discovery change even when the DNS record seems unchanged?
- Why does a stale DNS record create such a high-risk takeover path for attackers?
