SRV record: format, uses and how to set one up

An SRV record (service record) tells programs where to reach a particular service: not only which server, but also which port. Where an A record maps a name to an IP address, an SRV record maps a service such as VoIP calling, chat, or a game server to both a hostname and a port number. This article explains how an SRV record is structured, how priority and weight work, which services use it, and how to set one up and check it yourself.

What is an SRV record?

SRV stands for service, and it is a type of DNS record that describes where a network service lives. The record links a service to a combination of a hostname and a port, so an application automatically knows where to connect. It was defined in RFC 2782 in 2000 and carries the official DNS type number 33.

The difference from other records matters. An A or AAAA record only returns an IP address. An MX record points mail to a server, but it cannot specify a port and applies only to email. An SRV record can do both: it includes a port number and works for many kinds of services. That lets a VoIP phone, a chat client, or a game client configure itself without you having to type in a server address and port by hand.

What does an SRV record look like?

An SRV record has a fixed shape. The name on the left has three parts, and the value on the right has four fields:

_service._protocol.domain.   TTL   IN SRV   priority weight port target

_sip._tcp.example.com.       3600  IN SRV   10 20 5060 sip.example.com.

The name is written as _service._protocol.domain. The first part is the service, preceded by an underscore, for example _sip or _xmpp-client. The second part is the transport protocol, almost always _tcp or _udp, again with a leading underscore. The underscores keep these labels from clashing with regular hostnames. The domain that the rule applies to comes last.

The value of the record consists of four fields, in this order:

In the example above, a SIP phone looks up the service _sip._tcp for example.com and finds the server sip.example.com on port 5060, with priority 10 and weight 20.

Priority and weight: how a client picks a server

You can place several SRV records under the same name, for example for two or more servers. The application then chooses one of them using two simple rules.

First, the client looks at the priority. The records with the lowest number are tried first. Only when those cannot be reached does the client move on to the next priority. That is how you build failover: put your main server at priority 10 and a backup at priority 20.

When two records share the same priority, the weight decides the split. Weight works proportionally: a server with weight 60 receives roughly three times as many connections as a server with weight 20. That is how you spread the load across several servers. A weight of 0 gives a server only a small chance of being chosen while other servers with the same priority and a higher weight are available.

Common SRV records

Not every service uses SRV records, but several well-known applications do. The names and default ports are usually fixed:

On top of that, Microsoft Active Directory (with services such as LDAP and Kerberos), calendar and contact syncing (CalDAV and CardDAV), and some mail clients for automatic setup all rely on SRV records. The idea is always the same: the user only enters a domain, and the software discovers the right server and port on its own.

Important rules and pitfalls

A few rules from RFC 2782 prevent the most common mistakes:

• The target must be a hostname that has its own A or AAAA record. Never enter an IP address, and do not let the target point to a CNAME record (an alias).
• The port belongs in the record itself, in the port field, not in the target. The target is only the server name.
• A target that consists of a single dot, written as ., means the service is deliberately not available at this domain.
• An SRV record works only for programs that explicitly look for one. Web browsers do not: you reach a website through an A or AAAA record, never through an SRV record.

That last point is a common source of confusion. You cannot send a website to a different port with an SRV record, because browsers never query for one. SRV records exist for services like VoIP, chat, game servers, and automatic mail setup.

Setting up an SRV record with LJPc hosting

If you manage your domain with LJPc hosting, you set up an SRV record in the DNS manager. When you add a record, choose SRV as the type. You then fill in these fields:

1. The name in the form _service._protocol, for example _sip._tcp.
2. The priority, weight, and port, each a number from 0 to 65535.
3. The target: the full hostname of the server that provides the service.
4. A TTL, the time in seconds that resolvers may remember the answer.

The DNS manager accepts only a hostname as the target and rejects an IP address or an alias, exactly as the standard requires. If you are not sure which values to enter, check the documentation of the service you are setting up: it lists the correct service name, protocol, and port.

Checking an SRV record

After saving, you can look up an SRV record to confirm it is correct. Use the full name, including the service and protocol parts:

# macOS and Linux
dig SRV _sip._tcp.example.com +short

# Windows
nslookup -type=SRV _sip._tcp.example.com

The answer shows the priority, weight, port, and target. If you do not see your new record yet, give it some time. Changes in DNS are distributed worldwide and, because of the TTL, can take up to 48 hours before they are visible everywhere.

Still stuck? Get in touch with support and we will be glad to help.