Move DNS from Cloudflare to PowerDNS safely Print

This guide is for administrators moving authoritative DNS from Cloudflare to their own PowerDNS infrastructure. It does not migrate a website or mailboxes, and it does not require changes to a working PowerDNS Manager installation.

Prepare the destination and recovery plan

• Confirm the destination nameservers are configured, reachable over UDP and TCP port 53, and authorized to serve the zone. Test secondary replication before changing the domain's delegation.
• Save the existing nameserver delegation, registrar DNSSEC/DS settings, DNS records and relevant Cloudflare settings. Back up any existing PowerDNS zone before importing.
• Keep Cloudflare and the current website/email services active during the migration. Schedule a maintenance window and decide how record changes will be synchronized during the transition.
• If Cloudflare is also your registrar, confirm that your registration permits changing to external nameservers before planning the move.

Export the zone using Cloudflare's supported feature

1. Open your domain in the Cloudflare dashboard and go to DNS → Records.
2. Select Import and Export, then Export.
3. Save the exported BIND-format zone file securely. Repeat for each domain being migrated.

For automation, Cloudflare provides a native DNS-record export endpoint. Use a token scoped to the intended zones with DNS Read permission; Zone Read alone is not the DNS-record permission. Keep tokens out of source files, public directories and ordinary support replies. See Cloudflare's export documentation.

Review the complete records and Cloudflare-specific behavior

• Preserve the full record names and values, TTLs, MX priorities, SRV priority/weight/port values, quoted TXT data and CAA settings. Do not rebuild a zone file by writing only each record's type and content.
• Check A, AAAA, CNAME, MX, SPF, all DKIM selectors, DMARC, verification records and any other records used by your applications. Preserve mail-server address records as well as MX records.
• Cloudflare proxy status, Workers, redirects, WAF rules and CDN behavior are not PowerDNS features. Export comments may describe proxy or flattening settings, but importing them does not reproduce those services. Verify origin connectivity and trusted TLS certificates before removing a proxy that your website depends on.
• A flattened apex CNAME or Cloudflare-specific automatic TTL needs an explicit destination-compatible configuration. Do not assume an ordinary DNS server will reproduce Cloudflare's behavior.
• Use the destination's intended SOA and NS records. Do not blindly copy Cloudflare nameservers or DNSSEC signing records into a newly signed zone.

Import and test before changing nameservers

Use the zone-loading facility documented for your installed PowerDNS version and backend. PowerDNS 5 calls it pdnsutil zone load; older versions use pdnsutil load-zone. Loading into an existing zone replaces its records, so preserve a restorable backup and confirm the exact target before proceeding. See the pdnsutil manual.

1. Import one test zone first and read the complete result. Stop on parsing errors or unsupported records rather than skipping them silently.
2. Use the version-appropriate zone check and record listing. Compare the imported records against the export, allowing only the intended SOA, NS, TTL or provider-specific changes.
3. Query every destination nameserver directly for SOA, NS, website records, MX and mail-authentication records. Confirm that secondaries have received the intended zone.
4. Test the destination website and mail routes without changing public delegation. Keep both providers' records synchronized until the switch.

Plan DNSSEC before the delegation change

Warning: Changing nameservers while the parent still publishes a DS record for the old provider's keys can make the domain fail validation. A DS record belongs at the parent through your registrar; adding a new DS to the child zone is not a replacement.

For an ordinary migration with different signing keys, agree a controlled transition with the registrar and DNS administrator:

1. Remove the old DS record through the registrar while the old provider continues signing and answering.
2. Verify the parent no longer publishes it and wait for the previous DS cache lifetime to expire. Use the actual TTL and registrar guidance, not a fixed waiting period.
3. Only after the destination records and DNSSEC transition are ready, change the nameserver delegation. Keep the old service available through the previous delegation's cache lifetime.
4. When all delegated destination nameservers serve the intended signed zone and the old delegation can no longer be cached, publish the destination's correct DS through the registrar.
5. Validate the complete DNSSEC chain using a validating resolver and test website and mail delivery again.

This approach includes a temporary period without DNSSEC validation. If uninterrupted DNSSEC is required, use a coordinated key or multi-signer migration supported by both providers instead of this basic sequence. Do not disable signing first while an old DS can still be cached. See Cloudflare's DNSSEC guidance and PowerDNS's operational instructions.

Monitor and retain rollback

Check resolution through independent recursive resolvers, test the website with and without www, and send and receive test email. Watch for SERVFAIL, missing records and secondary-transfer failures. Keep the old service and exports until the relevant caches have expired and checks pass.

If rollback is needed, review the current DS/key state before restoring the old nameservers. A nameserver-only rollback can also fail DNSSEC validation. Stop and involve the DNS administrator if the signing transition is unclear. For PowerDNS Manager configuration, use its separate module guide.