DNS record types, A, AAAA, CNAME, MX, SRV, TXT, and the rest

Field note. An A record points your hostname at your server. An SRV record lets Minecraft skip the port. A TXT record proves you own the domain to mail providers. Knowing four record types covers most of what you'll touch.

If you've ever logged into a DNS provider's panel, you've seen a dropdown with twenty types of records. This article explains the ones you'll actually use, with examples of when each is appropriate.

The mental model

A DNS record is a tuple of:

• Name (play.myserver.com)
• Type (A, AAAA, CNAME, etc.)
• Value (an IP, a hostname, some text, etc.)
• TTL (how long it can be cached)

When a resolver looks up a name with a specific type, it gets back records of that type for that name.

Most names have multiple records, of multiple types. myserver.com likely has:

• A records (IPv4 addresses)
• AAAA records (IPv6 addresses)
• MX records (email server)
• TXT records (verifications, SPF, DKIM)
• NS records (nameservers, set at the parent zone)
• CAA records (cert issuance restrictions)

A: the basic record

play.myserver.com.   3600   IN   A   203.0.113.42

Reads: "the name play.myserver.com points to IPv4 203.0.113.42, cacheable for 3600 seconds."

This is the most common record type. Used for any service reachable over IPv4. Web servers, game servers, mail servers, anything.

You can have multiple A records for the same name:

play.myserver.com.   A   203.0.113.42
play.myserver.com.   A   203.0.113.43

Resolver returns both. Client picks one (often round-robins). Crude load balancing.

AAAA: the IPv6 record

play.myserver.com.   3600   IN   AAAA   2001:db8::1

Same idea, IPv6 address instead. The four As represent the four times longer address.

Modern clients prefer AAAA when available (Happy Eyeballs algorithm: try IPv6 first, fall back to IPv4 quickly if it doesn't work). If your service supports IPv6, add an AAAA record alongside the A. Many services skip this; they shouldn't.

A name can have both:

play.myserver.com.   A      203.0.113.42
play.myserver.com.   AAAA   2001:db8::1

Client uses whichever the network supports.

CNAME: the alias

www.myserver.com.   3600   IN   CNAME   myserver.com.

Reads: "www.myserver.com is an alias for myserver.com." Resolvers follow the alias and return whatever records myserver.com has.

Uses:

• Sub-domain aliases (www.x.com → x.com).
• Pointing at managed services (app.mycompany.com → mycompany.herokuapp.com).
• Vanity URLs that should follow the real service.

Rules:

• A CNAME's target can be any name (yours or someone else's).
• A name with a CNAME cannot also have other records. So www.example.com can't be a CNAME and have an MX record. The whole name follows the CNAME.
• CNAME at the apex (example.com itself) is forbidden by the DNS spec. Some DNS providers offer workarounds (ALIAS, ANAME records).

The non-apex rule is the biggest gotcha. If you want example.com to "point to" something dynamic, you usually need either:

• The provider's apex-CNAME extension, or
• Just put A/AAAA records directly with the actual IPs.

MX: mail exchanger

myserver.com.   3600   IN   MX   10   mail.myserver.com.

Reads: "to deliver email to anyone @myserver.com, send to mail.myserver.com, with priority 10."

The priority lets you have multiple MX records:

myserver.com.   MX   10   mail1.myserver.com.
myserver.com.   MX   20   mail2.myserver.com.

Senders try priority 10 first. If unreachable, fall back to priority 20. Lower number = higher priority.

The target of an MX record must be a hostname (with A or AAAA records), not an IP directly. This is a DNS quirk.

If you don't host your own email, your MX records typically point at your email provider:

myserver.com.   MX   10   mx1.yourmailprovider.com.
myserver.com.   MX   20   mx2.yourmailprovider.com.

Your email provider gives you the exact records to add.

TXT: arbitrary text

myserver.com.   3600   IN   TXT   "v=spf1 include:_spf.google.com ~all"

TXT records hold arbitrary text. Originally intended for human-readable notes; now used heavily for machine-readable verification and configuration.

Common uses:

SPF (Sender Policy Framework): list which servers are allowed to send email from your domain.

"v=spf1 include:_spf.google.com ~all"

DKIM (DomainKeys Identified Mail): public key used to verify email signatures.

"v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEB..."

DMARC: policy for how mail receivers should handle email that fails SPF/DKIM.

"v=DMARC1; p=reject; rua=mailto:[email protected]"

Domain verification: third-party services often ask you to add a specific TXT record to prove you own the domain.

"google-site-verification=abc123xyz"
"_acme-challenge=letterencrypted-cert-challenge"

A name can have many TXT records. Each is independent.

SRV: service locator

_minecraft._tcp.play.myserver.com.   3600   IN   SRV   0 10 25577 origin.myserver.com.

Reads (longest one yet): "for the Minecraft TCP service under play.myserver.com, with priority 0, weight 10, on port 25577, find the actual host at origin.myserver.com."

SRV records solve a specific problem: a hostname like play.myserver.com doesn't include a port. For services on non-default ports, clients need to know where to go.

We covered SRV in detail in article #48 of the original series. For Minecraft, this lets players type play.myserver.com even if your server is on port 25577.

Not all clients support SRV records. Most modern Minecraft clients do. Web browsers don't. Each protocol has its own SRV conventions.

NS: nameserver

myserver.com.   86400   IN   NS   ns1.cloudflare.com.
myserver.com.   86400   IN   NS   ns2.cloudflare.com.

Reads: "for myserver.com, ask these nameservers."

NS records at the parent level (.com) delegate the domain. NS records at your domain's apex are typically duplicated as a sanity check.

You usually don't edit NS records directly. You set them at your registrar (which updates the .com zone). Your authoritative nameservers report them at the apex automatically.

You can also use NS records to delegate subdomains:

clients.myserver.com.   NS   ns1.someotherprovider.com.
clients.myserver.com.   NS   ns2.someotherprovider.com.

This delegates the entire clients.myserver.com subtree to another set of nameservers. Useful for handing off control of a subdomain to a partner.

PTR: reverse DNS

42.113.0.203.in-addr.arpa.   PTR   play.myserver.com.

The weird structure: PTR records live in a special reverse-DNS hierarchy. The address 203.0.113.42 becomes 42.113.0.203.in-addr.arpa.

Used for reverse lookups: "what name is at this IP?" Email servers commonly check that the sending IP has a matching PTR record; missing PTR is a spam-filter signal.

PTR records are typically set by whoever owns the IP block (your ISP or hosting provider), not by you. If you need a specific PTR for your server (e.g., for outbound email), you ask your host.

CAA: certificate authority authorization

myserver.com.   CAA   0 issue "letsencrypt.org"

Reads: "only Let's Encrypt is allowed to issue certificates for myserver.com."

This is a security feature. When a Certificate Authority issues a certificate, it checks the CAA records. If your domain says only specific CAs are allowed, others should refuse to issue. Limits the damage if a CA is tricked into issuing a cert.

Optional but recommended. Adding a single CAA record is good hygiene for high-stakes domains.

ALIAS / ANAME / CNAME flattening

A non-standard but increasingly common feature. Lets you "alias" the apex of a domain to another hostname, working around the no-CNAME-at-apex rule.

myserver.com.   ALIAS   target.cdn-provider.com.

Behind the scenes, the DNS provider resolves the target periodically and serves the resulting IPs as A/AAAA records for myserver.com.

Different providers call this different things. Same idea.

DNSSEC records

If DNSSEC is enabled, you'll see records like:

• DNSKEY: public keys used for signing.
• RRSIG: signatures over your records.
• DS: delegation signer, at the parent zone.

These are managed by your DNS provider when you enable DNSSEC. You don't typically edit them directly.

Records you'll never use (probably)

A few DNS record types exist but rarely matter for ordinary use:

• SOA: Start of Authority. Metadata about the zone. Set automatically.
• HINFO: Host information. Mostly defunct.
• LOC: GPS coordinates of the server. Cute, almost never used.
• SSHFP: SSH key fingerprints. Used for SSH-over-DNS verification, rarely.
• HTTPS / SVCB: newer records for service-binding hints. Modern browsers use them but most domains don't have them yet.

A typical domain's records

For a small server's domain, expect:

myserver.com.       A      203.0.113.42
myserver.com.       AAAA   2001:db8::1
myserver.com.       MX     10 mx.emailprovider.com.
myserver.com.       TXT    "v=spf1 include:_spf.emailprovider.com ~all"
myserver.com.       CAA    0 issue "letsencrypt.org"
www.myserver.com.   CNAME  myserver.com.
mail.myserver.com.  A      [your mail server]
play.myserver.com.  A      [your game server]
_minecraft._tcp.play.myserver.com.   SRV   0 10 25577 play.myserver.com.

That's about 9 records, covering web, email, Minecraft, and security.

For a more sophisticated setup, multiply by 3 to 5 (subdomains for various services, multiple TXT records for various verifications).

Practical advice

Keep TTLs reasonable. 3600 (1 hour) is a good default. 300 (5 minutes) if you're about to change something. 86400 (1 day) for stable records.

Don't put production traffic on records with short TTLs forever. Short TTLs mean more queries to your authoritative servers, which costs money at scale.

Test changes with dig. Before announcing "the server moved to a new IP," verify the DNS actually returns the new IP:

dig play.myserver.com

If the new IP isn't returned, your change hasn't propagated yet (or wasn't made correctly).

Use +trace to see the full chain:

dig +trace play.myserver.com

Shows the resolution starting from root. Useful for debugging delegation issues.

Conclusion

DNS record types look intimidating but cluster into a few common patterns:

• A / AAAA: where this name is.
• CNAME: this name is just another name.
• MX: where email for this name goes.
• TXT: arbitrary metadata, especially security verifications.
• SRV: where this specific service for this name runs (host + port).
• NS: who manages this name.

Master those six and you can configure 99 percent of typical domains. The exotic types you can learn when you encounter them.

Coming up

We've covered DNS in depth. Next we turn to the actual addresses behind names: IPv4 and its 30-year scarcity problem.