Change management

A DNS change worksheet you can reuse

Capture the intended change, authority, backup, test evidence and rollback decision before publishing DNS updates.

Prepared with AI assistance. Read our editorial and corrections policy.

A small DNS edit can affect a large number of users because one record is shared by every resolver that asks for it. A change worksheet makes the intent and recovery path explicit. Use the questions below for a single record edit or as a supporting record for a larger migration.

Define a measurable result

Write the exact hostname and record type, its current value and the intended replacement. State the service outcome: for example, the website should answer HTTPS on a new host while inbound mail remains on the same provider. Avoid a vague goal such as “fix propagation.” Identify the person or service owner who can confirm success.

List dependencies before choosing a time. A new web address requires server routing and a certificate. A mail-provider change requires more than MX records; mailbox provisioning, authentication and any forwarding must be ready. Record which tasks are already complete and which would prevent a safe edit.

Confirm the system you are changing

Verify the parent delegation and the authoritative provider. Check the exact zone in the dashboard and confirm that the account has the required access. If a domain uses provider proxying, flattening or automatic records, document the effective behavior. Editing an unused copy of a zone can look successful in a dashboard while leaving public answers unchanged.

Query every authoritative nameserver before the change and keep the responses. If they already disagree, resolve that inconsistency before adding another change. For delegated subdomains, identify which zone actually owns the record.

Save a recoverable baseline

Export the zone where supported and save the exact record values, TTLs and relevant provider options. Store the backup outside the account being modified and ensure the people performing recovery can access it. A screenshot is helpful context but is weaker than a machine-readable export plus a record of provider-specific settings.

For DNSSEC-sensitive changes, capture the supported signing and delegation procedure without exposing private signing keys. For website migrations, keep the old host available. For mail changes, avoid deleting old accounts or queues until data preservation and cutover have been tested.

Copy these fields into your change record

Change owner:
Domain / authoritative provider:
Hostname and record type:
Current value / TTL:
New value / TTL:
Reason and expected service result:
Dependencies already verified:
Backup location and restore procedure:
Change window and timezone:
Authoritative tests before / after:
Recursive resolver tests:
Website or email functional tests:
Rollback trigger / owner / prior value:
Observation period and closure evidence:

Publish the smallest justified change

Keep unrelated record edits out of the change. Read back the stored value after saving, then query the authoritative servers directly. Watch for an editor appending the zone name twice, malformed TXT quoting or an MX priority placed into the wrong field. Compare actual responses with the intended value rather than assuming that a successful Save message means correct publication.

After authority is correct, test recursive resolution and the service itself. Old cached values can remain until their prior TTL expires. If the old and new destinations both work during that window, mixed responses may be expected. Record observations instead of repeatedly altering TTLs or records to force an immediate result.

Make rollback a decision, not a guess

Define the failure that would justify reverting, such as a new destination failing HTTPS or a legitimate mail stream failing after a known change. Identify the exact prior values and who can restore them. A rollback still depends on DNS caches; it does not instantly undo answers already held by resolvers.

Close the change only after the chosen observation period and functional checks. Keep the evidence with the backup, note any unexpected behavior and restore a normal TTL if the temporary setting is no longer needed. Use the migration guide for delegation changes and the incident workflow if the result is unclear.

Sources and further reading

Examples use reserved documentation names and addresses. Confirm current provider requirements before changing production systems.