DNS records are the data that makes the system work. Each record type serves a specific purpose — from mapping names to IP addresses to routing email to proving domain ownership.
Let’s explore every record type you’re likely to encounter, with practical examples you can actually use.
A and AAAA Records: Address Mapping
The most fundamental DNS records map domain names to IP addresses.
A Records (IPv4)
An A record maps a name to an IPv4 address (RFC 1035):
example.com. 300 IN A 93.184.216.34
www.example.com. 300 IN A 93.184.216.34
api.example.com. 60 IN A 203.0.113.50
Format: name TTL class type address
You can have multiple A records for the same name — this is called round-robin DNS and provides basic load distribution:
www.example.com. 300 IN A 93.184.216.34
www.example.com. 300 IN A 93.184.216.35
www.example.com. 300 IN A 93.184.216.36
Clients receive all IPs and typically try them in order (though behavior varies).
AAAA Records (IPv6)
AAAA records (RFC 3596) do the same thing for IPv6. The name is “quad-A” because IPv6 addresses are four times longer than IPv4:
example.com. 300 IN AAAA 2606:2800:220:1:248:1893:25c8:1946
Modern best practice: always publish both A and AAAA records if you support IPv6.
CNAME Records: Aliases
A CNAME (Canonical Name) record creates an alias — one name pointing to another (RFC 1034 §3.6.2):
www.example.com. 300 IN CNAME example.com.
blog.example.com. 300 IN CNAME mycompany.wordpress.com.
cdn.example.com. 300 IN CNAME d1234567890.cloudfront.net.
When a resolver encounters a CNAME, it restarts the resolution process for the target name. If you query www.example.com, you get back the CNAME pointing to example.com, then the resolver queries example.com and returns that A/AAAA record.
The CNAME Restriction
A CNAME cannot coexist with any other record at the same name. This is a hard rule from RFC 1034.
❌ This is invalid:
example.com. 300 IN CNAME other.example.net.
example.com. 300 IN MX 10 mail.example.com. ; INVALID!
This restriction causes real pain at the zone apex (example.com itself) because you need MX, TXT, and often NS records there. You can’t use a CNAME at the apex.
CNAME Flattening / ALIAS / ANAME
Many DNS providers offer proprietary solutions: “CNAME flattening,” “ALIAS records,” or “ANAME records.” These resolve the CNAME chain server-side and return A/AAAA records, working around the restriction. They’re not standard DNS — they’re provider features.
MX Records: Mail Routing
MX (Mail Exchanger) records tell mail servers where to deliver email (RFC 5321):
example.com. 300 IN MX 10 mail1.example.com.
example.com. 300 IN MX 20 mail2.example.com.
example.com. 300 IN MX 30 backup-mail.example.net.
Format: name TTL class MX priority target
The priority (preference) value determines order. Lower values = higher priority. Sending servers try 10 first, then 20, then 30.
You can use the same priority for load balancing:
example.com. 300 IN MX 10 mail1.example.com.
example.com. 300 IN MX 10 mail2.example.com.
The target must be a hostname, not an IP address. That hostname must have an A/AAAA record.
NS Records: Delegation
NS (Nameserver) records delegate authority for a zone (RFC 1035):
; At the registrar/parent zone
example.com. 86400 IN NS ns1.example.com.
example.com. 86400 IN NS ns2.example.com.
; Glue records (if nameservers are within the zone)
ns1.example.com. 86400 IN A 192.0.2.1
ns2.example.com. 86400 IN A 192.0.2.2
NS records appear in two places:
- Parent zone (the delegation point)
- The zone itself (the apex, for informational purposes)
Best practice: use at least two nameservers on different networks for redundancy.
TXT Records: The Swiss Army Knife
TXT records hold arbitrary text data (RFC 1035). Originally for human-readable notes, they’re now critical infrastructure for several protocols:
SPF (Email Authentication)
Sender Policy Framework (RFC 7208) prevents email spoofing:
example.com. 300 IN TXT "v=spf1 ip4:192.0.2.0/24 include:_spf.google.com -all"
This says: email from example.com should only come from the 192.0.2.0/24 range or Google’s servers. The -all means reject all others.
DKIM (Email Signing)
DomainKeys Identified Mail (RFC 6376) publishes public keys for email signature verification:
selector1._domainkey.example.com. 300 IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGS..."
DMARC (Email Policy)
Domain-based Message Authentication (RFC 7489) ties SPF and DKIM together with reporting:
_dmarc.example.com. 300 IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc@example.com"
Domain Verification
Services use TXT records to verify domain ownership:
example.com. 300 IN TXT "google-site-verification=abc123..."
example.com. 300 IN TXT "stripe-verification=def456..."
Multiple TXT records at the same name are allowed (unlike CNAME).
SOA Records: Zone Authority
Every zone must have exactly one SOA (Start of Authority) record at the apex (RFC 1035 §3.3.13):
example.com. 3600 IN SOA ns1.example.com. hostmaster.example.com. (
2024012801 ; Serial
3600 ; Refresh (1 hour)
600 ; Retry (10 minutes)
604800 ; Expire (1 week)
300 ; Minimum (negative cache TTL)
)
Each field matters:
| Field | Example | Meaning |
|---|---|---|
| MNAME | ns1.example.com. | Primary nameserver |
| RNAME | hostmaster.example.com. | Admin email (@ replaced with .) |
| Serial | 2024012801 | Version number (increment on changes) |
| Refresh | 3600 | How often secondaries check for updates |
| Retry | 600 | Retry interval if refresh fails |
| Expire | 604800 | When secondary stops serving if primary is unreachable |
| Minimum | 300 | TTL for negative (NXDOMAIN) caching |
The serial number is crucial for zone transfers. Common convention: YYYYMMDDnn where nn is a daily counter.
SRV Records: Service Discovery
SRV records (RFC 2782) locate services — like finding the XMPP or SIP server for a domain:
_sip._tcp.example.com. 300 IN SRV 10 60 5060 sipserver.example.com.
_xmpp-client._tcp.example.com. 300 IN SRV 5 0 5222 xmpp.example.com.
Format: _service._protocol.name TTL class SRV priority weight port target
- Priority: Lower = more preferred (like MX)
- Weight: For load balancing among same-priority servers
- Port: The port the service runs on
- Target: The server hostname
SRV enables service discovery without hardcoded ports. Clients look up _sip._tcp.example.com to find where SIP service lives.
CAA Records: Certificate Authority Authorization
CAA records (RFC 8659) specify which Certificate Authorities can issue certificates for your domain:
example.com. 300 IN CAA 0 issue "letsencrypt.org"
example.com. 300 IN CAA 0 issue "digicert.com"
example.com. 300 IN CAA 0 issuewild "letsencrypt.org"
example.com. 300 IN CAA 0 iodef "mailto:security@example.com"
- issue: CAs allowed to issue certificates
- issuewild: CAs allowed to issue wildcard certificates
- iodef: Where to send violation reports
CAs are required to check CAA records before issuing. This prevents unauthorized certificate issuance.
PTR Records: Reverse DNS
PTR (Pointer) records map IP addresses back to hostnames — the reverse of A/AAAA records:
34.216.184.93.in-addr.arpa. 300 IN PTR example.com.
IPv4 reverse DNS uses the in-addr.arpa zone with octets reversed. 93.184.216.34 becomes 34.216.184.93.in-addr.arpa.
IPv6 uses ip6.arpa with each nibble (4-bit chunk) as a label:
6.4.9.1.8.c.5.2.3.9.8.1.8.4.2.0.1.0.0.0.0.2.2.0.0.0.8.2.6.0.6.2.ip6.arpa. IN PTR example.com.
Why PTR matters:
- Email servers check PTR records to validate senders (mismatched PTR = likely spam)
- Logging and diagnostics often perform reverse lookups
- Some services refuse connections without valid reverse DNS
PTR records are managed by the IP address owner (typically your hosting provider or ISP), not the domain owner.
DNSSEC Records
DNSSEC adds cryptographic authentication to DNS, using several record types:
DNSKEY
Contains the public key used to verify signatures:
example.com. 3600 IN DNSKEY 257 3 13 mdsswUyr3DPW132mOi8V9xESWE8jTo0dxCjjnopKl+GqJxpVXckHAeF+KkxLbxILfDLUT0rAK9iUzy1L53eKGQ==
The 257 flag indicates a Key Signing Key (KSK).
DS (Delegation Signer)
A hash of the child zone’s KSK, placed in the parent zone:
example.com. 3600 IN DS 12345 13 2 49FD46E6C4B45C55D4AC...
This creates a chain of trust from parent to child.
RRSIG
Contains the actual signature for a record set:
example.com. 300 IN RRSIG A 13 2 300 20240228000000 20240131000000 12345 example.com. Kb1iSz9X4YP...
NSEC / NSEC3
Provides authenticated denial of existence — proving a name doesn’t exist:
example.com. 300 IN NSEC www.example.com. A MX AAAA RRSIG NSEC
NSEC3 adds hashing to prevent zone enumeration.
SVCB and HTTPS Records: Modern Service Binding
The newest additions (RFC 9460), SVCB and HTTPS records modernize service discovery.
HTTPS Record
Specifically for HTTPS services — the successor to A/AAAA for web:
example.com. 300 IN HTTPS 1 . alpn="h2,h3" ipv4hint=93.184.216.34 ipv6hint=2606:2800:220:1:248:1893:25c8:1946
Benefits:
- alpn: Advertise HTTP/2 and HTTP/3 support
- IP hints: Reduce round trips by including addresses
- ECH: Support for Encrypted Client Hello (TLS privacy)
The browser can establish an optimized connection from the first query.
SVCB Record
The general form for any service, not just HTTPS:
_smtp._tcp.example.com. 300 IN SVCB 1 mail.example.com. port=465
SVCB and HTTPS records solve problems that took ugly hacks before — like advertising HTTP/3 support without extra round trips.
Record Type Summary
| Type | Purpose | Example Use |
|---|---|---|
| A | IPv4 address | Website hosting |
| AAAA | IPv6 address | Modern connectivity |
| CNAME | Alias | CDN integration |
| MX | Mail routing | Email delivery |
| NS | Delegation | Nameserver assignment |
| TXT | Text data | SPF, DKIM, verification |
| SOA | Zone authority | Zone metadata |
| SRV | Service location | VoIP, chat servers |
| CAA | CA authorization | Certificate security |
| PTR | Reverse DNS | Email verification |
| HTTPS | HTTPS service | Modern web |
Key Takeaways
- A/AAAA are the workhorses, mapping names to IP addresses
- CNAME creates aliases but cannot coexist with other records
- MX routes email with priority-based fallback
- TXT records power modern email authentication (SPF, DKIM, DMARC)
- SOA defines zone metadata including serial numbers for replication
- CAA restricts which CAs can issue certificates
- HTTPS/SVCB are the modern way to advertise web services
Understanding record types is essential for configuring domains correctly. In the next chapter, we’ll explore how DNS caching and TTL work — the mechanism that makes the whole system fast.