Use PD DNS Manager maintenance results to see whether background DNS work is completing. A provider-health indicator and a successful public DNS answer describe different things, so check both when diagnosing a customer’s report.

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.

Inspect the current state

1. Open DNS → Zones and locate the affected provider and zone.
2. Review its health, sync, ownership and most recent backup information.
3. Open DNS → Maintenance and review the last result and time for the relevant task.
4. Check that the normal Blesta cron is running.
5. Use the appropriate Run now action only after identifying the intended task.

Reconcile checks zone/provider and service state. The health check asks the provider for the zone and its nameservers; it is not an end-to-end test of every resolver, website, mailbox or HTTPS certificate. A zone can exist at a provider while the registrar delegates somewhere else.

Diagnose work that is not progressing

Backups, bulk operations and replication use the existing billing-platform cron. Check whether the task is due, whether it reported an error and whether the provider connection still works. A stale display is not a reason to start multiple copies of a destructive record operation.

Read Activity for the original action and provider result. If a backend is temporarily unavailable, preserve the error and inspect the actual zone state before repeating a write. Avoid recreating a zone simply because a status is down.

Review orphan retention before ending a service

An orphan is a zone whose linked domain/service is cancelled, terminated or removed. Automatically clean up orphaned zones controls whether the module stops tracking it automatically. When cleaning an orphan, also delete the zone at the provider is a separate destructive choice.

Leaving provider deletion off retains the backend records even if client management is removed. Check the saved policy and a current snapshot before service cleanup; a DNS zone can still serve live website or mail traffic. Keep the zone, task time and redacted result for support. See the backup limitations guide before relying on a snapshot for recovery.

Check scheduled task results

Your hosting team should compare the task’s due time, normal cron, latest completion and Activity with actual provider state. Separate a provider read failure from a missing zone, wrong delegation or a website/mail problem. Before orphan cleanup, review both the binding-removal setting and the separate provider-deletion choice against a usable backup.

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