DisasterLab
PlaybooksDNS change takes the business offline
Infrastructurecritical30 minutes to prepare

DNS change takes the business offline

Incorrect nameservers or DNS records make the website, API, email, or verification services unreachable.

01DetectConfirm the signal
02ContainStop more damage
03RecoverRestore control
04VerifyProve it works

What do you need right now?

Prepare before it happensRecover from this now

Your preparation

0 of 0 safeguards ready
0%
Continue the prevention checklist
Incident worksheet

Make the next decision with evidence

Restore authoritative answers from a known-good zone while controlling cache effects, DNSSEC, certificates, email, and dependent verification records.

EvidenceDecisionActionProof

Capture before evidence disappears

  • Save the current and intended zone, registrar nameservers, DNSSEC DS records, TTLs, change history, actor, API token, and resolver results from several networks.
  • Record affected names, record types, regions, validation errors, email authentication, certificate issuance, and third-party domain verifications.
  • Capture authoritative responses with serials and compare them to recursive resolver and application behavior.

Decisions that change the response

QuestionAct whenAction
Revert or patch?A complete last known-good zone exists and no legitimate concurrent changes would be lost.Restore the reviewed zone; otherwise patch the smallest records and document divergence.
Disable DNSSEC?A broken chain blocks resolution and the correct keys or DS change cannot be restored quickly.Coordinate carefully with registrar and provider; account for cached validation state.

Proof that recovery worked

  • Authoritative servers return intended records and serials; public resolvers converge according to TTL.
  • Web, API, email, certificates, verification records, and failover targets pass end-to-end tests.
  • No stale provider, dangling alias, unexpected nameserver, or unauthorized zone editor remains.

Controls to put in place

  • Manage zones as reviewed code and export independent backups after every change.
  • Use low TTLs before planned migrations, not as a permanent substitute for safe changes.
  • Monitor authoritative answers, DNSSEC, nameservers, certificates, and email records externally.
Tabletop drill

Break one staging record and a DNSSEC validation path. Diagnose authoritative versus cached behavior, restore from versioned zone data, and time resolver convergence.

Escalate when

Contact DNS host and registrar when authoritative service, nameserver delegation, or DNSSEC chain cannot be repaired from your account.

What this means

The application may be healthy while users cannot find it. DNS changes can also break email delivery, certificate issuance, and third-party ownership verification.

Warning signs

  • Resolvers return NXDOMAIN, stale addresses, or inconsistent answers.
  • Website and API failures begin immediately after a DNS change.
  • MX, SPF, DKIM, DMARC, or verification records disappear.
  • Authoritative nameservers differ from the intended provider.

Recover now

First 15 minutes

  1. Record public answers from multiple resolvers and the authoritative nameservers.
  2. Compare the live zone with the last known-good exported zone.
  3. Revert only the incorrect records or nameserver delegation.
  4. Lowering TTL now will not accelerate records already cached.

Today

  1. Verify website, API, mail, certificates, and vendor verification separately.
  2. Confirm DNSSEC delegation matches the restored configuration.
  3. Monitor propagation across regions and recursive resolvers.
  4. Document the change source and require review for future high-impact edits.

Verify recovery

  • Authoritative and public resolvers return intended answers.
  • HTTP, API, inbound mail, outbound authentication, and certificates work.
  • DNSSEC validation succeeds where enabled.
  • No temporary workaround remains as permanent configuration.

Prepare now

Access

  • Registrar and DNS accounts have separate secure administrators.

Backups and evidence

  • The complete DNS zone is exported after meaningful changes.
  • DNS changes are logged with an owner and reason.

Contacts and ownership

  • Every critical record and nameserver has a documented purpose.

Practice

  • A harmless record has been changed and rolled back under review.

Common mistakes

  • Changing several records at once.
  • Forgetting mail and certificate records.
  • Assuming local cache results represent all users.

Sources

Last reviewed July 19, 2026Guidance changes. Confirm provider-specific actions in the linked official sources.