Use Maintenance and Activity to identify the failed DNS task before changing records or credentials. A provider zone-health indicator is separate from a public DNS response, website or mailbox test.

Review the original action

1. Open Azure DNS → Zones and identify the provider/group and domain.
2. Review ownership, records, relevant status and latest backup information.
3. Open Maintenance and inspect the last task time and result.
4. Review Activity for the original operation and redacted Azure response.
5. Check the normal Blesta cron for scheduled work.

The released health probe checks the zone at its provider and the nameservers it reports. It does not validate every resolver answer or the website’s HTTPS certificate. Confirm delegation and public records separately when the symptom concerns visitors.

Separate authentication and authorisation

A sign-in failure can concern the wrong tenant/client pair, secret value or expiry. An authorisation failure can concern the specific operation and resource scope. The module’s normal zone list uses one configured group; a successful connection test does not mean all subscription zones are included.

If Azure reports an unregistered Microsoft.Network namespace, have the subscription administrator review Subscriptions → Resource providers. Do not repeatedly rotate working secrets for a resource-provider registration problem.

Reconcile background and cleanup results

Use the appropriate available maintenance action deliberately, then inspect its result. A stalled or failed write needs actual-state reconciliation before another job is submitted.

An orphan is a zone whose linked domain/service is cancelled, terminated or removed. Check saved cleanup and provider-deletion choices before acting. Explicit Delete zone removes Azure DNS data; do not use it as a refresh action for a stale status. The module attempts a pre-delete snapshot, but deletion is not conditional on that snapshot succeeding. Verify a usable backup and the intended subscription/group before any planned deletion. After an uncertain result, check actual Azure state before repeating the request.

Keep the zone, task/action time and exact redacted error for support. For expiry issues use the secret-rotation guide; for missing zones use the placement guide. Avoid sending app secrets or unrelated customer records.

Check the maintenance result

Your hosting team and Azure administrator should compare the last job time/result, normal platform cron, saved service-account identity and tracked zone with the actual provider resource. Check authoritative DNS and application availability separately. For an orphan warning, establish whether the linked domain/service ended and review cleanup and provider-deletion choices before acting. Do not use Delete zone as a refresh or diagnosis action.

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