DNS Outage Runbook for Small Teams

A DNS outage is the quietest way to lose a whole business day: no errors in your own logs, no alerts from your own monitoring — because the thing that broke is upstream of every request. The honest runbook has four parts: watch the domain itself, keep a tested copy of your zone, lower TTLs before changes instead of during them, and know the 10-minute restore path by heart.

1. Monitor the domain, not just the site

Your site monitor checks https://www and gets an answer — so DNS must be fine, right? No: it answered because it resolved. The DNS checks that matter are cheap and upstream:

Check	How often	What it catches
Resolve apex + www + one API host against 8.8.8.8 and 1.1.1.1	Every 5 minutes	Zone edits gone wrong, nameserver failures
Domain expiry date	Daily	The auto-renew that silently failed (dead card, expired email on the registrar account)
Nameserver (NS) set matches what the registrar says	Daily	Accidental NS changes, hijack attempts

A 5-line cron script with dig and the WHOIS date covers all three. An outage caught here costs minutes; the same outage caught by a customer tweet costs the afternoon.

2. Keep a tested copy of your zone (the part everyone skips)

When DNS breaks, you will need to re-publish records fast — at a second provider, because the primary will be having a bad day. That only works if you already have:

A zone export (BIND-style or provider JSON) stored outside the provider — in your repo or backup bucket.
A second DNS provider pre-configured with the same records. Free tiers are fine; the point is that the zone is already there when you need it.
A quarterly check that the copy is still current. An untested backup is a wish, and DNS backups rot fast.

The 10-minute restore path: flip the NS records at the registrar to the second provider, verify with dig +trace, done. Doing this for the first time during an outage takes hours and mistakes; rehearsed, it takes minutes.

3. TTLs: lower before the change, never during the fire

The classic mistake is dropping a TTL to 60 seconds after something is already broken — caches keep serving the old answer for the old TTL no matter what you do now. The rule is boring and it works:

Normal TTLs: 300–3600s for hosts that change, 86,400s only for truly static ones.
Before a planned migration: lower TTLs 24–48h ahead, make the change, raise them back after.
During an outage: don't touch TTLs — republish correct records and let caches age out. Old-TTL panic edits only add a second failure mode.

And watch out for the hidden TTL: your CDN, mail provider, or status page may hold its own cached answers with longer TTLs than yours. During an incident, check what resolvers see, not what the zone file says.

4. The 10-minute restore path (when DNS is already down)

Confirm scope (2 min): dig the failing names against two public resolvers and one ISP resolver. All resolvers failing + registrar portal slow = provider-side outage, not your config.
Decide the path (1 min): provider-down → switch NS to the second provider. Your-record-mistake → restore the exported zone to the primary.
Execute from the runbook (5 min): the exact NS strings, the exact export filename, the exact dig +trace verification — written down, because typing nameserver hosts from memory under pressure is how typos become second outages.
Verify and tell people (2 min): test from a phone on mobile data (not office Wi-Fi with its own cached answers), then post the status update — even a two-line one. Silence makes a technical incident a trust incident.

5. The mistakes that turn minutes into hours

The single nameserver dependency. Two providers' nameservers is the whole point; one provider plus "we'll set one up if needed" is not redundancy.
The domain registered at the same place DNS lives. If the registrar and DNS provider are one company and that company melts down, your restore path goes through their outage queue too.
The registrar account nobody can log into. The owner's personal email, no 2FA recovery codes stored — the most common reason a 10-minute restore becomes a multi-day support ticket.
Restoring the zone but not verifying the served answer. Records published ≠ records served. dig +trace from outside is the only truth.

Takeaways

Watch the domain, not just the site. Expiry, NS set, and cross-resolver answers catch DNS trouble before customers do.
The second provider is configured in peacetime or it doesn't exist. The zone export nobody has tested is a wish, not a backup.
TTLs are lowered before changes, not during fires. Caches obey the TTL that was set when the record was cached — not your 3am panic edit.

---

The Ops Starter Kit ($14) turns the first-hour chaos of any outage — DNS included — into a fillable plan, and Vol. 2 ($27) adds the DR plan and evidence log for the review after. Launch week: 20% off any paid kit with code HIVE20 at checkout (ends Sep 11, 23:30 ACST).

Related: when the auth host itself stops resolving it is a DNS incident wearing an SSO costume — the SSO outage runbook covers the login side of the same bad day.

Put this to work. The Ops Starter Kit bundles the highest-leverage templates — incident response, runbooks, onboarding, checklists — into one download ($14).

Free start: grab the First 30 Minutes incident-response checklist, or get the free template library by email.

Need all of it at once? The Ops Mega Bundle collects all five ops kits in one download — $49.