Plesk DNSSEC 1.5.6 changes how the extension presents legacy delegation data: DS records that use the deprecated SHA-1 digest type are now hidden by default. This is a useful cleanup for administrators reviewing new work, but it does not delete a registrar record, change a parent-zone delegation, or repair an existing DNSSEC chain on its own. Treat the extension update and any live DNSSEC change as separate, planned tasks.
For a hosting team, DNSSEC remains a shared responsibility. Plesk can manage the zone-side signing view, while the registrar or parent-zone owner controls the DS delegation. Before assuming a record has gone away, confirm which team owns the authoritative zone, the registrar account, and the domain's current signing policy.
What changed in Plesk DNSSEC 1.5.6
- The extension hides DS records that use the deprecated SHA-1 digest type by default.
- The change affects the display of legacy delegation information; it does not remove records from the parent zone.
- Earlier Plesk DNSSEC 1.5.5 guidance remains relevant: new zones use ED25519 by default, and existing signed zones are not automatically changed.
The safest interpretation is simple: a cleaner panel list is not proof that an old DS record has been removed or that DNSSEC has been disabled. Keep live delegation changes with the team that controls the parent zone, and validate them through the normal vendor and registrar workflow.
Review legacy DNSSEC ownership before updating
- Confirm where the domain is authoritative. If an external DNS provider hosts the zone, manage DNSSEC there rather than attempting to sign a non-authoritative Plesk copy.
- Record the owner of the Plesk server, authoritative DNS, registrar account, and any customer approval path for the domain.
- Identify domains with an existing signing policy or a planned migration. Do not use a routine extension update to start a key rollover, unsign a domain, or change a DS record.
- For a legacy record that must remain visible for an approved audit or migration, use Plesk's current vendor documentation and change-control process before altering extension behavior.
- Keep unrelated nameserver, mail, CDN, and WordPress migration work out of the same maintenance window.
Update the extension through the normal Plesk workflow
Open Extensions, choose Updates, check the available DNSSEC release, review its vendor change log, and apply it through the established Plesk maintenance process. Teams that stage panel changes can review the extension version first and schedule the update with the administrator who owns DNS support.
After the update, confirm that the DNSSEC extension opens normally and that the signed-zone list is available. Do not infer that a hidden legacy record has been removed from the registrar or parent zone. When a domain's delegation needs to change, make that a separate, approved operation with the accountable DNS owner.
Keep signing, delegation, and migration decisions separate
For a new DNSSEC-enabled zone, Plesk's current defaults can help guide a planned signing decision. The domain still needs a matching DS delegation at the parent zone before validation can succeed. For an already signed domain, the low-risk path is normally to update the extension, verify normal operation, and leave a healthy signing configuration alone until a documented key-policy change is scheduled.
A domain move needs the same discipline. Do not combine a WordPress transfer, mail routing change, registrar handoff, and DNSSEC policy decision into one broad cutover. Separate ownership and acceptance checks make it much easier to find the source of a resolution or delivery problem without changing a working delegation in haste.
WordPress and hosting support checks
DNSSEC is not a WordPress setting, but every WordPress site depends on dependable resolution. After an approved DNSSEC or delegation change, open the public site, administrator sign-in, contact forms, transactional email, and any WooCommerce checkout path that belongs to the affected domain. Use the WordPress Support hub for website-owner triage and the Plesk guides for panel-specific maintenance.
For broader DNS and mail ownership work, see the Plesk email and DNS guide. When a hosted WordPress site is moving at the same time, keep the migration path explicit with the Plesk Migrator guide and the WordPress DNS and email cutover checklist.
Completion checklist
- The installed Plesk DNSSEC version and vendor change log were recorded in normal maintenance notes.
- Existing signed zones were not changed merely because legacy SHA-1 DS records are hidden by default.
- Any planned parent-zone delegation change has a named registrar or DNS owner and customer approval where required.
- Website, email, and application paths were checked only after an approved DNSSEC or delegation change.
- The service record identifies who owns Plesk, authoritative DNS, registrar access, and the next key-policy review.
