What an SRV record does
A domain name can identify more than a website. An organization might run a messaging service, a directory service, or another application on a host with its own name and network port. An SRV record lets an application ask DNS where to find a particular service, rather than assuming that the service runs on the domain’s main host or on a default port.
The key limitation is that the application must support SRV lookups for that service. Adding an SRV record does not redirect ordinary web browsers or change where a domain’s website loads. It supplies discovery information to clients that know to request and use it.
Reading the name and fields
An SRV record’s lookup name follows the pattern _service._protocol.domain. The service label identifies what the client wants, and the protocol label commonly identifies TCP or UDP. For example, a client looking for a fictional service called “chat” over TCP at example.com might query _chat._tcp.example.com. The exact service name and protocol must match what the application expects.
An SRV answer contains four values: priority, weight, port, and target. A sample record might be written as “_chat._tcp.example.com. 300 IN SRV 10 20 5222 chat1.example.com.” Here, 10 is the priority, 20 is the weight, 5222 is the port, and chat1.example.com is the target host. The 300 is a time-to-live value in seconds; it describes how long a resolver may cache the answer, not how long a connection should stay open.
The target is a host name, not an IP address or a URL. After receiving the SRV answer, the client resolves that host name to an address, commonly using A or AAAA records, and then attempts a connection on the stated port. The trailing dot sometimes shown on DNS names marks the end of the full name; DNS control panels may display or accept the name differently.
How priority and weight guide selection
Multiple SRV records can offer alternative hosts for the same service. A client first considers records with the lowest numerical priority value. If a host at that priority cannot be used, the client may try records at a higher numerical priority, according to the application’s connection rules. Priority therefore provides an ordering, not a measure of server speed.
Weight helps distribute selections among records that share a priority. Higher weights generally make a record more likely to be chosen, but they do not guarantee an exact share of connections. For example, weights of 30 and 10 at the same priority express a preference for the first target. They do not prove that every group of four connections will be split three to one.
These fields are useful for planning alternatives, but an SRV answer is not a health check. DNS can continue returning a record when its target is unreachable. The client’s behavior when a connection fails—and whether it tries another target—depends on the application.
Setting up a record carefully
Start with the service’s own documentation to confirm its required lookup name, protocol, port, and client behavior. In your DNS manager, create the SRV record under the intended domain and enter each field separately if the form provides separate boxes. DNS interfaces vary: one may ask for the complete lookup name, while another automatically appends the domain. Check the resulting full name so you do not accidentally repeat part of it.
Make sure the target host resolves to the intended address and that the service listens on the specified port. The target should be a host name with its own address records rather than an alias. If you publish several targets, check each one; a correctly formatted SRV record is not useful if its target cannot be resolved or reached.
Some services use a target of a single dot (“.”) to indicate that the service is not available at that name. This has a different meaning from leaving the SRV record out. Use it only when it matches the service’s specification and your intended configuration.
Troubleshooting a lookup
When a client cannot find a service, first verify the exact name it queries. A misplaced underscore, the wrong protocol label, or a domain added twice can produce a valid-looking record at the wrong name. Query DNS for that full SRV name and compare the returned priority, weight, port, and target with the configuration you intended. If you recently changed a record, cached answers may persist until their time-to-live expires.
Next, resolve the returned target’s A or AAAA records and check whether the application can reach the target on the advertised port. A successful DNS lookup confirms only that discovery information was returned; it does not confirm that the service is running or that a connection is permitted. If DNS and connectivity both look correct, check the application’s SRV support and its rules for choosing or retrying targets.
