# DNS Record Types Canonical: https://learndns.org/learn/2-3-record-types/ > A comprehensive guide to DNS record types — A, AAAA, CNAME, MX, NS, TXT, SOA, SRV, CAA, PTR, DNSSEC records, and the new SVCB/HTTPS records. 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): ```dns 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: ```dns 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: ```dns 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): ```dns 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: ```dns 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): ```dns 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: ```dns 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): ```dns ; 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: 1. **Parent zone** (the delegation point) 2. **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: ```dns 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: ```dns 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: ```dns _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: ```dns 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): ```dns 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: ```dns _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: ```dns 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: ```dns 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: ```dns 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: ```dns 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: ```dns 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: ```dns 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: ```dns 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: ```dns 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: ```dns _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.