SRV records, and what resolvers actually do

An SRV record is the reason play.example.com works when your Minecraft server is on port 25577. It is also the single most commonly misconfigured DNS record in game hosting, and the reason is that almost every tutorial teaches the shape without teaching what the fields mean.

The record, and the specification behind it

SRV records are defined by RFC 2782. The name has a fixed structure: an underscore-prefixed service, an underscore-prefixed protocol, then the domain:

_minecraft._tcp.play.example.com.  IN SRV  0 5 25577 mc.example.com.

The four values after SRV are priority, weight, port and target.

Priority is a preference. A resolver tries the lowest number first and only moves to a higher one if that fails. With a single record it is meaningless, and 0 is fine.

Weight distributes load between records of equal priority, proportionally. With one record it is also meaningless. The convention of writing 5 is habit, not requirement.

Port is the real payload. This is the field the whole record exists for.

Target is a hostname, and it must be a hostname. Not an IP address. A target of 203.0.113.10 is invalid per the specification, and resolvers are entitled to reject it, which is why the record "does not work" for some players and works for you.

The trailing dot, and why it eats people

mc.example.com without a trailing dot may be interpreted as relative and expanded to mc.example.com.example.com. Some DNS panels add the dot for you, some require it, and some silently accept either.

This is the failure that looks like propagation. The record exists, the panel shows it, and connections fail. Check what the resolver actually returns rather than what your panel displays:

dig _minecraft._tcp.play.example.com SRV +short

If that returns nothing, the record is wrong or not yet live. If it returns the wrong target, the dot is the first suspect.

What the target must also have

An SRV record points at a hostname. That hostname needs its own A or AAAA record, because RFC 1035 address resolution is still what turns it into an IP.

So a working setup is two records, not one: the SRV pointing at mc.example.com, and an A record for mc.example.com pointing at the server. Half the "my SRV does not work" cases are a target that resolves to nothing.

What it does not do

It does not hide your IP. Anyone can resolve the target. If you need the address hidden, that is a proxy or a protection service, not DNS.

It also does not replace the plain address. Players who already have your IP saved will keep using it, and a server that changes hosts needs both paths to keep working for a while, which is why connecting by raw address stays worth documenting even after you have a domain.

It does not work for every game. Minecraft Java reads SRV records. A great many other games do not, and their players type an address and a port. Before building a scheme around it, confirm the client actually looks, and if it does not, the hostname itself is what you are optimising rather than the record.

It also does not survive a change of port silently. Move the server, forget the record, and every returning player hits a port nothing is listening on. That is a five-second edit that nobody remembers because it lives in a different system from the one they just changed.

TTL, and the mistake before a migration

TTL is how long resolvers may cache the answer. A record with a TTL of 86400 will be remembered for a day after you change it.

Before moving a server, lower the TTL to a few minutes and wait for the old TTL to expire. Then move. Then raise it again. Skipping this step is why a migration that took ten minutes leaves players disconnected for a day, and it is the same planning that makes a domain worth having at all.

What to check when it does not work

SRV failures look like DNS failures and usually are not. Four checks, in the order that finds it fastest.

Query the record directly. dig SRV _minecraft._tcp.example.com from a machine that is not yours. If the answer is empty, nothing else matters and the problem is at the provider.

Check the trailing dot on the target. Covered above, and still the most common single cause. A target that resolves to play.example.com.example.com returns nothing and looks identical to a missing record.

Confirm the target has an A record. An SRV pointing at a name with no address behind it is a valid record that cannot be used, and nothing in the SRV lookup reports that.

Try it after the old TTL expires. A record changed an hour ago is still cached at whatever the previous TTL said, not the new one, which is why a correct record can fail for exactly as long as the value you set before you changed it.

The half of this that clients decide

Worth stating plainly, because it is the limit of the whole technique: whether an SRV record is used at all is a decision made by the client, not by DNS.

Minecraft's Java client looks one up. Most other games do not, and a launcher or server browser that has never heard of SRV will take the literal hostname and port it was given. That is not a configuration you can fix from the DNS side.

So an SRV record is a convenience for the games that support it and invisible everywhere else, which is the honest answer to whether it is worth setting up: yes for one specific audience, and no as a general solution to giving players an address.

Whether it is worth it

For a Minecraft server, yes, and the argument is short: it removes the port from what a player has to remember, and it lets you change hosts without changing what anyone types. That second one is the real value and it only pays off later, which is why people skip it early and regret it during their first move.

For everything else, check the client first. The record costs nothing to add and does nothing at all if the game never asks for it, and a server that is hard to reach is hard to keep, whatever the listing says about it.