Apply and verify

Apply re-reads and snapshots the destination, recalculates the change plan against that live state, writes those current operations, and then verifies every target record set against the destination’s authoritative nameservers. The key point is that the preview operation list is not replayed: the worker uses the plan produced by its fresh destination read.

Before you apply#

A connected provider destination must be active and writable. Review all three parts of Preview:

1. The status summary: every Review target will be written, while Unsupported and Managed rows have no target.
2. The mode: Keep extra records leaves destination-only records alone; Make an exact copy deletes them.
3. The plan: check Create, Update, Delete, and Already correct, not only the translation statuses.

Read Previews and record statuses and Translation rules if any row needs explanation. Use Report for a printable record summary and activity timeline.

Apply entitlement#

Preview and zone-file download are free. Writing to a provider requires an administrator and one of these entitlements for that migration:

The count is the number of translated target record sets, so Unsupported and Managed rows are not included. A higher one-time tier satisfies a lower requirement. Pro does not include applies; Agency includes the guided-cutover tier and therefore any-size apply, but not automated cutover. See Plans and billing or Pricing.

If card checkout is configured, the card reads Pay price and continue and returns to the migration. A launch access code can also unlock a tier where that program is available.

Apply step by step#

A Zone file destination has no apply stage. Select Download zone file and import it yourself; unsupported rows are omitted. See BIND zone files.

What happens on the worker#

Apply performs these operations in order:

1. It calls the destination adapter’s zone-ensure operation. This uses an existing matching zone or creates one and records the provider’s zone reference and nameservers.
2. It reads the destination zone and saves a destination-before snapshot.
3. It derives the target records from the preview, excluding rows without targets.
4. It recalculates merge or mirror changes against the just-read destination.
5. It sends that fresh plan to the provider adapter and records the subset that actually succeeded.
6. It stores the rollback deadline, marks the entitlement consumed, and queues verification after 10 seconds.

If the fresh plan differs from the preview, an event says the destination changed and records the new create, update, and delete counts. The fresh operations are still sent. Because zone ensure happens before the live read, a missing destination zone can be created before this plan is calculated.

The shared provider plan helper presents deletes first, then updates, then creates; it does not dependency-sort targets. Individual adapters can batch operations or replace a whole zone according to their API behavior, and no cross-provider transaction is implied.

Partial failures#

Provider APIs can accept some operations and reject others. DNSMigrator records up to the first five failed operations in Activity, removes those failures from the stored “applied” plan, and retains the successful subset for rollback. The migration becomes Needs attention and reports how many operations succeeded.

A partial apply receives a rollback deadline even though verification did not complete. Do not edit the successfully written records before deciding whether to roll back: the rollback safety check deliberately preserves a record that no longer matches DNSMigrator’s write.

Authoritative verification#

Verification does not query a recursive cache. For each translated target, the DNS helper queries up to the first four nameservers returned by the destination, keeps successful NOERROR answers, and compares the union of their values with the plan. Up to eight target record sets are checked in flight. This is an aggregate check, not a per-nameserver consistency test; one divergent server can be hidden by the union. The worker makes three attempts by default, waiting 40 seconds between attempts when failures remain and writing a verify-retry event. Use these dig commands for checking a DNS migration to reproduce targeted authoritative queries yourself.

Literal and alias targets have different success rules:

When an alias resolves but no source answer is available, the result is informational: Alias resolves. No source answer to compare. When nonempty source and destination addresses differ, it is also informational because CDNs and load balancers can legitimately vary answers.

The Verification panel shows:

• Match for pass rows.
• Resolves for info rows.
• Mismatch for fail rows, followed by missing and extra values when available.

A migration becomes Verified when there are zero failed rows; informational alias rows do not prevent it. The panel badge counts pass and informational rows together, so expand informational details rather than treating them as an exact byte-for-byte match.

If failures remain after the final attempt, the records stay applied and the migration becomes Applied, not rolled back. Fix the destination or wait for the provider, then select Verify again. The propagation checker is useful after delegation changes, while this verification checks the destination nameservers directly before cutover.

After verification#

Once the migration is Verified, continue to Nameserver cutover. If you need to undo destination writes, read Rollback first. Record rollback and nameserver switch-back are separate operations; neither substitutes for the other.