DNS Records Explained: The 30-Second Model
Every "my site is down" and half of all "my emails go to spam" incidents trace back to DNS. Yet DNS itself is simple — it's a distributed phone book that maps names to values, with aggressive caching layered on top. The caching is what makes it feel mysterious.
Here's resolution in 30 seconds. When your browser asks for app.example.com, your OS asks a resolver (your ISP's, or 1.1.1.1 / 8.8.8.8). If the resolver doesn't have the answer cached, it walks the hierarchy: the root servers point it to the .com servers, which point it to example.com's authoritative nameservers (the ones set at your registrar), which return the actual record. The resolver caches that answer for the record's TTL (time-to-live, in seconds) and serves it from cache until it expires.
That's it. Everything else is record types and cache behavior.
What Do the Main DNS Record Types Do?
| Record | Maps a name to... | Typical use |
|---|---|---|
| A | An IPv4 address | example.com → 203.0.113.10 |
| AAAA | An IPv6 address | example.com → 2001:db8::1 |
| CNAME | Another name (alias) | www → example.com, app → myapp.pages.dev |
| MX | Mail server hostname + priority | Where email for @example.com gets delivered |
| TXT | Arbitrary text | SPF, DKIM, DMARC, domain-ownership verification |
| NS | Authoritative nameservers | Delegates the zone (e.g. to Cloudflare) |
| SOA | Zone metadata | Serial number, refresh timers — mostly automatic |
| CAA | Allowed certificate authorities | 0 issue "letsencrypt.org" blocks rogue cert issuance |
| SRV | Service host + port | SIP, XMPP, some game and federation protocols |
A few rules that trip people up:
- A CNAME cannot coexist with any other record on the same name. That's why you can't put a CNAME at the domain apex (
example.com) — the apex must carry SOA and NS records. More on this below. - MX records point to hostnames, never IPs — and that hostname must resolve via an A/AAAA record, not a CNAME.
- TXT records are where modern email lives. SPF, DKIM and DMARC are all just TXT records with conventions.
You can inspect any of these for any domain with a DNS Lookup — query each record type and see exactly what the world sees.
TTL and the Propagation Myth
"DNS propagation takes 24–48 hours" is one of tech's most persistent half-truths. DNS doesn't push changes anywhere. When you update a record, the authoritative server answers with the new value immediately. What takes time is cache expiry: every resolver that looked up your record before the change keeps serving the old answer until its cached copy's TTL runs out.
Practical consequences:
- Lower the TTL before a planned change. If your record has a 24h TTL, drop it to 300 (5 minutes) at least 24 hours before migration day. After the switch, raise it back.
- Different users see different results during the window — that's normal, it's their resolvers' caches at different stages.
- A DNS Propagation checker queries resolvers around the world at once, showing you exactly which regions have picked up the new value and which are still serving stale cache.
# See the remaining TTL count down on a cached answer
dig example.com A +noall +answer
# example.com. 212 IN A 203.0.113.10 ← 212 seconds left in this resolver's cache
Common Tasks, Done Right
Pointing a domain at a server
Root domain → A record to the server's IP. www → CNAME to the root. Hosting on a platform (Vercel, Cloudflare Pages, GitHub Pages)? They'll give you either an IP for an A record or a target hostname for a CNAME — follow their doc exactly, since platform IPs can change.
The CNAME-at-apex problem
Platforms love to say "just CNAME your domain to myapp.platform.dev" — but the RFC forbids CNAME at the apex. Solutions: use a DNS provider with CNAME flattening or ALIAS/ANAME records (Cloudflare, Route 53, DNSimple), or redirect the apex to www and CNAME the www.
Email records: SPF, DKIM, DMARC
Three TXT records decide whether your email lands in inboxes:
; SPF — who may send mail claiming to be you
example.com. TXT "v=spf1 include:_spf.google.com -all"
; DKIM — public key to verify your messages' signatures
s1._domainkey.example.com. TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSq..."
; DMARC — what receivers should do when SPF/DKIM fail
_dmarc.example.com. TXT "v=DMARC1; p=quarantine; rua=mailto:[email protected]"
Gotchas: only one SPF record per domain (multiple records = SPF fails entirely), maximum 10 DNS lookups inside the SPF chain, and start DMARC at p=none to monitor before enforcing.
A Debugging Workflow for "The Domain Doesn't Work"
Work top-down — each step rules out a layer:
1. Does the domain even exist and point where you think? A WHOIS Lookup shows registration status, expiry date (expired domains are a classic silent killer), and the delegated nameservers. If the nameservers listed at the registrar aren't the ones you're editing records on, nothing you change will ever take effect.
2. Do the authoritative servers return the right answer?
dig @ns1.your-dns-provider.com example.com A +short
Querying the authoritative server directly bypasses all caching. Wrong answer here = the record itself is wrong or missing.
3. Do public resolvers agree?
dig @1.1.1.1 example.com A +short
dig @8.8.8.8 example.com A +short
Authoritative is right but resolvers are stale → it's a TTL wait, not a bug. Check global status with a propagation checker rather than refreshing in panic.
4. Is it actually DNS? If the name resolves but the site still fails, DNS is innocent. Check that the server answers on ports 80/443, and verify the certificate matches the hostname with an SSL Checker — a cert issued for the old domain, or an expired one, produces errors that look like DNS problems but aren't.
5. Nuke your local cache last. sudo systemd-resolve --flush-caches (Linux), sudo dscacheutil -flushcache (macOS), ipconfig /flushdns (Windows). Browsers keep their own DNS cache too — chrome://net-internals/#dns.
The order matters: most people start at step 5 and work backwards, wasting an hour flushing caches when the real problem was nameserver delegation at step 1.
Check Any Domain Now
Run a DNS Lookup on any domain to see its A, CNAME, MX, TXT and NS records in seconds. No account required.