Cloudflare management without losing DNS ownership

SHM supports Cloudflare in two related contexts. An account can connect a personal Cloudflare API token and manage matching hosted zones. A server using Synconix DNS Manager can expose SDM-managed Cloudflare controls through the DNS workflow. Both begin with the same rule: the hosted account must own the domain context it is allowed to change. Keeping these paths distinct prevents conflicting changes between a personal token and a server-managed DNS cluster.

Credentials and ownership

Token scope

The account connection is designed for a Cloudflare API token with Zone Read and DNS Edit permissions for the intended zones. SHM stores the token encrypted on the server and does not return it to the browser after saving.

Zone discovery matches Cloudflare zones to domains hosted by the account. A valid token is not enough to manage unrelated zones, and an account domain is not enough to use a token that cannot access it.

Ownership inside a parent zone

Users can review and manage supported DNS records for matched zones. Parent-zone logic allows a hosted subdomain to work within its permitted name without granting control over the rest of the parent zone. Record names and zone ownership are validated before mutation.

This matters for agencies and shared environments where one Cloudflare zone may contain more than one operational area. The panel distinguishes records inside the hosted name from the broader set the token may technically be able to edit.

Synchronization without collateral damage

Sync should preserve what it did not create

Cloudflare sync can add or update supported local records in the remote zone while leaving unrelated Cloudflare records intact. It is not a replace-the-world operation. Optional automation can add the expected address record for a newly created subdomain when the account setting enables it.

That preservation rule is essential. Mail, verification, third-party applications, and older services often share a zone. Synchronisation should reconcile the records SHM owns without deleting unrelated records.

Settings that belong beside DNS

The account workspace includes practical zone controls such as development mode, security level including Under Attack mode, cache level, Always Online, Brotli, and cache purge where the Cloudflare API and zone support them. These are operational controls, not a copy of every Cloudflare dashboard page.

A cache purge remains explicit because it affects live traffic. Development mode remains visible as a temporary operating state with a clear effect on the zone.

The server-managed path

When SDM owns the path

When Cloudflare is connected through SDM, SHM uses the SDM-managed route for zone status, records, proxy state, settings, and purge operations. The DNS cluster remains the ownership and synchronization authority. Personal-token fallback is used only where the selected workflow and ownership contract allow it.

This gives hosted users useful Cloudflare control without handing them cluster credentials or requiring every customer to understand the server's DNS topology.

One operational rule

The integration is deliberately narrower than logging into Cloudflare as the account owner. It covers the DNS and zone operations that belong in hosting management, protects token handling, and checks the domain scope again at execution.

That is the practical value: hosted domains, local DNS intent, Cloudflare state, and ownership rules meet in one workflow. The user gets fewer dashboards. The server administrator gets fewer shared credentials. Unrelated DNS records remain protected from unintended changes.