Synchronize a DNS package across multiple servers and select its master

Add and test each provider connection first. Verify permission to read and write the relevant zones. A provider that cannot create zones can still be suitable for an existing verified binding when the required remote operations are available. Do not assume that a valid token authorises every domain in an account.

Review record types across the selected backends. The package uses their compatible intersection for records. DNSSEC, reverse DNS and secondary-zone capabilities require additional per-zone checks, and synchronization does not copy provider-specific proxy settings, signing keys, hosted files or email accounts.

1. Open DNS packages and edit the package.
2. Open Servers, choose Add server, then Add servers to this package.
3. Tick one or several connections, or use Select all when every listed connection belongs in this package. Choose Add selected servers.
4. Select exactly one Master server. Choose the backend whose managed records should be the source for this package.
5. Enable Synchronize all added servers when that is the intended arrangement, then choose Save servers.

There is no need to restrict this workflow to a hard-coded pair of providers. The current implementation checks provider capabilities and permissions. Add only the servers you intend to operate; a package does not automatically enroll every connection in the installation.

Use an owned test zone and compare the master and every assigned target. Check records, TTLs, provider bindings and job status. Targets can fail independently, so one successful result does not establish that all servers are synchronized. Resolve the failed target's specific permission, record-type or connectivity problem.

Query every authoritative nameserver directly. A synchronized secondary copy has no effect on public resolution unless it is part of the domain's effective authoritative arrangement. Do not change registrar nameservers until all intended authorities answer consistently.

No. Verify the registry or parent delegation separately from the package's management and replication state. Prepare any required nameserver change through its own reviewed workflow.

This is API-driven replication. It is distinct from AXFR-based secondary DNS; the package does not enable both by treating them as interchangeable. Existing provider-owned NS records and DNSSEC material require deliberate handling.

Removing a server from the package or turning off synchronization retains its remote zones. Plan cleanup separately after confirming that no domain delegates to that server. When changing the master, use the dedicated workflow and verify the destination before relying on it; failure should not be worked around by deleting the working source.

• Change a DNS package master without confusing replication and delegation
• Add a DNS provider connection and prove that it can manage zones
• Configure secondary DNS with an authorised transfer source
• Operate DNSSEC from zone signing through parent DS verification