Leaving Cloudflare: proxied records, flattened apex CNAMEs and the registrar lock

An orange cloud is not a DNS record. It is a routing decision that makes Cloudflare part of the HTTP path, changes the addresses returned to clients, and can hide the origin value that another DNS provider would publish directly. A move away from Cloudflare must separate portable DNS from proxying, flattening, redirects, and registrar policy before the delegation changes.

Cloudflare proxied records carry two behaviors#

Cloudflare documents that A, AAAA, and CNAME records can be Proxied. A proxied query returns Cloudflare anycast addresses instead of the configured origin, and HTTP/HTTPS traffic goes through Cloudflare. A DNS-only query returns the origin address and does not route that traffic through Cloudflare. See Cloudflare's current Proxy status documentation.

A live query on September 27, 2026 showed the public side of that behavior for example.com:

dig +dnssec +noall +answer example.com A

example.com. 300 IN A     172.66.147.243
example.com. 300 IN A     104.20.23.154
example.com. 300 IN RRSIG A 13 2 300 20260927200628 20260925180628 34505 example.com. ...

Those answers do not tell you what an API-configured origin is. A provider API export is therefore preferable to copying public DNS. DNSMigrator's canonical record metadata preserves Cloudflare's proxy flag during the source read. When the destination does not support proxying, the translation engine removes that metadata and emits a proxy-lost warning: traffic will go directly to the record value without Cloudflare's CDN or WAF.

That warning requires an application decision, not just a DNS acknowledgement. Before publishing an origin such as the documentation address below, answer these questions:

www.example.com. 300 IN A 192.0.2.44

• Does the origin accept traffic from the public Internet rather than only Cloudflare IP ranges?
• Does it have a publicly trusted certificate for the hostname?
• Which cache, redirect, bot, rate-limit, firewall, and header rules must move elsewhere?
• Will exposing the address change the origin's threat model?

Test the candidate endpoint while retaining the production hostname:

curl --resolve www.example.com:443:192.0.2.44 \
  --fail --show-error --verbose https://www.example.com/health

This tests TLS, the Host header, and the HTTP response at that address. It does not reproduce Cloudflare products, and it does not verify DNS. Run direct authoritative DNS queries separately.

Cloudflare CNAME flattening is not an apex CNAME you can copy#

Cloudflare's CNAME flattening documentation says flattening follows a CNAME chain and returns the final IP address instead of the CNAME. It also allows a CNAME-like target at the zone apex.

The apex is special because it already owns SOA and NS data. RFC 1034 section 3.6.2 says that when a CNAME exists at a node, no other data should be present there. A literal apex CNAME therefore conflicts with the records a zone needs. Providers bridge that gap with different, nonuniform mechanisms.

Suppose Cloudflare stores this intent:

example.com. 300 IN CNAME app.hosting.example.

A flattened public response may contain only addresses:

example.com. 300 IN A    192.0.2.80
example.com. 300 IN AAAA 2001:db8::80

The right destination representation depends on its capabilities:

1. A native hostname ALIAS/ANAME can preserve the target and follow address changes.
2. A destination that explicitly supports apex CNAME flattening can preserve the CNAME-like intent.
3. Amazon resource aliases may need both a DNS name and the resource's hosted zone ID.
4. Static A/AAAA records preserve only the addresses observed at one moment and will not follow later target changes.
5. A destination with none of these options cannot represent the record safely.

DNSMigrator's translator follows that order of ideas. It maps to a supported alias form where possible. For an apex CNAME that cannot become an alias, it can use supplied current A addresses with a warning that they are static. Otherwise it blocks the row as an unresolvable or unsupported apex alias. Review apex CNAME and alias translation instead of accepting a superficially similar record.

Redirects and worker routes are applications#

Cloudflare redirects and Worker routes are attached to hostnames, but they are not ordinary DNS resource records. The same is true of provider-specific feature types in other platforms.

DNSMigrator classifies Cloudflare redirect and worker-route types as provider features. If the destination does not support the same type, translation blocks the row and tells you to recreate the behavior there. It does not synthesize an A record or assume an HTTP status code.

Build a small behavior inventory before cutover:

http://example.com/*       -> https://www.example.com/$1   301
https://old.example.com/*  -> https://docs.example.net/$1  302
api.example.com/*          -> Worker route

Then test status codes, path and query preservation, methods, and TLS at the replacement edge. DNS can direct a name to that edge; DNS cannot implement the redirect itself.

Cloudflare Registrar changes the order of the move#

Cloudflare's Registrar FAQ states that domains on Cloudflare Registrar use Cloudflare nameservers. Custom-branded nameservers on eligible plans are still Cloudflare nameservers. If you need unrelated authoritative nameservers, Cloudflare says to transfer the domain to another registrar.

That creates two separate migrations:

• Registration transfer: move the domain's registrar of record while keeping the current Cloudflare nameservers in place.
• DNS operator change: after the transfer completes and the new registrar permits it, change the delegation to the new DNS provider.

Do not combine those state changes into one unexplained maintenance window. Confirm transfer eligibility, authorization, domain contact access, locks, and DNSSEC requirements against the current registrar documentation. A registration transfer should not require changing working DNS at the same time.

DNSMigrator distinguishes DNS-provider and registrar connections. Automated cutover requires a registrar connection and stores the original nameserver set so it can request a revert if needed. Guided cutover gives you the exact NS and DS actions when the registrar API cannot perform them. See registrar connections and cutover.

Leaving Cloudflare: how to migrate DNS away from Cloudflare#

Exit checklist#

• Source data came from the Cloudflare API, not only an AXFR or recursive lookup.
• Every orange-clouded name has an origin, TLS, and edge-security plan.
• Apex targets use a live destination alias mechanism or an explicitly maintained static address.
• Redirect and Worker behavior has an application-layer replacement and tests.
• DNSSEC DS removal and publication are scheduled in the correct order.
• A Cloudflare Registrar domain is transferred out before assigning third-party nameservers.
• Old and new authorities answer equivalent portable DNS throughout the delegation TTL.

Leaving Cloudflare is straightforward only after “Cloudflare” has been split into its DNS, proxy, application, and registrar roles. Move each role deliberately; the NS change comes last. If Route 53 is the candidate destination, compare its alias and routing model in Route 53 vs Cloudflare DNS. Put signed zones through the DNSSEC migration procedure, compare the authorities with the DNS record diff tool, and finish with the DNS migration checker.