Most DNS records point domains to specific destinations: A records map to IP addresses, MX records route email to mail servers, CNAME records create aliases. SRV records work differently, they specify not just where to find a service, but also which port to use, how to prioritize multiple servers, and how to distribute load. This extra information makes SRV records essential for applications that need more sophisticated service discovery than a simple hostname provides.
If you've ever configured VoIP phone systems, instant messaging servers, or certain multiplayer game infrastructures, you've likely encountered SRV records. Understanding their structure and proper configuration ensures these services work reliably without manual endpoint configuration for every client.
What SRV Records Actually Do
An SRV record (Service record) publishes the location of a specific service for your domain. Instead of just saying "this domain points to this server," it says "this particular service, using this particular protocol, is available at this server, on this port, with this priority."
This specificity allows client applications to automatically discover service endpoints. A VoIP phone doesn't need you to manually enter the server address and port, it queries DNS for the appropriate SRV record and gets all the information it needs in a single lookup.
What makes SRV different from other records:
Unlike an A record that just provides an IP address, or a CNAME that points to another hostname, SRV records include:
- The specific service being provided (like "sip" for VoIP or "xmpp" for instant messaging)
- The protocol being used (TCP or UDP)
- The port number for the service
- Priority and weight values for handling multiple servers
- The target hostname where the service is located
This richer information enables sophisticated service architectures with automatic failover and load distribution.
Understanding SRV Record Structure
SRV records have a specific naming format that can look intimidating at first:
_service._proto.name TTL class SRV priority weight port target
Let's break down each component:
_service: The symbolic name of the desired service, always prefixed with an underscore. Common examples include _sip for VoIP, _xmpp for instant messaging, _minecraft for game servers, or _ldap for directory services.
_proto: The transport protocol, either _tcp or _udp, also prefixed with an underscore. This specifies whether the service uses TCP or UDP networking.
name: The domain name where the service is provided. This is often your domain (example.com) but can be a subdomain if the service is hosted separately.
priority: A number that determines preference order when multiple SRV records exist. Lower numbers have higher priority, just like MX records. Clients try the lowest-priority server first.
weight: Used for load distribution among servers with the same priority. Higher weight values receive proportionally more traffic. If all servers have equal weight, traffic distributes evenly.
port: The TCP or UDP port number where the service listens. This is what makes SRV records particularly useful, clients don't need to know or configure port numbers; they're provided automatically.
target: The hostname of the server providing the service. This must be a hostname that resolves to an A or AAAA record, not an IP address directly.
Real-World SRV Examples
VoIP and SIP Configuration
Session Initiation Protocol (SIP) is commonly used for voice and video communication. When you configure a VoIP phone or softphone client, SRV records allow the device to automatically discover your SIP servers.
_sip._tcp.example.com. 3600 IN SRV 10 60 5060 sipserver.example.com.
_sip._udp.example.com. 3600 IN SRV 10 40 5060 sipserver.example.com.
This configuration tells SIP clients that your SIP service is available via TCP and UDP on port 5060 at sipserver.example.com. The weights (60 for TCP, 40 for UDP) indicate that 60% of traffic should prefer TCP while 40% uses UDP, assuming the client supports both protocols.
_sip._tcp.example.com. 3600 IN SRV 10 50 5060 sip1.example.com.
_sip._tcp.example.com. 3600 IN SRV 10 50 5060 sip2.example.com.
_sip._tcp.example.com. 3600 IN SRV 20 0 5060 sip-backup.example.com.
This setup provides two primary servers (priority 10) with equal weight (50 each), distributing load between them. If both primary servers become unavailable, clients fall back to the backup server (priority 20).
XMPP Instant Messaging
Extensible Messaging and Presence Protocol (XMPP) powers various instant messaging systems. Proper SRV records enable automatic federation between XMPP servers.
XMPP client configuration:
_xmpp-client._tcp.example.com. 3600 IN SRV 0 5 5222 xmpp.example.com.
This tells XMPP clients (like chat applications) to connect to xmpp.example.com on port 5222.
XMPP server-to-server configuration:
_xmpp-server._tcp.example.com. 3600 IN SRV 0 5 5269 xmpp.example.com.
This enables federation, allowing your XMPP server to communicate with other XMPP servers across the internet. Without this record, other XMPP servers can't automatically discover how to connect to your server.
Minecraft Server Discovery
Modern Minecraft server implementations support SRV records, allowing players to connect using your domain name rather than remembering an IP address and port number.
Minecraft SRV configuration:
_minecraft._tcp.play.example.com. 3600 IN SRV 0 5 25565 mc.example.com.
With this record, players can connect to play.example.com and their Minecraft client automatically discovers the actual server at mc.example.com running on port 25565 (the default Minecraft port).
_minecraft._tcp.play.example.com. 3600 IN SRV 0 5 25566 mc.example.com.
If your Minecraft server runs on a non-standard port (25566 in this example), the SRV record handles it transparently. Players still connect to play.example.com without needing to specify the port manually.
Microsoft Services
Microsoft environments heavily use SRV records for service discovery, particularly in Active Directory and Exchange environments.
LDAP for Active Directory:
_ldap._tcp.dc._msdcs.example.com. 600 IN SRV 0 100 389 dc1.example.com.
_ldap._tcp.dc._msdcs.example.com. 600 IN SRV 0 100 389 dc2.example.com.
Domain controllers publish these records so that clients can automatically locate LDAP services for authentication and directory queries.
_autodiscover._tcp.example.com. 3600 IN SRV 0 0 443 autodiscover.example.com.
This allows Outlook and other mail clients to automatically configure themselves by discovering Exchange server settings.
Priority and Weight in Practice
Understanding how clients use priority and weight values helps you design effective service configurations.
Priority determines the order of attempts: When multiple SRV records exist, clients always try the lowest priority value first. Only if all servers at that priority level fail do they move to the next priority level.
Priority 10: primary-server.example.com (tried first)
Priority 20: secondary-server.example.com (tried if priority 10 fails)
Priority 30: backup-server.example.com (tried if priority 10 and 20 fail)
This creates a clear failover hierarchy.
Weight distributes load within a priority level: When multiple servers share the same priority, weight determines traffic distribution. The algorithm typically works like this:
Server A: Priority 10, Weight 60
Server B: Priority 10, Weight 30
Server C: Priority 10, Weight 10
Approximately 60% of connections go to Server A, 30% to Server B, and 10% to Server C. The actual distribution depends on the client's implementation, but this ratio represents the intent.
Weight 0 has special meaning: Setting weight to 0 for all servers at the same priority level tells clients to select randomly rather than attempting weighted distribution. This is simpler and works fine when you want equal distribution.
Priority 10, Weight 0: server1.example.com
Priority 10, Weight 0: server2.example.com
Priority 10, Weight 0: server3.example.com
Clients randomly choose among these three servers.
Setting Up SRV Records in Your DNS
When configuring SRV records in your registrar's DNS management interface, the exact fields and terminology vary slightly between providers, but the underlying information remains the same.
Common field names you'll encounter:
- Service: The service name (sip, xmpp, minecraft) without the underscore
- Protocol: The protocol (tcp, udp) without the underscore
- Priority: Numeric priority value
- Weight: Numeric weight value
- Port: Port number for the service
- Target: Hostname where the service is located
Some DNS interfaces combine service and protocol into a single field, while others have separate inputs for each component. When using a domain registrar's DNS management system, look for an SRV record type option in the record creation dropdown. Important configuration notes:
The target hostname must resolve to an A or AAAA record. You cannot point an SRV record directly to an IP address, and you cannot point it to a CNAME. If your service is hosted at a location that only provides a CNAME, you'll need to work around this limitation, possibly by creating your own A record that points to the final IP address.
The target hostname should end with a dot (fully qualified domain name) in many DNS interfaces, though some systems add this automatically. server.example.com. with a trailing dot is fully qualified; server.example.com without might be interpreted as relative to the current zone.
TTL values for SRV records typically range from 300 (5 minutes) to 3600 (1 hour). Lower values make changes propagate faster but increase DNS query load. Higher values reduce query load but mean changes take longer to take effect.
Common SRV Record Mistakes
Pointing SRV to a CNAME: This violates DNS specifications. If your service provider gives you a CNAME as the target, you need to resolve that CNAME to its final A record and use that hostname instead, or ask the provider for a proper hostname you can use in the SRV target.
Using an IP address as the target: SRV records must point to hostnames, not IP addresses. If you need to use an IP address, create an A record first, then point the SRV record to that A record's hostname.
Incorrect service or protocol names: Service and protocol names are standardized. Using sip instead of _sip or getting the protocol wrong (tcp instead of _tcp) means clients won't find the record. Follow the exact naming conventions for your service.
Forgetting the underscore prefix: Both service and protocol names must start with an underscore in the actual DNS record, even if your registrar's interface doesn't show them explicitly.
Priority confusion: Remember that lower priority numbers mean higher priority, which is counterintuitive. Priority 10 is tried before priority 20.
Weight misunderstanding: Weight only matters within the same priority level. Changing weights doesn't affect which server is tried first if they have different priorities.
Port number mistakes: Double-check that the port number matches where your service actually listens. A common error is using the default port (like 5060 for SIP) in the SRV record when your server is actually configured to listen on a different port.
Testing SRV Records
Before relying on SRV records in production, verify they're configured correctly and resolve properly.
Query SRV records with dig:
dig SRV _sip._tcp.example.com
This shows all SRV records for the specified service and protocol, including their priority, weight, port, and target values.
Verify the target resolves:
dig A sipserver.example.com
Confirm that the target hostname in your SRV record actually resolves to an IP address.
Test service connectivity:
telnet sipserver.example.com 5060
Verify that the service is actually running and accepting connections on the specified port at the target hostname.
Use service-specific tools: Many protocols have debugging tools that specifically test SRV record functionality. For SIP, tools like sipsak can test SRV-based discovery. For XMPP, telnet to the port and initiate an XMPP handshake to confirm the service responds correctly.
When SRV Records Don't Work
Not all applications support SRV records. While the DNS specification defines SRV records and many modern applications implement support, older software or simple network tools might not know how to query or use them.
Application support varies: Check whether your specific software actually supports SRV-based service discovery before spending time configuring SRV records. Some applications offer it as an optional feature that needs to be enabled. Others might support it for some protocols but not others.
Firewall complications: Just because SRV records point to a server doesn't mean network firewalls allow connections. Ensure that firewall rules permit traffic to the ports specified in your SRV records.
SSL/TLS hostname verification: When services use encryption, certificate verification might fail if the SRV target hostname doesn't match the certificate's common name or subject alternative names. This requires careful certificate planning.
Legacy client compatibility: If you need to support old clients that don't understand SRV records, you might need to maintain both SRV records for modern clients and alternative configuration methods (like A records on standard subdomains) for legacy clients.
SRV Records for Load Balancing
While SRV records can distribute load using weight values, they have limitations compared to dedicated load balancing solutions.
Client-side decision making: SRV-based load distribution depends on client implementation. Different clients might interpret weight values differently or not respect them at all. This makes the actual distribution somewhat unpredictable.
No health checking: DNS doesn't know if a server is healthy or overloaded. SRV records continue directing traffic to a failed server until you manually update the record. Proper load balancers actively monitor backend health and route traffic only to healthy servers.
Sticky sessions: SRV records provide no mechanism for session persistence. If your service requires clients to maintain connections to the same server throughout a session, SRV-based load distribution might cause problems.
For serious load distribution needs: Use SRV records for basic failover and rough load distribution among a small number of servers. For sophisticated load balancing with health checks, session persistence, and dynamic traffic shaping, deploy a proper load balancer and point your SRV records to it.
Advanced SRV Patterns
Service-specific subdomains:
_sip._tcp.voip.example.com. SRV 0 5 5060 sipserver.example.com.
_xmpp-client._tcp.chat.example.com. SRV 0 5 5222 xmppserver.example.com.
Using separate subdomains for different services provides organizational clarity and allows you to delegate management of different services to different teams or systems.
Geographically distributed services:
_service._tcp.us.example.com. SRV 10 50 443 server-us-east.example.com.
_service._tcp.us.example.com. SRV 10 50 443 server-us-west.example.com.
_service._tcp.eu.example.com. SRV 10 50 443 server-eu.example.com.
Regional subdomains with SRV records allow you to route clients to geographically appropriate servers, reducing latency.
_service._tcp.prod.example.com. SRV 0 5 443 prod-server.example.com.
_service._tcp.test.example.com. SRV 0 5 443 test-server.example.com.
Separate production and testing environments with distinct SRV records prevent accidental cross-environment connections.
Protocol-Specific Considerations
- Publish records for both TCP and UDP unless your deployment specifically uses only one
- Consider separate records for different SIP services (voice, video, presence)
- Weight values can prefer TCP for reliability while maintaining UDP as fallback
- Include TLS variants (_sips._tcp) if using encrypted SIP
XMPP (Instant Messaging):
- Client-to-server (_xmpp-client._tcp) and server-to-server (_xmpp-server._tcp) records are different and both necessary for full functionality
- Server-to-server records enable federation with other XMPP domains
- Port 5222 is standard for client connections, 5269 for server connections
- SRV records allow clean server addresses without exposing ports
- Particularly useful when running multiple servers on different ports
- Some game server hosting platforms provide SRV record requirements in their documentation
- Calendar and contact synchronization services can use SRV records for autodiscovery
- Reduces manual client configuration for calendar and address book syncing
Maintenance and Monitoring
Document your SRV records: Unlike A records where the purpose is obvious, SRV records can be obscure months after configuration. Document which service each record supports, why specific priority and weight values were chosen, and dependencies on other infrastructure.
Monitor service availability: If clients depend on SRV records for service discovery, monitor both the DNS records themselves and the target services. A misconfigured SRV record might not be immediately obvious without testing.
Plan for changes: When migrating services to new servers, consider the SRV record update process. Lower TTL values before changes, update records, verify client connectivity, then restore normal TTL.
Review unused records: Periodically audit your SRV records and remove ones for services no longer in operation. Obsolete records create confusion during troubleshooting.
Practical Recommendations
Start simple: For new deployments, begin with single-server SRV records. Add failover and load distribution only when you have operational experience with the service and understand its failure modes.
Test thoroughly: SRV records have more moving parts than simple A records. Test with actual client software, not just DNS query tools, to verify complete functionality.
Consider alternatives: If your application doesn't require dynamic service discovery, simple A or CNAME records might be easier to manage and troubleshoot. Use SRV records when they provide clear benefits, not just because they exist.
Work with your service provider: If you're setting up SRV records for a hosted service, follow their documentation exactly. Service providers know which configuration works with their infrastructure.
Understand your client base: If all your clients support SRV records well, use them confidently. If client support is mixed or uncertain, plan for alternative configuration methods.
Making SRV Records Work for You
SRV records provide powerful service discovery capabilities when you need them. They allow centralized configuration of service locations, ports, and failover behavior without requiring individual client configuration. For protocols that support them properly, SRV records simplify deployment and make infrastructure changes less disruptive.
The key is matching the tool to the need. Simple services with single servers might not benefit much from SRV records. Complex deployments with multiple servers, failover requirements, or non-standard port configurations gain substantial value from proper SRV record implementation.
Understanding the structure, proper configuration, and limitations of SRV records transforms them from mysterious DNS entries into practical tools for service management. When configured correctly and supported by your applications, they provide automatic service discovery that makes infrastructure more flexible and user-friendly.
.png&w=2048&q=75)
.png&w=3840&q=75)
.png&w=3840&q=75)
.png&w=3840&q=75)