Plesk DNSSEC 1.5.5 changes the default signing choice for new DNS zones: ED25519 is now the default, while deprecated key-generation algorithms are no longer offered for new zones. Plesk says existing signed zones are not affected. That makes this a useful maintenance release, but not a reason to re-sign every customer domain or change an established key policy without a plan.
For a hosting team, DNSSEC is a chain-of-trust service. The panel can sign the zone, but the registrar or parent zone still has to publish the right DS record. A panel change, registrar change, and customer DNS migration should not be treated as one casual task. Keep the routine extension update separate from any deliberate signing or key-rollover work.
What changed in Plesk DNSSEC 1.5.5
- New zones use ED25519 by default.
- Deprecated key-generation choices are no longer offered when signing a new zone.
- Existing signed zones are unchanged by this extension release.
The change applies to a new signing decision. It does not mean an already signed domain needs an emergency key replacement, a new DS record, or a panel-wide policy change. Treat a planned key or signer change as its own reviewed maintenance event.
Check the environment before updating
- Confirm where each DNS zone is authoritative. If an external DNS provider hosts the zone, manage DNSSEC there rather than trying to sign a non-authoritative copy in Plesk.
- Inventory zones that are already signed, their service owner, and the registrar or parent-zone owner responsible for DS records.
- Confirm that the DNSSEC extension is installed and supported by the server’s DNS service. Plesk documents DNSSEC support for Plesk for Linux with BIND or Plesk for Windows with Microsoft DNS Server.
- Review the extension’s change log in the Plesk interface and schedule a quiet change window if DNS changes are governed by a customer or operations process.
- Keep unrelated DNS, mail, nameserver, and WordPress migration work out of the same maintenance window.
Update the extension in Plesk
Open Extensions, then choose Updates. Select Check Now, inspect the available DNSSEC update and its change log, then apply the update through the normal Plesk workflow. Plesk documents both automatic and manual extension updates, so teams that prefer staged changes can review the available version before making it part of their normal maintenance cycle.
After the update, confirm that the DNSSEC extension still opens normally and that the existing signed-zone list is intact. Do not use the extension update as a prompt to rotate keys, unsign domains, alter registrar records, or replace DNS defaults for working customer zones.
Use the new default only for a planned new zone
When a newly hosted domain is ready for DNSSEC, open the domain’s DNSSEC view in Plesk and use the panel’s signing workflow. Review the generated DS information, then give it to the team or registrar account that controls the parent zone. DNSSEC does not become active just because Plesk has signed the child zone; the delegation must be completed at the parent.
Before calling the work complete, verify that the domain continues to resolve as expected, that the delegated DS details match the signer currently in use, and that normal website, mail, and customer-facing services still reach the intended destination. Record the responsible owner and the next planned review date with the service record.
Leave existing signed zones alone unless there is a change plan
Existing signed zones are not affected by Plesk DNSSEC 1.5.5. The lowest-risk outcome is usually to update the extension, verify normal operation, and leave a healthy signing configuration in place. If your organization needs to change its signing policy later, make that an explicit rollout with a named DNS owner, registrar coordination, a customer-impact check, and a clear validation point.
Be especially careful when a domain’s registrar, DNS provider, and hosting panel are managed by different people. A DS record left behind after an unintended signing change can make the domain appear broken to validating resolvers. Conversely, removing DNSSEC in the panel without coordinating the parent-zone record can interrupt resolution. Plesk’s DNSSEC documentation describes the signer and DS relationship; follow the vendor workflow instead of improvising around a live domain.
WordPress and hosting support checks
DNSSEC is not a WordPress plugin setting, but WordPress sites depend on reliable domain resolution. After a DNSSEC or delegation change, check the public site, administrator sign-in, contact forms, transactional email, and any WooCommerce checkout path that belongs to the affected domain. For broader DNS and mail ownership checks, use the Plesk email and DNS guide. For website-owner triage, start with the WordPress Support hub.
When a customer is moving a WordPress site at the same time, separate the DNSSEC decision from the site move. The Plesk Migrator guide and the WordPress DNS and email cutover checklist help keep the hosting move, mail routing, and registrar handoff accountable.
Completion checklist
- The installed Plesk DNSSEC version is recorded and its change log was reviewed.
- Existing signed zones remain present and were not altered merely because the extension was updated.
- For each new signed zone, the registrar or parent-zone owner has confirmed the DS delegation.
- Normal website, email, and application paths work for the affected domain.
- The service record identifies who owns Plesk, authoritative DNS, registrar access, and the next key-policy review.
