What is an SRV record? When is it necessary to configure a service location record?

　　In the world of domain name resolution, A records and CNAME records are familiar to everyone, but there's a record type that's often overlooked—the SRV record. Unlike an A record, which directly tells you "where the server is," it provides more detailed information about "where a specific service is located, which port to access it through, and which server to prioritize."

　　I. What is an SRV Record?

　　An SRV record stands for Service Location Record, a resource record type in the DNS system specifically used to locate the address and port of a server providing a specific service. It is defined in RFC 2782, with DNS type code 33.

　　The biggest difference between SRV records and A records and CNAME records is that SRV records not only tell you "where to go," but also "which door to use."

　　Here's a straightforward example:

　　A record: example.com → 192.168.1.100 (only tells the IP address)

　　SRV record: _sip._tcp.example.com → Priority 10, Weight 5, Port 5060, Server sip-server.example.com (also tells the service type, port, and priority)

　　The standard format of an SRV record is as follows:

　　_Service._Protocol.Domain.TTL Category SRV Priority Weight Port Target Host

　　II. What Key Information Does an SRV Record Contain?

　　A complete SRV record contains four core parameters, which are key to its differentiation from other DNS records:

　　Parameter Meaning and Function

　　Priority: The smaller the value, the higher the priority, determining the primary/backup order. Smaller values ​​are accessed first.

　　Weight: The larger the value, the higher the probability of being selected, used for load balancing among servers of the same priority.

　　Port: The port number the service listens on, telling the client which port to connect to; no manual configuration is required.

　　Target Host: The domain name of the server provided. It must point to an existing A record or AAAA record, not a CNAME record.

　　Logic of Priority and Weight:

　　The client first checks the priority—servers with smaller values ​​are selected first. Only when all high-priority servers become unavailable will the request be downgraded to a lower-priority server.

　　If multiple servers have the same priority, traffic is then distributed proportionally according to their weights. The higher the weight value, the more requests are allocated to it.

　　III. When is it necessary to configure SRV records?

　　SRV records are not needed in all scenarios. The following are the most common application scenarios:

　　1. Enterprise Communication and Collaboration Systems

　　VoIP Telephone Systems: Enterprise telephones based on the SIP protocol use SRV records of type _sip._tcp or _sip._udp to locate the call server and port.

　　Instant Messaging: Internal enterprise IM tools use SRV records to locate the message server.

　　LDAP Directory Services: LDAP services used by enterprises for unified authentication use SRV records of type _ldap._tcp to allow office devices to automatically connect to the directory server.

　　2. Microsoft Active Directory

　　This is one of the most classic and essential application scenarios for SRV records. The normal operation of Microsoft Active Directory (AD) depends on a DNS server that supports SRV records. AD clients and domain controllers use SRV records to determine the IP address of the domain controller.

　　If your enterprise network uses Windows domain controllers, configuring SRV records is mandatory, not optional.

　　3. High Availability and Load Balancing of Database Services

　　MySQL officially supports connecting to servers via DNS SRV records. When you have multiple MySQL instances (such as a server cluster) providing the same service, you can use SRV records to achieve failover, load balancing, and replication.

　　_mysqlx._tcp.example.com. 86400 IN SRV 0 5 33060 server1.example.com.

　　_mysqlx._tcp.example.com. 86400 IN SRV 0 10 33060 server2.example.com.

　　Clients will select available MySQL servers based on priority and weight. When a node is added or removed from the server, only the DNS records need to be updated; there is no need to modify the configuration of each client.

　　4. Cloud Services and Email Systems

　　Cloud Email Service: Optimizes email sending and receiving paths using SRV records of type _smtp._tcp and _pop3._tcp.

　　Postfix Mail Server: Supports load balancing and automatic configuration using DNS SRV records starting from version 3.8.0.

　　5. Games and Entertainment Services

　　Multiplayer Online Games: Assigns corresponding game servers to players in different regions and versions using SRV records, avoiding the need to manually enter complex IP addresses and ports.

　　For example, Minecraft Java Edition supports the use of SRV records, allowing players to connect directly to the server using domain names without needing to remember port numbers.

　　6. XMPP Instant Messaging Protocol

　　XMPP protocols (such as Jabber) require SRV records to support federated authentication and service discovery. A typical record is _xmpp._tcp.example.com.

　　IV. Notes on Configuring SRV Records

　　The target domain name must be resolvable: The target host of the SRV record cannot be an IP address and must already have an A record or AAAA record configured. More importantly, the target hostname cannot be a CNAME alias; it must be an A/AAAA record that directly points to the IP address.

　　Priority and weight settings should be reasonable: Priority is recommended to be set at intervals of "10, 20, 30," leaving room for future additions of new servers. Weights should be allocated reasonably based on server performance.

　　TTL values ​​should be adjusted flexibly: If the service changes frequently, the TTL can be temporarily set to 300 seconds to allow for quick resolution; once the service is stable, increase the TTL (e.g., 3600 seconds or 86400 seconds) to reduce the number of DNS queries.

　　Note the UDP packet size limit: RFC 1035 stipulates that the UDP DNS response message payload cannot exceed 512 bytes. When adding multiple SRV records, pay attention to the total size; if necessary, switch to TCP transmission.

　　FAQs：

　　Q1: What is the difference between an SRV record and an A record?

　　A1: An A record only returns the IP address, telling the client "where the server is." SRV records contain six dimensions of information: service type, protocol, port, priority, weight, and target host. They tell the client "where this service is, which portal to use, and who to contact first." SRV records are suitable for scenarios requiring "service-level location," while A records are suitable for the most basic domain-to-IP mapping.

　　Q2: Do I need to configure SRV records for website DNS?

　　A2: Generally not. Ordinary websites (HTTP/HTTPS) can function normally using A or CNAME records. SRV records are mainly used for specific services on non-standard ports, such as SIP phones, LDAP directories, XMPP instant messaging, MySQL clusters, and Microsoft Active Directory.

　　Q3: How are the priority and weight of SRV records used specifically?

　　A3: Priority determines the primary/secondary order; lower values ​​take precedence. Assuming you have three servers with priorities of 10, 20, and 30, the client will first try server 10, then 20 if that fails, and only try server 30 if that fails. Weights take effect within the same priority range; higher weight values ​​increase the probability of being selected, used for load balancing.

　　Q4: I've configured SRV records, but the client can't connect. What could be the reason?

　　A4: Common reasons include: ① The A/AAAA record for the target host doesn't exist or is incorrect; ② The target hostname uses a CNAME alias (SRV doesn't support this); ③ Priority and weight settings cause the client to keep trying unavailable high-priority servers; ④ The server's firewall hasn't opened the corresponding port; ⑤ The client application itself doesn't support SRV record queries.

　　Q5: Do all DNS providers support SRV records?

　　A5: Most mainstream DNS providers support SRV record types, but they need to be added manually in the DNS management interface. When adding, enter the record value in the format of Priority Weight Port Target Host. If your provider doesn't support it, you can contact their technical support.