Saving modifications to DNS and Sender Policy Framework options generaties new keys for the zone. Invalidating DNSSEC immediately and unexpectedly.
Need a sollution soon
Is anyone else experiencing similar issues with DNSSEC?
Adrie
| SYSTEM INFORMATION | |
|---|---|
| OS type and version | Debian GNU/Linux 10 (Buster) |
| Webmin version | 1.990 |
From what I learned from https://forum.virtualmin.com/t/fatal-zone-contains-nsec-records/114280 I went back to Webmin 1.990 to 1.984.
Even knowing this will not solve the issue.
Help, acknowledgment and fixing, from the maintainers is highly appreciated. In case I’m doing something wrong, please let me know.
Adrie
Hi,
Are you sure that you’re having and running the latest Virtualmin 6.17-3 installed?
I really cannot reproduce and witness DNSSEC keys being changing on saving virtual-server.name - Server Configuration ⇾ DNS Options page. It shouldn’t be happening unless you intentionally toggle DNSSEC signature enabled option.
Perhaps, the workaround would be is to disable DNS domain enabled feature on virtual-server.name - Edit Virtual Server page and then re-enable it. Be careful, it will reset domain’s DNS zone record to default.
Afterwards try enabling DNSSEC signature enabled option and later checking if the issue is still happening?
Just tried to your workaround, unfortunately without any luck.
I disabled DNSSEC and disabled DNS domain enabled and enabled it again like you suggested. I then selected my domain in Webmin → Servers → BIND DNS Servers : Existing DNS Zones, then Setup DNSSEC key
In Virtualmin → Server Configuration → DNS Options. The DNSSEC signature enabled is Yes and DNSSEC zone keys exist.
If at that point I hit the Save the keys go away and signature enabled is disabled. Enabling it here will not work.
I can confirm some of the weird behavior here. It is really a problem as any action taken in Virtualmin’s “DNS Options”, generates a new DS. So this means, for me at least, that domain is down and have to input the new DS to the register, but for the regular users it is a problem. I guess it shouldn’t happen, not a desired outcome, given that regular users will use that area and in doing so they will break DNS resolution for no reason at all. Plus, if they access VIrtualmin via their domain.name:port I guess they are also locked out of Virtualmin, the only alternative being of course direct IP or the name of the server itself, not very friendly and maybe not known.
What is more interesting is I get a lot of email warnings everyday about all the domains that can’t be signed (it is super to get notified, not about that), but including the ones that shouldn’t have DNSSEC enabled and that don’t have any keys… In fact given that the DNSSEC domains mostly work, I get only emails about the ones that shouldn’t have DNSSC.
Later edit: this bug Always update to NSEC3 records if the type changed https://sourceforg… · webmin/webmin@cef983f · GitHub is solved in my case, modified the file and resigning is working again, also not about that.
My 2 cents … 
Small Script to easly check | output for debug …
#!/bin/sh
echo “Check Virtualmin Domains DNSSEC ( delv domain.net )”
doms=virtualmin list-domains --name-only --no-alias
for dom in $doms; do
echo #####################################
echo domain: $dom
echo ------- @1.1.1.1 -----------------
delv @1.1.1.1 $dom | grep '; ’
echo ------- @localdns 127.0.0.1 -------
delv @127.0.0.1 $dom | grep '; ’
echo #####################################
done
This is pretty serious issue! I could also reproduce it with Virtualmin 6.17-3, while using latest commits from our upstream repo fixes the problem.
@Jamie, please double confirm that it was fixed already?
That issue with NSEC3 records has been fixed in github … but it should never have caused any kinds of DNS records to go missing.
Will this github-fix also fix the disabling of DNSSEC when saving “DNS and Sender Policy Framework” ?
Not Yet , just tested on a domain, and DS was changed 
After apply the change/add of “-n”
Modification : > changed from disallow to neutral …
after Save the key id is regenerated …
and the previous Key is Lost…
------- @1.1.1.1 ------------------
;; resolution failed: SERVFAIL
------- @localdns 127.0.0.1 -------
;; validating domain.tld/DNSKEY: no valid signature found (DS)
;; no valid RRSIG resolving ‘domain.tld/DNSKEY/IN’: 127.0.0.1#53
;; broken trust chain resolving ‘domain.tld/A/IN’: 127.0.0.1#53
;; resolution failed: broken trust chain
getting more info on what happen now…
– FolowUp —
So the master zone key for the domain file is changed due to :
cd /var/named/dskeys && dnssec-keygen -a RSASHA256 -b 3072 -n ZONE -r /dev/urandom domain.tld
cd /var/named/dskeys && dnssec-keygen -a RSASHA256 -b 3072 -n ZONE -f KSK -r /dev/urandom domain.tld
After that the zone is resigned …
cd /var/named/dskeys && dnssec-signzone -o domain.tld -3 - -u -f /var/named/masters/domain.tld.hosts.webmin-signed /var/named/masters/domain.tld.hosts
The Zone file from “create /var/named/masters/” command adds all the new records and restarts bind after assuming the key generated just then, and overwriting the actual key that i updated the registrar whit.
The new KeyFiles *.key and *.private overwrite the old id and the key is lost…
No, those are unrelated.
This issue with losing DNSSEC records fixed on the latest patches to feature-dns.pl file.
Hello,
since one of the latest updates i’ve here a lot of problems with dnssec enabled domains. Wich files i’ve to replace in Webmin und the payed version of virtualmin and what to do to make it work again. Thank you for your help.
I can confirm that replacing feature-dns.pl in folder:
../webmin/virtual-server/
fixes the changing / invalidation of DNSSEC for me
I can also confirm that with the replacement of the feature-dns.pl file everything is ok now. What I also noticed is that all secondary DNS entries and also the IP addresses of these for notification were gone for the domains where dnssec is enabled. I had to add these again, then everything was ok.
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.