Plan parent DS removal before turning off signing in PD PowerDNS. A parent that still expects signed answers can make an unsigned child fail validation.

Review the current trust chain

Identify the authoritative zone, registrar or parent, current DS and signing state. Confirm who can change the parent. If a move or rollover is in progress, coordinate with the DNS administrator rather than removing keys as an experiment.

Remove the dependency first

1. Remove the intended DS through the registrar or parent workflow.
2. Confirm the parent has published the removal.
3. Keep the child signed while previously cached DS data expires, using the relevant TTL and administrator’s transition plan.
4. Only then open the zone’s DNSSEC panel and choose Disable DNSSEC.
5. Inspect the result and verify public DNS after the change.

PowerDNS’s operational guidance warns that leaving a parent DS while going unsigned makes the zone fail validation. There is no universal fixed wait that fits every zone; use the actual parent TTL and state.

Check the intended result

The module’s disable operation deletes the returned signing keys for this zone at the provider; it does not merely hide the module’s status indicator. Do not assume an ordinary BIND export can recover those keys. Removing one ordinary DS record inside an unrelated zone is not the same as removing this zone’s parent DS.

Check authoritative answers and public validation separately from the provider connection. If the parent state or transition is unclear, leave the signing state unchanged while your hosting team’s DNS administrator establishes the parent publication, cached dependency and intended sequence. Use the enabling guide for the opposite procedure.

Check the unsigned transition

Your hosting team’s DNS administrator should establish the actual parent DS removal and cached dependency before key deletion, using the domain’s intended transition plan. Compare the original disable result with the provider’s remaining keys and authoritative signing state. The module deletes returned zone keys in sequence; a later refusal can follow earlier deletions, so inspect current state before another attempt.

See the PD PowerDNS Blesta guide for related tasks, or explore PD PowerDNS.