Cloudflare partial setup – Best Practice and Advise

Hi everyone,

We are currently evaluating a Cloudflare setup for one of our clients and would like to validate whether our approach makes sense and if others have experience with a similar setup.

Context & requirements

The main reason for implementing Cloudflare is performance improvement across multiple markets
The client prefers a partial (CNAME) setup, because they want to keep DNS management internal within their IT team
This is important due to broader domain usage, internal policies, and increased compliance requirements after a recent acquisition

Proposed approach

Use a Cloudflare Business plan
Implement Cloudflare in a partial (CNAME) setup for all current websites and a future webshop
Keep DNS fully managed internally, while Cloudflare is used for CDN, caching, and performance-related features

Questions

Does this sound like a correct and recommended approach for this use case?
Are there any known limitations we should be aware of when using a partial setup with DW10?
- What configurations should be done then in DW10 to accomplish this?
Are there any official docs, best-practice guides, or reference links you would recommend reading?
Would implementing Cloudflare now with a partial setup have any impact on the upcoming Cloudflare roll-up (Product Brief Q4), or is it better to wait until that is finished?

Any insights or shared experiences would be greatly appreciated.

Kind Regards,

Ferri

Hi Ferri,

For the US market, we use Cloudflare extensively and currently run a mix of partial (CNAME) and full DNS setups, depending on customer preference. So yes — a partial setup works well and is a perfectly valid approach.

Beyond performance and CDN, we also use Cloudflare as a first-line WAF. All traffic on port 443 is proxied through Cloudflare, and we apply a number of baseline protections, such as:

Geo-based filtering (e.g. allowing US/CA traffic, blocking or challenging others)
SQL Injection validations
Overall rate limiting
Cloudflare-managed rulesets (with some tuning required to allow backend traffic that wouldn’t normally be allowed for frontend requests)

We also make active use of caching rules (CDN), and in some cases go beyond static assets to improve performance:

Caching the homepage for anonymous users with an empty cart
Caching certain anonymous AJAX / WebAPI requests where responses are deterministic (e.g. product sliders)

This has proven very effective during traffic spikes caused by bots or marketing campaigns. From our experience, we haven’t seen any major issues when pairing Cloudflare with DW.

One important consideration is tracking: requests served directly from Cloudflare won’t reach the VM, so DW-based tracking may not capture them. In practice, this is often acceptable (or even desirable), as most customers rely on third-party analytics like Google Analytics, which continue to function normally since Cloudflare still serves the required JS assets.

More broadly, we see Cloudflare as a first line of defense, not the only one. Some protections (e.g. advanced POST inspection) are optional and can be costly in Cloudflare, so DW still needs to handle things like SQL injection detection and other security checks. The upside is that DW can do this with far less load, since Cloudflare absorbs much of the traffic and noise upstream. It does mean audits and troubleshooting span an additional platform, but overall this has been a very positive trade-off for us.

Unfortunately, I don’t have a single document or reference I can share. We operate on an Enterprise subscription, which may expose additional configuration options compared to Business.

Hope this helps.

Best regards,
Nuno

Developer forum

Cloudflare partial setup – Best Practice and Advise

Replies