Cloudflare Zone Onboarding Options

We’re diving deep into the different ways you can onboard zones to Cloudflare in this post. If you’re already convinced you want to use Cloudflare and want to skip ahead to the options, expand the table of contents below and jump to your section of interest. Fair warning: we’re covering a principle, a story of how I started looking deeper at Cloudflare for network services and five different onboarding methods, so grab a coffee.

Table of Contents

Communication: The principle That Makes Everything Possible

My blog is called Packets and Principles, so it seems fitting to start this post with a principle: communication.

None of this would have been successful without extensive conversations with many people, from conversations with the CISO, the Cloudflare account manager, the financial controllers for multiple silos, the SOC Director, the architects of DNS and datacenter governance, the application owners, application developers, system architects and systems administrators, web developers, the network manager, colleagues, the users of applications impacted, and many more.

Even for an introvert like me who relishes digging into the technical details, having an impact requires more than just knowledge and doing the right thing. It’s one of the reasons I started blogging again, take opportunities to speak when I can, and have focused on documentation-driven projects in recent times.

Lack of communication causes great ideas to die, so if you have an idea, start writing it down, sharing it, and speaking about it. While we can achieve decent things individually, if we want the leverage to achieve truly great things, we need to do it with the help of others, and communication is the base principle that makes that possible.

How I Started Looking Deeper at Cloudflare

It was 2020, and despite COVID, we were nearing the end of a project to move most of our corporate data centers globally to a world-class provider that would give us consistency and connectivity benefits that would prepare us for the future, reimplementing and doubling down on a colocation strategy that had partially been abandoned years earlier and also allowing us to bring consistency to our cloud connectivity strategy that had saved us during the onset of COVID. That strategy had us putting a network aggregation point or data center in a well-connected world-class colocation facility in-region as close as practical to the facilities and users that needed to access the network. Only one datacenter in India remained to be moved. Our datacenter provider, at ours and other customers’ urging, had announced their intent to acquire data centers in India. Our plan was coming together until it was revealed that the only way we could lease space would be to go through the prior owner under terms that were so crazy our legal team wouldn’t accept them even with heavy modification.

Disheartened by the inability to execute our strategy until after the deal closed, my manager asked me to start looking into cloud-based network options. While it was clear that cloud was the future for compute and storage needs, up until that point, networking in the cloud was primarily about supporting workloads running in that cloud, not for providing the kind of more general network services that we hosted in our colos with WAN circuits, routers, firewalls, switches, load balancers, and VPN appliances. But right about then, Azure, AWS, and others started to show signs that they would introduce network services that not only would allow you to connect to the cloud but also across the cloud to connect your locations together. Now when you are deciding where to place an application, it is generally a best practice to put the application just as close to the user as it needs to be, but no closer. The closer you get the application to the user, the better the performance will be, but also the higher the cost to maintain the application will be, and the more problems you will have with the application due to having less proper, less capable systems the closer you get to the user. But when you are building a network that needs to support all of the applications, you really need to build something that will handle the requirements of every application. One of the biggest levers we have to influence network (and thus application) latency is distance.

Because of that, one key to my first look at cloud-based networking capabilities was making a list of the tens of countries we were in and all the major cities we were in and then researching each cloud network service to evaluate what countries and cities had pops that offered that network service. If cost didn’t matter, we would have had a colo in every major city to provide better service to the business that relied on that network. Maintaining that many pops would be too expensive, but what if a cloud-based service could actually deliver on that promise of a pop in every major city for a similar cost to a brick and mortar colo in the region with all its circuits, power, cooling, and capital cost? That’s what really started to make Cloudflare stand out. It turns out that even though the big cloud providers have an extreme number of pops, they run very few of their services there. So if you are using the more limited CDN services of a cloud provider, you might be able to tap into all those pops, but if you wanted to use their client VPN service, their site-to-site WAN services, their private network (think VPC or VNET) service, or compute service, those were only available in big data centers that were few and far between, in many cases half a continent away from where our hundreds of locations were.

But with Cloudflare, if there is a service that deals with data in flight on its way to an application (including their WAF, client VPN, DLP, SWG, IPSEC, or GRE services), caching of content (including caching of web content, caching of their R2 storage service, and caching of their key value store), or even their workers edge computing or things like snippets, Cloudflare has built that service so that it can run on every server in every pop in over 300 cities, with many major cities having two or more pops. Now, of course, there is a whole lot more nuance to Cloudflare and its services, but this is what got me to start looking deeper, to read their blog and realize how much more fitting they will be for security-critical services in the threat landscape that is yet to come than other network vendors.

Introduction

In the first post in this series, I explained how the F5 breach announced in October 2025 drove me to write now, why I decided to migrate publicly accessible enterprise applications from F5 BIG-IP to Cloudflare, the principle of buying from builders, and the operational complexity of managing appliances across multiple locations. I also provided a high-level overview of the migration process that this series is based on.

This post tackles the first critical decision you’ll face: how to onboard your zones to Cloudflare. This choice will affect everything from how you manage DNS to what features you can use and how much control you have over per-application settings.

For accessibility, we will focus explicit examples in this series on using custom hostnames with custom origin servers as the onboarding option, as it is accessible across a wide range of situations and price points. However, we will cover other, more proper onboarding types in this post so that you can know some of the reasons you might choose those over custom hostnames.

The options range from making Cloudflare your primary DNS provider (full setup) to keeping your existing DNS infrastructure and only routing specific traffic through Cloudflare (partial, or custom hostname setups) and one in between (secondary). Each approach has tradeoffs around DNS control, operational complexity, per-application customization, and plan requirements.

Cloudflare Onboarding Options

Full/Primary Setup

The normal Cloudflare setup makes Cloudflare authoritative for your domain. This is what most people think of when they think of adding a domain to Cloudflare: you change your nameservers at your registrar to point to Cloudflare’s assigned authoritative nameservers and maintaing your domain only on Cloudflare.

If you ever have the pleasure of being targeted by a DDoS for ransom gang (I might be foreshadowing a future story here), you will find out quickly that in addition to targeting volumetric traffic at your IP address or web servers, the DDoS will almost always target your DNS servers with lookups for randomly generated hostnames that may make your DNS servers or middle boxes fall over. A high volume of random requests means that cache and other performance optimizations for DNS servers won’t work, and new sessions for each request can make similar optimizations on middle boxes ineffective. That is one of the reasons that most people will say that a full/primary setup is best, because it dosn’t help if your applicatoin is being protected by Cloudflare but your DNS is down, because it isn’t.

Even though the full/primary setup is often considered best, it can be made even better when combined with the Enterprise only subdomain setup that we’ll discuss later.

Many enterprises will have an internal team or external provider that is already handling DNS for their domains, so moving the hosting of those domains is often the first hurdle or objection you will get when attempting to implement Cloudflare in a sizable company.

DNS, just like networking, underpins the functioning of almost every single piece of technology in an enterprise, so there tends to be rules, governance, and operational practices built up around it that make a full setup difficult or impossible.

Some enterprises will also use record types that are not supported by Cloudflare, and that can also be a hindrance to using a full setup.

For more details, see Cloudflare’s full setup documentation.

Secondary Setup with Override

If your internal DNS team still wants to maintain administrative control but is OK with Cloudflare handling resolution, a secondary setup can be used where Cloudflare pulls copies of zones into their infrastructure via zone transfer using AXFR or IXFR and answers requests. In this setup, you still need to have your registrar point to Cloudflare for resolution, but primary copies of the zones still reside on your infrastructure and can still be managed in whatever way they have been in the past.

DNS override can be used to enable some Cloudflare functionality by setting specific A, AAAA, or CNAME records to Proxied status.

Features that create a DNS record, like Load Balancing and Spectrum, don’t work even with DNS override enabled because secondary DNS with pre-signed DNSSEC does not support Secondary DNS Overrides. Secondary DNS can only override existing records, not create new ones.

If your DNS team answers requests internally for public names different than externally, this may cause issues with only a portion of traffic going through Cloudflare. That may not seem like a big issue, but it may also mean that you aren’t able to lock down your firewalls so that requests from non-Cloudflare IPs are blocked.

Secondary DNS is only available to Enterprise customers.

For more details, see Cloudflare’s secondary DNS documentation.

Full Setup with Subdomains (Enterprise Only)

With this option, you use a separate zone for each application, creating NS records in your second level domain for the subdomain/hostname that point queries to Cloudflare for the subdomain.

Due to the fact that some settings can only be set at the zone level, this is the only option that allows you to set some settings on a per-application basis.

Because administrator access can be controlled at the zone level, this is also the best option if you have different teams that will manage their own Cloudflare settings.

If you are used to using BIG-IP GTM or DNS in a similar manner, this is very similar to how that is onboarded in your second level domain by creating NS records that point to the BIG-IP. For a subdomain setup, we would just point those NS records at Cloudflare instead.

This also allows you to use Cloudflare even if the DNS of the parent domain is hosted by another provider or your own DNS servers.

This feature is currently only available on an Enterprise plan.

With a subdomain setup, it is still important to have some sort of protection for the parent domain DNS resolution, as an attack on the parent domain could prevent resolution of the NS records that delegate the subdomain to Cloudflare. This could be provided by Magic Transit and the DNS protection feature built into Magic Firewall, or the parent domain could be on another provider (or primary or secondary DNS on Cloudflare) that provides protection.

For more details, see Cloudflare’s subdomain setup documentation.

Partial Setup with CNAME (Business/Enterprise)

This method of onboarding relies on you setting up CNAME records in your authoritative DNS that would point, say, app.examplecompanydomain.com to app.examplecompanydomain.com.cdn.cloudflare.net, in addition to creating a TXT record to validate that you own the domain.

Partial setups may not be able to take advantage of CNAME flattening if your authoritative provider doesn’t support it, making DNS resolution time longer than some of the other options.

With a partial setup, it is still important to have some sort of protection for the parent domain DNS resolution, as an attack on the parent domain could prevent resolution of the CNAME records that direct traffic to Cloudflare.

If your organization is used to using BIG-IP LTM and pointing an A record directly at a virtual IP running on LTM, this can seem a bit more similar to them, in that the existing A record would be replaced by a CNAME pointing at a *.cdn.cloudflare.net hostname.

On the Business plan, if another team at your company is able to request that DNS TXT records be setup, they could inadvertently take over the partial setup for your domain. Enterprise plans have a protection against this called zone holds, but if you were on Enterprise, you could use the better subdomain option.

Partial setup is available to customers on Business or Enterprise plans.

For more details, see Cloudflare’s partial setup documentation.

Alternate Domain with Custom Hostnames (Available on Any Paid Plan)

This last option is not usually covered in documentation about onboarding options.

This works by onboarding an alternate domain as primary onto Cloudflare where you will run Cloudflare services, and then using the custom hostnames feature to allow the alternate domain to terminate TLS connections for the hostname that is used to run the application. Then you point a CNAME from the original domain to a name in the alternate domain.

There is a more marketing focused name for this feature called “SSL for SaaS,” where you could use this to allow your customer to point one of their domains at your Cloudflare account, but this also works for your own domains.

If your organization is used to using BIG-IP LTM and pointing an A record directly at a virtual IP running on LTM, this can seem a bit more similar to them, in that the existing A record would be replaced by a CNAME pointing at a record in your alternate domain name.

This feature is supported on any paid plan type, so we will focus on this in the rest of the series so that most readers could practice this method that could also be used at a day job. We will, however, use it in combination with some additional paid features like Advanced Certificates and Total TLS that will help us to comply with some certificate issuance restrictions that are more common in enterprise environments, like limiting the issuance of wildcard certificates with a CAA record.

Without an Enterprise plan, custom hostnames do have some potential downsides that we will need to work around in our configuration, like requests landing at your origin with the SNI of the custom origin, and you also must use TLS certificates provided by Cloudflare. With an Enterprise plan, you can rewrite the SNI with SNI rewrites and use certificates that you provide yourself. Custom hostnames also aren’t available for use at the apex of a domain unless you are using an Enterprise plan, but in a company, most of your apps won’t be running at the domain apex.

Like secondary and partial setup, it is still important to have some sort of protection for the original domain DNS resolution, as an attack on the original domain could prevent resolution of the CNAME required to chain to the alternate domain.

For more details, see Cloudflare’s custom hostnames documentation.

Comparison of Onboarding Methods

Here’s how the different onboarding approaches compare across key dimensions:

Choosing an Onboarding Type

What type of onboarding you choose will depend highly on how willing your organization is to make certain changes, how highly optimized you want your security, cache, HTTP versions, timeout, and other settings, how much ability you have to configure TLS settings on servers, and what plan you are planning to use.

If you have full control over DNS and want the simplest setup with the best DDoS protection for DNS infrastructure, go with full/primary.

If you need per-application control over Cloudflare settings and have an Enterprise plan, the subdomain approach combined with full/primary or secondary is the most proper solution.

If you need to keep your existing DNS provider but can use CNAMEs and have a Business or Enterprise plan, partial setup is your best bet.

If you need maximum flexibility across different plan types or are just getting started with Cloudflare, custom hostnames with an alternate domain provides the most accessible path forward.

What’s Next in This Series

Now that you understand the different ways to onboard zones to Cloudflare and why we’ll be focusing on custom hostnames for the remainder of this series, the next post will dive into SSL/TLS at the origin. We’ll cover why the cloud based model pushes us towards end-to-end encryption, managing server certificates with origin certificates or certificates from a CA,working with application teams to configure web servers for TLS, implementing authenticated origin pulls, setting up NAT to enable direct to server connectivity and enabling advanced certificates and Total TLS in Cloudflare.

For the complete roadmap of topics we’ll be covering, refer to the What’s Next in This Series section from the first post. Each subsequent post will build on the foundation we’re establishing here, taking you from zone onboarding all the way through to production go-live and F5 decommissioning.

The journey from appliances to cloud-delivered security is as much about understanding your options as it is about the technical implementation. Choose the onboarding method that fits your organization’s constraints today, knowing that you can evolve your approach as your Cloudflare usage matures.