DNS Record Types: An Overview

Every DNS record answers a question. Not just "what's the IP address?" but "where should mail go?" and "who can issue certificates for this domain?" and "can I trust this response?"

The record type is the question being asked. The record data is the answer.

The Grammar of DNS

Resource records follow a simple structure: name, type, class, TTL, and data. But the type field is where meaning lives. It transforms raw data into instructions.

The data 192.0.2.1 means nothing on its own. Put it in an A record, and it becomes an instruction: connect here. The type is the verb.

Address Records: A and AAAA

A records answer the most fundamental question: "What IPv4 address should I connect to?"

example.com.    A    192.0.2.1

When your browser needs to reach example.com, it asks for the A record and gets an address to connect to. This is the foundation everything else builds on.

AAAA records answer the same question for IPv6:

example.com.    AAAA    2001:db8:85a3::8a2e:370:7334

The name isn't arbitrary—IPv6 addresses are four times longer than IPv4, so four A's. Modern sites should have both. The Internet is bilingual now.

CNAME Records: The Redirect

A CNAME doesn't point to a place—it points to another question.

www.example.com.    CNAME    example.com.

"Where is www.example.com?" "Go ask example.com."

The resolver follows the trail, looking up example.com's A record to find the actual address. This indirection is powerful for CDNs and cloud services—they can change their IP addresses without you touching your DNS.

But CNAME has a constraint: you can't use one at the apex (the bare domain). CNAME means "this name is that name"—a complete alias. The apex already has NS and SOA records that can't be aliased. A CNAME there would create a logical contradiction: the name can't both be something else and have its own authoritative records.

MX Records: Mail Routing

MX records answer: "Where should mail for this domain be delivered?"

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

The number is priority—lower means "try first." If mail1 is down, senders try mail2. Redundancy built into the protocol itself.

Notice that MX records point to hostnames, not IP addresses. The mail server's hostname needs its own A record. This indirection lets you move mail servers without updating everyone else's DNS.

TXT Records: The Escape Valve

TXT records hold text. That simplicity makes them infinitely flexible:

SPF declares which servers can send mail as you:

example.com.    TXT    "v=spf1 include:_spf.google.com ~all"

DKIM provides public keys for email signature verification:

selector._domainkey.example.com.    TXT    "v=DKIM1; k=rsa; p=MIGf..."

Domain verification proves you control a domain:

example.com.    TXT    "google-site-verification=abc123..."

TXT records became the escape valve for everything DNS wasn't designed to do. Need to store arbitrary data for a service? TXT record.

NS Records: Delegation

NS records answer: "Who has authority over this zone?"

example.com.    NS    ns1.provider.com.
example.com.    NS    ns2.provider.com.

These point to the name servers that can answer questions about your domain. Every domain needs at least two for redundancy.

NS records also enable subdomain delegation. Want api.example.com managed by a different DNS provider? Add NS records for that subdomain pointing to their servers. Authority transfers cleanly.

PTR Records: Reverse Lookup

Most DNS queries ask: "What's the address for this name?" PTR records answer the reverse: "What name belongs to this address?"

This matters for trust. When a mail server connects claiming to be mail.example.com, the receiving server can verify: "You say you're mail.example.com. Does your IP address agree?" If the PTR record for that IP points somewhere else, that's suspicious.

PTR records live in special reverse zones (like 1.2.0.192.in-addr.arpa) and are managed by whoever owns the IP address—usually your hosting provider, not you.

SOA Records: Zone Metadata

Every DNS zone has exactly one SOA (Start of Authority) record. It's administrative metadata: the primary name server, contact email, serial number, and timing values that control how secondary servers sync.

You rarely edit SOA records directly. But when DNS changes aren't propagating, the serial number is often the culprit—it must increment for secondaries to notice updates.

Specialized Records

SRV: Service Discovery

SRV records answer: "Where is the server for this specific service?"

_sip._tcp.example.com.    SRV    10 5 5060 sipserver.example.com.

For SIP over TCP, connect to sipserver.example.com on port 5060. The numbers handle priority and load balancing. SRV records advertise not just where services are, but how to connect.

CAA: Certificate Control

CAA records answer: "Which certificate authorities can issue certificates for this domain?"

example.com.    CAA    0 issue "letsencrypt.org"

Before issuing a certificate, CAs must check CAA records. If you've declared only Let's Encrypt can issue for your domain, other CAs will refuse. This prevents unauthorized certificate issuance—a real attack vector that has been exploited.

DNSKEY: Cryptographic Trust

DNSSEC adds signatures to DNS responses, and DNSKEY records hold the public keys for verification. This prevents attackers from forging responses.

Most domain owners don't touch DNSKEY records directly—your DNS provider handles the cryptography. But knowing they exist explains how DNS can be secured against spoofing.

Choosing Records