Use PD DNS Manager replication pairs to keep a target provider’s record copy aligned with a source. Treat the source as authoritative for the mirrored data: target-only edits can be overwritten or removed on a later sync.

Before a change, confirm the provider connection and the actual zone it resolves. With Route 53, name-based operations resolve the first matching hosted-zone name; selecting a familiar domain is not sufficient when AWS holds multiple zones with that name. Have your AWS administrator compare the hosted-zone ID, records and assigned nameservers before proceeding. With Google Cloud DNS, the current connection derives the managed-zone name from the domain. An existing zone with a different native name can appear in a list yet fail to open correctly; establish that mapping with your Google Cloud administrator instead of creating a duplicate zone.

For a PowerDNS backend, module reads and zone-file snapshots omit disabled native record values. Editing an affected record set can rebuild it from the enabled values. If your hosting team uses disabled records, preserve and review the native record set with your DNS administrator before module changes; use your established native management process where those values must be retained. A module export is not a complete backup of those disabled values or other provider settings.

Administrative bulk jobs and replication write directly to the provider. Customer editing locks, allowances, content rules and forwarding-record protections must not be assumed to stop these operations. Your hosting team must review the target zones and exclude records owned by another feature before running them.

Prepare both providers

Connect and test the source and target. Review target permissions, record types, quotas and minimum TTLs, and keep copies of records that already exist at the target. Choose a target intended for replication, rather than a separately maintained production zone with unrelated records.

Record mirroring is not proof of DNS failover. Registrar delegation, the target nameserver’s authority, DNSSEC and the service’s operational design must support the DNS arrangement you intend. Provider-specific proxy and forwarding settings do not become portable merely because records are copied.

Configure the pair

1. Open DNS → Maintenance and find Multi-server replication.
2. Add a pair with the intended source and target providers.
3. Review the direction and scheduled interval before saving.
4. Use Sync now for a controlled first run.
5. Inspect the result and compare the source and target zone records.
6. Verify the intended public DNS behaviour separately.

A missing target zone can be created. Existing target records are reconciled with the source without deleting and recreating the entire target zone. The target’s own SOA and apex NS identity are retained; ordinary record changes can include additions, replacements and removals. TTL differences can also cause a remove-and-add change. The sync does not take an automatic safety snapshot or perform a final target-record verification; preserve a target copy beforehand and read back the result yourself. A failure after a removal can leave a partial result. Secondary source zones are skipped, and deleting a whole source zone does not automatically delete its old target zone.

Keep direction and ownership clear

Do not make conflicting manual edits at both ends. Review an existing pair before changing either provider or using the target for unrelated DNS. A source deletion or invalid record deserves investigation before propagating a bad configuration further.

If a run is incomplete, check per-zone/provider errors and the last completed maintenance result. Reconcile what changed before repeating it. Keep the pair, zone, request time and redacted error for support. For a one-time move followed by registrar cutover, use provider migration rather than leaving an unintended ongoing mirror.

Check the replicated records

Your hosting team should compare the pair’s direction, source records, target-only records and actual target after the run. Check provider permissions, supported types, quotas and the last cron result separately. A failed sync can leave removals already applied; use your preserved target copy to plan recovery before another run.

See the PD DNS Manager Blesta guide for related tasks, or explore the module.