fundamentals

DNS Record Types

A, AAAA, CNAME, MX, NS, TXT, SOA — the building blocks of DNS

The record that broke email for a day

A startup pushes their new marketing site live. Everything works — the website loads, the blog is up, the contact form submits. Then the support tickets start rolling in: nobody can receive email. The team spends hours checking their mail server before discovering the real culprit: someone added a CNAME record at the zone apex (example.com), which silently clobbered the MX records that route email. One wrong record type, and mail delivery stopped completely.

DNS record types are the building blocks of the entire system. Each type serves a specific purpose, follows specific rules, and interacts with other types in ways that matter. Understanding them is not academic — it is the difference between a working configuration and a silent, hours-long outage.

What is a DNS record?

DNS records — formally called Resource Records (RRs) — are instructions stored on authoritative DNS servers. Every record has five fields:

Field	Description	Example
Name	The domain name this record belongs to	`www.example.com.`
Type	The record type	`A`, `AAAA`, `CNAME`, `MX`, etc.
Class	Almost always `IN` (Internet)	`IN`
TTL	Time to live — how long resolvers can cache this record (seconds)	`3600`
RDATA	The record’s data payload	`93.184.216.34`

When a resolver queries for www.example.com A, it is asking: “Give me all records with name www.example.com, type A, class IN.”

Query type distribution

Not all record types are queried equally. Based on Vercara’s analysis of 3.56 trillion DNS queries (February 2024):

Record Type	Share of Queries
A	55.25%
AAAA	19.07%
HTTPS	6.88%
NS	5.68%
PTR	3.54%
Other types	~9.58%

A records dominate because every website visit, API call, and network connection starts with an IPv4 address lookup. AAAA queries are growing steadily as IPv6 adoption increases. The HTTPS record type, relatively new, already accounts for nearly 7% of queries as browsers use it to discover HTTP/2, HTTP/3, and encrypted client hello parameters.

The core record types

A record — IPv4 address mapping

The most fundamental DNS record. It maps a domain name to a 32-bit IPv4 address.

dig A example.com

;; ANSWER SECTION:
example.com.        86400   IN      A       93.184.216.34

A single domain can have multiple A records for load balancing or redundancy. The resolver typically returns all of them, and the client picks one (often randomly or round-robin).

AAAA record — IPv6 address mapping

The IPv6 equivalent of the A record. Maps a domain name to a 128-bit IPv6 address.

dig AAAA example.com

;; ANSWER SECTION:
example.com.        86400   IN      AAAA    2606:2800:220:1:248:1893:25c8:1946

Modern systems query for both A and AAAA records simultaneously. If both are available, the client uses a “Happy Eyeballs” algorithm (RFC 8305) to race IPv4 and IPv6 connections and use whichever responds first.

CNAME record — canonical name (alias)

A CNAME creates an alias from one domain name to another. When a resolver encounters a CNAME, it restarts the lookup using the target name.

dig CNAME www.example.com

;; ANSWER SECTION:
www.example.com.    86400   IN      CNAME   example.com.
example.com.        86400   IN      A       93.184.216.34

Critical rules for CNAME records:

A CNAME cannot coexist with other record types at the same name. If example.com has a CNAME record, it cannot also have A, MX, TXT, or any other record type. This is why you cannot put a CNAME at the zone apex (the bare domain like example.com) — the apex always needs SOA and NS records.
Each CNAME hop adds latency. If a.example.com CNAMEs to b.example.com which CNAMEs to c.example.com, each hop may require an additional round-trip. Most resolvers follow CNAME chains automatically, but long chains degrade performance.
CNAME records should not point to other CNAME records in practice, though the protocol allows it. RFC 1034 recommends against CNAME chains.

Some DNS providers offer proprietary ALIAS or ANAME record types that behave like a CNAME at the zone apex by resolving the target server-side and returning an A/AAAA record. These are not standardized in any RFC.

MX record — mail exchange

MX records specify which mail servers accept email for a domain, along with a priority value. Lower priority numbers indicate preferred servers.

dig MX example.com

;; ANSWER SECTION:
example.com.        86400   IN      MX      10 mail.example.com.
example.com.        86400   IN      MX      20 backup-mail.example.com.

When a mail server wants to deliver email to user@example.com, it queries for MX records and tries the server with the lowest priority number first. If that server is unavailable, it falls back to the next priority level.

Priority	Server	Role
10	`mail.example.com`	Primary mail server
20	`backup-mail.example.com`	Backup — used only when primary fails

MX records must point to an A or AAAA record — never to a CNAME. This is specified in RFC 2181 and violating it can cause mail delivery failures with some mail transfer agents.

NS record — name server

NS records declare which name servers are authoritative for a zone. They are the mechanism behind DNS delegation — the way the root zone points to TLD servers, and TLD servers point to your domain’s servers.

dig NS example.com

;; ANSWER SECTION:
example.com.        86400   IN      NS      ns1.example.com.
example.com.        86400   IN      NS      ns2.example.com.

Every zone requires at least two NS records for redundancy. Most production setups use two to four. NS records account for 5.68% of all DNS queries.

TXT record — text data

TXT records store arbitrary text strings associated with a domain. While originally designed for human-readable notes, they have become the workhorse of email authentication and domain verification.

dig TXT example.com

;; ANSWER SECTION:
example.com.        86400   IN      TXT     "v=spf1 include:_spf.google.com ~all"
example.com.        86400   IN      TXT     "google-site-verification=abc123..."

Common uses for TXT records:

Use Case	Example Value
SPF (email sender policy)	`"v=spf1 include:_spf.google.com ~all"`
DKIM (email signing key)	`"v=DKIM1; k=rsa; p=MIGfMA0..."` (at `selector._domainkey.example.com`)
DMARC (email auth policy)	`"v=DMARC1; p=reject; rua=mailto:dmarc@example.com"` (at `_dmarc.example.com`)
Domain verification	`"google-site-verification=abc123..."`
General metadata	Any string up to 255 characters per segment

A single domain can have multiple TXT records. TXT records longer than 255 characters are split into multiple strings within a single record, which the client concatenates.

SOA record — start of authority

Every zone has exactly one SOA record, and it must be the first record in the zone file. It contains administrative metadata about the zone.

dig SOA example.com

;; ANSWER SECTION:
example.com.    86400  IN  SOA  ns1.example.com. admin.example.com. (
                              2025021301  ; Serial
                              3600        ; Refresh (1 hour)
                              900         ; Retry (15 minutes)
                              1209600     ; Expire (2 weeks)
                              86400       ; Minimum TTL (1 day)
                          )

The SOA fields, explained:

Field	Value	Meaning
MNAME	`ns1.example.com.`	Primary name server for the zone
RNAME	`admin.example.com.`	Admin email (`admin@example.com` — the first `.` replaces `@`)
Serial	`2025021301`	Version number; incremented on every change (often `YYYYMMDDNN`)
Refresh	`3600`	How often secondary servers check for updates (1 hour)
Retry	`900`	Wait time before retrying a failed zone transfer (15 min)
Expire	`1209600`	How long secondaries serve data without contacting primary (2 weeks)
Minimum TTL	`86400`	Default TTL for negative caching / NXDOMAIN responses (1 day)

The serial number is critical for zone transfers. Secondary servers compare their serial with the primary’s — if the primary’s serial is higher, a zone transfer is initiated.

PTR record — reverse lookup

PTR records map an IP address back to a domain name, the reverse of what A and AAAA records do. They use the special in-addr.arpa (IPv4) and ip6.arpa (IPv6) zones.

dig -x 93.184.216.34

;; ANSWER SECTION:
34.216.184.93.in-addr.arpa. 86400 IN PTR www.example.com.

Note the reversed IP octets: 93.184.216.34 becomes 34.216.184.93.in-addr.arpa. This reversal aligns the IP address with the DNS delegation hierarchy (most specific on the left).

PTR records are used for:

Email server verification: Many mail servers reject messages from IPs without valid reverse DNS
Logging and diagnostics: Network tools resolve IPs to hostnames for readability
Anti-spam checks: SPF and DKIM validation often includes reverse DNS verification

PTR records account for 3.54% of all DNS queries.

Modern record types

HTTPS and SVCB records

The HTTPS record (RFC 9460) is a newer type that allows browsers to discover connection parameters in a single DNS query — including supported HTTP versions (HTTP/2, HTTP/3), encrypted client hello (ECH) configuration, and alternative IP addresses.

dig HTTPS example.com

;; ANSWER SECTION:
example.com.    300 IN  HTTPS   1 . alpn="h2,h3" ipv4hint=93.184.216.34

At 6.88% of all queries, HTTPS records are already more common than many traditional types. They eliminate an extra round-trip that browsers previously needed to discover HTTP/3 support, meaningfully improving page load times.

CAA record — certificate authority authorization

CAA records specify which Certificate Authorities are permitted to issue TLS certificates for a domain. They are a security control that prevents unauthorized certificate issuance.

dig CAA example.com

;; ANSWER SECTION:
example.com.    86400   IN      CAA     0 issue "letsencrypt.org"
example.com.    86400   IN      CAA     0 issuewild "letsencrypt.org"

The issue tag controls standard certificates. The issuewild tag controls wildcard certificates. The iodef tag specifies a URL or email for violation reports.

SRV record — service location

SRV records specify the host and port for specific services. They are used heavily in VoIP (SIP), chat (XMPP), directory services (LDAP), and authentication (Kerberos).

dig SRV _sip._tcp.example.com

;; ANSWER SECTION:
_sip._tcp.example.com. 86400 IN SRV 10 60 5060 sipserver.example.com.

The format is priority weight port target. Priority works like MX (lower = preferred). Weight enables load balancing among same-priority records — higher weight receives proportionally more traffic.

Record type quick reference

Type	Purpose	Points To	At Zone Apex?
A	IPv4 address	IP address	Yes
AAAA	IPv6 address	IP address	Yes
CNAME	Alias	Another domain name	No (conflicts with SOA/NS)
MX	Mail routing	Mail server hostname + priority	Yes
NS	Delegation	Name server hostname	Yes (required)
TXT	Text data	Arbitrary string	Yes
SOA	Zone metadata	Admin info, serials, timers	Yes (required, exactly one)
PTR	Reverse lookup	Domain name	N/A (used in `arpa` zones)
HTTPS	Connection hints	Service parameters	Yes
CAA	Certificate auth	CA domain name	Yes
SRV	Service location	Host + port	N/A (uses `_service._proto` prefix)

Common mistakes

CNAME at the zone apex. This breaks NS and SOA records. Use an A/AAAA record, or your provider’s proprietary ALIAS/ANAME type.

MX pointing to a CNAME. The RFC says MX targets must resolve directly to A/AAAA records. Some mail servers will follow the CNAME anyway, but others will reject it.

Missing reverse DNS (PTR). If your mail server’s IP has no PTR record, many receiving servers will reject or spam-folder your messages.

Conflicting records. An A record and a CNAME at the same name will cause unpredictable behavior. Only CNAME can exist alone at a name (with no sibling records).

TTL mismatches on record sets. All records of the same name and type should have the same TTL. Mismatched TTLs within an RRset violate RFC 2181 and can cause inconsistent caching behavior.

Next steps

Records do not exist in isolation — they live in zones, the administrative units of DNS. Understanding how zones are structured and delegated will help you see how these record types fit together in a real-world DNS configuration.

Related Resources

Zones And Delegation

Spf