The Complete Guide to DNS Record Types: From A Records to Troubleshooting

Editing DNS is one of the highest-leverage operations in operations work: you change a few lines of text, and you can take an entire site down or silently lose all inbound email — and when something breaks, it can take hours before you’re even sure. Most people only ever touch A records and CNAMEs, then discover their understanding is skin-deep the first time an MX misconfiguration or a CAA-blocked certificate issuance bites them. This guide walks through the record types that matter, how TTL caching really behaves, and a troubleshooting workflow you can reuse.

What DNS Resolution Actually Does

DNS is, at its core, a distributed key-value database: the key is a domain name, and the values are records of various types. When you type example.com into a browser, roughly this happens:

The browser and OS check their local caches first; a hit means no network traffic at all.
On a miss, the query goes to a recursive resolver — usually run by your ISP or company, or a public one like 8.8.8.8 or 1.1.1.1.
The resolver starts at the root servers, asks the .com TLD servers, then asks example.com’s authoritative servers, caches the answer, and returns it to you.

The crucial insight: your laptop almost never talks to authoritative servers directly. Layers of caching sit in between. That single fact explains the two classic DNS phenomena — changes don’t take effect instantly worldwide (old caches haven’t expired), and different regions can see different answers at the same moment (their caches are in different states). Keep this chain in mind; TTL and troubleshooting build directly on it.

A Records: IPv4 Addresses

The A (Address) record is the workhorse — it maps a name to an IPv4 address:

example.com.    300    IN    A    93.184.216.34

A single name can hold multiple A records, and resolvers return all of them; clients typically round-robin through the list. That’s the crudest form of load balancing, and it comes with a caveat: DNS round-robin has no health checking. If one machine dies, a fraction of your users still get the dead address. Production load balancing belongs to a real LB or CDN, not a pile of A records.

AAAA Records: IPv6 Addresses

AAAA records are structurally identical to A records, except they point to an IPv6 address. The name is a joke about size: IPv6 addresses are 128 bits, four times the 32 bits of IPv4 — hence four A’s:

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

The usual pattern is to publish both A and AAAA. IPv6-capable clients prefer AAAA; everything else falls back to A. Publish only an A record, and users on IPv6-only networks may not reach you at all.

CNAME Records: Aliases

A CNAME (Canonical Name) record says “this name is just an alias for that other name,” and resolution follows the alias:

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

Ask for the A record of www.example.com, and the resolver sees the CNAME, goes off to resolve example.com’s A record, and returns the whole chain. The everyday use case is pointing subdomains at third-party services — a CDN or hosted platform that hands you a hostname.

MX Records: Where Mail Gets Delivered

MX (Mail Exchange) records tell the world which servers accept email for your domain. They carry an extra priority field — lower numbers win:

example.com.    300    IN    MX    10 mail.example.com.
example.com.    300    IN    MX    20 backup-mx.example.com.

Senders try priority 10 first, and fall back to 20 on failure. Two rules trip people up: the MX target must be a hostname (which itself resolves via A/AAAA records), not an IP address — and it must not be a CNAME. More on both in the misconfiguration section.

TXT Records: Verification and Policy Text

TXT records let you attach arbitrary text to a name. In practice they serve two dominant purposes: domain ownership verification and email anti-spoofing policy:

example.com.    300    IN    TXT    "v=spf1 include:_spf.example.net ~all"
example.com.    300    IN    TXT    "google-site-verification=abc123..."
_dmarc.example.com. 300 IN  TXT    "v=DMARC1; p=quarantine"

SPF (which servers may send mail for you), DKIM public keys, DMARC policy, and every “prove you own this domain” check from SaaS platforms all live in TXT records. A name can hold many TXT records at once; they don’t interfere with each other.

NS and SOA: Delegation and Zone Management

NS (Name Server) records declare which authoritative servers are responsible for this zone:

example.com.    172800    IN    NS    ns1.dns-provider.com.

When you “change nameservers” at your registrar, you’re updating the NS records the parent zone holds for you. The reason a DNS provider migration “takes a day or two to propagate” is that NS records typically carry long TTLs, and resolvers everywhere are sitting on cached copies.

SOA (Start of Authority) is the one record every zone must have exactly once. It holds administrative metadata: the primary nameserver, the admin contact, a serial number (secondary servers compare serials to detect zone updates), plus refresh, retry, expiry, and negative-caching timers. You’ll rarely edit the SOA by hand, but you’ll see it constantly in dig output.

CAA and SRV: Less Common, Still Useful

CAA (Certification Authority Authorization) records declare which certificate authorities may issue certificates for your domain:

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

With CAA in place, issuance requests from any CA not on the list are refused — a real defense against mis-issuance. The classic gotcha: you restricted CAA to one CA on the main domain, and months later a certificate request from a different CA fails mysteriously for a subdomain. CAA records are inherited down the tree, so the parent policy applies unless the subdomain overrides it.

SRV (Service) records describe “which host and port provides this service,” with priority, weight, and port fields:

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

You’ll meet SRV in SIP, XMPP, and Minecraft server setups. Ordinary websites never need it, but when you see an underscore-prefixed name like _service._protocol.domain, now you know what it is.

To see what records a domain currently publishes without opening a terminal, the DNS Lookup tool shows the resolved records for a domain directly.

Why CNAME Can’t Coexist With Other Records

This is the most commonly violated DNS rule: once a name is a CNAME, it may not hold any other record type (DNSSEC internals aside). The logic is sound — a CNAME means “everything about this name is defined by that other name,” so a simultaneous A record would create an irresolvable contradiction about which answer is authoritative.

The famous consequence: your apex domain (example.com) cannot be a CNAME. The apex must carry SOA and NS records, and a CNAME can’t coexist with them — so example.com CNAME cdn.example.net is invalid. This is why so many CDN setups point www at the provider and leave the bare domain as an awkward special case.

Workarounds: use A/AAAA records pointing at the service’s IPs (you’re on the hook for updates when they change), or use a provider extension called CNAME Flattening, ALIAS, or ANAME, where the authoritative server resolves the target dynamically and returns A records as if the apex had them. These extensions are provider-specific, not part of the DNS standard — names, semantics, and edge cases differ between providers, and configs don’t necessarily port when you switch.

TTL and Caching Behavior

Every record carries a TTL (Time To Live), measured in seconds: how long the answer may be cached. The 300 in the examples above means five minutes. Once a recursive resolver has the answer, it serves the cached copy until the TTL expires without asking the authoritative server again.

TTL is a trade-off:

Long TTL (e.g., 86400 seconds, a full day): less load on authoritative servers, faster repeat resolution — but changes roll out slowly.
Short TTL (60–300 seconds): changes take effect in minutes, at the cost of more query traffic and slightly higher lookup latency.

The most valuable operational habit in this whole guide: before a planned migration, lower the TTL at least one full old-TTL period in advance. If the current TTL is 86400, drop it to 300 at least a day ahead, wait until the world’s caches hold the short-TTL version, then cut over the IP — the switch completes in minutes. Once things are stable, raise the TTL again. If you’ve ever changed a record and heard “works for me” from half the team and “still broken” from the other half, you were watching old TTLs expire in real time.

Common Misconfigurations

The DNS mistakes that actually happen in the field are a short list:

CNAME at the apex: invalid; most DNS providers refuse to save it, but some UIs let it through and produce bizarre resolution and mail failures. Use A/AAAA or your provider’s ALIAS-type feature instead.
MX pointing at a CNAME: explicitly forbidden by the RFCs. Point MX at a hostname that has its own A/AAAA records, like mail.example.com.
Not lowering the TTL before a migration: you change the IP, then realize the old answer is cached for a day, and all you can do is wait. See the previous section for the right sequence.
CNAME mixed with other records at the same name: e.g., a CNAME plus a TXT record on blog.example.com. It violates the coexistence rule and behaves unpredictably.
Stale data on the old provider during a nameserver switch: keep records identical on both the old and new authoritative servers during the transition window, or some users resolve stale data.
CAA too restrictive: only one CA is authorized, and a later certificate request from a different CA fails for reasons nobody connects to DNS.

Troubleshooting Workflow: dig, nslookup, and Propagation

DNS troubleshooting boils down to one question: is the authoritative data wrong, or are caches just stale? A reusable workflow:

Ask the authoritative server directly, bypassing every cache, to see the “truth”:

dig @ns1.dns-provider.com example.com A +short

If the authoritative answer itself is wrong, fix the configuration at your DNS provider.

Ask public recursive resolvers to see what’s cached:

dig @8.8.8.8 example.com A +short
dig @1.1.1.1 example.com MX

Compare steps 1 and 2: authoritative correct but recursive stale means caches haven’t expired — wait for the TTL or keep checking. Both agree but don’t match your expectation means the config change never actually landed.

Read the full response and the TTL countdown: plain dig example.com A (no +short) shows the remaining TTL — it decreases on every query — and which server answered. dig +trace example.com walks the entire delegation chain from root to authoritative, pinpointing which level is misbehaving. On systems without dig (stock Windows), nslookup example.com and nslookup -type=MX example.com cover most of the same ground.
Check propagation across regions: resolvers in different geographies hold different cache states. Without a terminal, the DNS Lookup tool gives you a quick read on current record values; combine it with the authoritative-vs-recursive comparison to decide whether you’re just watching propagation lag.
For mail problems, walk the MX chain: does the MX target hostname actually have an A record? Is the IP it resolves to the mail server you expect? The IP Address Lookup tool tells you who owns that IP, which catches the classic “mail is being delivered to a long-decommissioned server” case.

One often-missed prerequisite: DNS records are about hostnames, and the clue in your hand is often a full URL. Run it through the URL Parser to extract the hostname first — don’t paste paths and query strings into dig.

DNS has few rules, but each one is learned the hard way until someone writes them down: A is IPv4, AAAA is IPv6, CNAME is an exclusive alias, MX needs a priority and a non-alias target, TTL is in seconds and gets lowered before a migration. Internalize those, plus the authoritative-vs-recursive diagnostic, and most DNS incidents resolve in ten minutes.