Good Day,
My server is showing the following error:
"Warning : The following zones have expired DNSSEC signatures : domain1.com (02/15/2025), domain2.com (02/15/2025) Use the BIND DNS Server module to either disable DNSSEC for these domains, or check why signing is failing."
For more than a week I haven’t made any changes to server settings and this error appeared unexpectedly.
After this error I enabled automatic DNSSEC signing. But still I am getting error.
Sounds like Virtualmin is not managing your DNS, but you haven’t informed Virtualmin of that fact.
Virtualmin cannot manage DNSSEC if your DNS is not hosted on servers Virtualmin is managing. You will need to update those records yourself on whatever DNS servers are hosting your DNS.
And, as an aside, you don’t need DNSSEC. It does nothing useful for the vast majority of users and services (web, mail, FTP, and database are all services in the “does nothing useful for” category…I don’t know what services are in the “does something useful for” since most network services support TLS, which provides every feature of value that DNSSEC offers without the additional complexity).
“And, as an aside, you don’t need DNSSEC. It does nothing useful for the vast majority of users and services (web, mail, FTP, and database are all services in the”
@Joe From where can I disable it for all domains? And will disabling it solve my issue?
Thanks
I had to upload DNSSEC information key type etc… to my Registrar and this was not reflected immediately. It took 24hours or so before my DNSSEC chain was complete allowing it to work properly.
Ah, yeah, there’s the one delegation record, which does depend on your registrar (or whoever is authoritative for the parent domain, but that’ll be the registrar for most cases). But, that doesn’t generally change often, unless the original secrets are compromised.
If you added delegation records at your registrar, disabling it will not solve your issue, you also need to remove those records (though you should still disable it if you don’t want to invest the time to understanding how DNSSEC works).
And, if you didn’t add delegation records, you never had DNSSEC to start with, and you should disable it.
I have to disagree with that statement. While it’s true that DNSSEC may not be essential for every user or service, saying it “does nothing useful” is misleading.
DNSSEC protects against DNS spoofing and hijacking, which can redirect users to malicious sites. It also ensures integrity for DNS-based authentication mechanisms like DANE, DNSCrypt, and SSHFP records, which rely on secure DNS data. While many services use TLS for security, DNSSEC still plays a role in preventing DNS-based attacks, especially in high-security environments.
I think that DNSSEC is very useful when you are running apps where they do not give the users notifications about the domains they are connecting too because the user just expects everything to be correct.
Moreover, I also checked the function for DNSSEC on my Domain Registrar’s portal and for now I am not using it as currently I am not hosting secure applications that require DNSSEC.
TLS has nothing to do with DNS. But, DNS doesn’t matter in this context (the context of a Virtualmin server or any general purpose web/mail hosting server).
Users interact with DNS to reach services, and TLS protects users from MITM and spoofing of any services that use TLS. If a user makes a web request and it is encrypted with a valid TLS cert for that domain, the user knows that the DNS server didn’t lie to them. A spoofed DNS response for virtualmin.com that leads somewhere else will result in an invalid certificate warning.
I’ve never seen a vector of attack that DNSSEC protects against that TLS wouldn’t also protect against, without the complexity of DNSSEC. And, DNSSEC has some problems of its own. Thomas Ptacek (a security researcher that is pretty well-known) wrote this a decade ago, and it remains true: Against DNSSEC — Quarrelsome
That blog post also a has a FAQ worth reading (linked at the top).
DNSSEC stops DNS poisoning and I think stops routers from proxying these websites for the purpose of using their own certificates allowing network admins to inspect Https traffic.
Clients have to cooperate with any scheme that involves terminating TLS connections.
DNSSEC doesn’t prevent that, if the user is cooperating with their TLS connections being hijacked in that way.
It is not extremely uncommon in enterprise networks, but there’s nothing DNSSEC can do to stop it from being done if the user allows it to be done. It requires users to add the local CA to their trusted CA bundle, DNSSEC doesn’t alter that in any way. So, as I said, TLS would protect in this scenario (if the user doesn’t add the site CA), but DNSSEC probably does not if the user is using the site DNS resolver, which is not obligated to tell the client about any signing going on.
It seems like you really dislike DNSSEC and are willfully disregarding its benefits. That’s fine, everyone has their tech grudges. Personally, I have an irrational hatred for IPv6. I once dreamt that everyone involved in developing it went to hell, and honestly, that was a good dream.
That said, TLS does not prevent DNS spoofing; it only helps detect it in some cases. If an attacker poisons DNS and redirects traffic, TLS will warn the user only if the certificate doesn’t match, but this isn’t foolproof. Fraudulent TLS certificates have been issued before, users often ignore warnings, and techniques like HTTP downgrade (SSL stripping) can bypass TLS entirely.
DNSSEC, on the other hand, prevents attacks that TLS does not, such as DNS cache poisoning, MITM on DNS queries, subdomain hijacking, and email spoofing via SMTP. While DNSSEC has deployment challenges, I found it quite easy to implement with Virtualmin/Webmin.
Many dismiss security measures, thinking they won’t be targeted, until they get hit by mistake and accounts are drained. When that happens, and the security team failed to implement every available safeguard, heads will roll. And it won’t be the head of the user who clicked on something stupid and filled in personal data on a shady website.
