Skip to content

CLOUDFLARE

Cloudflare at NetWise

NetWise manages hundreds of client domains through Cloudflare. The important operational principle is that these zones form a managed estate: common security behaviour is maintained centrally, while DNS records and genuine site-specific exceptions remain specific to each domain.

What Cloudflare does for NetWise

Cloudflare is used for:

  • authoritative DNS for domains whose DNS is under NetWise management;
  • proxying normal website traffic where appropriate;
  • TLS between visitors, Cloudflare and correctly configured NetWise origins;
  • custom WAF controls and other edge security protections.

Cloudflare is not the only security layer. Origin/server and application controls remain important, including the controls on NetWise hosting and within WordPress.

DNS onboarding is documented separately in Move a Domain to Cloudflare.

The estate baseline

NetWise has a scheduled Cloudflare Worker named the baseline auditor. It runs daily at 05:30 UTC and audits active zones in the NetWise Cloudflare account against the canonical custom-WAF baseline.

The distinction between a new zone and a known zone is deliberate:

  • a genuinely new Cloudflare zone can have missing canonical rules added automatically;
  • a zone already known to the registry is audited only;
  • differences on a known zone are reported as DRIFT and are not automatically changed.

This prevents the daily process from silently overwriting later configuration changes or deliberate exceptions on established zones.

See Cloudflare Security Baseline for the baseline itself and the onboarding safeguards.

How a zone becomes known

The auditor keeps a registry keyed by Cloudflare zone ID.

The existing estate was explicitly bootstrapped into that registry without making WAF changes. After bootstrap, a zone is treated as new only when its zone ID is first inserted into the registry.

A hostname that reappears under a different zone ID is recorded as having been seen before. Operators should therefore investigate unusual zone recreation or replacement rather than assuming hostname equality makes it the same registered zone.

What automation owns

For a newly discovered zone, the baseline auditor can:

  • inspect the current custom WAF ruleset;
  • add only canonical rules that are missing;
  • preserve unrelated existing rules;
  • verify the exact canonical definitions and their relative order;
  • verify that unrelated rules were not changed;
  • roll back changes created by that onboarding run if verification fails.

For established zones, it reports compliance, drift or API errors without WAF writes.

This means staff should not manually recreate the baseline as a routine part of adding a domain to Cloudflare. Equally, they should not assume that the daily run will repair drift on an established zone.

What remains an operational decision

The baseline does not make every Cloudflare zone identical.

DNS content, proxy status, origin configuration and genuine exceptions still depend on the service using the domain. Before changing an established zone, determine whether a difference is:

  • genuine drift that needs correction;
  • an intentional site-specific rule or exception;
  • a legacy configuration that needs investigation;
  • a failed onboarding state requiring supervised handling.

Do not remove an unfamiliar rule merely to make a zone look uniform.

Where the implementation lives

The current implementation is maintained in the local NetWise Cloudflare tooling workspace under:

workers/baseline-auditor/

The source code is authoritative for exact rule expressions, ordering and runtime behaviour. The wiki documents the operational contract and reasoning rather than duplicating those implementation details.

← Cloudflare · Wiki home