PD DNS Manager brings zones from different DNS backends into Blesta. Connect the account that hosts your zones, then review its records and capabilities before handing editing access to customers.

Before a change, confirm the provider connection and the actual zone it resolves. With Route 53, name-based operations resolve the first matching hosted-zone name; selecting a familiar domain is not sufficient when AWS holds multiple zones with that name. Have your AWS administrator compare the hosted-zone ID, records and assigned nameservers before proceeding. With Google Cloud DNS, the current connection derives the managed-zone name from the domain. An existing zone with a different native name can appear in a list yet fail to open correctly; establish that mapping with your Google Cloud administrator instead of creating a duplicate zone.

For a PowerDNS backend, module reads and zone-file snapshots omit disabled native record values. Editing an affected record set can rebuild it from the enabled values. If your hosting team uses disabled records, preserve and review the native record set with your DNS administrator before module changes; use your established native management process where those values must be retained. A module export is not a complete backup of those disabled values or other provider settings.

Prepare the connection

Install PD Modules, connect the account holding your licence, then install PD DNS Manager from the Store and allow the staff role that needs it. Your DNS provider account is a separate connection from this licence account.

Use the credential fields for the backend you select. Cloudflare uses an API token; AWS Route 53 uses an access-key pair; Google Cloud DNS uses service-account JSON and takes the project from its embedded project_id; control panels use their corresponding server credentials. Keep credentials in the provider settings, never a client note or screenshot.

Grant the actions you intend to use. Listing zones, editing records, creating a zone and forwarding a domain can require different privileges. A successful connection test does not prove every optional action is authorised.

Add and test the provider

1. Open PD Modules → DNS → Providers → Add a provider.
2. Choose the backend that actually hosts the zones.
3. Complete its credential and connection fields, including the correct account/project/server scope.
4. Click Test connection and review the result.
5. After success, click Add provider and check the provider’s status and zone list.

A refused test can mean incorrect credentials, expiry, restricted resources or an API that your billing server cannot reach. Source-IP restrictions apply to that server’s outbound connection, rather than your browser’s address. Ask the server/provider administrator to resolve reachability instead of repeatedly changing working DNS.

Choose placement for new domains

Review accepting new domains, existing domains only and the default provider separately. The default is a placement choice for new zones; changing it does not migrate zones that already exist. See the provider-migration guide for moving an existing zone.

When rotating credentials, create the replacement, edit the provider, test and save, then revoke the old credential after the replacement is working. If a particular feature is refused, review that feature’s required permission without granting unrelated account access.

Check the provider connection

Your hosting team and provider administrator should compare the selected backend, saved account/project/server scope, credential expiry and exact refused action. A connection test proves only the request it performs. Check billing-server connectivity separately from provider authorisation, then test and save any intended credential replacement before retiring the old one.

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