DNSSEC Denial-of-existence warnings

I have a master and slave DNS server (currently running ISPC3.2.11p2) setup hosting multiple domains.
When I checked DNSSEC config a while ago on https://dnsviz.net all was ok.
But recently I'm getting warnings about denial-of-existence, referring to RFC 9276.

Long story short it is adviced to use SHA-1, no extra iterations, empty salt for NSEC3 parameters.

When I manually change

Code:

domain.tld.    NSEC3PARAM    Standaard    1 0 0 <SALT>

to

Code:

domain.tld.    NSEC3PARAM    Standaard    1 0 0 -

in my master DNS the warnings go away and all is secure again.

As all domains and records come from ISPConfig I'm not quite sure on how to approach a resolution to get rid of the warnings.

 

I came across line 174 in /usr/local/ispconfig/server/plugins-enabled/bind_plugin.inc.php

Code:

$app->system->exec_safe('cd ?; dnssec-signzone -A -e +1382400 -3 $(head -c 1000 /dev/random | sha1sum | cut -b 1-16) -N increment -o ? -K ? -t ?', $dns_config['bind_keyfiles_dir'], $domain, $dns_config['bind_keyfiles_dir'], $dns_config['bind_zonefiles_dir'].'/'.$filespre.$domain);

hoping it could solve the warnings.
Unfortunately changing it to

Code:

$app->system->exec_safe('cd ?; dnssec-signzone -A -e +1382400 -3 - -N increment -o ? -K ? -t ?', $dns_config['bind_keyfiles_dir'], $domain, $dns_config['bind_keyfiles_dir'], $dns_config['bind_zonefiles_dir'].'/'.$filespre.$domain);

does solve the initial warnings but also creates errors instead.

 

Side question:
What's the reason to deviate from 14 days expiration, which is default for Bind, to 16 days?

 

Nevermind the earlier mentioned errors. Seems to maybe have been a caching thing.

Changing the above does exactly what I tried to accomplish
No more Denial-of-existence warnings (and eventually no errors too).
But I would like the professional opinion of one of the devs here before I roll it out.

 

Thanks for the answer.

That gets me to this followup question:
Changing to mentioned file only will undo the change at the next ISPC update I would think.
Is there a way around that? For example an altered copy in the conf-custom folder or something like that?

 

Thanks for that advise.
Usually I check the changelog so there should be no problem.

Though I do think this change should really be considered in a near ISPC update.
RFC 9276 is nearly 2 years old now and since then it's considered best practice to have an empty salt.

(Taken from https://datatracker.ietf.org/doc/rfc9276/)

 

I think the recent unexprected errors had to do with slave ns5.he.net not fully doing what it's supposed to do, which I used for most of my zones next to my own master and slave.
That server gave other errors too for quite some time now (while ns4.he.net doesn't give any issues at all).
I replaced that one for another free slave from NS-Global.
Now all my zones are resigned with an empty salt and dnsviz.net isn't complaining about anything anymore for all my zones (including some reverse zones)

 

@till I saw you merged the Bind change into the next milestone. Thanks for that.

I'm not familiar with PowerDNS at all but I would guess it has something similar.

I found line 535 in /usr/local/ispconfig/server/plugins-enabled/powerdns_plugin.inc.php:

Code:

$cmd_set_nsec3 = sprintf('%s set-nsec3 %s "1 0 10 deadbeef" 2>&1', $pdns_pdnssec, $zone);

Syntax "1 0 10 deadbeef" looks a lot like Bind's syntax to me.

To comply with RFC 9276 I think it would become:

Code:

$cmd_set_nsec3 = sprintf('%s set-nsec3 %s "1 0 0 -" 2>&1', $pdns_pdnssec, $zone);

But I'm in no position to test and verify that.