By the end of this guide you'll have a domain name like example.com sending visitors and players to your own server, instead of an ugly raw IP address. We'll cover websites and game servers, including the SRV record trick that lets Minecraft players join without typing a port. This is written for beginners, so if you've never touched a DNS record before, you're in the right place.
What DNS records actually do
DNS is the phone book of the internet. People type a name they can remember, and DNS hands their computer the real address (an IP) where your server lives. When someone visits your site or connects to your game server, their device quietly asks a DNS server "where does this name point?" and gets back a number.
You only need to know a handful of record types to get started. Here's the short version.
| Record | What it points to | When you use it |
|---|---|---|
| A | An IPv4 address (like 203.0.113.42) | The main one. Points a name at your server. |
| AAAA | An IPv6 address (like 2001:db8::1) | Same idea as A, but for IPv6. |
| CNAME | Another name (an alias) | Make www point at your root domain, for example. |
| SRV | A host plus a port | Game servers, so Minecraft players skip the port. |
A record means address. A CNAME is just a nickname that says "go look up this other name instead." Keep those two straight and most of DNS makes sense.
Step 1: Find your server's public IP
Before you can point a name anywhere, you need the address you're pointing it at. This is your server's public IP, the one the outside world sees. It is not the 192.168.x.x address your home router hands out.
If you run a VPS or a game server through a panel, the IP is usually shown right in the dashboard. On the Bytte.cloud panel, for example, the server's address sits at the top of the console page. If you have SSH access to a Linux box, ask the server itself.
# Ask a public service what IP the world sees
curl -4 ifconfig.me
# Example output
203.0.113.42For an IPv6 address, run the same idea over IPv6.
curl -6 ifconfig.me
# Example output
2001:db8:85a3::8a2e:370:7334Write that number down. You'll paste it into the A record in a moment. If you only get an IPv4 result and no IPv6, that's fine. Plenty of servers run IPv4 only.
Step 2: Log in to your registrar or DNS host
Your records live wherever your domain's DNS is managed. Often that's the company you bought the domain from (Namecheap, GoDaddy, Porkbun, Cloudflare, and so on). Look for a section called DNS, DNS Management, or Advanced DNS. That's where you add and edit records.
One thing to check first. If your domain uses custom nameservers from a different provider (say you moved DNS to Cloudflare), you have to edit records there, not at the registrar. Editing records in the wrong place is the single most common reason changes seem to do nothing. The active nameservers win.
Step 3: Create the A record for your root domain
This is the heart of it. You're telling the world that example.com lives at your IP. In the DNS panel, add a new record with these values.
| Field | Value |
|---|---|
| Type | A |
| Name (or Host) | @ |
| Value (or Target) | 203.0.113.42 |
| TTL | 3600 (or Auto) |
The @ symbol means "the root domain itself," so example.com with nothing in front. Some panels want you to leave the name blank for the root instead of typing @. Both mean the same thing.
In raw zone file form, the record you just made looks like this.
; A record for the root domain
example.com. 3600 IN A 203.0.113.42If your server has IPv6 and you want to use it, add a matching AAAA record the same way. Same name (@), type AAAA, and your IPv6 address as the value.
example.com. 3600 IN AAAA 2001:db8:85a3::8a2e:370:7334Step 4: Point www at your domain with a CNAME
People type www out of habit, so you want www.example.com to work too. The clean way is a CNAME that aliases www back to your root domain. Then you never have to update two IPs if your server moves. Add this record.
| Field | Value |
|---|---|
| Type | CNAME |
| Name (or Host) | www |
| Value (or Target) | example.com |
| TTL | 3600 |
In zone file form.
www.example.com. 3600 IN CNAME example.com.One rule worth burning into memory. You cannot put a CNAME on the root domain (@) at most providers, because the root needs other records like MX for email and a CNAME would conflict. So the root uses an A record, and www uses a CNAME. Some hosts offer a workaround called CNAME flattening or ALIAS records, but for now, root gets an A and www gets a CNAME.
The same CNAME pattern works for subdomains. Want a panel at panel.example.com or a blog at blog.example.com? Add a record with that name pointing to an A record or another host. For a subdomain that lives on a different IP, just use an A record for it directly.
; A subdomain that lives on the same server
api.example.com. 3600 IN A 203.0.113.42Step 5: Understand TTL and why changes take time
TTL stands for time to live, measured in seconds. It tells other DNS servers how long they're allowed to cache your record before checking again. A TTL of 3600 means resolvers around the world may hold the old answer for up to an hour.
This matters when you change something. If you update an IP, anyone who looked up your domain in the last hour might still see the old address until their cache expires. There's no button that instantly fixes this everywhere. You wait it out.
A practical trick. If you know you're about to move servers, lower the TTL to 300 (five minutes) a day or two ahead of time. After the move settles, raise it back to 3600 or higher. Lower TTL means faster changes but slightly more lookups. For records that rarely change, a higher TTL is fine.
Step 6: Add an SRV record so Minecraft players skip the port
Game servers often run on a port that isn't the default. A Minecraft server might live on 203.0.113.42:25571 instead of the standard 25565. Without help, players would have to type the full address including that port. An SRV record hides the port so they can just type play.example.com and connect.
First, set up a normal A record for the host the SRV will point at. Then add the SRV record on top. Many panels split the SRV into separate fields, so here's how they map.
| Field | Value for Minecraft Java |
|---|---|
| Type | SRV |
| Service | _minecraft |
| Protocol | _tcp |
| Name | play (this becomes play.example.com) |
| Priority | 0 |
| Weight | 5 |
| Port | 25571 |
| Target | play.example.com |
The target is a name, not an IP, and that name needs its own A record pointing at your server's IP. Set that up alongside the SRV. In a raw zone file, the whole thing looks like this.
; A record the SRV points at
play.example.com. 3600 IN A 203.0.113.42; SRV record so play.example.com finds the real port
_minecraft._tcp.play.example.com. 3600 IN SRV 0 5 25571 play.example.com.The four numbers after SRV are priority, weight, port, and the closing target. Priority and weight only matter if you run several backend servers, so 0 and 5 are safe defaults. The important number is the port, 25571 here, which is the real port your server listens on. Now a player types play.example.com in their Minecraft client, with no port, and it just works.
A note for Bedrock Edition. Bedrock does not read SRV records, so console and phone players still enter the host and port separately. The SRV trick is a Java Edition thing.
Step 7: Check your work with nslookup or dig
Don't assume it worked. Verify it. Two tools do the job: nslookup (built into Windows, macOS, and Linux) and dig (the friendlier one on macOS and Linux).
Start with the A record.
dig example.com A +short
# Expected output
203.0.113.42If you don't have dig, nslookup works everywhere.
nslookup example.com
# Expected output
Server: 1.1.1.1
Address: 1.1.1.1#53
Non-authoritative answer:
Name: example.com
Address: 203.0.113.42Check the www CNAME too.
dig www.example.com CNAME +short
# Expected output
example.com.And the SRV record. This one is easy to forget how to query, so here it is in full.
dig _minecraft._tcp.play.example.com SRV +short
# Expected output
0 5 25571 play.example.com.The same query with nslookup needs the type flag.
nslookup -type=SRV _minecraft._tcp.play.example.com
# Expected output
_minecraft._tcp.play.example.com service = 0 5 25571 play.example.com.If those answers match what you typed into the panel, you're done. If they show old values or nothing at all, head to troubleshooting below.
Step 8: Query a specific resolver to see propagation
Your computer caches DNS, so it might show stale results even after the change has spread. To see what a fresh, public resolver thinks, point your query straight at one. Cloudflare is 1.1.1.1 and Google is 8.8.8.8.
dig @1.1.1.1 example.com +short
dig @8.8.8.8 example.com +shortIf both public resolvers return the new IP but your own machine still shows the old one, the change has propagated and your local cache just needs to clear. On Windows, flush it like this.
ipconfig /flushdnsOn macOS, run this instead.
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponderTroubleshooting
It still resolves to the old IP. Almost always caching. Check the record's old TTL, then wait that long. Query a public resolver with dig @1.1.1.1 example.com +short to see the real current state, and flush your local cache. If a public resolver still shows the old value after the TTL has clearly passed, you probably edited records in the wrong place. Confirm which nameservers are actually live with dig example.com NS +short and make sure you're editing DNS there.
Nothing resolves at all (NXDOMAIN). The name doesn't exist as far as DNS is concerned. Double check the record name. A common mistake is typing the full domain in the name field, which creates play.example.com.example.com by accident. In most panels the name field only takes the part before your domain, so use play, not play.example.com.
The website loads but with the wrong site or a default page. DNS is doing its job, so this is a server problem, not a DNS problem. Your web server (Nginx, Apache) needs a virtual host or server block configured for that domain name. DNS only delivers the visitor to the door. The server decides what to show.
Minecraft can't connect through the SRV name. Test the raw address first. If 203.0.113.42:25571 works but play.example.com doesn't, the SRV record is the issue. Verify it with the dig command from Step 7. The most frequent slip is the service and protocol prefix. It must be exactly _minecraft._tcp with the underscores, and the target must have a matching A record. Also remember Bedrock ignores SRV entirely.
Proxied versus DNS only (Cloudflare orange cloud). If your DNS is on Cloudflare, each record has a toggle. The orange cloud means proxied, where Cloudflare sits in front and your real IP is hidden. That's great for websites but it breaks game servers, because Minecraft and most game traffic don't go through Cloudflare's HTTP proxy. For a game server, set the record to DNS only (grey cloud). When proxied, a dig will return Cloudflare's IPs rather than your server's, which is expected and not a bug.
Email stopped working after changes. If you deleted or replaced records on the root, you may have removed MX records that handle mail. Email uses its own MX records, separate from your A record. Restore them from your mail provider's instructions if you wiped them by accident.
Wrapping up
That's the whole flow. Find your public IP, add an A record on the root, alias www with a CNAME, and use an SRV record when a game server needs to hide its port. Then verify everything with dig or nslookup instead of trusting that it worked. Give changes time to propagate based on the TTL, and when results look stale, query a public resolver to see the real picture. Once the records check out, your domain quietly does its job every time someone connects, and nobody has to remember a string of numbers again.
