Enable automatic zone creation after reviewing the Google project, initial records and intended client binding. A zone created at Google Cloud is not proof the registrar delegates the domain to it.

Prepare the provider

Connect the intended project and confirm permission for zone creation as well as listing/records. A successful Test connection proves the tested list request, not every write.

Check which enabled provider connection is accepting new zones and which project its JSON selects; an existing-domains-only connection is not the destination for new setups. Inspect the actual chosen provider in Activity.

Check existing zones and prepare required website, mail and verification records. Automatic zone creation does not migrate all settings from an earlier DNS host.

Enable and inspect the lifecycle action

1. Open Google Cloud DNS → Settings.
2. Review Automatically create a DNS zone on registration and new services.
3. Enable it for the intended lifecycle policy.
4. Follow a controlled normal activation process and inspect Zones and Activity.
5. Confirm the project, records and customer binding before directing the client to DNS.

On Blesta, review the relevant domain/service activation and resulting account binding. Use the platform’s normal lifecycle rather than event names or registrar hooks borrowed from another billing system.

Keep takeover and zone creation separate

On current Blesta installations, automatic TLD takeover can request nameserver changes through the Domains plugin and a registrar module that supports those updates. It depends on the saved automatic-zone/TLD policy and the platform accepting the registrar request. Confirm the actual public delegation afterwards; a created zone or accepted request is not proof that resolver traffic moved. If that registrar route is unavailable, arrange the nameserver change through your normal registrar process.

Compare the registrar delegation with the exact managed zone’s assigned nameservers. A successful registration/service action does not prove every DNS action succeeded; review the original result before repeating a create.

Review cleanup and retention

Check Automatically clean up orphaned zones, When cleaning an orphan, also delete the zone at the provider and the saved service-termination retention choice before cancelling services. Removing management and deleting provider DNS are different outcomes.

Keep a current record snapshot and deliberate retention policy for zones still serving traffic. Reconcile actual existing zones after an uncertain response, then keep the lifecycle event, action time and redacted result if support is needed.

Check the created zone and delegation

Your hosting team should identify the lifecycle event, selected accepting provider and project, then compare zone creation, customer assignment and registrar delegation separately. A successful domain/service action does not prove every DNS action completed. Inspect existing managed-zone identities before repeating an uncertain creation and review retention/provider-deletion settings before cancellation.

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