Safe DNS-change checklist

A safe DNS change is a controlled operation, not an edit followed by waiting. Name the owner, capture the current state, reduce risk before the window, change one control plane at a time, verify from authoritative data outward, and keep a tested path back.

1. Define the outcome and owner

Write down:

• exact names and record types changing;
• user-visible outcome;
• responsible change owner and approver;
• authoritative DNS provider and registrar;
• website, CDN, certificate, and email owners affected;
• maintenance window and communication channel; and
• maximum acceptable interruption.

If nobody owns verification and rollback, the change is not ready.

2. Classify the risk

Use the highest applicable level:

• Read-only: queries and inventory only.
• Reversible: a record change with preserved prior state.
• Availability-impacting: nameserver, address, mail-routing, or DNSSEC changes that can interrupt service.
• Ownership-impacting: registrar, registrant, transfer, recovery, or account changes.

Higher-risk changes need explicit approval, stop conditions, and a rollback owner.

3. Capture the current state

Before editing, export or record:

• parent delegation, glue, and DS;
• child-apex SOA, NS, and DNSSEC state;
• complete zone data, including disabled or rarely used records;
• current authoritative answers and TTLs;
• web apex and www behavior;
• MX, SPF, DKIM, DMARC, verification, SRV, and CAA records;
• proxied or provider-specific record state;
• registrar and registry status codes; and
• screenshots or machine-readable exports needed for rollback.

Query every intended authoritative server. A control-panel export alone does not prove what each server publishes.

4. Map dependencies

For every changing record, identify:

• the service that consumes it;
• aliases, delegated subzones, or glue involved;
• certificate issuance or validation dependencies;
• email senders and receivers;
• monitoring and verification endpoints; and
• application or CDN configuration that must already exist.

DNS can point traffic to an unprepared destination perfectly.

5. Plan cache timing

Record the existing TTL before lowering it. If a shorter change-window TTL is needed:

1. publish the lower TTL;
2. wait at least the previous TTL;
3. verify every authoritative server serves the lower value; and
4. only then schedule the value change.

Existing caches keep the lifetime they previously learned. Negative caching can also preserve an earlier absence [2].

Never describe the plan as reaching a global propagation percentage.

6. Inspect DNSSEC before delegation changes

Record:

• whether DS exists at the parent;
• DS TTL and values;
• child DNSKEY and signatures;
• current validating-resolver result; and
• whether both providers support a reviewed multi-signer transition.

DNSSEC authenticates the delegation chain [3]. A stale DS paired with new, unrelated child keys can make the zone bogus.

If the migration uses an insecure interval, remove DS and wait for its cached lifetime to expire before serving unrelated keys. Use an operator-reviewed procedure for multi-signer changes; DNSSEC timing and rollover require explicit coordination [4].

7. Define stop conditions

Stop before changing state if:

• the current zone cannot be exported;
• intended authoritative servers disagree;
• required web, email, or certificate destination is not ready;
• the parent DS state is unknown;
• account recovery or registrar access is unverified;
• rollback values are incomplete;
• the maintenance owner is unavailable; or
• monitoring cannot distinguish DNS from application failure.

During execution, stop adding changes after the first unexplained result.

8. Execute the smallest coherent change

Use the approved source of truth. Have a second person or automated comparison verify high-risk values before submission.

Avoid combining:

• registrar transfer with DNS-provider migration;
• nameserver change with unrelated record cleanup;
• DNSSEC key change with an unplanned delegation change; or
• web migration with email migration.

The DNS hierarchy deliberately separates administration through delegation [1]. Preserve that clarity in the change plan.

9. Verify from the inside out

Verify in this order:

1. control plane accepted the intended change;
2. every authoritative server returns the intended RRset and TTL;
3. parent delegation, glue, and DS match the plan;
4. named recursive resolvers return explainable states;
5. DNSSEC validation is secure or intentionally insecure;
6. TLS certificates and hostname coverage are correct;
7. HTTP status, redirect, headers, CDN, and origin behavior are correct;
8. inbound and outbound email behavior is correct; and
9. monitoring and user journeys remain healthy.

Record exact query, observer, answer, TTL, and time. “It works for me” is not a verification record.

10. Roll back deliberately

Rollback criteria should be decided before execution. Restore from captured values, not memory.

Account for caches: reverting authoritative data does not erase new values already cached. A DNSSEC rollback must preserve a valid chain during every transition; parent DS and child signing cannot be toggled as if they were one setting.

After rollback:

• verify authoritative servers agree;
• verify parent delegation and DS;
• test named resolvers as cache lifetimes permit;
• verify every affected application layer; and
• record the incident and remaining cache window.

11. Close the change

When stable:

• restore normal TTLs where planned;
• remove temporary records only after dependency review;
• archive evidence and final configuration;
• update diagrams and runbooks;
• record unexpected behavior; and
• schedule a later review for provider-specific settings.

Next step

For a provider-specific application of this checklist, use Cloudflare nameserver onboarding and DNSSEC sequencing.