Fail Over Authoritative DNS to a Standby Provider

Keep a synced standby zone, lower TTLs ahead of time, switch registrar name servers during an outage, and verify answers from multiple public resolvers.

advanced~45 mindnsreliabilityoperations

Objective

Move authoritative DNS for a production domain to a standby provider with pre-synced records, coordinated DNSSEC handling and verified resolution.

Environment

A standby DNS provider with the zone created and name servers assigned
Registrar access with multi-factor authentication and a change approval trail
A complete record export from the current provider, including MX, TXT, CAA and SRV records
DNSSEC signing keys or a documented plan to remove the DS record
Resolution monitoring from multiple public resolvers

Steps

1. Export and inventory records

Export every record from the active zone and list records managed by automation, including ACME TXT challenges and verification records.

Expected state: A record inventory exists and every automated record has an identified owner.

2. Build and compare the standby zone

Import the records into the standby provider, then diff the normalized record sets from both providers before changing any delegation.

Expected state: The two exports match exactly except for provider-specific name server records.

3. Lower the TTL ahead of time

Reduce the zone default and key record TTLs to sixty seconds at least one day before the planned switch or outage trigger.

Expected state: Public resolvers return the short TTL for the records that will change.

4. Coordinate DNSSEC

If the providers use different signing keys, remove the DS record at the registrar and wait for the old TTL to expire before switching name servers.

Expected state: The zone validates without a DS mismatch, or DNSSEC is fully disabled for the transition.

5. Switch registrar name servers

Replace the registrar delegation with the standby provider name servers, then verify the change through the registry and multiple resolvers.

Expected state: Authoritative queries reach the new provider and public resolvers return the expected answers.

6. Verify all critical records

Query A, AAAA, MX, TXT, CAA and SRV records through several resolvers and compare them with the exported baseline.

Expected state: Every critical record resolves identically from at least three public resolvers.

Decision points

Should the old provider stay configured as a secondary?

Keep both zones in sync and switch back if needed
Remove the old zone immediately

Keep both zones in sync for thirty days; restoring the old delegation is the fastest rollback and costs little.

How should DNSSEC be handled when providers differ?

Import the same keys into the new provider
Remove DS, switch, then re-sign

Import the same keys when the provider supports it; otherwise remove the DS and wait out the TTL, because a mismatched DS causes a hard resolution failure.

Should the switch wait for TTL expiry?

Switch immediately after the registrar accepts the change
Wait for the old TTL to drain before changing records at the new provider

Publish the final records before switching and leave them unchanged during propagation; editing both during the transition is what creates split answers.

Expected outcome

The domain is served by the standby provider with matching records, valid DNSSEC state and confirmed resolution from multiple networks.

Verification

Run dig against the authoritative name servers and against 1.1.1.1 and 8.8.8.8 for each critical record, then confirm the registrar reports the new delegation.

Cleanup

Keep the previous provider zone active and paid for thirty days, restore the normal TTL after the change window, and archive the record diff.

A failover you can trust is prepared in advance

Switching name servers during an outage is too late to discover that the standby zone is missing an MX record or that a wildcard does not exist. Build the standby zone now, keep it synchronized, and practice the delegation change on a non-critical domain. The registrar is the single point of control: whoever can change the name servers can redirect all traffic, so require multi-factor authentication and two-person approval for that action.

Safety checks

Confirm the registrar account has multi-factor authentication and that at least two people can perform the delegation change. Export the zone with a method that includes every record type, and check for records managed by ACME, email verification and third-party services. Do not lower the TTL and switch in the same hour; resolvers that cached the long TTL will keep it until it expires.

Compare before you delegate

Normalize exports before diffing so provider-specific formatting does not hide a real gap. The commands below compare A and MX answers and check which name servers are authoritative.

dig +short NS example.com @1.1.1.1
dig +short A api.example.com @8.8.8.8
dig +short MX example.com @9.9.9.9
diff <(sort primary-zone.txt) <(sort standby-zone.txt)

Lower the TTL a day ahead, then leave the records alone during propagation. If you change an A record at the same moment as the delegation, some resolvers will cache the old answer for the full old TTL and others will see the new one, producing a split that looks like a partial outage.

DNSSEC order matters

When both providers can sign with the same keys, import them and keep the DS record unchanged. When they cannot, remove the DS at the registrar and wait at least the old TTL before changing name servers, then re-add a DS for the new provider. Removing the DS makes the zone insecure but resolvable; changing name servers with a stale DS makes it fail closed, which is worse during an incident.

Rollback

Restoring the previous name servers at the registrar is the rollback, and it is fully reversible as long as both zones still exist and hold the same records. Propagation takes the TTL, not seconds, so keep both providers authoritative and synchronized for thirty days. The irreversible step is deleting the old zone or its DNSSEC keys before the rollback window closes.