Records & Zones

The full reference for DNS records you'll actually configure.

Address Records

A — IPv4 Address

api.example.com    A    203.0.113.10

The everyday workhorse. Maps a name to an IPv4 address. Multiple A records for the same name = round-robin (resolver picks one; clients may cache).

AAAA — IPv6 Address

api.example.com    AAAA    2001:db8::1

Same as A but for IPv6. Always pair A with AAAA if your services support IPv6 — modern clients prefer IPv6 (Happy Eyeballs algorithm) and pure-v4 setups miss a meaningful share of traffic.

Aliasing Records

CNAME — Canonical Name

www.example.com    CNAME    example.com.

www.example.com resolves to whatever example.com resolves to. The trailing dot makes it absolute (otherwise the zone's domain is appended).

Restrictions:

• No CNAME at the apex (example.com itself). Use A/AAAA or ALIAS.
• No other records on the same name as a CNAME. A CNAME owns its name.
• CNAME chains work but cost extra lookups. Keep them short.

ALIAS / ANAME / Flattened CNAME

A synthetic record type from Route 53 (ALIAS), Cloudflare (CNAME flattening at apex), and others. Lets you "CNAME the apex" by having the DNS provider resolve the target and return A/AAAA records.

# Cloudflare (CNAME at apex, flattened by them)
example.com    CNAME    fancy-cdn.example.com.
# Resolved as A records when queried

# Route 53 (alias to AWS resources)
example.com    ALIAS    d111111abcdef8.cloudfront.net.

Not portable between providers; check what yours supports.

Mail Records

MX — Mail Exchange

example.com    MX    10  primary-mail.example.com.
example.com    MX    20  secondary-mail.example.com.
example.com    MX    30  tertiary-mail.example.com.

The number is priority (lower = preferred). If primary is down, sender tries secondary, etc.

For Gmail / Google Workspace:

example.com    MX    1   smtp.google.com.

For Microsoft 365:

example.com    MX    0   example-com.mail.protection.outlook.com.

SPF, DKIM, DMARC — Sender Authentication

Stop your domain from being used in spam. All three are TXT records.

# SPF — which servers may send mail from this domain
example.com    TXT    "v=spf1 include:_spf.google.com -all"

# DKIM — public key for verifying signed mail
google._domainkey.example.com    TXT    "v=DKIM1; k=rsa; p=MIGfMA0..."

# DMARC — policy for handling messages that fail SPF/DKIM
_dmarc.example.com    TXT    "v=DMARC1; p=reject; rua=mailto:dmarc@example.com"

SPF policy ends in -all to reject unauthorized senders. DMARC p=reject is the goal after observing for weeks at p=none.

Service Discovery Records

SRV — Service Records

_service._proto.example.com    SRV    priority weight port target
_sip._tcp.example.com          SRV    10 60 5060 sipserver.example.com.

Encodes the host and port for a service. Used by SIP, XMPP, Kubernetes internal DNS, Minecraft servers. Most web apps don't use SRV; consumer of the protocol must know to look it up.

TXT — Arbitrary Text

example.com                TXT    "v=spf1 ..."
google-site-verification   TXT    "abc123def..."
acme-challenge.example.com TXT    "verification-token"

Used for verification flows (Google, Microsoft, ACME for Let's Encrypt), SPF, DKIM, DMARC, and arbitrary domain proofs.

Security Records

CAA — Certificate Authority Authorization

example.com    CAA    0 issue "letsencrypt.org"
example.com    CAA    0 issue "amazon.com"
example.com    CAA    0 issuewild ";"        # no wildcards from any CA
example.com    CAA    0 iodef "mailto:security@example.com"

Tells the public CA ecosystem which CAs are authorized to issue certificates for your domain. A misissued cert is a huge security hole; CAA records make that harder.

Set CAA for every domain you control. Cost: zero. Benefit: real.

DNSSEC — DNS Security Extensions

DNSSEC cryptographically signs DNS responses so resolvers can verify they weren't tampered with. Enabled at the zone level by your DNS provider plus a DS record at the parent zone (set via your registrar):

example.com    DS    12345 13 2 ABCDEF1234567890...

Pros:

• Prevents on-path DNS attacks (cache poisoning).
• Enables DANE (TLS auth via DNS).

Cons:

• One more thing that can break — rotation issues take you offline.
• Doesn't authenticate the last mile (client to recursive resolver — that's DoH/DoT's job).

Some providers (Cloudflare) make enabling DNSSEC one click; do it.

Other Useful Records

NS — Nameserver

example.com           NS    ns1.cloudflare.com.
status.example.com    NS    ns1.statuspage.io.    # delegating subdomain

The records that define which servers are authoritative for a zone (or part of one).

PTR — Reverse DNS

10.113.0.203.in-addr.arpa    PTR    api.example.com.

Maps IP back to hostname. Set by the IP owner (your ISP or cloud provider), not you — except in your own private DNS zones. Mail servers often check PTR records before accepting mail from an IP.

SOA — Start of Authority

Auto-managed by DNS providers. Contains zone metadata: primary nameserver, contact email, serial, refresh/retry/expire/minimum-TTL.

You rarely edit this directly; the provider exposes the relevant fields in their UI.

HTTPS / SVCB — Service Binding (newer)

example.com    HTTPS    1 . alpn="h3,h2" ipv4hint=203.0.113.10

A newer record type that gives clients hints about how to connect — supported protocols, IP hints, ECH config. Browsers use it to skip HTTP/1.1 fallback handshakes and to fetch ECH keys.

Worth setting for performance once your DNS provider supports it (Cloudflare, NS1, Route 53 all do).

Traffic Management

Advanced DNS providers let you serve different answers based on the query's origin:

Geo-Based

visitors from EU       → eu.example.com    → 198.51.100.10
visitors from US       → us.example.com    → 203.0.113.10
visitors elsewhere     → default.example.com

Latency-Based

The provider measures latency from its global resolver fleet to your endpoints and serves the closest.

Weighted

us.example.com   70% → 203.0.113.10
                 30% → 203.0.113.20

For canary deployments at the DNS level. Coarse-grained (no per-user stickiness; respect TTL).

Health-Checked Failover

example.com   →   primary  (health-checked)
              ↓   if down: secondary

Active/passive at the DNS level. Failover latency is bound by TTL — fast failover needs short TTLs and risks query volume.

For real traffic management, don't rely on DNS alone — use it with a real LB or a service mesh.

Zones, Delegation, and Subdomains

A zone is the smallest unit of DNS authority — a domain you fully control. example.com is a zone; sub.example.com is usually still in the same zone unless you delegate it.

Delegation

# In example.com zone:
status.example.com    NS    ns1.statuspage.io.
status.example.com    NS    ns2.statuspage.io.

Statuspage now owns DNS for status.example.com and anything below it. Common for SaaS providers needing full control.

Multi-Provider Strategy

Some teams run the same zone across multiple DNS providers for redundancy. You publish identical records at both; your registrar's NS records point to both providers. If one provider has an outage, the other still answers.

Operational overhead: keep records in sync. Tools like OctoDNS or external-dns help.

Zone-as-Code

Don't manage DNS by clicking. Put the zone in version control:

• OctoDNS — Python; multi-provider; the most mature option.
• Terraform DNS providers — each DNS provider has a Terraform module.
• dnscontrol — JavaScript DSL; Stack Exchange's tool.

# Terraform — Cloudflare DNS
resource "cloudflare_record" "api" {
  zone_id = var.zone_id
  name    = "api"
  type    = "A"
  value   = "203.0.113.10"
  ttl     = 300
}

Now DNS changes go through PR review and CI. Treat DNS like any other production config.

What's Next

You know what every record type does and how to compose them. Best Practices covers TTL strategy, redundancy, monitoring, and the pitfalls that take sites offline.