DNS records explained: A, CNAME, SRV, TXT, MX and TTL

DNS is a lookup table with a cache in front of it, and nearly every confusing thing about it is the cache. The records themselves are simple, there are only about six you will ever create, and the rules that catch people out can be counted on one hand: a CNAME cannot live at the apex, an MX record cannot hold an address, a TTL you set today only takes effect after the old one expires, and "propagation" is not a process that happens to your change - it is other people's caches going stale at their own pace.

This post covers what each record does, the exact form it takes, how a resolver finds it, and the commands that tell you the truth when a web interface says the record is saved and nothing works.

How a lookup actually works#

When something needs the address for play.example.com, four different machines are usually involved, and knowing which one has your answer is most of the diagnosis.

The stub resolver in your operating system does no real work. It asks whichever resolver it was configured with, usually by DHCP, and caches the answer briefly. Browsers keep a cache of their own on top of that, which is why a page can keep resolving to the old address after you have flushed everything else.

The recursive resolver - your ISP's, or a public one like 1.1.1.1 or 8.8.8.8 - does the actual chasing. If it already has the answer within its TTL, it returns that and nothing else happens; this is the case in the overwhelming majority of lookups, and it is also why your change appears to be ignored.

The root and TLD servers hold delegations rather than answers. The root knows which servers run .com; the .com servers know which nameservers are authoritative for example.com. Neither has ever heard of play.

The authoritative nameservers hold your zone: the actual records you typed. Whatever they say is the truth. Everything upstream is a copy with an expiry date on it.

Two consequences worth holding on to. A change you make is live at the authoritative servers immediately - there is no queue and no distribution step. And a resolver that has a cached answer will not ask again until its TTL runs out, no matter how right you are.

The record types, and what each is for#

A and AAAA are the ones you will create most. They map a name to an address, and a name can have several of each - a client picks one, usually the first it is given, and the order rotates. This is the crudest form of load balancing and it has no health checking whatsoever: if one of the addresses is down, some fraction of your visitors get an error.

CNAME says "this name is really that name". A resolver that finds one restarts the lookup on the target. It is useful for pointing www at your apex, or a subdomain at a provider's hostname so they can change the address underneath without telling you. Its rules are the topic of the next section because they cause more trouble than everything else combined.

MX points at a hostname with a priority number, lowest preferred. Two rules, both broken constantly: the target must be a hostname, never an IP address, and that hostname must have an A or AAAA record and must not itself be a CNAME. MX is also the record that never has anything to do with your game server. Mail is a separate service on a separate machine, and RE:NODE does not host email at all - if you need it, that is a different provider and its records live alongside your others. SPF, DKIM and DMARC explained covers the TXT records that decide whether your mail is believed.

TXT is arbitrary text, which is why it has accumulated so many jobs. Domain ownership verification for Google, Microsoft and dozens of others; SPF as a string starting v=spf1; DKIM public keys under a selector at selector._domainkey.example.com; DMARC policy at _dmarc.example.com. Only one SPF string may exist per name - two of them is a configuration error that silently fails mail authentication rather than producing an error anywhere you will see it.

SRV packs a service, protocol, host, port, priority and weight into one record, which is how a Minecraft address hides a non-standard port. The name has a fixed shape with leading underscores, _minecraft._tcp.play, and the target must be a hostname with its own A record. SRV records for Minecraft takes every field apart and shows the dig commands that prove it works.

CAA is the one people meet by accident. It lists which certificate authorities may issue for your domain, and if you have CAA records that do not include the authority your host uses, certificate issuance fails with an error that mentions CAA somewhere in the third paragraph. Most domains have no CAA records, which means any authority may issue, which is the default and is fine.

CNAME, and why it cannot live at the apex#

The rule is older than most of the internet people use it on: a name that has a CNAME may have no other records. Not an MX, not a TXT, not an NS record. The CNAME is the whole answer and a resolver is supposed to follow it rather than look for anything else.

Your apex - example.com with no subdomain - is required to have an SOA record and NS records, because that is what makes it a zone at all. So it can never have a CNAME. Every DNS provider enforces this, and the error message is usually unhelpful.

The workarounds, in the order you should try them:

1. Use an A record at the apex and point it at the address. Simple, correct, and it means you have to edit it if the address changes.
2. Use your provider's ALIAS, ANAME or CNAME flattening. These are not real record types. The provider resolves the target for you and serves the result as an A record, refreshing it in the background. Cloudflare calls it flattening and does it automatically for a CNAME at the apex; Route 53 calls it an alias record; others call it ANAME. It works well and it only works at the provider that implements it, so it does not survive a move.
3. Do not use the apex. Put the service on www or on a subdomain and redirect the apex to it with an HTTP redirect from something that can answer on the apex. www versus apex domain and redirects covers which one to pick as your canonical host and why it matters more for a website than it feels like it should.

The second rule that follows from the same restriction: a CNAME cannot sit next to a TXT record for the same name. If a service asks you to add a verification TXT at www and www is already a CNAME, one of the two has to move.

TTL, caching and the propagation myth#

TTL is a number of seconds attached to every record. It tells a resolver how long it may keep the answer before asking again. That is the whole mechanism.

The trap is that lowering a TTL does not take effect until the old TTL expires. If your record has been sitting at 86400 and you drop it to 300 an hour before a migration, resolvers that already have the answer will keep it for the rest of their day regardless. Lower the TTL at least one old-TTL period before you need it, which usually means the day before.

There is a second cache most people never hear about. When a resolver asks for a name that does not exist, it caches that "does not exist" answer too, for a length of time taken from the zone's SOA record rather than from any record you created. This is why a name you just created can keep returning NXDOMAIN for several minutes after everything is correct - you tested it before you created it, and you are being served your own negative cache.

"Propagation" is the wrong word for all of this and it does real harm, because it suggests a process with a progress bar. Nothing propagates. Your authoritative servers are correct the instant you save, and every stale answer in the world is a cache somewhere counting down its own timer. The practical difference: there is nothing to wait for at your provider, and there is nothing you can do to speed up somebody else's resolver.

Registrar, nameservers and DNS host are three roles#

A great deal of confusion comes from three separate jobs that the same company often performs.

• The registrar is who you buy the domain from and who holds the registration. Their only DNS involvement is storing which nameservers are authoritative.
• The DNS host runs those nameservers and holds your records. This is where you create an A record. It is often the registrar, and it does not have to be.
• The web or game host runs the server the records point at. This is usually a different company, and it usually has no DNS interface at all.

RE:NODE is the third of those and only the third. There is no zone editor in the panel, no domain registration and no email hosting - you create the records at whoever runs your DNS, and point them at the address shown on the server's page. Nameservers versus DNS records covers moving one of the three without disturbing the other two, which is a job people get wrong roughly once per domain.

Changing nameservers is a different operation from changing a record, and a slower one. The delegation lives at the TLD and often carries a TTL measured in days. Copy every existing record into the new provider before switching, not after, so that resolvers arriving at either set of nameservers get the same answers during the overlap.

The records for a game server and for a website#

For a game server, the whole job is usually two records or one.

node       300  IN  A     203.0.113.10play       300  IN  CNAME node.example.com._minecraft._tcp.play  300  IN  SRV  0 5 25571 node.example.com.

An A record holds the address. A CNAME gives it a friendlier name, so that moving the server is one edit in one place. An SRV record, for Java Minecraft only, lets players omit the port. Nothing else is involved: no MX, no TXT, and no proxying. If your DNS provider offers an HTTP proxy - Cloudflare's orange cloud is the one everybody meets - it must be off for any record a game client will use, because it proxies HTTP and HTTPS and nothing else. Cloudflare for websites and game servers is specific about where the line falls.

For a website, the shape is:

@     3600  IN  A     203.0.113.20www   3600  IN  CNAME example.com.@     3600  IN  TXT   "v=spf1 -all"@     3600  IN  CAA   0 issue "letsencrypt.org"

The @ means the apex. The -all SPF record on a domain that sends no mail is a small kindness to everybody, because it tells receiving servers that nothing claiming to be from you is genuine. The CAA record is optional and only worth adding if you know which authority issues your certificates.

Order matters when a certificate is involved. The record must resolve to the server before issuance is attempted, because the validation works by the authority connecting to the name. Your domain and its certificate sets out the sequence, and connecting a domain to a game server does the same for the game case. If you expect several servers, give each one its own name from the start - subdomains for servers explains why that is easier than retrofitting it later.

Checking a record with dig and nslookup#

Never trust a provider's record list as evidence that a record is published. Ask a resolver.

# The short answer from your default resolver$ dig +short A play.example.com203.0.113.10# Ask a specific public resolver, bypassing your ISP's cache$ dig @1.1.1.1 +short A play.example.com# Ask the authoritative servers directly, removing every cache$ dig +trace play.example.com$ dig NS example.com +short# Other types$ dig +short MX example.com$ dig +short TXT _dmarc.example.com$ dig +short SRV _minecraft._tcp.play.example.com# The TTL as it is right now, counting down in a cache$ dig A play.example.com | grep -A1 'ANSWER SECTION'

On Windows without dig, nslookup -type=MX example.com 1.1.1.1 does the same job, and naming the resolver on the end is the important part. Querying 1.1.1.1 explicitly tells you what a stranger sees; querying your own default tells you what your router cached.

Reading the status line in a full dig response saves a lot of guessing:

• NOERROR with an empty answer means the name exists but has no record of that type. You created an A record and asked for AAAA, or you asked for SRV on a name that only has A.
• NXDOMAIN means the name does not exist. A typo, or the zone appended twice, or you are inside the negative cache window.
• SERVFAIL usually means a broken or unreachable nameserver, or a DNSSEC validation failure. It almost never means the record is wrong.
• REFUSED means the server you asked is not authoritative and will not recurse for you.

To flush your own caches when you need a clean test: ipconfig /flushdns on Windows, sudo dscacheutil -flushcache followed by sudo killall -HUP mDNSResponder on macOS, and resolvectl flush-caches on systemd Linux. Chrome keeps its own at chrome://net-internals/#dns, which is why the browser can be wrong after everything else is right.

Why your change has not applied#

In rough order of how often each one is the answer:

1. Something is still holding the old record. Your resolver, your router, your operating system or your browser, for as long as the previous TTL allowed. Test against 1.1.1.1 to see the truth.
2. The name was appended twice. Most web interfaces take a relative name, so typing play.example.com in the host field produces a record for play.example.com.example.com. Look at an existing record to see which convention the form uses. This is invisible in the record list unless you read carefully.
3. You edited the zone at a provider that is not authoritative. The nameservers at the registrar point somewhere else, often at a host you left months ago. dig NS example.com settles it in one line.
4. You are inside the negative cache. You checked before creating it, got NXDOMAIN, and the resolver is entitled to remember that for the SOA's minimum.
5. The record is right and the service is down. DNS pointing at a closed port looks exactly like DNS not working. Test the port separately - game server ports explained covers doing that from outside.
6. A proxy is in the way. A proxied record hands out the proxy's address, not your server's, which is correct for HTTP and fatal for anything else.

The routine that avoids all of this on a planned change is dull and works: lower the TTL a day ahead, wait out the old one, make the change, verify with dig against a public resolver, and leave the old destination running for a few hours. Moving a server without losing players has the rest of it.

FAQ#

How long does a DNS change take to work?

At your provider, instantly. For anyone who already looked up that name, up to the length of the old TTL. A brand new name with nothing cached anywhere usually works within seconds, which is why creating a record feels faster than changing one.

Why can I not put a CNAME on my root domain?

Because a name with a CNAME may have no other records, and the root of a zone must have SOA and NS records. Use an A record instead, or your provider's ALIAS, ANAME or CNAME flattening feature if it has one.

What is the difference between a nameserver and a DNS record?

Nameservers are the machines that answer questions about your domain, set at the registrar. Records are the answers they give, created at whoever runs those nameservers. Changing nameservers moves the whole zone; changing a record edits one answer.

Do I need an MX record for my game server?

No. MX records are for mail and nothing else, and mail should never be directed at a game server. If you have MX records pointing at a mail provider, leave them alone while you change the A record for your server.

What TTL should I use?

3600 seconds for normal running, dropped to 300 the day before a planned change and put back afterwards. Use 60 only for dynamic DNS, where the address genuinely changes without warning.

How do I check a record without waiting for a cache?

Query a public resolver by name with dig @1.1.1.1 +short A example.com, or go straight to the authoritative servers with dig +trace. Both bypass whatever your own network has remembered.