Cybersecurity glossary
What is an SRV Record?
Learn what an SRV record is, how DNS service discovery uses priority, weight, port, and target, and where SRV records help clients locate services such as SIP, LDAP, and XMPP.
Definition
An SRV record is a DNS resource record that tells clients which host and port provide a named service, along with priority and weight values for selection behavior.
When clients need more than a hostname
Some protocols cannot assume that a service lives on the default port of a predictable host like www. A client may need to discover which machine actually handles the service and which port it should speak to. SRV records were designed for exactly that job.
This turns DNS from simple name-to-address plumbing into a lightweight service-discovery layer. When both the protocol and client support SRV, operators can move services, add redundancy, and publish preference rules without hardcoding endpoints into every client configuration.
The four facts an SRV answer carries
An SRV record is richer than a plain address record because it tells the client how to choose among multiple service endpoints, not just where one hostname points.
Service and protocol labels
Names such as _ldap._tcp.example.com identify what service is being requested and which transport is expected.
Priority
Lower values are tried first, letting operators express preferred and fallback targets.
Weight
Among equal-priority targets, weight helps distribute connections rather than sending everything to one host.
Port and target
The answer tells the client which TCP or UDP port to use on which target hostname.
How SRV-based service discovery works
The client derives the SRV owner name
Based on the protocol, it queries a name like _service._proto.example.com.
The resolver returns one or more SRV records
Each answer includes priority, weight, port, and a target hostname.
The client ranks the candidates
Targets with lower priority win, and equal-priority targets may be balanced by weight.
The target hostname is resolved
The client performs A or AAAA lookups for the chosen target to get actual addresses.
The connection uses the published port
The application connects to the target on the SRV-specified port instead of assuming a default.
Fallback happens if needed
If the preferred endpoint fails, the client can try the next eligible SRV target according to protocol behavior.
Protocols that commonly rely on SRV records
SRV matters most where clients are expected to discover service endpoints dynamically. It is not universal DNS behavior, so support depends on the application ecosystem.
| Service area | How SRV helps | Operational note |
|---|---|---|
| LDAP and Active Directory | Clients can locate domain controllers or directory services without static host lists. | Correct priorities and site-aware design are important for predictable client behavior. |
| SIP and VoIP | Call setup can discover the right host and port for signaling services. | Protocol support is good, but failover behavior still depends on client implementation. |
| XMPP or messaging systems | Clients can discover messaging endpoints using standardized service labels. | Certificate names and service names still need to line up cleanly. |
| Custom internal services | Teams can publish service locations without hardcoding ports into every consumer. | Only useful if the internal client libraries are built to query and honor SRV. |
Practical SRV publishing advice
SRV records are elegant when supported and frustrating when assumptions are vague. Small publishing errors often turn into client-specific bugs.
- Confirm the application or library actually performs SRV lookups before designing around them.
- Keep priority and weight semantics intentional rather than copying random examples from unrelated protocols.
- Ensure every SRV target hostname resolves cleanly to reachable A or AAAA records.
- Monitor the service using the same discovery path that real clients follow, including the SRV lookup and port.
- Lower TTLs before planned migrations if you need clients to shift to new service targets quickly.
- Avoid pointing SRV targets at ephemeral names that are likely to disappear without DNS cleanup.
- Document which service labels and protocols are officially supported so consumers do not guess.
- Test fallback behavior because different client implementations may treat equal priorities and weights differently.
Security and design cautions
SRV records do not authenticate anything by themselves. They tell a client where to go, but transport security, certificate checks, and application authentication still decide whether the destination should be trusted.
There is also an adoption trap: teams publish SRV and assume discovery is solved, only to learn that a major client ignores the records entirely. SRV is powerful when it is part of a protocol contract, not when it is treated as a universal DNS magic trick.
The practical takeaway
An SRV record lets DNS publish service endpoints with priority, weight, port, and target hostname. That makes it a useful discovery tool for protocols that were designed to use it.
Before relying on SRV, verify client support and test the full lookup path. Good service discovery comes from compatible applications plus accurate DNS, not from the record alone.
Related security terms
A Record
SRV targets ultimately resolve through address records such as A or AAAA.
CNAME Record
Aliases can appear near service-discovery designs, but SRV has different client expectations.
MX Record
MX also uses preference ordering, which makes it a useful comparison when learning SRV.
DNS Resolver
Resolvers return SRV answers, but client software must know how to interpret them.
TTL (Time to Live)
TTL determines how long clients or resolvers may reuse a service-location answer.
Frequently asked questions
What does SRV stand for in DNS?
SRV stands for service. The record helps a client discover the host and port for a named service.
How is an SRV record different from an A record?
An A record gives an address for a hostname. An SRV record names a service, includes a port, and points to a target hostname that must then be resolved.
What do priority and weight mean in SRV?
Priority determines which targets should be preferred first, while weight helps distribute traffic among targets with the same priority.
Why are service names written like _sip._tcp.example.com?
The underscore labels separate the service and protocol namespace from ordinary hostnames and help avoid collisions.
Do all clients support SRV records?
No. SRV only helps when the application protocol and client software are designed to look for SRV answers.
Can an SRV record point directly to an IP address?
No. The target is a hostname, which clients then resolve using address records.
References
Explore authoritative guidance and frameworks related to srv record.
Explore every security definition
Return to the glossary to search by term, alias, starting letter, or security category.