❯ DNS, explained for founders who have real systems to run

2026-09-24 ·5 min read

by Jonas Reyes — the builder's desk, Side Quest Studios September 25, 2026

Your website is down. Your email is bouncing. Some customers can reach you, some can't, and your "uptime monitor" says everything is green. You've been on hold with your registrar for 40 minutes. Somebody in Slack just typed "is it DNS?" and you want to throw your laptop.

It's DNS. It's always DNS. Let me save you the next four hours.

What DNS actually is

DNS is the phone book of the internet. That's the analogy everyone uses and it's fine, but it undersells the part that matters: DNS is a distributed, cached, eventually-consistent phone book, and every layer of it can lie to you for a while.

When someone types yourcompany.com into a browser, their machine asks a resolver (usually their ISP's, or 8.8.8.8, or 1.1.1.1) "what's the IP for this name?" The resolver doesn't know either, so it walks up a tree: root servers → the .com servers → your authoritative nameservers. Your authoritative nameservers are the ones you actually control — usually at your registrar (Namecheap, Cloudflare, Route 53) or wherever you pointed your NS records.

The answer comes back with a TTL — time to live, in seconds. That's a countdown timer on how long everyone is allowed to remember the answer before asking again. TTL 300 means "cache this for 5 minutes." TTL 86400 means "cache this for a day, and if you fat-finger a change, you get to stare at a broken site for 24 hours while the internet slowly forgets."

That last sentence is the whole reason you're reading this.

The three things you actually configure

Forget the 15 record types. You need three, maybe four.

A record — name → IPv4 address. www → 203.0.113.10. Done.

CNAME — name → another name. blog.yourcompany.com → yourcompany.ghost.io. Useful when a vendor gives you a hostname instead of an IP. Rule: you cannot put a CNAME on your root domain (yourcompany.com). The DNS spec forbids it because a CNAME can't coexist with the MX and NS records that live at the root. Every registrar that "lets" you do it is doing a hack behind your back.

MX — where email goes. yourcompany.com → mx1.yourprovider.com with a priority number. Get this wrong and your invoices bounce. Get it slightly wrong and half your mail works, which is worse.

TXT — the junk drawer. SPF, DKIM, DMARC, domain verification for Google Workspace, Slack, that one SaaS you signed up for in 2023. If a vendor says "add this TXT record," add it. If they say "add four," add four. Don't get creative.

That's it. Ninety percent of your DNS life is those four.

Where it breaks, and why it's always at 2am

The classic failure: you migrate servers. New IP. You update the A record. Half your users see the new site instantly. The other half get the old one for the next six hours, because their resolver cached the old answer and the TTL was 3600.

Fix: lower your TTL before the migration. Set it to 300, wait one full old-TTL period (so at least an hour if it was 3600), then make the change. The internet forgets fast, you flip the IP, everyone converges in five minutes. I've done this dance maybe two hundred times and it has never once failed me.

The other classic: you change your nameservers at the registrar and nothing happens. That's because NS changes propagate on the registry's schedule, not yours. Give it 24 hours before you panic. Then panic.

And the one that eats entire afternoons: split-horizon DNS. Your laptop is on the office VPN, the VPN pushes its own resolver, and now internal.yourcompany.com resolves to a 10.x address while your phone on LTE gets NXDOMAIN. Nothing is broken. You're just asking two different phone books. Run dig internal.yourcompany.com @1.1.1.1 and dig internal.yourcompany.com side by side and watch the answers diverge.

The commands. Learn three of them.

Everything you need is dig. It's on every Linux box and it's in bind-utils or dnsutils on any distro worth using. On Debian/Ubuntu: sudo apt install dnsutils. On RHEL family: sudo dnf install bind-utils.

Check what the world sees:

dig yourcompany.com A +short

If that returns the wrong IP, the problem is upstream of you — your registrar, your nameservers, or your authoritative zone file. If it returns the right IP but users still can't reach you, the problem is their cache. Different problem, different fix.

Ask a specific resolver, bypassing your local cache:

dig yourcompany.com A @8.8.8.8 +short
dig yourcompany.com A @1.1.1.1 +short

If Google's resolver and Cloudflare's resolver disagree, you've got a propagation problem. Wait, or find out which POP is stale.

Watch the full delegation chain:

dig yourcompany.com +trace

This walks root → .com → your nameservers, one hop at a time, and shows you exactly where the chain breaks. When a client says "our domain is broken," this is the first command I run. Nine times out of ten it dies at the registry.

Check your email setup before your customers do:

dig yourcompany.com MX +short
dig yourcompany.com TXT +short

If the MX records point somewhere you don't recognize, you've got a mail problem coming. If there's no v=spf1 in the TXT output, your outbound mail is going to spam and you don't know it yet.

A note on the AI pitch decks

Every AI vendor this year is going to tell you they've "reinvented networking" or "AI-native DNS" or some such. Here's the thing. A recent writeup noted that an AI hallucination nearly triggered a US military operation (TechCrunch). DNS is the layer where a hallucinated answer means your customers can't reach you and your email goes to a black hole. Keep it boring. Keep it in files you can read with cat. Keep it in BIND or NSD or PowerDNS or Knot — all of which are open source, all of which have been battle-tested for decades, all of which let you dig the answer yourself instead of opening a support ticket.

If you want DNS with a nice API, fine — Cloudflare and Route 53 both work. But keep a copy of your zone file in your git repo as plain text. When the API goes sideways at 3am, scp the zone file to a $5 VPS running nsd, point your registrar at it, and you're back up in twenty minutes. I have done this. It is not theoretical.

What I'd actually do this week

Log into your registrar. Find your TTLs. If they're over 3600 on records you might ever change, drop them to 300. Today.
Run dig yourcompany.com MX +short and confirm those MX hosts exist and are ones you recognize. Every founder I've ever told to do this has found at least one stale record.
Copy your full zone file into a git repo. Commit it. Now you have a backup and a diff history for the day someone fat-fingers a CNAME.
Set up a free uptime check on your authoritative nameservers, not just your website. If the nameservers go dark, the website going down is a symptom, not the disease.

DNS isn't glamorous. It's the reason your business is reachable. Treat it like production infrastructure, because it is.

We build and run systems like this for founders at Claw Way — the boring plumbing that keeps the interesting stuff alive.

References

AI-assisted, curated for Side Quest Studios.