DNS Change Management

A changeset moves through a defined set of states. Most teams use a subset, but the full path looks like this:

1. Draft — you create the changeset and add record changes (create, update, delete).
2. Submitted — the changeset is locked from edits and queued for review or auto-approval.
3. Pending approval — another team member reviews the proposed changes (skipped if no approver is assigned).
4. Approved — the changeset is ready to apply, immediately or on a schedule.
5. Scheduled — the changeset is queued for application at a future time you picked.
6. Applying — ZoneWatcher is sending the changes to your DNS provider.
7. Applied — the provider confirmed every record change.
8. Verified — ZoneWatcher re-read the zone and confirmed every record matches the expected post-change state.
9. Propagated — the change has been observed across the DNS resolvers ZoneWatcher polls.

A changeset can be cancelled from any state up through Scheduled. If application fails after retries, it lands in Failed; if it conflicts with a concurrent zone change, it lands in Conflict. Both can be retried.

There are three ways to create a changeset:

• From the Records tab on a zone view. Use Add Change to create, edit, or delete one or more records and ZoneWatcher batches them into a draft.
• From a specific check in the zone history. The Revert Change action drafts a changeset that returns the zone to its state before that check ran.
• From an applied changeset, the Rollback action drafts a reverse changeset — covered separately in DNS Change Rollback.

You can name a draft changeset before submitting it so it is easy to find later. Each item in the changeset stores its before- and after-state so the diff is visible at every stage.

The Validate action runs a dry-run against the live provider data: it confirms every target record still exists, that the after-state passes provider rules (TTL bounds, type restrictions, allowed characters), and that no other team member has touched the same records since the draft was started. Validation is automatic on submit and you can also trigger it manually at any time before the changeset becomes terminal.

Submitting a changeset transitions it to Submitted. From there you can either send it directly through to Approved (if your team allows self-approval) or use Request Approval to assign a specific approver and add a message. Approvers see the changeset in their notification feed and can review the diff, the AI risk score and summary, and approve or reject with a comment.

The Apply action on an Approved changeset asks whether to apply now or schedule for later. Apply Now dispatches the change immediately and the page polls every two seconds while it is in flight. Schedule for Later stores the chosen UTC timestamp and ZoneWatcher applies it automatically at that moment.

If the provider rate-limits us mid-apply, ZoneWatcher backs off and retries automatically. If a record fails after the retry budget is exhausted the changeset moves to Failed; you can fix the underlying issue and use Retry to re-attempt the failed items only.

Every pending changeset receives an AI risk score from 1 to 100 along with a plain-language summary. The score factors in record-type criticality, ASN and geolocation shifts on IP changes, attack patterns like mail-server hijacks or nameserver takeovers, and historical context from your zone. The summary appears in the changeset list, on the detail page, and inside the approval confirmation modal so reviewers can spot risky changes at a glance.

See the AI DNS Risk Assessment overview for the full description of how scores are calculated.

Once a changeset reaches Verified, ZoneWatcher polls a curated set of public DNS resolvers and shows per-resolver status (propagated, mismatch, timeout) until the changeset is fully propagated. The Propagation section on the changeset detail page lists each resolver with its IP, current status, the number of checks performed, and the timestamp it first reported the new value.

Each notification channel can subscribe to changeset events: Submitted, Approval requested, Approved, Rejected, Cancelled, Schedule reminder, Applied, Propagated, Conflict, Propagation timeout, Failed, Rolled back, and Rollback failed. Every notification deep-links back to the changeset.

We are rolling out Change Management to providers in waves. The grid below reflects which providers currently have changeset support enabled by default. If your provider shows a checkmark, the Add Change and Revert Change actions are available on its zones today; the rest are queued for upcoming releases.

DNS Change Management is included on the Control plan. Teams on Monitor or Protect can see the Changesets navigation entry but the page itself displays an upgrade prompt. The feature is currently in beta — we are rolling out vendor support incrementally; the Revert Change and Add Change actions are only visible on zones whose provider has change management enabled.

See Volume Discounts for how Control pricing scales with the number of monitored domains.