Enable automatic Azure DNS zone creation only after reviewing provider scope, initial records and client ownership. A created provider zone and a working registrar delegation are separate outcomes.

Prepare the connection

Confirm the app can create zones in the intended subscription/resource group. The connection test uses a list request; it is not proof of every write. If the group does not exist, have its creation prepared or separately authorised instead of assuming the DNS role grants it.

Check which enabled provider connection is accepting new zones and the subscription/group it selects. A connection set to existing domains only is not the destination for new setups; inspect the actual chosen provider in Activity.

Review existing zones and required website, mail and verification records. Automatic creation is not a migration of an old DNS service.

Enable and inspect the lifecycle result

1. Open Azure 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 provider/group, records and account binding before directing the customer to DNS.

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

Keep takeover 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 request. Verify the actual public delegation afterwards; a created zone or accepted request does not establish that resolver traffic moved. If that registrar route is unavailable, arrange the change through your normal registrar process.

Check the assigned Azure nameservers and registrar delegation for the exact zone. A successful main registration/service action does not prove DNS creation or delegation succeeded; inspect the original result instead of repeatedly creating zones.

Review cleanup and retention

Check Automatically clean up orphaned zones and When cleaning an orphan, also delete the zone at the provider before cancellations or service cleanup. Removing management and deleting live provider DNS are different decisions.

Keep a current record snapshot and an agreed retention policy for zones still serving traffic. If the create result is uncertain, reconcile actual provider state before retrying. Retain the lifecycle event, action time and redacted error for support.

Check the created zone and delegation

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

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