Almost every "the site is down" ticket I've worked starts the same way: someone assumes it's the server, and it turns out to be DNS. Not because DNS is fragile — it's actually one of the more reliable parts of the internet's plumbing — but because it's invisible until it's wrong, and most people (including a fair number of engineers) only learn it properly after getting burned once.
This is the version of DNS I wish someone had handed me early in my hosting career: not the textbook definition, but which records actually matter, what breaks when they're wrong, and how to reason about a domain that "isn't working" without guessing.
What a DNS record actually does
A DNS record is a single instruction, published from your domain's nameservers, that answers one specific question: for this name, what's the value? An A record answers "what IPv4 address does this hostname point to." An MX record answers "which mail server should handle email for this domain." Every record type is narrow and single-purpose on purpose — that's what makes the system composable.
The part that trips people up is propagation. A DNS record isn't "live" the instant you save it — it's cached by resolvers around the internet for however long the record's TTL (time to live) says, which means a change can take anywhere from minutes to 48 hours to be visible everywhere, depending on what TTL was set before you changed it. If you're planning a migration, lowering TTLs a day or two in advance is the difference between a clean cutover and hours of "it works for me but not for my customer."
The records that matter most
A / AAAA — point a hostname directly at an IPv4 or IPv6 address. This is the record most people mean when they say "point my domain at my server."
CNAME — points a hostname at another hostname, not an IP. Useful for subdomains that should always track wherever the target resolves, but a CNAME can't coexist with other records on the same name — a rule that catches a lot of people trying to add both a CNAME and an MX on the same host.
MX — routes email for the domain to a specific mail server, with a priority value so you can define a primary and fallback. Get this wrong and mail doesn't bounce loudly — it often just fails silently or gets misrouted, which is worse.
TXT — free-form text, used far beyond its original purpose. This is where SPF, DKIM, and domain-verification records live. TXT records don't do anything by themselves; they're read by other systems (mail servers, verification services) that know how to interpret specific formats.
NS — declares which nameservers are authoritative for a domain or subdomain. Get this wrong at the registrar level and none of your other records matter, because nothing knows to ask your DNS provider in the first place.
CAA — specifies which certificate authorities are allowed to issue SSL certificates for your domain. An easy one to skip, and an easy one to use as a lightweight guardrail against unauthorized certificate issuance.
A troubleshooting order that actually saves time
When a domain "isn't working," I check things in a specific order, because most tools will happily lie to you if you skip a step:
- Confirm the domain's nameservers first, at the registrar, not at the DNS provider. If the registrar is still pointing at a previous host's nameservers, nothing you change in your current DNS panel matters yet.
- Query the record directly against an authoritative nameserver, not through your local resolver, to rule out a caching issue before you start debugging a record that's actually already correct.
- Check TTL on the record in question. A "wrong" answer that matches what the record used to say, five minutes after you changed it, usually isn't a bug — it's cache.
- Only then look at the application/server layer, once DNS is confirmed to be resolving where you expect.
Skipping straight to step 4 is the single most common time sink I see — restarting services, checking firewall rules, and re-deploying code, when the actual issue was a stale nameserver delegation from a domain transfer three days earlier.
Email is where DNS mistakes hurt the most
DNS misconfiguration for a website usually shows up immediately and gets fixed fast. DNS misconfiguration for email is sneakier — mail can keep "working" for weeks while quietly landing in spam folders, because SPF, DKIM, and DMARC are reputation signals, not hard failures. I've covered that specifically in Why Your Emails Land in Spam: A Practical Email Deliverability Guide, since it deserves its own deep dive rather than a paragraph here.
The habit worth building
Treat DNS changes with the same care as a production deploy: know the current TTL before you touch anything, change one thing at a time, and verify against an authoritative source rather than trusting the first cached answer you get. DNS rarely breaks on its own — it breaks when it's changed carelessly, and then takes hours to visibly recover because of caching, which makes the mistake feel much worse than it needed to be.