DNS Record Types You'll Actually Use

In one line

A, AAAA, CNAME, ALIAS, MX, TXT, NS, SOA, SRV, CAA, and PTR each answer a different question; knowing which one to use avoids the classic apex-CNAME and email-verification mistakes.

0/4 · 0%

Key ideas

01
A: name → IPv4 address. AAAA: name → IPv6 address. These are the final answer for most lookups.
02
CNAME: name → another NAME (an alias); the resolver then looks that name up. Rules: a CNAME can't coexist with other records at the same name, so you can't put one at the zone apex (example.com). ALIAS/ANAME records (Route 53 alias, Cloudflare CNAME flattening) solve that by resolving the target server-side.
03
MX: where to deliver email, with priorities. TXT: arbitrary text, used for domain verification (Google, ACM), SPF, DKIM, and DMARC email authentication. NS: which servers are authoritative for a zone or delegated subdomain. SOA: zone metadata, including the negative-cache TTL.
04
SRV: service location with port and priority (_sip._tcp.example.com); used by some service-discovery systems and Kubernetes headless services. CAA: which certificate authorities may issue certs for your domain, a cheap security control. PTR: reverse DNS (IP → name), used by mail servers and logging.
05
Delegation: to hand dev.example.com to another team or account, create NS records for dev in the parent zone pointing to the child zone's name servers. That's how multi-account setups give each environment its own DNS zone.

Code & diagrams

records.shbash

dig +short A example.com
dig +short AAAA example.com
dig +short CNAME www.github.com
dig +short MX gmail.com
dig +short TXT google.com | head -3
dig +short NS example.com
dig +short CAA google.com
dig -x 8.8.8.8 +short           # PTR: reverse lookup

Explain it without notes

Why can't you put a CNAME at example.com pointing to your load balancer's hostname, and what do you use instead?

Practice

Which records would you create to (a) verify domain ownership for ACM, (b) send api.example.com to a CloudFront distribution, (c) restrict certificate issuance to Let's Encrypt and Amazon?

Trade-offs

↔
CNAME chains make changes easier (update one target) but add lookups and a dependency on the target's DNS; flattened aliases are faster but are provider-specific.

Done when you can

I know A, AAAA, CNAME, ALIAS, MX, TXT, NS, SOA, SRV, CAA, and PTR.
I know why the apex can't be a CNAME.
I can delegate a subdomain with NS records.