DNS Records: Types and Functions

A zone file is a collection of resource records. There are about 100 defined record types, but you'll use about 10 in practice. Here's what actually matters, with the mistakes that actually happen in production.

Every DNS record has this structure:

<name>  <TTL>  <class>  <type>  <rdata>

The class is almost always IN (Internet). The type is what most people mean when they say "DNS record type." The rdata is type-specific.

A Record

Maps a hostname to an IPv4 address.

api.example.com.    300    IN    A    93.184.216.34

The simplest record. You probably set these constantly. A few things worth knowing:

You can have multiple A records for the same name (round-robin load distribution). This is not the same as load balancing — the resolver returns all records, the client picks one, and there's no health checking. A server goes down, clients keep trying it until the TTL expires and they get an updated set.

www.example.com.    60    IN    A    192.0.2.1
www.example.com.    60    IN    A    192.0.2.2
www.example.com.    60    IN    A    192.0.2.3

TTL matters here. If you're running a service where IPs change (autoscaling, failover), keep TTLs short. If your IPs are stable, longer TTLs reduce resolver load and speed up resolution for end users.

AAAA Record

Same as A, but for IPv6.

api.example.com.    300    IN    AAAA    2606:2800:220:1:248:1893:25c8:1946

Common mistake: adding AAAA records without validating your IPv6 connectivity end-to-end. Clients that get a AAAA record will try IPv6 first (Happy Eyeballs algorithm, RFC 8305). If your IPv6 path is broken, you get connection timeouts before the fallback to IPv4. This looks like intermittent slowness and is a pain to diagnose.

CNAME Record

Canonical Name. Maps one name to another name (not an address).

www.example.com.    300    IN    CNAME    example.com.
blog.example.com.   300    IN    CNAME    example.ghost.io.

When a resolver encounters a CNAME, it follows the chain — querying for the target name until it reaches something that resolves to an address.

The apex domain restriction: You cannot put a CNAME at the zone apex (the bare domain — example.com.). An apex record must also hold SOA and NS records, and a CNAME cannot coexist with other records of the same name. This is in RFC 1034. It's not optional.

This trips people up constantly. You can't CNAME example.com. to lb.provider.com.. Various DNS providers work around this with proprietary record types (Cloudflare's CNAME flattening, AWS Route 53's ALIAS records, Azure Traffic Manager's ALIAS). These are not standard DNS — they're client-side resolution tricks that return A records while appearing to be CNAMEs. They work, but they're not portable.

MX cannot point to a CNAME: RFC 2181, section 10.3. Mail servers do an MX lookup, get a name, then do an A/AAAA lookup on that name. If the MX value is a CNAME, some mail servers will refuse the lookup entirely. Always point MX records directly to A records.

CNAME loops: a.example.com CNAME b.example.com and b.example.com CNAME a.example.com will cause resolution failures. Resolvers have hop limits (typically 8-10), but the error messages are cryptic.

MX Record

Mail exchange. Specifies the mail servers for a domain.

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

The number before the hostname is the priority. Lower number = higher priority. If mail1 is up, all mail goes there. If mail1 is unreachable, sending MTAs try mail2.

Always verify your MX targets have A records. Setting an MX to a hostname that doesn't resolve means your mail bounces. This happens.

If you're using a mail provider (Google Workspace, Microsoft 365), they give you specific MX values. Copy them exactly. Don't add your own alongside theirs unless you know what you're doing — you'll split your inbound mail.

TXT Record

Arbitrary text data. Was originally for human-readable information. Now it's the dumping ground for everything that doesn't have its own record type.

example.com.    300    IN    TXT    "v=spf1 include:_spf.google.com ~all"
example.com.    300    IN    TXT    "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com"
_domainkey.example.com.    300    IN    TXT    "v=DKIM1; k=rsa; p=MIGfMA0..."

In practice, TXT records carry:

SPF: Which servers are allowed to send email for your domain
DKIM: Public key for signing verification of outbound email
DMARC: Policy for handling email that fails SPF/DKIM
Domain verification: Google Search Console, AWS SES, and many others verify domain ownership via TXT records
ACME challenges: Let's Encrypt DNS-01 validation places temporary TXT records

You can have multiple TXT records on the same name. SPF, DMARC, and a verification token can all coexist at example.com.. What you cannot do is have multiple SPF records — SPF specifies exactly one TXT record with v=spf1, and multiple will cause SPF evaluation to fail (RFC 7208, section 3.2).

NS Record

Nameserver. Specifies which servers are authoritative for a zone.

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

NS records appear in two places: the parent zone (the delegation) and the zone itself (the apex NS records). These should match. If they don't, you have a "lame delegation" — the parent points to servers that don't think they're authoritative. The result is SERVFAIL for your entire domain.

To check for lame delegations:

# What the TLD thinks your nameservers are
dig example.com NS @a.gtld-servers.net

# What your nameservers claim
dig example.com NS @ns1.provider.com

If these differ, something is wrong.

SOA Record

Start of Authority. Every zone has exactly one. It's the zone's administrative record.

example.com.    3600    IN    SOA    ns1.provider.com. hostmaster.example.com. (
                                     2024031501    ; serial
                                     3600          ; refresh
                                     900           ; retry
                                     604800        ; expire
                                     300 )         ; minimum TTL (negative caching)

Fields:

Primary nameserver: The primary NS for this zone (used in zone transfers)
Responsible party email: With the first . replaced by @ — so hostmaster.example.com means hostmaster@example.com
Serial: Must increment on every zone change. Secondary nameservers compare serial numbers to decide whether to transfer the zone. If you update records without incrementing the serial, secondaries won't pick up the changes.
Refresh: How often secondaries check for updates (seconds)
Retry: How long secondaries wait before retrying a failed zone transfer
Expire: How long secondaries serve the zone if they can't reach the primary
Minimum TTL: Used as the TTL for NXDOMAIN (negative) responses — "this name doesn't exist, cache this for N seconds"

PTR Record

Pointer. The reverse of an A record — maps an IP address to a hostname. Used for reverse DNS lookups.

34.216.184.93.in-addr.arpa.    3600    IN    PTR    api.example.com.

The IP address is reversed and appended to in-addr.arpa. (or ip6.arpa. for IPv6). Authority for these zones is delegated to whoever owns the IP block.

For most people, this means: your hosting provider controls your PTR records, and you need to request them through their interface or API. You can't set PTR records in your own DNS zone unless you also own the IP block.

PTR records matter for:

Mail server reputation (many spam filters check that the sending IP has a matching PTR and that the PTR resolves back to the same IP — "forward-confirmed reverse DNS" or FCrDNS)
Logging and monitoring (makes log analysis readable)
Some security tools and network equipment that look up source IPs

SRV Record

Service locator. Used for service discovery.

_xmpp-server._tcp.example.com.    3600    IN    SRV    10    5    5269    xmpp.example.com.

Format: priority, weight, port, target.

SRV records are used by SIP (VoIP), XMPP, some Kubernetes service discovery, and Microsoft protocols (Active Directory, Exchange). If you're not doing these, you may never write an SRV record manually. But you'll see them when debugging email or VoIP issues.

CAA Record

Certification Authority Authorization. Specifies which CAs are allowed to issue TLS certificates for your domain.

example.com.    3600    IN    CAA    0    issue    "letsencrypt.org"
example.com.    3600    IN    CAA    0    issuewild    "sectigo.com"
example.com.    3600    IN    CAA    0    iodef    "mailto:security@example.com"

Tags:

issue: Which CA can issue single-name certificates
issuewild: Which CA can issue wildcard certificates
iodef: Where to send violation reports

If you have no CAA records, any CA can issue for your domain. If you add CAA records, only listed CAs can issue. CAs are required to check CAA before issuing (RFC 6844, mandatory since 2017).

The failure mode: you add a CAA record for your main CA, then Let's Encrypt tries to renew a certificate and fails with a CAA check error. This happens at 2am when renewals run. Add "letsencrypt.org" to your CAA records if you use Let's Encrypt anywhere in your infrastructure, even for internal services.

DNSSEC Record Types

If DNSSEC is enabled on a domain, you'll see four additional record types in the zone. You rarely write these by hand — your DNS software generates and manages them. But you need to know what they are when you're debugging DNSSEC validation failures.

DNSKEY: Holds the public key used to sign zone data. A zone has at least two: the Zone Signing Key (ZSK), which signs individual records, and the Key Signing Key (KSK), which signs the DNSKEY set. The distinction matters for key rollovers.

dig example.com DNSKEY

RRSIG: The actual signature. Every signed RRset gets an RRSIG record alongside it. Contains the signature itself plus metadata: signing algorithm, expiry time, the key tag (which DNSKEY was used to sign it).

dig example.com A +dnssec
# Answer section includes both A record and its RRSIG

DS (Delegation Signer): Lives in the parent zone (not the child zone). Contains a hash of the child zone's KSK. This is the link that creates the chain of trust from the root down. When you enable DNSSEC, you publish a DS record at your registrar — they put it in the TLD zone.

dig example.com DS
# Returns the DS record from the TLD zone

NSEC / NSEC3: Authenticated denial of existence. When a query returns NXDOMAIN, the resolver can't just trust the negative response unless it can be signed. NSEC creates a signed chain of all existing names in the zone; NSEC3 does the same but with hashed names to prevent zone enumeration.

dig nonexistent.example.com A +dnssec
# Returns NSEC/NSEC3 record proving the name doesn't exist

To check if DNSSEC validation is passing for a domain:

dig example.com A +dnssec +cd
# +cd disables checking — if you get an answer here but SERVFAIL without +cd,
# you have a DNSSEC validation failure

# Or use the dedicated validator
dig @8.8.8.8 example.com A +dnssec
# Look for the 'ad' (Authenticated Data) flag in the response

If dig returns SERVFAIL and dig +cd returns an answer, something in the DNSSEC chain is broken: expired RRSIG, missing DS record, mismatched keys after a key rollover, or NSEC records that don't match the zone contents.

Record Types You'll Encounter But Rarely Write

NAPTR: Used in VoIP/telephony. Complex. Hopefully someone else set it up.
TLSA: DANE (DNS-Based Authentication of Named Entities). Associates a TLS certificate with a domain name via DNS. Requires DNSSEC. Mostly used in email (SMTP MTA-STS alternative).

Key Takeaways

A and AAAA for addresses, CNAME for aliases, MX for mail, TXT for everything else.
Never CNAME an apex domain. Never point MX at a CNAME. These are hard rules, not preferences.
SOA serial must increment on every zone change or secondaries won't update.
CAA records control which CAs can issue certificates for your domain. Forgetting to include your actual CA causes certificate renewal failures.
PTR records are controlled by IP block owners, not domain owners.

Up Next

You know what records exist. Next: how a resolver actually finds them — the full journey from query to answer.