A domain goes offline in two very different ways, and most small teams have only planned for one of them.
The first: the web server dies. DNS still resolves, browsers get a connection refused, someone restarts the box, everyone moves on.
The second: the nameservers die. Nothing resolves at all. Mail bounces, the marketing site disappears, the API looks like it never existed, and — worst of all — you cannot even reach the server to fix it, because you have no way to find it.
The second failure mode is entirely avoidable, and it is usually invisible until it happens.
The configuration that causes it
imonitorsoft.com. NS ns1.imonitorsoft.com.
imonitorsoft.com. NS ns2.imonitorsoft.com.
ns1.imonitorsoft.com. A 203.0.113.10
ns2.imonitorsoft.com. A 203.0.113.10 <-- same address
Two nameservers, one IP. Registrars accept this. It satisfies the "at least two NS records" checkbox. It provides exactly zero redundancy, because both nameservers are the same machine, and usually the same machine as the website.
When that box stops answering, the entire zone becomes SERVFAIL. Not "down" in the sense your monitoring notices — the domain effectively stops existing.
How to check yours in 60 seconds
# what the registry delegates to
dig +short NS example.com
# where those nameservers actually live
for ns in $(dig +short NS example.com); do
echo "$ns -> $(dig +short A $ns | paste -sd, -)"
done
# and ask a public resolver, not your own cache
dig @1.1.1.1 example.com A +short
If every nameserver resolves to the same IP, you have a single point of failure that will take the whole domain with it.
The fix, in order of effort
1. Move DNS to a provider that runs it as a product. Cloudflare's free tier is enough. You point the registrar at their nameservers and never host authoritative DNS on the same box as the website again.
2. If you must self-host DNS, split it. Two nameservers on two providers (or two regions), each with its own address. The registry's requirement exists precisely because one machine is not redundancy.
3. Keep the DNS provider independent of the hosting provider. When your host has a bad day, you want to be able to re-point the A record somewhere else in five minutes. If DNS lives inside the host, you cannot.
What this costs when it goes wrong
Not the server bill — the recovery time. When the domain does not resolve:
- You cannot SSH by name; you need the IP written down somewhere
- Customers cannot reach support to tell you the site is down
- Certificate renewals and API callbacks fail silently
- Search engines start dropping pages from the index after a few days
- Every link you published for months points at a host that no longer answers
That last one is the expensive part. Content is recoverable — you have the source. Index position is not.
A small checklist
- [ ] Nameservers resolve to at least two different addresses
- [ ] DNS provider is not your hosting provider
- [ ] The origin IP is written down somewhere outside the infrastructure
- [ ]
dig @1.1.1.1 yourdomain.comworks from a network you do not control - [ ] You have a copy of the zone file exported somewhere
- [ ] Monitoring checks resolution, not just HTTP
That last item matters more than it looks. An HTTP check on a hostname silently fails when DNS fails — and if your monitor runs inside the same network, its cache may still answer, so it reports green while the world sees SERVFAIL.
We run Onsites AI with a self-hosted option, and this is exactly why the deployment docs insist on external DNS rather than putting it on the app server. If you are setting up a small support stack, the self-hosting notes cover the boring parts that decide whether you survive a bad day.
Top comments (1)
good one. worth adding that this has to be fixed before the bad day, not during it. the NS records and glue in the parent zone usually carry a long TTL (two days for .com), so if you move DNS while the box is down, a lot of resolvers keep asking the dead machine until their cache runs out. dig +trace example.com shows you what the parent actually hands out