Halloween at Nexthosting: 10% off game servers with the code – until November 1
Learn how to set up a domain for your game server correctly. Configure A and SRV records for optimal availability and performance.
In short: you set an A record pointing to your server's IP. If your service uses a non-standard port, you add an SRV record as well. Writing a port directly into the A record does not work technically. After that, you need patience, because DNS changes do not take effect immediately.
play) points to the server IP.play, mc, and ts have become established conventions.Set the A record first, then test with nslookup, and add SRV only if your client actually queries it.
An A record pointing to the server IP is the foundation of every game server domain, while an RFC 2782-compliant SRV record is only additionally required for non-standard ports and supporting clients.
| Topic | Details |
|---|---|
| A record as the basis | A subdomain like play or mc points directly to the server's IPv4 address. |
| SRV only when needed | Required for non-standard ports, but only if the client supports SRV lookups. |
| Lower the TTL before changes | Reduces the window of DNS propagation, which can take up to 24 hours. |
| Plan for DNSSEC | Protects DNS records from spoofing, especially relevant for communities with their own economy. |
| Choose a provider with full DNS access | Nexthosting combines domain, server, and DNS management in one control panel. |
For registering a domain for your game server, two record types are enough in most cases: A and SRV. The rest is additional equipment that you should know about but rarely need day to day.
An A record points to an IPv4 address. This is the basis for practically every game server domain: play.deinedomain.de points to 1.2.3.4, done. If your server uses IPv6, you additionally need an AAAA record that points to the IPv6 address. Many hosts now assign both in parallel, because some clients prefer IPv6 as soon as it is available.
CNAME records do not point to an IP but to another hostname. Handy, but with an important restriction: a CNAME must never be set on the root domain (deinedomain.de without a subdomain) if other records such as MX exist there. For subdomains, however, it is unproblematic.
SRV records are the real key for game servers. They map a service to a hostname plus port, following the structure defined in RFC 2782. An SRV entry for Minecraft looks different from one for TeamSpeak, but the principle stays the same: the client queries the service name and gets back a hostname and port, without you having to worry about port numbers in the URL.
TXT records are used for verification, for example for domain ownership checks or email authentication. They are irrelevant for game access itself, just like MX records, which only concern email routing. You can ignore them as long as you do not run email addresses on the domain.
With most registrars, the setup takes less than five minutes if you know where to click.
play, mc, or server.nslookup play.deinedomain.de or simply use ping to check whether the correct IP comes back.Before you change an existing record, it is worth lowering the TTL shortly beforehand. This shortens the window in which DNS propagation causes delays, and you see sooner whether your change has arrived. If you are planning the registration of a new domain, you can create the DNS zone right in the same control panel.
Pro tip: If the domain does not work after the change, try connecting directly via IP:port. If that works, the problem is definitely with DNS, not with the server itself.
The standard case for Minecraft is unspectacular: if your server runs on the default port 25565, a simple A record is enough.
play.example.com A 1.2.3.4
Players then simply enter play.example.com without a port, because 25565 is the expected default. But if your server uses a different port, such as 25577, things get interesting. In that case, you can add an SRV record so that players can still connect without specifying a port.
_minecraft._tcp.play.example.com 0 5 25577 server01.example.com
The four values after the name are priority, weight, port, and target host. For a single server, priority and weight almost always stay at 0 and 5, as common SRV tutorials show. The target host must resolve via its own A record or AAAA record; according to the guides in common DNS documentation, a direct IP entry in the SRV field is not sufficient.
| Field | Example value | Meaning |
|---|---|---|
| Priority | 0 | Order when there are multiple targets |
| Weight | 5 | Load distribution at equal priority |
| Port | 25577 | Actual server port |
| Target | server01.example.com | Must resolve via an A record |
After the change, it is best to test on a second device whether the connection works without a port. For a Minecraft server with ready-made infrastructure, this configuration can usually be done directly in the control panel, without any manual DNS line.
Not every service needs an SRV record, and that is a good thing, because not every client queries it.
_ts3._udp.ts.example.com 0 5 9987 server01.example.com.A common mistake: users try to put the port and IP directly into a single record. That does not work. RFC 2782 requires a hostname as the target, never an IP address or a port literal directly in the target field.
0 and 5 in simple setups.The target host of an SRV record is not free text. It must actually exist and be resolvable via DNS itself, otherwise the whole chain leads nowhere, no matter how correctly the priority and port are entered.
Once you have understood this, you will rarely make mistakes in future configurations.
When you have connection problems, a fixed order of checks is worth following instead of randomly changing settings.
nslookup or dig show whether the domain returns the correct IP at all. Keep the TTL in mind; propagation can take up to 24 hours.IP:port instead of the domain. If that works, the problem is with DNS, not the server.Pro tip: Write down the current values before every DNS change. That way you can roll back within seconds instead of spending a long time searching for what was entered before.
When registering a domain for game servers, a good provider takes some of the sources of error off your hands, simply because the control panel does not allow typical pitfalls in the first place. Nexthosting offers servers located in Germany, DDoS protection, and a control panel in which DNS records can be managed clearly, without you having to click through multiple menu levels.
If you already run a server at Nexthosting, you can register the matching domain right alongside it and do not have to juggle two separate management interfaces.
A domain like deinprojekt.de is the standalone, registered address that you pay for at a registrar. A subdomain like play.deinprojekt.de is a part of it that you can create as often as you like and free of charge, without registering another domain.
For game server operators, this is a crucial point: you usually only need a single domain to run multiple servers or services. If your Minecraft server runs at mc.deinprojekt.de and your TeamSpeak at ts.deinprojekt.de, both share the same domain but have separate DNS records and can even be on different IPs.
This pays off especially when a community grows. If you start with a Minecraft server, a Rust server or a FiveM project may join later, and each of them simply gets its own subdomain instead of you having to buy a completely new domain. The root domain itself can be used in parallel for a project website or a forum, without the services interfering with each other.
Some operators use multiple domains for different projects instead, for example when brands are meant to stay separate. Technically, both are possible, but for most individual projects, one domain with cleanly named subdomains is entirely sufficient, and in the long run it saves both administrative effort and ongoing costs for additional registrations.
The choice of domain provider helps determine how easily you can manage SRV records and A records later. Not every panel is equally accessible, and you only notice this when you need an unusual record for the first time.
Important criteria for the selection:
Registering a new domain directly with the hosting provider saves exactly this additional step: you create A and SRV records in the same panel in which your server runs, without switching between two customer accounts. For community projects where several admins need access, it is also worth looking at permission levels in the panel, because not every co-admin should automatically be able to change the entire DNS zone.
DNSSEC cryptographically signs your DNS records and prevents attackers from injecting forged responses into the resolution process, for example through so-called DNS spoofing or cache poisoning. Without DNSSEC, a querying system trusts the first response it receives, regardless of whether it is genuine or manipulated.
For game server operators, this is more relevant than it might first sound. If a DNS response is forged, players may end up on a completely different server without noticing, for example in a phishing attempt that impersonates your server. Especially for communities with their own economy or login systems, this is a real risk.
Activation takes two steps: first you enable DNSSEC in the zone at your DNS provider, then you store the so-called DS record with the registrar of your domain so that the parent zone trusts the signature. Not every registrar supports this automatically, so it is worth taking a quick look at the provider's documentation before you buy.
One drawback remains: DNSSEC makes DNS responses larger and more complex, which in theory can lead to compatibility problems with very old systems. For the vast majority of modern setups, especially with standard game servers, this is no longer a practical obstacle. Anyone who already runs their own domain for their server should plan DNSSEC in as an additional layer of protection, not as an optional extra for later.
Anyone who runs a game server from home knows the problem: the internet provider does not assign a fixed IP but a dynamic one, which can change every few hours or with every router restart. An A record you entered once thus becomes invalid overnight, and players end up nowhere.
The solution is called DynDNS. A small client program or a router function automatically reports every IP change to a DynDNS service, which then updates the associated DNS record. Your subdomain therefore stays stable, even if the IP behind it changes several times a day.
Important here: the TTL for a DynDNS record should be significantly lower than for a static A record, often in the range of 60 to 300 seconds, so that changes reach players quickly instead of only becoming visible after hours. Many routers, from Fritz!Box to various other models, come with a native DynDNS function, so no separate additional program needs to run.
By contrast, if you use a rented server from a host, you usually do not have this problem at all, because fixed IP addresses are standard there. This is one of the underrated advantages of a rented server over a home server: you save yourself the entire DynDNS configuration and the additional source of error that comes with it, especially when your home internet connection is already under load.
A good domain name for a game server is short, easy to remember, and can be spelled out in voice chat without anyone having to ask again. It sounds trivial, but it is the point where many projects already fail, because the name is too complicated to pass on verbally among players.
A few practical guidelines:
play, mc, or ts signal right away what it is about, and thereby make it easier for the community to accept it.The top-level domain plays a smaller role than many assume. .de looks reputable and local, while .net or .gg have also become established in the gaming scene. More important than the extension is that the name fits the project and still sounds just as good in a year as it does today, because changing domains after building a community is always painful.
Most tutorials on this topic treat SRV records like an optional extra, a nice bonus for advanced users. That falls short. Anyone who runs a Minecraft or TeamSpeak server on a non-standard port without setting up SRV forces every player to remember the port number and type it in correctly. That is not a small detail; it is the difference between a community that grows and one that loses out at the first technical hurdle.
The real weak point lies elsewhere, namely in the order of steps. Many operators change DNS records without a second thought and without lowering the TTL beforehand, and then wonder for days about players who still end up on the old IP. That is no mystery, just plain impatience paired with a lack of planning. If you are planning a migration, lower the TTL days in advance, not hours.
And one point that is completely underestimated: DNSSEC. For communities with their own economy, logins, or payment processing, going without it is a real but avoidable risk that hardly anyone plans for, because it feels technically more complex than it actually is. If you are setting up a domain today for a project that is meant to grow over months, you should think about DNSSEC from the start, not only when something has gone wrong.
— Erik
If you register the domain with one provider and rent the server from another, you juggle two control panels, two support contacts, and, when in doubt, two different ideas of what an SRV record should look like. Nexthosting combines domain registration, server operation, and DNS management in a single customer account, so you maintain A records, SRV entries, and TTL values in the same place where your server runs.
This pays off especially for Minecraft projects, where a Minecraft server at Nexthosting can be connected directly to a matching domain, without a detour via a third provider. The same principle also applies to Garry’s Mod, FiveM, or Rust: servers located in Germany, DDoS protection, and a control panel that does not treat DNS records as an afterthought.
If you are only just planning to set up your own domain for your server, take a look at domain registration at Nexthosting and check whether your desired name is still available. It takes just a few minutes, and you save yourself a later move between two providers.
What matters most is DDoS protection, a server location in Germany, and a control panel with full DNS access. Nexthosting offers exactly this combination for Minecraft, FiveM, Garry’s Mod, and other titles.
Your Minecraft server uses the static IPv4 address that your hosting provider assigns to you, and you enter it in the A record of your subdomain. For dynamic home connections, you need a DynDNS solution instead to compensate for the changing IP.
You rent a server from a hosting provider, set up your game on it, and then connect a domain or subdomain to the assigned IP using an A record. For titles like Minecraft or Rust, providers such as Nexthosting offer ready-made server environments including a control panel.
A good domain name is short, has no hyphens, and is easy to pass on verbally, for example in voice chat. Established subdomain conventions like play or mc signal the purpose right away and make it easier for new players to get started.
No, only if your service uses a non-standard port and your client actually supports SRV lookups. If your server runs on the default port, a simple A record is completely sufficient.