DNS Record Types Explained: A Complete Reference

A reference guide to the most important DNS record types, what they do, and when to use them.

What are DNS records?

The Domain Name System (DNS) is a distributed database that maps human-readable domain names to machine-readable values. Each mapping is stored as a resource record with a specific type that determines how the data is interpreted. Understanding record types is fundamental to configuring domains, debugging connectivity issues, and securing internet services.

Address records

A (IPv4 address)

Maps a hostname to an IPv4 address. This is the most basic and most queried record type. A domain can have multiple A records for load balancing or redundancy.

example.com.    300   IN  A   198.51.100.42

AAAA (IPv6 address)

Maps a hostname to an IPv6 address. Functionally identical to A records but for the IPv6 address family. As IPv6 adoption grows, publishing AAAA records alongside A records is increasingly important.

example.com.    300   IN  AAAA  2001:db8::1

Delegation and aliasing

CNAME (canonical name)

Creates an alias from one name to another. When a resolver encounters a CNAME, it restarts the lookup using the target name. A CNAME must not coexist with other record types at the same name (the "CNAME exclusivity" rule). This means you cannot place a CNAME at the zone apex alongside NS or SOA records.

www.example.com.  300  IN  CNAME  example.com.

NS (name server)

Delegates a zone (or subdomain) to a set of authoritative name servers. NS records at the zone apex define which servers are authoritative for the entire domain. NS records at a subdomain create a delegation point.

example.com.    86400  IN  NS  ns1.example.com.
example.com.    86400  IN  NS  ns2.example.com.

Mail records

MX (mail exchanger)

Specifies which servers accept email for a domain and in what priority. Lower preference values indicate higher priority. If the highest-priority server is unreachable, the sender tries the next.

example.com.    300  IN  MX  10  mail1.example.com.
example.com.    300  IN  MX  20  mail2.example.com.

TXT (text)

A general-purpose record that holds arbitrary text data. In practice, TXT records are used extensively for email authentication (SPF, DKIM, DMARC), domain ownership verification, and service-specific configuration. A domain can have multiple TXT records, but certain protocols (like SPF) require exactly one.

example.com.    300  IN  TXT  "v=spf1 include:_spf.google.com -all"

Infrastructure records

SOA (start of authority)

Every DNS zone has exactly one SOA record. It declares the primary name server, the responsible party's email address, and timing parameters that control zone transfers and caching: serial number, refresh interval, retry interval, expire time, and negative caching TTL (minimum TTL).

example.com.  86400  IN  SOA  ns1.example.com. admin.example.com. (
                              2024010101  ; serial
                              3600        ; refresh
                              900         ; retry
                              604800      ; expire
                              86400 )     ; minimum TTL

PTR (pointer)

Maps an IP address back to a hostname (reverse DNS). PTR records live in the in-addr.arpa (IPv4) or ip6.arpa (IPv6) zones, managed by whoever controls the IP address block. Reverse DNS is used for logging, email server verification (many mail servers reject connections without valid PTR records), and diagnostic tools.

Service records

SRV (service locator)

Specifies the hostname and port for a specific service. Used by protocols like XMPP, SIP, LDAP, and Minecraft. The record format includes priority, weight (for load balancing among equal-priority targets), port, and target hostname.

_sip._tcp.example.com.  300  IN  SRV  10 60 5060 sip.example.com.

CAA (certification authority authorization)

Specifies which Certificate Authorities are permitted to issue certificates for a domain. CAs are required to check CAA records before issuance. If no CAA record exists, any CA may issue. CAA records are a lightweight defense against mis-issuance.

example.com.  300  IN  CAA  0 issue "letsencrypt.org"
example.com.  300  IN  CAA  0 iodef "mailto:security@example.com"

Security records

TLSA (DANE)

Binds a TLS certificate (or public key) to a specific service port via DNS, secured by DNSSEC. This is the foundation of DANE (DNS-Based Authentication of Named Entities), which allows domain operators to pin certificates without relying solely on the CA ecosystem. See the DANE/TLSA Setup Guide for details.

_443._tcp.example.com.  300  IN  TLSA  3 1 1 abc123...

DNSKEY / DS / RRSIG (DNSSEC)

These record types form the DNSSEC chain of trust. DNSKEY holds the zone's public signing keys. DS (Delegation Signer) records in the parent zone point to the child's DNSKEY. RRSIG records contain cryptographic signatures over other record sets. Together, they allow resolvers to verify that DNS responses have not been tampered with.

Less common but useful

SSHFP (SSH fingerprint)

Publishes the fingerprint of an SSH host key in DNS, allowing clients to verify server identity without TOFU (trust on first use). Requires DNSSEC to be meaningful.

NAPTR (naming authority pointer)

Used in ENUM (telephone number to URI mapping) and SIP routing. Provides rewriting rules that transform one string into another, often used in conjunction with SRV records.

HTTPS / SVCB (service binding)

Newer record types (RFC 9460) that allow a domain to advertise HTTPS capabilities, supported protocols (HTTP/2, HTTP/3), and alternative endpoints in a single DNS lookup. These records can eliminate the need for separate A/AAAA lookups and HTTP redirects from port 80 to 443.

TTL consistency

The Time-to-Live (TTL) value on a DNS record tells resolvers how long to cache the response. When different record types for the same domain have wildly different TTLs, it creates operational problems that are hard to diagnose.

Consider a domain with A records at TTL 300 (5 minutes) and MX records at TTL 86400 (1 day). If you migrate to a new server and update both records simultaneously, the A record propagates in minutes while the MX record takes up to a day. During that window, web traffic reaches the new server but email still routes to the old one. If the old server is decommissioned, email bounces for up to 24 hours.

Common TTL consistency issues:

Mixed TTLs on related records -- A and AAAA records for the same hostname should have the same TTL. If A is 300 and AAAA is 3600, a DNS change propagates at different speeds for IPv4 and IPv6 clients.
High TTL on records that change -- MX, A, and CNAME records involved in migrations should have their TTLs lowered well before the change (at least one full TTL cycle before). A 86400 TTL means you need to lower it at least 24 hours before the actual migration.
Very low TTLs without reason -- TTLs under 60 seconds increase DNS query volume significantly. This is appropriate during active migrations or for DNS-based failover, but should not be the permanent state. Low TTLs increase latency (more cache misses) and load on authoritative servers.
Inconsistent TTLs in an RRset -- all records of the same type at the same name must have the same TTL (RFC 2181 Section 5.2). A records at the same name with TTLs of 300 and 3600 violate the standard and cause unpredictable resolver behavior.

A reasonable default is 300-3600 seconds for records that may change (A, AAAA, MX, CNAME) and 86400 for stable records (NS, SOA, DNSKEY). The key is consistency within related record groups and intentional lowering before planned changes.

Common mistakes

CNAME at the apex: You cannot put a CNAME at the zone root because it conflicts with the required SOA and NS records. Use an A/AAAA record, or if your DNS provider supports it, a provider-specific alias record (ALIAS, ANAME).
Multiple SPF TXT records: SPF requires exactly one TXT record starting with v=spf1. Multiple records cause evaluation to fail.
TTL too high during migrations: Lower your TTL well before changing records. A 86400-second (1-day) TTL means some resolvers will serve stale data for up to 24 hours after a change.
Missing trailing dot in zone files: In zone file syntax, example.com without a trailing dot is relative to the zone origin. Write example.com. (with the dot) for fully qualified names.
No CAA records: Without CAA, any CA can issue a certificate for your domain. Publishing CAA records is a simple, effective measure against unauthorized certificate issuance.

DNS Record Types Explained