PD Azure DNS can sign a public zone and display the DS material needed by its registrar or parent-zone owner. Signing in Azure and establishing the parent chain of trust are separate steps.

Prepare authority and access

Identify the exact Azure zone, authoritative nameservers and registrar. Confirm the relevant operator can change the zone’s signing and the parent DS. Client write controls can be restricted by locks or the saved domain-only editing policy; do not widen app permissions to work around a client policy refusal.

Enable and delegate signing

1. Open the zone’s records and available DNSSEC control/page.
2. Review the zone and choose Enable DNSSEC.
3. Allow the operation to complete and inspect its result.
4. Copy the shown DS fields exactly for that zone.
5. Add those DS values at the registrar, or through the parent-zone owner for a delegated child zone.
6. Check the parent DS, child signing and public validating response together.

A DS record entered into the wrong ordinary zone does not establish trust for the domain. Keep key tag, algorithm, digest type and digest paired with the correct zone. Microsoft’s signing guide explains the parent-delegation step.

Disable in the correct order

Remove the relevant DS at the parent/registrar first and wait for that DS TTL to expire while the child remains signed. Then use the supported disable-signing action and verify the resulting state. Microsoft’s unsigning procedure explains why that order is required.

Do not repeatedly toggle signing to diagnose a validation failure. Separate an authorisation refusal from mismatched DS, changed keys, delegation or cached parent data. A BIND snapshot does not copy signing keys or recreate the parent chain automatically; plan signing separately during an ordinary-record migration.

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