• The new Python extension is now available. It allows customers to deploy and manage WSGI-based Python applications on their websites directly from Plesk.
  • Debian 11 has reached its end-of-life (vendor EOL date - August 31, 2026). Plesk Obsidian 18.0.81 is the last release to support it.
    If you are running Plesk Obsidian on Debian 11, we recommend you upgrade those servers to Debian 12 using our dist-upgrade tool.
  • We plan to deprecate and remove the support for XML RPC protocol versions earlier than 1.6.9.1 in Plesk Obsidian 18.0.82. We strongly recommend that you update all existing integrations using earlier versions of the XML RPC protocol to comply with the version 1.6.9.1 specification.

Issue Enabling DNSSec for existing keys -- Workaround for double plesk bug.

nelteren

Basic Pleskian
Server operating system version
Debian 13.7
Plesk version and microupdate number
18.0.81.3
There is a known bug in plesk where DNSSec in plesk doesn't function properly due to the fact that it's still not been updated with the changes to bind / using dnssec-policy files.

I've as a workaround created a manual script that writes/copies around a default policy file (filling in the variable details) that's standard for every domain that gives it a 90-day ZSK rollover, 365-day KSK rollover, and sets the 8 various 'delay periods' correctly. Here's the code:

This functions... until you try to re-enable a borked dnssec via plesk itself: It will try to find the first key you used for KSK/ZSK. It only works for DNSSec that's (in my case) less than 3 months old. Older domains are then put in a state where you can't re-enable it. This is a huge problem: DNSSec effectively prevents global DNS from working now for those domains for a long period. It's deliberately built to prevent any attempts at DNS hijacking/takeover, so you can't just put a new thing in.

The error I see is this (the second plesk bug):

Error: Unable to sign the DNS zone. Execution CLI utility is failed: dnsmng. dnsmng: Unable to get files attributes for key '/var/named/run-root/var/keys/(REDACTED)+012+12345 : No such file or directory.
System error 2: No such file or directory dnsmng: Unable to get files attributes for key '/var/named/run-root/var/keys/acme.com/Kacme.com.+012+12345': No such file or directory
System error 2: No such file or directory

Supposing my first key was generated under the file "Kacme.com.+012+12345". That key has been deleted a year ago and no longer exists anywhere. This is fine, there's been a new key in use the last few months "Kacme.com.+016+45678".

In other words, I have all my keys, it's plesk that's the problem that tries to mess with the PK files. I want it to leave all the files in there alone and just set it to enabled in the json/database. [[Skip the check for the ZSK/KSK.]]. How?

I know how I can solve the problem (until anyone edits anything in the DNS, then the problem will re-appear). I take the file 'named.conf' and add these lines to the domain's zone record by manually editing the autogenerated file (i.e. it'll go back to a bad state after the first dns plesk change):

Code:
<<<<< OLD
zone "acme.nl"
    type master;
    file "acme.nl";
    inline-signing yes;
    allow-transfer {
        <slave dns IP>
        <slave dns IP6>
        common-allow-transfer;
    };
};

>>>>> NEW
zone "acme.nl"
    type master;
    file "acme.nl";
    key-directory "keys/acme.nl";
    inline-signing yes;
    dnssec-policy "acme.nl";
    allow-transfer {
        <slave dns IP>
        <slave dns IP6>
        common-allow-transfer;
    };
};

As you can see, all it needs to do to make-stuff-work is to just add those two lines. Bind can, by itself, handle automatically creating/destroying/managing KSK/ZSK files. Plesk shouldn't be messing with that, yet it is.

Can I bypass the buggy implementation and set the config in the plesk database manually maybe?
 
Back
Top