Connecting a domain to a game server: A, SRV and ports

Point an A record at the address your panel shows for the server, wait for it to resolve, and hand players play.example.com plus the port. That is the job for almost every game, and it takes two minutes. The interesting part is the port, because a domain name carries an address and nothing else, and only a small number of games will go and find the port for themselves.

There are exactly three ways to make the port disappear, and one way to live with it. This post goes through all four, which game belongs to which, and how to check the result before you post it in Discord.

The gap: a name carries an address, a game needs a port#

An A record maps a name to an IPv4 address. An AAAA record does the same for IPv6. Neither has a field for a port number, a protocol or a path, and no amount of configuration at your DNS provider changes that. So play.example.com resolves to 203.0.113.10 and the client is still standing in front of a machine with sixty thousand doors, needing to be told which one.

Your four options:

1. Tell people the port. play.example.com:27015. Ugly, universal, works everywhere, and still far better than an address nobody can remember or reissue.
2. Publish an `SRV` record. The client looks it up and learns the port by itself. Only works for games whose client actually performs the lookup, which in practice means Minecraft Java and a handful of non-game services.
3. Run on the port the client assumes. If the game defaults to 27015 and you are on 27015, nobody types a port. This is the cleanest answer when it is available.
4. Put a proxy in front. The proxy listens on the expected port and forwards to the real one internally. Standard for HTTP, and available for Minecraft through a proxy such as Velocity. Not available for most UDP games.

Finding the address to point at#

Before any of that, get the right address. On a panel-based host, the server's own page shows the address and port it is actually bound to, and that pair is what goes in the record and in the connection string. Copy it rather than typing it from memory, because the port in your head is frequently last month's.

Three traps at this step:

• The panel's address is not the server's address. panel.renode.space is a website. It is not where your game server listens, and pointing a record at it achieves nothing.
• A shared address is normal. Several servers can sit behind one address on different ports. That is why the port matters, and it is also why you cannot assume the default port is free. Static addresses, and whether you need one covers the two cases where a dedicated address stops being optional - being allow-listed by somebody else, and needing a default port you cannot share.
• The query port is not the game port. Most games allocate at least two. Players connect to the game port; server browsers talk to the query port. Putting the query port in the record produces a name that resolves and a connection that never completes. Game server ports explained has the full taxonomy.

RE:NODE does not sell domains and does not run DNS, so the record itself goes in wherever your zone lives - your registrar, Cloudflare, or whoever your nameservers point at. dig +short NS example.com answers that question definitively, and editing records in a panel that is not authoritative is a popular way to waste an afternoon.

The A record, which always works#

This is the version to reach for unless you have a specific reason not to.

1. In your DNS provider's editor, create an A record.
2. Name: play if the form takes a label, play.example.com if it wants the full name. Check an existing record to see which shape it uses.
3. Value: the IPv4 address from the server page.
4. TTL: 300 while you are setting it up, 3600 once it is settled.
5. Save, then resolve it from outside your own network before telling anybody.

play    300  IN  A     203.0.113.10node    300  IN  AAAA  2001:db8::10

If your provider has an HTTP proxy feature - Cloudflare's orange cloud is the one people hit - it must be switched off for this record. That proxy terminates HTTP and HTTPS. A game protocol is neither, so a proxied record hands your players an address belonging to the proxy network, which will never accept a game connection. The record must be DNS-only, the grey cloud. Cloudflare for websites and game servers sets out exactly what the orange cloud will and will not carry.

Once there is more than one server, stop pointing service names directly at addresses. Put the address in a machine name and point service names at that with a CNAME, so a move is one edit instead of nine - subdomains for servers is that pattern in full.

SRV records, and the games that read them#

An SRV record carries a host and a port together, so a client that looks one up needs no port from the player. The catch is that the client has to ask, and almost none do.

Minecraft Java does. When a player types a hostname with no port, the client queries _minecraft._tcp.<hostname> first, and if a record comes back it uses the target and port from it. If nothing comes back it falls back to a plain A lookup and assumes 25565.

_minecraft._tcp.play  300  IN  SRV  0 5 25571 node.example.com.node                  300  IN  A          203.0.113.10

The second record is the one people forget. Nothing in an SRV record is an address: the target is a hostname, and that hostname needs an A record of its own. An IP address typed into the target field is invalid and fails silently. SRV records for Minecraft goes through every field, the three shapes registrar forms come in, and the dig commands that prove it.

Outside Minecraft Java, treat SRV as unavailable unless you have tested it. Minecraft Bedrock does not perform the lookup. Source and GoldSrc engine games do not. Valheim, Palworld, Rust, Terraria and the rest of the survival catalogue do not. Voice servers are the notable exception - TeamSpeak 3 uses _ts3._udp and Mumble uses _mumble._tcp - which is worth knowing because it is often the other half of a community's DNS.

Default ports, and proxies that take the port away#

If the port can be the default, make it the default and stop reading. A player who types play.example.com and nothing else is the best outcome available, and for a game on its standard port an A record alone achieves it.

Ports shift between versions of some of these, so confirm against the port your server actually bound to, which the console prints at startup.

The proxy route is narrower than people expect. A reverse proxy works by understanding the protocol well enough to read the requested hostname and route on it, which is why it is standard for HTTP and rare elsewhere - what a reverse proxy does explains the sequence. Minecraft has the equivalent in Velocity and BungeeCord, which listen on 25565 and forward players to backends on internal ports, and can even route by the hostname the player typed so that creative.example.com and play.example.com land in different servers behind one public port. Minecraft Velocity proxy networks is that build. For a UDP shooter or survival game there is no equivalent you should rely on, and a generic TCP or UDP forwarder adds a hop and a failure point to save a colon.

RE:NODE game plans do not include a proxy slot, which is deliberate: there is nothing useful for an HTTP proxy to do with a game stream. App and web plans do include one, because HTTP is exactly where it earns its place.

What each game client accepts#

The record is only useful if the client will take a name in the box. Most will, and the ones that refuse have a console command that does not.

If a client rejects a name that resolves correctly everywhere else, that is the client, not your DNS. Give those players the address and port and move on - the name still earns its keep for everybody else and for the day you migrate.

Crossplay complicates this further. A Bedrock player reaching a Java server through Geyser connects to a different port over UDP, so they need their own address-and-port pair whatever the Java side looks like - Geyser and Bedrock crossplay covers the two front doors.

Proving it before you announce it#

A failed join has too many possible causes to be a test. Separate DNS from the network from the game, in that order.

$ dig +short A play.example.com @1.1.1.1203.0.113.10$ dig +short SRV _minecraft._tcp.play.example.com @1.1.1.10 5 25571 node.example.com.$ nc -vz play.example.com 25571Connection to play.example.com 25571 port [tcp/*] succeeded!

Naming the resolver matters. Querying 1.1.1.1 or 8.8.8.8 explicitly bypasses whatever your router and ISP have cached, which is how you distinguish "not published" from "not propagated". On Windows, nslookup play.example.com 1.1.1.1 and Test-NetConnection play.example.com -Port 25571 do the same two jobs.

For a UDP game there is no handshake for nc to complete, so the port test does not exist in a useful form. Confirm the server bound where you think it did by reading its console at startup - it will say - and then do the only test that counts: join with the name, from a machine that is not on your own network. A phone on mobile data is the fastest way to prove that the path works for somebody who is not you.

What a domain will not do for you#

It does not hide your address. Anybody can resolve the name in two seconds. A domain is a convenience layer, not protection. The thing that sits between a flood and your server is upstream filtering, and even that only drops obvious volumetric traffic - what we do about attacks is the honest version.

It does not reduce latency. The packets take the same path they took before. The only network number a name changes is the one-off lookup at connection time.

It does not survive a client that cached the address. Some clients resolve once at connect and hold the result for the session, and Steam's favourites list in particular remembers what it found. After a move, ask people to remove and re-add the entry rather than debugging why one person still lands on the old box.

It does not fix a closed port. A perfect record pointing at a port nothing is listening on looks exactly like a broken record from the client's side. If the name resolves and the join fails, the problem has moved on from DNS.

Moving the server, and what breaks when you do#

The whole reason to use a name is the move, so do it properly.

1. A day ahead, drop the TTL on the record - and on the SRV target, if you have one - to 300.
2. Wait out the previous TTL in full, so every cache has picked up the short value.
3. Move the world or the data, start the new server and confirm it works by address.
4. Change the record. One line.
5. Leave the old server running for a few hours. Players mid-session do not re-resolve anything, and stale caches keep arriving.
6. Watch the old server's console. When nobody has connected for an hour, it is done.
7. Put the TTL back up.

Moving a server without losing players covers the rest, including the part where the data moves before the DNS and not after.

Three things commonly break during a cutover. The old record is still cached by a player's router, and they insist the server is down - have them try the address directly to confirm. The new server's firewall has the game port open but not the query port, so it works and never lists. And somebody's shortcut has the IP baked in from before you owned a domain, which is the problem the domain was bought to end.

FAQ#

Can I get rid of the port so players just type my domain?

Only in three situations: the game is Minecraft Java and you publish an SRV record, the server runs on the game's default port, or a protocol-aware proxy listens on the default port for you. Otherwise play.example.com:27015 is the correct answer and it is still an improvement on a raw address.

Do I need to buy a domain from my host?

No, and you generally cannot. A domain is bought from a registrar and its records live wherever its nameservers point. Hosting and DNS are separate services that only meet at the value of one record. RE:NODE neither sells domains nor hosts DNS.

Why does the name work for me but not for my friends?

Almost always caching. Your resolver has the new answer and theirs has the old one, for the remainder of the previous TTL. Test the name against 1.1.1.1 to see the published truth, and check nobody has the address saved with an old port attached.

Should I use A or CNAME for a game server?

An A record is fine and is one lookup shorter. A CNAME pointing at a machine name is better once you run more than one server, because moving the machine becomes a single edit. Do not put a CNAME at the apex of the domain - that is not allowed.

Does pointing a domain at my server give it a certificate?

Not for a game server, and it does not need one: game protocols do not use HTTPS. Certificates matter for web and app servers reached over HTTPS, where the proxy slot issues and renews one for you once the name resolves.