PD Cloudflare DNS can create zones from billing-platform lifecycle events. Review provider authorisation, ownership and retention before enabling it; creating a zone and changing the domain’s nameservers are different operations.

Prepare the provider and delegation plan

Confirm the enabled provider selected for new setups, its acceptance of new domains and its token/resource coverage for the intended zone creation. A provider retained for existing domains is not eligible merely because it still connects. A connection test for existing-zone reads does not prove every new-zone action is authorised. Check the provider result for a controlled domain before relying on automation for customer activations.

For full Cloudflare DNS hosting, the domain’s registrar delegation must point to the zone’s assigned nameservers. A newly created provider zone can remain pending until that is completed; do not treat its appearance in the module as proof that it is authoritative.

Enable zone creation

1. Open PD Modules → Cloudflare DNS → Settings.
2. Enable Automatically create a DNS zone on registration and new services when that is your intended policy.
3. Review the relevant billing-platform lifecycle event and ownership linking.
4. Follow a controlled registration/activation process and inspect Zones, Activity and Maintenance for the actual result.
5. Verify the correct client assignment and authoritative nameservers before handing over editing access.

On Blesta, review the domain/service activation event. For eligible registered domains and selected TLD takeover settings, the module can request nameserver updates through Blesta’s Domains registrar integration when that integration and registrar support the operation. Check the returned registrar result; a stored zone or accepted request is not proof that public delegation has changed. If the integration is unavailable or refuses the change, use your supported registrar process and verify the nameservers separately.

Review cleanup before cancellation

By default, orphaned zones are flagged for attention. Automatically clean up orphaned zones, When cleaning an orphan, also delete the zone at the provider, and Keep the DNS zone when a service is terminated affect different retention decisions. Read their saved values before ending a service.

Deleting a provider zone removes its DNS records and can stop dependent services. Removing a client binding is a different way to withdraw access without deleting DNS. Keep an appropriate backup and an agreed retention plan before a destructive cleanup.

Check failures without duplicating zones

Review the original action and error in Activity/Maintenance. A failed create should be distinguished from an existing pending zone, a wrong account or a registrar-delegation issue. Reconcile the provider state before repeatedly creating a zone or changing nameservers.

Your hosting team should retain the domain, lifecycle event, original request time and redacted result while checking the actual creation and delegation stage. Do not include the provider token or a whole client-account export.

Check the created zone and delegation

Your hosting team should compare the original billing lifecycle event, eligible selected provider, actual zone, customer assignment, queued retry and Activity/Maintenance result before another create. Your DNS administrator should compare the zone’s assigned nameservers with the registrar result and public delegation separately. Review cleanup and keep-zone choices before ending a service. Do not delete a pending zone, repeat orders or change delegation merely to obtain a different result.

See the PD Cloudflare DNS Blesta guide for related tasks, or explore the module.