Use PD DirectAdmin DNS lifecycle management to link an existing native domain’s zone to the intended customer. The setting’s create-zone wording does not mean this module creates a missing domain or standalone DNS zone.

Prepare the existing domain

Confirm the domain is already on the intended DirectAdmin account and is visible to the configured provider context. Review its required records and client ownership. A successful domain-list test does not prove every DNS write or signing action.

Enable and inspect the binding

1. Open DirectAdmin DNS → Settings.
2. Review Automatically create a DNS zone on registration and new services.
3. Enable the intended lifecycle policy only after domain/account preparation.
4. Follow the platform’s normal controlled activation process.
5. Inspect Zones and Activity for the intended provider and customer binding.

An absent domain is reported in Activity rather than created by the module. Automatic new setups need an enabled DirectAdmin connection that accepts new domains. A connection reserved for existing domains is not the intended target for a new setup. Review which eligible connection will be used and confirm that the native domain already exists in its account context.

On Blesta, review the relevant normal domain/service activation and resulting customer binding, rather than borrowing registrar-hook assumptions from another platform.

The DirectAdmin domain lookup does not supply authoritative nameservers to this workflow. Review the provider’s Authoritative nameservers (optional) setting against the actual prepared servers before requesting takeover. A missing list can cause takeover to be skipped; saving a list does not configure the DNS server or prove registrar publication.

Review retention and delegation

Removing a management relationship is different from deleting the native domain. This module refuses standalone provider-zone deletion, including requests reached through orphan cleanup or termination policy. Do not treat a refusal as proof the server zone was removed.

On Blesta, nameserver takeover can request a change through the Domains plugin’s registrar layer when that route is available and the registrar accepts it. Match the intended TLD takeover list, confirm that the existing native zone is ready, and inspect the separate takeover result in Activity. If the route is unavailable or the registrar refuses it, complete delegation through its supported workflow. The takeover list is not a domain-binding filter.

Verify the actual existing domain and binding after an uncertain result before repeating the lifecycle action. Retain the event, original action time and redacted error while your hosting team checks the binding and delegation separately. Do not remove a native hosting domain merely to clear a DNS-management warning.

Check the domain and delegation

Your hosting team should compare the lifecycle event, automation setting and provider eligible for new setups with the actual existing DirectAdmin domain and zone, current records and module customer/domain/service binding. A saved connection or completed order does not establish that DNS creation or registrar nameserver update succeeded. Check Activity for creation and takeover outcomes separately, then verify actual delegation. Inspect an uncertain creation before repeating it.

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