Why trust this guide
By Victus Cloud · Reviewed by Victus Cloud · No individual author claimed. Verify paths, versions, and backups before changing a live service.
Evidence-led, product-agnostic
DNS is a phone book, slowly updated
DNS maps names like example.com to addresses and services. Changes propagate because resolvers around the world cache records for the duration of their TTL (time to live). This caching is why a correct edit can take minutes to hours to appear everywhere. Expect a delay after edits; a change that 'did not work' may simply not have propagated yet. Always confirm at multiple resolvers and from different networks before concluding something is broken.
Two mental models help. First, DNS answers questions: 'what IP is this name?' or 'where is the mail server for this domain?' Second, DNS is hierarchical and distributed, so no single edit is instantly global. When troubleshooting, think in terms of 'who is answering, and what are they caching?' rather than 'why isn't the internet updated yet?'
Don't point mail at your game server
MX records control email delivery. Pointing your root or mail host at an unrelated service can break delivery silently. Keep mail and application records deliberate and separate unless you intend to route mail through that system.
The record types you will meet
A small set of record types covers almost everything a game or VPS operator needs. Each has a distinct job, and confusing them is the most common cause of 'DNS is correct but nothing works' tickets. The table summarizes the essentials; the sections below add the cautions that matter in practice.
| Type | Maps to | Typical use |
|---|---|---|
| A | IPv4 address | Point a name at a VPS or service IPv4 |
| AAAA | IPv6 address | Same, for IPv6-enabled services |
| CNAME | Another name | Alias one hostname to a canonical name |
| SRV | Host and port for a service | Game or services needing port discovery |
| MX | Mail server name | Email delivery routing |
| TXT | Text | Verification, SPF, and policy records |
A and AAAA: the address itself
An A record points a name at an IPv4 address; an AAAA record does the same for IPv6. If your VPS or service exposes both, publish both so IPv6-capable clients use the modern path. If your plan does not expose IPv6, publishing an AAAA record that points nowhere will cause slow failures for IPv6 clients, so verify support first. The name in the record is relative to your zone—play means play.example.com within that domain.
CNAME: convenient, but with sharp edges
A CNAME aliases one name to another, so you can point www.example.com at a canonical target and maintain the address in one place. The sharp edge: a CNAME says 'this name is exactly that other name,' so it cannot coexist with other records at the same label. That is why most providers restrict CNAME at the zone apex (the root, example.com); use the provider's recommended alias or A/AAAA records there instead. Also, a CNAME target must be a name, never an IP address.
Lower TTL before big changes
Before a migration, reduce the TTL on the records you will change (for example to 300 seconds) so that when you cut over, the old value expires quickly. Raise it back afterward to reduce resolver load and improve caching.
SRV records for game services
Some game services use SRV records so clients can discover both the host and the port from a friendly name. An SRV record encodes priority, weight, port, and target—for example directing _minecraft._tcp.play.example.com to play.example.com on a non-default port. Only configure SRV when the specific software or client actually requires it; adding one for a service that ignores it does nothing but confuse future editors. When you do use it, the target must be a name with its own A/AAAA, not an IP.
_minecraft._tcp.play.example.com. IN SRV 0 5 25565 play.example.com.MX and TXT: don't let apps break mail
MX records tell the world where to deliver email for your domain; TXT records carry verification tokens and mail policies such as SPF. A frequent mistake is pointing the root or mail host at a game or web service, which silently breaks inbound mail. Keep MX records pointed at your real mail provider, and add TXT verification only where the service asks for it. After any DNS change, re-test mail delivery from an external account rather than assuming it works.
A careful pointing workflow
- Confirm the exact hostname you want (root, www, play, and so on).
- Set A and AAAA to the public address provided by the current plan; verify IPv6 support first.
- For aliasing, use CNAME to the canonical name rather than duplicating addresses.
- For game services that need port discovery, configure SRV only if the software requires it.
- Lower TTL before big changes so rollback is fast, then raise it afterward.
- Test from outside and allow propagation time before troubleshooting further.
If reachability fails after DNS looks correct, the problem is often the service not listening, a firewall blocking the port, or the address not matching what the plan exposed. DNS alone does not open ports. Confirm the application is running, the expected port is allowed, and the target address matches the one the panel shows before blaming the records.
Verify after propagation
Once TTL has elapsed, query from an independent resolver and from a player's network. A consistent answer everywhere means the record is live; a mismatch usually means you are still waiting on cache expiry somewhere.
Common mistakes that waste an afternoon
- Editing the wrong zone or a typo'd hostname that no one queries.
- Forgetting that the apex often cannot be a CNAME.
- Publishing an AAAA with no IPv6 path, causing slow IPv6 failures.
- Pointing MX at a host that is not a mail server.
- Changing TTL only after the incident, when caches are already long.
The honest summary
DNS is simple in concept and unforgiving in practice. Know what each record type does, change TTL early, separate mail from application records, and verify from the outside after propagation. Done carefully, pointing a domain at your service is a five-minute task; done carelessly, it becomes a day of 'it works for me but not for them.'