DNS records explained: A, AAAA, CNAME, MX, TXT, SRV, CAA — and the gotchas

[Aior]

DNS is the protocol everyone uses and few understand​

DNS bugs are some of the most common production issues. The reason: DNS is conceptually simple but operationally subtle, and most teams pick up just enough to deploy something working without ever learning the corners. Below is the practical reference for the records that actually matter.

A and AAAA​

• A — points a name to an IPv4 address
• AAAA — points a name to an IPv6 address

The fundamentals. Multiple A records → DNS round-robin (basic load balancing, not health-aware). Modern DNS providers offer geo-routing, latency-based, weighted — these are vendor-specific extensions of the A record concept.

Always include AAAA in 2026 if your origin supports it. IPv6 traffic is non-trivial.

CNAME​

Aliases one name to another name. Used for "www.example.com → example.com" or "shop.example.com → example.myshopify.com".

The classic gotcha: CNAME at the apex (root) is forbidden by spec. You can't have "example.com → cdn.provider.com" as a CNAME. Workarounds:

• ALIAS / ANAME records — vendor-specific (Cloudflare CNAME flattening, Route 53 ALIAS, Hetzner DNS ANAME). Behave like a CNAME at the apex.
• Manual A record sync — set the A record to whatever the target's IP is, update on changes. Brittle.

In 2026, use vendor-specific apex aliasing on most modern DNS providers.

MX​

Mail exchanger records — where email for the domain is delivered. Format: priority + hostname.

Common patterns:

• Single MX → simple, single point of failure
• Multiple MX with same priority → load balanced
• Multiple MX with different priority → primary + backup

The MX hostname must be an A/AAAA record, not a CNAME (per RFC). Most providers enforce this.

TXT​

Free-form text. Used for:

• SPF — "v=spf1 include:_spf.google.com -all" — declares authorised mail senders
• DKIM — public key for email signature verification (selector-based)
• DMARC — "_dmarc" subdomain, declares how to handle SPF/DKIM failures
• Domain ownership verification — for Google Workspace, Microsoft 365, etc.

The single most-screwed-up TXT record: SPF. The most common mistakes:

• Multiple SPF records → invalid; merge into one
• "+all" at the end → permits all senders, defeats the purpose
• Forgetting to include third-party senders (transactional email service, CRM)

SRV​

Service location — used by SIP, XMPP, Minecraft, Active Directory. Format includes priority, weight, port, target.

Most teams don't touch SRV records. When you need them, the documentation is service-specific.

CAA​

Certification Authority Authorisation — controls which CAs can issue certificates for the domain. A modern hardening control:

• example.com. CAA 0 issue "letsencrypt.org" — only Let's Encrypt can issue
• example.com. CAA 0 issuewild ";" — no wildcard issuance allowed
• example.com. CAA 0 iodef "mailto:security@example.com" — where to report violations

Add CAA records to high-value domains. Free, hardens against unauthorised certificate issuance.

TTL — the underrated knob​

TTL = how long a resolver caches the record. Common patterns:

• Long TTL (24h, 48h) — for stable records. Reduces DNS query load.
• Short TTL (300s) — for records that might change. Necessary before a planned change.
• Very short TTL (60s, 30s) — for failover / dynamic. Operational cost is high; use sparingly.

The pre-migration discipline: lower the TTL to 300s well before the change (24-48 hours), so the actual change propagates fast.

Propagation — what's actually happening​

"DNS propagation" is shorthand for "various DNS resolvers around the world updating their caches as TTLs expire". There's no global state. Tools (whatsmydns.net) sample resolvers in different regions to give a picture.

The discipline: change at low TTL, monitor for the change visibility, increase TTL back after the change is stable.

DNSSEC​

• Cryptographic signing of DNS records — defends against cache poisoning
• Increasingly supported by registrars + DNS providers
• Configuration error rate is real — bad DNSSEC means complete DNS unavailability for the domain
• For most use cases, optional but recommended

One pattern we'd warn about​

Editing DNS records during high-traffic periods. DNS changes during peak load amplify the cost of mistakes. Schedule changes for low-traffic windows when feasible.

One pattern that always pays off​

DNS records in version control / IaC. Terraform's DNS providers, dnscontrol, octoDNS — all let you manage zones declaratively. Manual zone editing in a web UI is the path to drift.

What DNS provider are you on? And — for the IaC folks — has dnscontrol or octoDNS held up at scale?