Handing players a raw 203.0.113.10:27015 is fragile: it is hard to remember, hard to type, and if your server ever changes IP every advert and forum post is suddenly dead. A domain fixes both problems — players connect to play.yourserver.net, and if the IP changes you update one DNS record instead of chasing every listing. GoldSrc resolves hostnames in the connect command, so this works with no client-side setup. Here is how to wire it up.
In your domain registrar or DNS provider, create an A record mapping a subdomain to your server's public IPv4 address:
Type: A Name: play (becomes play.yourserver.net) Value: 203.0.113.10 TTL: 3600
Use a subdomain like play or cs rather than the bare domain so you keep the root free for a website. Keep the TTL moderate (an hour); if you plan to move servers soon, drop it to 300 seconds a day ahead so the change propagates fast when you flip it.
Once DNS has propagated, the game resolves the name exactly like an IP. In the client console:
connect play.yourserver.net
The engine looks up the A record, gets 203.0.113.10, and connects to the default port 27015. This is the same connect flow as connecting via console — the only difference is a name in place of the number.
Here is the trap. DNS resolves names to IP addresses only — it carries no port. If your server runs on anything other than 27015, players must still append the port after the resolved name:
connect play.yourserver.net:27016
A plain A record cannot hide a non-default port. If you run several servers on one box (see multiple servers on one VPS), give each a memorable subdomain pointing at the same IP, and publish each with its port. Do not expect an SRV record to help here; the GoldSrc client does not consult SRV records for game connections, so the port must be in the connect string.
Set the in-game hostname and advertise the domain together so players associate the two:
hostname "YourServer.net | Classic CS 1.6"
Put the connect domain in your MOTD, GameTracker page, and Discord. When everything points at play.yourserver.net, a future IP move is a one-record edit rather than a re-advertising campaign.
If you host from a home connection, your ISP may hand you a dynamic IP that changes on reconnect — a static A record goes stale every time it moves. The fix is dynamic DNS: a small updater client on the host machine (or built into your router) watches the public IP and rewrites the A record automatically whenever it changes, so play.yourserver.net always tracks the current address. Many DNS providers support this on a subdomain. Home hosting has other trade-offs — upload bandwidth, NAT port-forwarding, and no DDoS filtering — but for a small server among friends, dynamic DNS keeps a memorable name working through IP churn without manual edits.
Filtered hosting often gives you a protected IP or hostname that fronts your real server. In that case the A record should point at the protected address, not your origin, or you defeat the filtering. See DDoS-protected hosting for how the proxy address relates to your origin; the domain always advertises the front, never the box behind it.
connect hangs then fails on the name but works on the IP — DNS has not propagated yet, or the A record has a typo. Wait for the TTL, then re-check the record value.From a machine that is not yours, resolve the name and confirm it returns your server IP, then run connect play.yourserver.net (with the port if non-default) and confirm you land on the server. Change the in-game map and confirm the domain still connects — it should, since nothing about the map affects DNS. Finally, simulate a move on paper: if you had to change IP, confirm you know exactly which one A record to edit. If that record is the only thing you would touch, the domain is doing its job.