Migrating DNS from Cloudflare: export, fix, cut over

What you'll learn

• How to export a Cloudflare zone and what the file contains
• Which Cloudflare records and features do not survive a move, and what to do about each
• How to check the new zone before anyone depends on it
• The cutover order, including DNSSEC and Cloudflare Registrar
• What you gain and what you give up by leaving Cloudflare DNS

Cloudflare is the default DNS for a large part of the web, and many teams never chose it: it came with the CDN, a free plan or a tutorial. Moving away is usually about control rather than features: EU data residency, access per zone for a team, an audit trail, or not tying DNS to a CDN contract. The move itself is a short checklist, but a few Cloudflare-specific details decide whether it is uneventful.

1 Before you start: what changes when DNS leaves Cloudflare

Be clear about what you give up. Cloudflare runs DNS on a large anycast network, and it bundles DNS with its proxy, WAF and CDN. When the nameservers move away, the proxy stops in front of every hostname, because nothing sends traffic to Cloudflare any more.

• Proxied records (the orange cloud) will point straight at your origin servers.
• Workers routes, Cloudflare Tunnel hostnames and Pages on the apex depend on Cloudflare answering DNS for the zone.
• Email Routing uses Cloudflare's MX and TXT records and stops when DNS moves.
• Page Rules, redirects, cache and firewall rules are proxy features, not DNS; they do not exist outside Cloudflare.

If you depend on the proxy, you can keep it for specific hostnames on most plans by keeping those on a Cloudflare-hosted zone or moving them to another CDN. Decide this per hostname before the move.

2 Step 1: export the zone

In the Cloudflare dashboard open the domain, go to DNS, Records, and use Import and Export to download the zone as a BIND-format file. Through the API the same file comes from the zone's DNS records export endpoint:

curl -s "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/dns_records/export" \
  -H "Authorization: Bearer $CF_API_TOKEN" > example.com.zone

Open the file before you import it. Three things need attention.

2.1 Proxied records contain your origin IPs

For proxied records the export holds the real origin address, marked with a cf-proxied:true tag in a comment. After the move, those names resolve directly to that address. That is often fine, but check two things for each one: the origin accepts traffic from the internet (firewalls that only allow Cloudflare's ranges will block everyone), and you are comfortable publishing the address. If an origin was meant to stay hidden behind the proxy, give it a new address or keep that hostname behind a CDN.

grep 'cf-proxied:true' example.com.zone

2.2 A CNAME at the apex must become an ALIAS

Cloudflare lets you put a CNAME on the zone apex and flattens it into addresses when answering. Standard DNS does not allow a CNAME next to the apex's SOA and NS records. Change that line to an ALIAS record before importing, so the new provider resolves the target and answers with its addresses:

; before (Cloudflare export)
example.com.  300  IN  CNAME  example.pages.dev.
; after (import)
example.com.  300  IN  ALIAS  example.pages.dev.

2.3 Cloudflare-only records

Remove or replace records that point at Cloudflare services you will not use any more: Email Routing MX and SPF entries, Tunnel CNAMEs to cfargotunnel.com, and verification TXT records for Cloudflare features. Keep verification records for other services (Google, Microsoft 365, certificate authorities).

3 Step 2: import and compare

Create the zone at the new provider and import the file. Then compare answers from both sides before anyone uses the new nameservers. A short loop over the names that matter is enough:

for name in example.com www.example.com mail.example.com; do
  for type in A AAAA MX TXT; do
    old=$(dig +short "$name" "$type" @ada.ns.cloudflare.com | sort)
    new=$(dig +short "$name" "$type" @ns1.primedns.net | sort)
    [ "$old" = "$new" ] || echo "DIFF $name $type: cloudflare=[$old] new=[$new]"
  done
done

Use your zone's own Cloudflare nameserver names (shown in the dashboard). Expect differences exactly where records were proxied: Cloudflare answers with its own proxy addresses, the new zone with your origin.

4 Step 3: cut over

1. Lower TTLs at Cloudflare to 300 seconds a day before. Records set to "Auto" TTL are typically 300 seconds already.
2. DNSSEC: if it is on, delete the DS record at the registrar (for Cloudflare Registrar it is managed in the Cloudflare dashboard), wait for its TTL, then continue. The full sequence is in How to change DNS provider with DNSSEC enabled.
3. Cloudflare Registrar: domains registered there must use Cloudflare's nameservers. Transfer the domain out first: unlock it in the Cloudflare dashboard, copy its auth code (EPP code) and start the transfer in PrimeDNS under Domains, so the domain and its DNS end up in one place (or use any other registrar), then set the nameservers. Domains registered or transferred in the last 60 days usually cannot be transferred yet.
4. Change the nameservers at your registrar to the new provider's.
5. Keep the Cloudflare zone unchanged for a few days. Resolvers that still cache the old NS records keep asking Cloudflare, and they should get the same answers.
6. Turn DNSSEC back on at the new provider and add its DS record.

Check the delegation from the parent, which shows the move is complete regardless of caches:

dig +short NS example.com @a.gtld-servers.net   # use your TLD's servers for other TLDs

5 How PrimeDNS handles this

• BIND import with a dry run. Paste or upload the Cloudflare export, preview exactly what will be created, then commit. SOA and the apex NS records are managed by PrimeDNS, and re-running an import skips records that already exist.
• ALIAS records at the apex for what Cloudflare calls CNAME flattening.
• The same import over the API for moving many zones at once, and export back to BIND at any time: no lock-in.
• Built for teams and portfolios: roles per zone, one login across several accounts, and an Audit Log with the old and new value of every change.
• Split-horizon views and Observability (who queries your zones, NXDOMAIN analysis, TTL advice) are part of the DNS product, not add-ons.
• Domain transfer with the auth code in the same panel, so a domain leaving Cloudflare Registrar and its DNS move together.
• EU-based service and data.

If some hostnames depend on Cloudflare's proxy, CDN or firewall, keep those behind Cloudflare or another CDN and move the rest of the zone.

Step-by-step instructions are in the zone migration guide.

6 Frequently asked questions

How do I export my DNS records from Cloudflare?

In the dashboard, open the domain, go to DNS, Records, and use Import and Export to download a BIND zone file. The API offers the same export for scripting.

What happens to proxied (orange cloud) records after moving DNS?

They resolve straight to the origin address stored in the record. Cloudflare's proxy, caching and firewall no longer apply, so make sure the origin accepts direct traffic and that its address may be public.

Can I move DNS away from Cloudflare if my domain is registered with Cloudflare Registrar?

Not while it stays at Cloudflare Registrar, which requires Cloudflare nameservers. Transfer the domain with its auth code (EPP code) from the Cloudflare dashboard, for example to PrimeDNS under Domains, then point it at the new nameservers. Keep the Cloudflare DNS zone running until the transfer is complete.

How long does the move take?

The work takes an hour or two for a typical zone. Resolvers switch to the new nameservers as the NS records cached from the parent zone expire, commonly within one to two days; keep the Cloudflare zone active until then.

7 References

1. Cloudflare: Import and export records
2. Cloudflare: CNAME flattening
3. Cloudflare Registrar documentation
4. RFC 1034 (CNAME and other data, section 3.6.2)

Information about other providers is based on their public documentation as of October 2026. Product names and trademarks belong to their owners. Spotted something out of date? Write to This email address is being protected from spambots. You need JavaScript enabled to view it..