Pointing a domain at your server

To reach your server by name instead of by IP address you add one DNS record, at whichever provider currently answers for the domain. When it does not work it is almost always one of two things: the record was added in the right form in the wrong place, or it was added correctly and something is still holding the old answer.

The records you need

A record

Maps a name to an IPv4 address. This is the one you want for a server.

That makes play.example.com resolve to 203.0.113.10. Your server's address is on its own page in the panel, described in Networking and IPs.

AAAA record

The same thing for an IPv6 address. Add one only if the server genuinely answers on that address, because a client with working IPv6 will try the AAAA first. A stale or wrong AAAA record produces failures that look random: it works for some people, fails for others, and works for everyone the moment IPv6 is disabled, while your A record tests perfectly throughout.

CNAME record

Points one name at another name, never at an address. It is for following something that moves, such as a hostname your provider gives you. Three rules catch people out:

• A CNAME cannot coexist with any other record on the same name. If play has a CNAME it cannot also have an A record, a TXT record, or anything else.
• It cannot be used at the zone apex, meaning the bare example.com with no subdomain in front. Some providers offer their own workaround for this under a name like ALIAS, ANAME, or CNAME flattening, which is not a standard record type and behaves slightly differently at each of them.
• Every lookup follows the chain to the end, so if the target's address changes, your name follows without you touching anything. That is the only reason to use one.

None of these carry a port number

A record points at a machine. It cannot point at a port, so if your service is not on the default port, players still have to type the name and the port together. The one exception worth knowing is Minecraft Java, whose client looks up an SRV record at _minecraft._tcp in front of the name and will use the port it finds there. That is a feature of that game client, not of DNS generally, and no other common game does it.

TTL, and what propagation really means

Every record carries a TTL, a number of seconds. Any resolver that looks your name up keeps the answer for that long and does not ask again until it expires.

So nothing propagates. There is no push, no broadcast, and no queue. The moment you save a change, the authoritative nameservers give the new answer to anyone who asks. Everyone else keeps the answer they already have until their copy runs out. What people describe as propagation is a lot of separate caches expiring at different moments.

That has three practical consequences:

• The wait after a change is governed by the old TTL, not the new one. If the record had a TTL of 86400, some resolvers will hold the old address for up to a day, and lowering the TTL at the same time as the change does nothing for them.
• Different people switch over at different times, depending on when their resolver last asked. One player being on the new address and another still on the old one is normal for the length of the old TTL, not a fault.
• Your own machine caches separately from your resolver, and some applications cache separately again and ignore the TTL entirely.

Pointing the domain at your server

1. Find out who actually answers for the domain

   This decides everything else. Ask for the domain's nameservers:

   ShellCopy

   dig NS example.com +short

   Copy

   nslookup -type=NS example.com

   Whatever comes back is where DNS for that domain is edited. It is often not the company you bought the domain from.

2. Sign in to that provider

   Not the registrar, unless the nameservers above belong to the registrar. Open the DNS or zone editor for the domain.

3. Add the record

   Type A, name the subdomain only, value the server's IPv4 address, TTL 300 while you are testing. Providers differ on how the root of the domain is written: most use @, some want the field left blank, and a few want the full domain name. Follow the convention of the one you are in.

4. Check it before telling anyone

   Use the commands in the next section. Query a public resolver as well as your own, so you are not reading your own cache back.

5. Connect by name

   Use the name in place of the IP address, keeping the port if the service needs one. If the name resolves correctly and the connection still fails, DNS has done its job and the problem is elsewhere.

Checking it

dig, on macOS and Linux

dig is preinstalled on macOS. On Linux install dnsutils on Debian and Ubuntu, or bind-utils on Alma, Rocky, and RHEL.

The short answer:

dig A play.example.com +short

The same answer with its TTL, which tells you whether you are looking at a cached copy and how long it has left:

dig play.example.com A +noall +answer

play.example.com.	287	IN	A	203.0.113.10

That 287 is the seconds remaining on the cached copy. Run it twice a few seconds apart: if the number is counting down, you are being served from a cache. If it resets to the full TTL each time, you are getting a fresh answer.

Ask a public resolver instead of your own, which is the quickest way to tell a local cache apart from a real problem:

dig A play.example.com @1.1.1.1

Follow the delegation from the root servers, ignoring caches on the way:

dig +trace play.example.com

Use AAAA in place of A to check the IPv6 record, and NS to check the delegation.

nslookup, on Windows and everywhere else

nslookup play.example.com

nslookup -type=AAAA play.example.com

nslookup -type=NS example.com

nslookup play.example.com 1.1.1.1

The last form asks a specific resolver, which is the equivalent of dig with an @ server. Non-authoritative answer in the output is normal and is not an error: it means the answer came from a cache rather than from the domain's own nameservers.

PowerShell has a more readable version that also shows the TTL:

Resolve-DnsName play.example.com -Type A -Server 1.1.1.1

Clearing your own cache

ipconfig /flushdns

sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

sudo resolvectl flush-caches

Windows, macOS, and Linux with systemd-resolved. This clears your machine only. It does nothing for your players, and it does nothing to your ISP's resolver.

The mistakes that cause most of it

Editing DNS at the registrar while the nameservers point somewhere else

The most common failure by a wide margin. Buying a domain at one company and using another company's DNS is completely normal, and both of them will show you a DNS editor with your records in it. Only the one the NS records point at is being asked anything.

The symptom is a record that looks perfect in the panel while dig keeps returning the old value, or nothing at all, no matter how long you wait. The check is the NS query in step 1 above. Edit at whichever provider that query names, and ignore the other editor entirely.

Expecting an instant change after a long TTL

Defaults of 3600 or 86400 seconds are common, so an hour or a day is the honest answer to "how long until it changes". Immediately after a change, dig +trace or a query against a public resolver will show the new value while your own machine still shows the old one. Both are correct at the same time and neither is broken.

If you cannot wait, the only real lever is the one you no longer have: the TTL that was in force before you made the change.

The name field doubling the domain

Entering play.example.com in a name field that wants only play creates play.example.com.example.com. The record exists, it is not where you think. If a lookup for your name fails but the doubled version resolves, that is the cause.

An old AAAA record left in place

Covered above, and worth checking specifically whenever a name works for some people and not others.

Assuming DNS opened something

A record maps a name to an address. It does not start a service, open a port, or change anything about the server. Once the name resolves to the right address, DNS is finished, and a connection that still fails is a question for the server or the rules in front of it. See When players cannot connect.

Related