❯ DNS, Explained for the Founder Who Just Wants the Site to Load
Your site is down. Your customers are emailing. Your developer says "it's a DNS propagation issue" and disappears for four hours. You pay for hosting, you pay for a domain, you pay for monitoring, and none of it explains why a thing that worked yesterday does not work today.
Here's the uncomfortable truth: DNS is the part of your stack nobody owns until it breaks. It's also the part where a single fat-fingered change can take down every product you run, all at once, faster than any deploy. I've watched a company lose a full day of revenue because someone edited a record at 4:55pm on a Friday and nobody knew the rollback was a one-line fix. So let's fix the knowledge gap. Five minutes, no hand-waving.
DNS is a phone book, and your registrar is not your host
DNS stands for Domain Name System. It translates a name humans type — yourbrand.com — into an IP address machines use, like 203.0.113.42. That's it. That's the whole job.
The confusion starts because three different companies get lumped into one mental bucket:
- The registrar is where you bought the name. It's the deed office. It controls who technically owns the domain.
- The DNS provider holds the records that say where traffic goes. Sometimes this is the registrar, sometimes it's Cloudflare, sometimes it's your host. This is the part that matters when things break.
- The host runs the actual server your site sits on.
Founders routinely assume these are one thing. They're not. I've seen a team cancel hosting, thinking it would kill the site, and instead they just orphaned a record pointing at a server that no longer existed. The domain stayed registered. The records stayed put. The site died anyway.
Rule one: know which company holds your records. Write it down. Put it somewhere your co-founder can find at 2am.
The records you actually need to understand
You don't need to memorize the spec. You need to recognize about five record types when you see them in a dashboard.
A record — maps a name to an IPv4 address. This is the one that points your root domain at a server. If your site won't load and everything else is fine, this is your first suspect.
CNAME — maps a name to another name instead of an address. Common for www pointing at your main domain, or for pointing a subdomain at a hosted service. The gotcha: you generally can't put a CNAME on your root domain. That trips people up constantly.
MX records — mail routing. If you break these, your website keeps working and your email silently stops. This is the nastiest failure mode because you won't notice for a day, and by then you've missed customer replies you'll never get back.
TXT records — freeform text. In practice, this is where domain verification and email authentication live. When a vendor asks you to "add a TXT record to prove you own the domain," this is what they mean.
TTL — Time To Live. Not a record type, but the most important number on the page. It tells the world how long to cache a record before asking again. A TTL of 3600 means up to an hour of stale data after you make a change.
That last one is why "propagation" gets blamed for everything. More on that below.
The one-hour myth that wastes your afternoons
"DNS propagation takes 24 to 48 hours" is the most repeated lie in this industry. It's technically true in the same way that "a flight from New York to LA takes six hours" is true — it can, but usually it doesn't.
What actually happens: the moment you save a change, your DNS provider serves the new answer. The delay is other servers and devices holding onto the old answer until their cached copy expires. That expiration window is the TTL you set.
So if your TTL is 300 seconds, the change is effectively live in five minutes for most of the world. If your TTL is 86400, you just signed up for a day of pain. The propagation time isn't a law of physics. It's a setting you control.
The fix is boring and it works: set your TTL low — 300 seconds — a day before you plan a change. Make the change. Verify. Then raise it back up. I've done this before every migration for years and I can count the surprises on one hand.
And when you check whether a change took effect, don't trust your own browser or your laptop. Both cache aggressively. Use a public lookup tool, or ask someone on a different network. Your machine lying to you is a feature, not a bug, and it will make you think a change failed when it worked fine.
Where real founders get burned
Three failure modes, in order of how often I see them.
The expired domain. Your registrar is a company you interacted with once, years ago, using an email address that may no longer exist. Renewal notices go to a dead inbox. The card on file expired. The domain lapses, and someone buys it out from under you. This is not hypothetical — it's a genre of business-ending mistake. Turn on auto-renew, and make sure the billing email is one a human actually reads. If you own a domain that matters, put it on a calendar reminder 60 days before expiry, independent of auto-renew. Belt and suspenders.
The verification record you deleted. Some tool verifies your domain with a TXT record, you remove it later during cleanup, and months later email deliverability quietly degrades or a service cuts you off. Don't prune records you don't recognize. If you didn't add it, someone did, for a reason. Ask before you delete.
The migration with no fallback. You move your records to a new provider, something's wrong with the config, and now you're debugging live with no way back. Before any migration, export a full copy of your existing records. Screenshot the dashboard. That export is your rollback plan, and it takes four minutes.
What I'd actually do this week
This isn't theory. Here's the operating checklist I'd run on any company I was responsible for, and it takes under an hour.
First, log into your registrar and confirm auto-renew is on and the contact email is current. Do this today. Not next sprint.
Second, find out who holds your DNS records. Log in. If you can't log in, that's your real emergency — fix access before anything else. A domain you can't administer is a domain you don't control.
Third, export your zone file or screenshot every record. Store it somewhere your team can reach. This is your disaster recovery for the layer everyone forgets.
Fourth, check your TTLs. If they're set to a day or more, ask why. Usually the answer is "nobody changed the default."
Fifth, confirm your MX and TXT records are intact if email matters to you. It does.
None of this is glamorous. That's the point. DNS rewards the boring operator and punishes the person who treats it as someone else's problem. The teams that survive outages aren't the ones with the best monitoring dashboards — they're the ones who knew where the records lived before the pager went off.
There's a broader lesson here that shows up everywhere in infrastructure. The systems that take you down are rarely the ones you're actively working on. They're the ones you set up once, forgot about, and assumed would keep working. DNS is patient. It will wait years to bite you.
We build and run this kind of plumbing for founders at Claw Way on hub.sqs.chat — the unglamorous layer that keeps the visible stuff standing. But you don't need us to do the five steps above. You need thirty minutes and the willingness to look at a dashboard you've been avoiding.
Go check your registrar. Right now. The site that's up today is not guaranteed to be up tomorrow, and the difference is usually one forgotten setting.
References
- RFC 1034 - Domain Names: Concepts and Facilities - https://www.rfc-editor.org/rfc/rfc1034
- RFC 1035 - Domain Names: Implementation and Specification - https://www.rfc-editor.org/rfc/rfc1035
- RFC 5737 - IPv4 Address Blocks Reserved for Documentation (the 203.0.113.0/24 range used above) - https://www.rfc-editor.org/rfc/rfc5737
by Priya Anand — the product desk, Side Quest Studios
AI-assisted, curated for Side Quest Studios.