DNS Helper

SRV

An SRV record says which server, and which port on it, handles a given protocol for a domain. It's the same job an MX record does for mail, generalised: MX only ever points to a mail server, on mail's own well-known port, because it was written specifically for mail. SRV does the same thing for any protocol that's bothered to define its own service name.

That's also why the name looks different from every other record on this site. An SRV record's own name encodes the protocol it's for, in a fixed _service._protocol.domain shape, rather than the plain hostname an A or CNAME record uses.

Five fields, not one value

Priority works exactly as it does on an MX record: lower is tried first, and more than one SRV record under the same name, the second row in the table above, gives a fallback if the first doesn't answer. Weight only matters between records that share the same priority, it lets you split traffic unevenly between them (a server with weight 10 gets roughly twice the traffic of one with weight 5) rather than splitting it evenly by default. Port is the actual port that protocol is listening on, not assumed the way it is for, say, plain web traffic. Target has the same rule as MX's own value: it has to be a hostname with its own A or AAAA record, never a bare IP address and never a CNAME.

Where this actually shows up

SRV is easy to overlook because so much of the everyday web doesn't use it at all, browsers still just connect to port 80 or 443 without consulting an SRV record first. It's the protocols built after DNS had matured that lean on it: Matrix federation between homeservers, a self-hosted Minecraft server on a nonstandard port, Microsoft Teams or Skype for Business federating with an on-premises Exchange server, and LDAP or Kerberos locating their servers inside an Active Directory environment all depend on one.

A record you're told to add, not one you invent

Like DKIM, the exact name and target of an SRV record usually comes from whichever service needs it, Matrix's own setup guide, a game server's own documentation, rather than something to work out from first principles. Get the service name and protocol wrong, even a typo in the leading underscore, and the record simply won't be found by anything looking for it, DNS won't complain, it'll just come back empty.

NAPTR, the more elaborate relative

If a VoIP provider or a phone-number service hands you a NAPTR record, it is the record that usually sits one step before SRV. Where an SRV record says which host and port to use for a service, a NAPTR record, defined in RFC 3403, is a small rewrite rule: it carries an order and a preference (the same lowest-first idea as MX, with order taking precedence), a flags field and a services field whose meaning each application defines, and then either a regexp, a substitution that turns the original string into the next thing to look up, or a replacement name. The two last fields are mutually exclusive, and a record with both is an error.

It shows up in two places. SIP clients, as described in RFC 3263, try NAPTR first to learn which transport a server offers, then SRV, then plain address records, and the RFC says the NAPTR step is only a SHOULD: with no NAPTR records, a client goes straight to SRV. ENUM, defined in RFC 6116, maps a telephone number into DNS by removing everything but the digits, reversing them with dots between and adding e164.arpa, so +442079460148 becomes 8.4.1.0.6.4.9.7.0.2.4.4.e164.arpa, and the NAPTR records at that name say where to reach the number, for example a SIP address. Publishing under e164.arpa is not something a domain owner just does: the number holder goes through the zone administrator named in the policy for that part of the tree.

The regexp field contains backslashes, which normally have to be doubled in a zone file, and RFC 3403 has a section of advice for DNS administrators on exactly that. Treat a NAPTR record like a DKIM key: enter it exactly as the service gave it to you, and test it afterwards. This site does not give NAPTR a page of its own, because what the fields mean depends on the application using them, and the application's own documentation is the better source.