Drift monitoring

Drift monitoring compares each provider's current zone with the saved DNSMigrator draft and marks differences without writing anything. The key point is that the scheduled checkbox needs Pro or Agency, while Check for drift is a read-only manual action available on every plan.

What counts as drift#

A drift check runs the same provider-specific planning logic as a managed-zone preview. For each attached provider, DNSMigrator lists zones and reads the full API-visible records when it finds a matching zone, then applies saved defaults, transforms, ignore rules, purge policy, and catalog support checks. A missing zone—or a listZones() call that rejects—is treated as an empty live record list. One or more planned operations means that provider has drifted.

This is not a comparison between providers and it is not an authoritative DNS propagation test. In the release planner:

• supported canonical record sets are compared directly rather than passed through the migration translator;
• saved TTLs are compared as written and are not clamped to provider ranges;
• records matched by ignore rules are preserved;
• Never delete records at the provider allows unrelated provider-only sets;
• unsupported draft records are omitted from that provider’s plan; and
• provider-managed SOA and DNSKEY records are omitted.

When lookup finds the zone, the provider’s normal full readZone() path supplies the records used for the check.

Run a manual check#

Any workspace member can start the manual read. Editing, previewing through the web UI, and pushing remain owner/admin actions.

If some provider plans record errors, the remaining plans still determine In sync or Drifted. DNSMigrator stores the first recorded plan error on the zone; only an all-error result sets overall status to Error. A failed zone listing is not in that error count because lookup treats it as an empty zone.

Enable scheduled monitoring#

Open Zones → select the zone → Settings → Monitoring and backups. Check Alert me when a provider drifts from this zone. The setting's help text is literal: DNSMigrator compares every attached provider with the saved records on a schedule and sends the drift event to configured notification channels.

The scheduler scans for due work every five minutes, so the interval is a target rather than a wall-clock appointment. A per-zone singleton key prevents duplicate queued checks. Turning monitoring off stops future scheduled checks; it does not remove the last-check time or change the current status by itself.

The service enforces the entitlement even if a client bypasses the form: enabling monitoring without the drift feature returns Drift monitoring needs the Pro plan. Both Pro and Agency include that feature.

Configure drift alerts#

The monitoring switch does not create a notification destination. Go to Notifications, select Add a channel, and choose Email, Slack, or Webhook. Include Zone drift detected in that channel's event list. See Notifications and webhooks for channel setup and signed webhook delivery.

When a check changes a zone from another status to drifted, DNSMigrator queues one zone.drift event with:

• the zone name in the title;
• the total add, change, and delete count across drifted providers;
• a link to the managed zone; and
• singular or plural wording based on the difference count.

It does not send the same drift alert on every scheduled check while the zone remains drifted. After a check returns the zone to in sync, a later new drift can trigger another alert. Notification delivery retries are handled independently from the DNS check, and a failed channel does not change DNS state.

Resolve a difference#

First decide which state is correct.

Keep the saved DNSMigrator draft#

1. Select Preview changes.
2. Expand every provider and confirm that the proposed operations repair only the unwanted differences.
3. Type the zone name under Changes and push.
4. After provider APIs settle, select Check for drift again.

A successful push does not automatically run an authoritative verification. The follow-up drift check confirms the provider-visible state. In a multi-provider zone, one failed provider can leave successful providers updated, so use the next preview to identify the remaining repair.

Keep the external provider change#

Edit the corresponding record under Records, then select Save changes. For a larger external change, select Back up now first; after the manual backup appears under Backups, use View to inspect the provider snapshot or Restore into editor to replace the saved draft from that snapshot. Review it carefully when several providers differ, because each backup represents one provider at one time.

After adopting the external state, preview before any push. This shows whether the newly accepted records are supported and how they compare at every attached provider rather than copying an unchecked console change across the set. See Backups and restore for restore behavior.

What monitoring never does#

A drift job never adds, updates, or deletes DNS records, never changes nameservers, and never enables or disables DNSSEC. It also does not automatically adopt external changes or roll them back. Those actions always require an owner or admin to save a draft, review a preview, and complete the typed push confirmation described in Preview and push.