DNS records explained: A, AAAA, CNAME, MX, TXT, NS and CAA, and why changes take time

DNS is the layer everyone edits nervously. The form is small, the feedback is delayed, and a typo takes the website or the email down for everyone who has already cached it. Most of that anxiety comes from two things being poorly explained: what each record type is actually for, and why a change you made an hour ago is visible from your laptop but not from your colleague’s. This guide covers the record types you will genuinely touch, the apex-CNAME rule that trips up every first-time deploy, how TTL and caching produce the phenomenon people call propagation, the three TXT records that decide whether your mail is delivered, and how to read what the DNS lookup here tells you — including the honest caveat about where that answer comes from.

What happens when a name is resolved

Your device asks a recursive resolver— your ISP’s, your company’s, or a public one like 1.1.1.1 or 8.8.8.8. If it does not have the answer cached, it walks down the tree: a root server points it at the .com nameservers, those point it at the nameservers for your domain, and those — the authoritative servers — give the real answer. The resolver caches it for the TTL and returns it.

Everything confusing about DNS follows from that cache. There is no push, no broadcast, no synchronisation. When you edit a record, the authoritative servers change instantly and every resolver in the world keeps serving its stale copy until the clock runs out.

One thing to know about the lookup tool here: browsers cannot speak raw DNS on UDP port 53, so it queries over DNS-over-HTTPS against Cloudflare or Google — whichever you pick — and shows you that resolver’s answer, with its remaining TTL. That is a genuine third-party request, and it is the one tool on this site that makes one; the domain name you type is the only thing sent. It also means you are seeing a public resolver’s cache, which is usually what you want when checking “has my change reached the world yet”, and is not the same as what your own network’s resolver would say.

The record types

The lookup tool can query any of these individually, or run a “common” sweep of A, AAAA, CNAME, MX, TXT and NS in one go — which is the fastest way to see the overall shape of a domain, including the answer to “is this thing even pointed at us?”

The apex CNAME rule

This is the rule that breaks the first deploy of nearly every static site. A CNAME means “this name is an alias; look up that name instead”, and the specification says a name with a CNAME may have no other records. But the apex of your zone — example.com with nothing in front of it — must carry SOA and NS records. So a CNAME at the apex is forbidden, and most providers simply refuse to save it.

Three ways out, in order of preference:

• ALIAS / ANAME / CNAME flattening. A provider-side feature: the nameserver resolves the target itself and answers with A and AAAA records, so clients see something legal. Route 53, Cloudflare, DNSimple and most modern hosts have it under one of those names.
• Point the apex at an IP and use a CNAME only for www. Fine when the target has a stable address; fragile with a platform that changes IPs.
• Redirect the apex. Serve a redirect from apex to www at the edge, and let www be the CNAME.

A related gotcha: because a CNAME excludes all other records, you cannot put a CNAME on a name that also needs an MX or TXT record. This is why adding a verification TXT to a subdomain already aliased to a SaaS provider fails, and why mail for a CNAME’d subdomain quietly stops.

TTL, caching, and the thing that is not propagation

Every answer carries a TTL in seconds, and the lookup tool shows it next to each record. A resolver may serve that answer, unchanged, until the TTL expires. So the practical procedure for any planned change is:

1. A day or two before, lower the TTL on the records you will change to 300 seconds. Wait for the old, longer TTL to expire everywhere.
2. Make the change. Resolvers now pick it up within five minutes.
3. Once you are happy, put the TTL back up — 3600 or higher — so you are not paying for a lookup on every request.

Two subtleties. First, negative answers are cached too: if you query a name before creating it, the “does not exist” is cached for theduration in your SOA record’s minimum field, which is why a record you just added still 404s and then works fine an hour later. Create the record first, then test. Second, some resolvers and many operating systems clamp or ignore very short TTLs, and browsers keep their own DNS cache on top — so “it works everywhere except my machine” is usually a local cache, not the zone.

The three TXT records that decide whether your email arrives

Email authentication is entirely DNS, and getting it wrong is the most common cause of mail landing in spam:

• SPF lists who may send as your domain: v=spf1 include:_spf.google.com ~all. Rules that matter — exactly one SPF record per domain (two is a permanent error), a maximum of ten DNS lookups across all your include, a, mx and redirect mechanisms, and a final ~all (soft fail) or -all (hard fail) rather than +all, which authorises the entire internet.
• DKIM publishes a public key at selector._domainkey.example.com. Your mail provider signs outgoing messages with the private half; receivers fetch the key and verify. Multiple selectors coexist happily, which is how you rotate keys or run several senders.
• DMARC at _dmarc.example.com ties the two together and tells receivers what to do when they fail: v=DMARC1; p=none; rua=mailto:…. Start at p=none with reports going somewhere you will read them, confirm your legitimate mail passes, then move to quarantine and finally reject. Going straight to reject is how a company discovers its invoicing system was sending mail nobody had authorised.

All three are TXT records, so the lookup tool shows them in one query — and reading them directly is much faster than trusting a provider’s dashboard, which often shows what it intended to publish.

CAA: who is allowed to issue your certificates

A CAA record names the certificate authorities permitted to issue for your domain: 0 issue "letsencrypt.org", with issuewild for wildcards and an iodef address to be notified of refused attempts. Certificate authorities are obliged to check it before issuing and to refuse if they are not listed, and the check walks up the tree — so a record at the apex covers subdomains that have none of their own.

Two things it does not do: it has no effect on certificates that already exist, and browsers never look at it. It is a control on issuance. The most common way it bites is self-inflicted — you add a CAA for one provider, then a year later a different platform tries to provision a certificate and fails with an error that never mentions DNS. If certificate issuance suddenly fails on a domain that has been fine for years, check CAA before anything else.

For the certificates themselves — what is inside them, whether the chain is complete, when they expire — the certificate checkerhere reads the files you drop into it (PEM, DER, P7B or PFX) and verifies the chain in your browser. It inspects certificates you hold rather than fetching a live server, which is the right tool when you are staging a renewal and the wrong one for “what is that host serving right now”.

DNSSEC and the AD flag

DNSSEC signs DNS answers so a resolver can detect tampering. When a validating resolver has checked the signatures, it sets the AD (Authenticated Data) flag on the response — and the lookup tool surfaces it, so you can tell at a glance whether the answer was validated rather than merely received.

The failure mode is worth knowing because it is dramatic: if your zone is signed and the signatures are wrong or expired, validating resolvers do not fall back to an unvalidated answer — they return SERVFAIL and your domain vanishes for everyone using them. A SERVFAIL that only some resolvers show is a DNSSEC problem until proven otherwise. This usually happens after a nameserver migration where the DS record at the registrar was not updated in step.

Reading a broken domain, in order

1. NS first.Are the authoritative nameservers what you expect? Half of all “my DNS change did nothing” reports are edits made at the registrar while the domain is served by someone else.
2. Then the record itself, with its TTL. A record that exists with a long TTL and a wrong value tells you how long the wrong answer will linger.
3. Read the status. NXDOMAIN means the name genuinely does not exist; an empty answer with a success status means the name exists but has no record of that type — a completely different problem. SERVFAIL points at DNSSEC or a broken authoritative server; REFUSED means the resolver declined to answer at all.
4. Compare two resolvers. Query Cloudflare and Google for the same name; a difference is a cache in the middle of expiring, not a broken zone.
5. Then look locally. Flush the OS cache, and remember the browser has one of its own.