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

[nelteren]

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):

<<<<< 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?

 

[Sebahat.hadzhi]

Thank you for the report, @nelteren . I will need you to provide me with some additional details so I can have a full picture and provide accurate details to our engineers to further investigate the behavior. Could you please clarify the following:

1. What are the exact steps that lead to the error when re-enabling DNSSEC? In particular, what do you mean by DNSSEC becoming “borked,” and what actions are performed between the initial configuration and the failed re-enable attempt?
2. Does the affected domain currently fail DNSSEC validation, or does the problem only occur when enabling DNSSEC through Plesk?
3. After manually adding the key-directory and dnssec-policy directives, does DNSSEC work correctly, and does the issue return after making a DNS change through Plesk?

Thanks in advance.

 

[GCM]

We are seeing a very similar issue on another Plesk server.

In our case, the problem can be reproduced when Plesk regenerates the DNS configuration using:

plesk sbin dnsmng --update example.com
After the DNS regeneration, the required dnssec-policy assignment disappears from the generated BIND configuration.

This still occurs with Plesk Obsidian 18.0.81.3, although PPPM-15337 was reported as fixed in 18.0.81.

We are currently using our own guard/repair mechanism to detect and restore the missing DNSSEC configuration after Plesk DNS changes.

I have documented our reproducible case separately here:

https://talk.plesk.com/threads/dnssec-configuration-still-gets-broken-by-dnsmng-update-possibly-related-to-pppm-15337.395540/

The symptoms appear related, but since our issue is reproducible through dnsmng --update rather than only through plesk repair dns, it may be a separate code path or an incomplete fix for PPPM-15337.

 

[SirAdams]

After upgrading our Plesk server from Debian 12 to Debian 13, DNSSEC signing is no longer working correctly.

Environment:

• Hostname: mail.ptkardio.pl
• OS: Debian 13.7
• BIND: 9.20.30
• Plesk DNSSEC extension: 1.5.6, release 16040, enabled
• 12 affected DNSSEC-enabled zones managed by Plesk

Initially, BIND failed to start with:

/etc/named.conf:47: option 'auto-dnssec' no longer exists
loading configuration: failure
As a temporary workaround, we configured a custom dnssec-policy "maintain" for the affected zones, using separate ECDSAP256SHA256 KSK and ZSK keys with unlimited lifetimes. Existing keys were retained, and key purging was disabled.

With this workaround, BIND started successfully. All 12 zones returned signed SOA responses, and each zone published a KSK matching at least one existing public DS record.

However, after running:

plesk repair dns
Plesk regenerated the configuration and removed the per-zone dnssec-policy "maintain" statements. The zones retained key-directory and inline-signing yes. The custom policy definition remains included but is no longer assigned to these zones.

Current state:

• BIND is running, and named-checkconf succeeds.
• All 12 affected zones answer DNS queries but return no DNSKEY records and no RRSIG signatures for SOA queries.
• The Plesk DNSSEC extension still reports the zones as signed. For example:

plesk ext dnssec info --domain-name ptkardio.pl
reports:

Status: Signed
However, these direct queries to the local authoritative server return no DNSKEY records and an unsigned SOA response:

dig @127.0.0.1 ptkardio.pl DNSKEY +dnssec +noall +answer
dig @127.0.0.1 ptkardio.pl SOA +dnssec +noall +answer
Public DS records remain published for the affected domains, so unsigned responses can cause DNSSEC validation failures.

Please investigate the DNSSEC integration between Plesk and BIND 9.20 on Debian 13 and provide a permanent, supported fix that:

1. Restores signing while preserving the existing keys and DS trust relationships.
2. Survives plesk repair dns and subsequent DNS changes through the panel.
3. Keeps key rollover management consistent with the Plesk DNSSEC extension.
4. Clarifies how the temporary custom policy should be removed or replaced safely.

Please confirm whether this is a known issue and whether a patch or supported workaround is available.

Thank you.

 

[tessa67]

Hi SirAdams,

as far as I can tell this is a known bug: PPPM-15337. A staff member described it in this thread (Resolved - DNSSEC and bind not start): "plesk repair dns" removes the dnssec-policy entries from /etc/named.conf, and a fix was expected with 18.0.80. But GCM reports in this thread (Issue - DNSSEC configuration still gets broken by dnsmng --update – possibly related to PPPM-15337) that it still happens on 18.0.81.3/.4, and also with "plesk sbin dnsmng --update", so not only with the repair command. Which exact Plesk version are you on? Please post it, and mention PPPM-15337 if you open a ticket with Plesk support.

To your points:

1) "Status: Signed" in the extension
That's just what the Plesk DNSSEC extension has stored in its own database. It doesn't check what BIND really does. Your dig output (no DNSKEY, no RRSIG) is the real state, so keep using dig as the source of truth:

dig @127.0.0.1 <zone> DNSKEY +dnssec +noall +answer
rndc dnssec -status <zone>

2) The official workaround is unsign/sign again, but I would NOT do that for you
That recreates the signature and may generate new keys. With the DS records already published at your registrar you would then need a clean DS change, otherwise you are in a validation-failure situation. So I'd only do that as a planned rollover.

3) A permanent, supported fix doesn't exist yet as far as I know
Until Plesk fixes it, the only thing that survives "plesk repair dns" and DNS changes in the panel is to put the missing line back automatically. GCM does the same with his own guard script, and another user in a different thread overwrote named.conf from a saved copy via an event handler. A small idempotent guard could look like this (adapt the policy name, and test on a copy first). It assumes that Plesk writes "dnssec-policy" directly below "inline-signing yes;", as in the zone blocks posted in this thread. If your zone blocks look different, adjust the sed line:

#!/bin/bash
# /usr/local/sbin/named-dnssec-guard.sh
CONF=/etc/named.conf
TMP=$(mktemp)
cp -a "$CONF" "$TMP"
sed -i '/^zone "/,/^};/{/inline-signing yes;/{n;/dnssec-policy/!s/^/    dnssec-policy "maintain";\n/}}' "$TMP"
if cmp -s "$CONF" "$TMP"; then rm -f "$TMP"; exit 0; fi
if named-checkconf "$TMP"; then
    cp -a "$CONF" /root/named.conf.before-guard
    cat "$TMP" > "$CONF"
    rndc reload
    logger -t named-dnssec-guard "dnssec-policy assignment restored"
else
    logger -t named-dnssec-guard "check failed, config left untouched"
fi
rm -f "$TMP"

chmod 700 /usr/local/sbin/named-dnssec-guard.sh
echo '* * * * * root /usr/local/sbin/named-dnssec-guard.sh' > /etc/cron.d/named-dnssec-guard

Important: right after Plesk regenerates the config, BIND already reloads without the policy, so your zones are unsigned until the guard runs (up to a minute with this cron). With a published DS record, validating resolvers return SERVFAIL for that time. So after every "plesk repair dns" or bigger DNS change, run the script by hand immediately:

/usr/local/sbin/named-dnssec-guard.sh

Then check the result with the dig and rndc commands from point 1.

4) Removing your temporary policy later
Once Plesk has really fixed this, first remove the cron job and the script, then test with one zone: look at "rndc dnssec -status <zone>" before and after the change. If the new policy uses the same algorithm and roles as your existing keys, BIND should keep using them; if the algorithm or key setup differs, BIND will start a rollover, which means new DS records. So keep algorithm and key roles the same, and don't change more than one zone at a time.

Keep us posted, and please report back here what support says about the version.

Regards
Tessa

 

[tessa67]

Hi nelteren,

I think you are hitting two different things here.

1) Plesk dropping the DNSSEC lines when it regenerates named.conf
That is what you describe in your workaround, and it looks like the known bug PPPM-15337. A staff member wrote about it here: Resolved - DNSSEC and bind not start (the "repair dns" command removes the dnssec-policy entries, fix was expected for 18.0.80). GCM reports that it still happens on 18.0.81.3/.4, and also with "plesk sbin dnsmng --update", not only with the repair command: Issue - DNSSEC configuration still gets broken by dnsmng --update – possibly related to PPPM-15337 . He works around it with his own guard script that restores the missing lines after Plesk DNS changes, which is basically your manual edit, automated.

2) The "Unable to get files attributes for key ..." error when re-enabling
I couldn't find any report of this one. From the error text it looks like the extension remembers the first key files of a domain and checks that they still exist. That is only my guess from the message, not something I could confirm. This is the part where Plesk staff has to look at it.

What I would do:
- Answer Sebahat's three questions, especially what exactly you did between "signed and working" and "can't re-enable". The more precise your steps, the easier it is to reproduce.
- Add these facts to your answer: the exact Plesk version, the full error text with timestamp, the list of files in the key directory of one affected domain, and the output of:

plesk ext dnssec info --domain-name <domain>

- I would not edit the Plesk database by hand to skip the key check. I don't know what else the extension stores there, and with a published DS record a wrong state means validation failures for your visitors. If you still want to try it, make a full dump first:

plesk db dump psa > /root/psa-before-dnssec-edit.sql

- Until Plesk fixes the first problem, your manual named.conf edit will be reverted on the next DNS change. You can automate it like GCM does: a small cron job or event handler that adds the key-directory and dnssec-policy lines back if they are missing, checks the result with named-checkconf and only then reloads BIND. Keep in mind that between Plesk regenerating the config and your script running, the zone is unsigned. With a DS record published that means SERVFAIL for validating resolvers, so run the script by hand right after every bigger DNS change.

If you want, post one zone block as Plesk generates it (domain name anonymized) and I can help you with such a guard script.

Regards
Tessa