DNS is the internet’s address book. People remember names, machines route to numbers, and DNS is the lookup in between. Every page you load starts with it: before a single byte of the site arrives, your device has to ask where that name lives.
Most of the confusion around DNS comes from two things — not knowing which record type answers which question, and not understanding why a change you made an hour ago still has not taken effect.
What actually happens when you type a name
Your device asks a resolver, usually run by your provider or by a public service. If the resolver already knows the answer it returns it immediately. If not, it works down the hierarchy: a root server points it at the servers for .com, those point it at the nameservers for your domain, and those — the authoritative servers — give the real answer.
That last step matters. The authoritative nameservers are the only place the truth lives. Everything else in the chain is a cache, and caches are the source of nearly every “but I already changed it” problem.
The record types worth knowing
A maps a name to an IPv4 address, and AAAA does the same for IPv6. These are the fundamental lookups — the thing that turns a hostname into somewhere to send packets.
CNAME makes one name an alias for another. The resolver finds the CNAME, then starts again on the name it points to. It is how you point www at a hosting provider without caring what address they use this week.
MX says where mail for the domain should be delivered. Each entry carries a number, and senders try the lowest first. It is a preference, not a ranking — a lower number just means try this one earlier, and equal numbers share the load.
TXT holds arbitrary text, and does far more work than that description suggests. Nearly all email authentication and almost every domain verification runs through it.
NS lists the nameservers with authority for the zone, SOA carries its serial number and timers, and CAA names which certificate authorities are allowed to issue certificates for the domain — a useful thing to set, and one almost nobody does.
You can read any of these for a live domain with the DNS lookup tool.
The CNAME rule that catches everyone
A CNAME cannot coexist with any other record on the same name. That sounds like a technicality until you try to put one on your bare domain — example.com rather than www.example.com — and your provider refuses.
The reason is that your bare domain must carry SOA and NS records, because it is the top of the zone. A CNAME there would conflict with both, so the standard forbids it.
The workaround is provider-specific. Many DNS hosts offer ALIAS, ANAME, or “CNAME flattening”, which resolve the target behind the scenes and hand back a plain A record. If your host does not, you are stuck pointing the apex at an address directly.
TTL, and why changes are not instant
Every record carries a TTL — the number of seconds a resolver may cache the answer before asking again. A record with a TTL of 3600 can be served from cache for an hour after you have changed it, by every resolver that happened to ask just before the edit.
This is why DNS changes appear to roll out gradually and inconsistently: different resolvers cached at different moments, so they expire at different moments. Nothing is propagating anywhere. Caches are simply timing out one by one.
The practical move is to lower the TTL before you need it. Drop it to 300 seconds a day ahead of a planned migration, make the change, then raise it again once things have settled. Lowering it at the same time as the change does nothing — the old TTL is already cached.
The email records, in one place
Three TXT records decide whether your mail is trusted, and they are easier to reason about as a set:
SPF lists which servers may send mail as your domain. It lives on the domain itself and starts v=spf1. There must be exactly one — two SPF records is a misconfiguration, not twice the protection.
DKIM publishes the public key used to sign your outgoing mail, so a receiver can verify the message was not altered. It lives on a subdomain like selector._domainkey.example.com, which means you have to query that exact name to see it.
DMARC lives at _dmarc.example.com and tells receiving servers what to do when a message fails the other two — nothing, quarantine it, or reject it. Starting at p=none and reading the reports before tightening is the standard, and sensible, order.
When a site is reachable but wrong
If DNS resolves correctly and the site still misbehaves, the problem has usually moved up a layer. Two things are worth checking before anything else.
The response headers and redirect chain will show whether requests are being bounced somewhere unexpected — an accidental loop, or a chain three hops longer than it needs to be, each hop a full round trip before anything renders. And if you are seeing an unfamiliar response code, the status code reference will tell you whether it is your problem or theirs.
For the network layer itself, the subnet calculator works out ranges and host counts from CIDR notation, and what is my IP tells you which address the internet currently sees you as — useful when a firewall rule or an allowlist is not behaving.
A short checklist
Before assuming DNS is broken: check the record actually exists at the name you think it does, remember that subdomains like _dmarc and _domainkey must be queried directly, confirm the TTL has had time to expire, and make sure you are not looking at a cached answer from your own machine. Most “DNS is broken” turns out to be one of those four.