DANE Rollover scheme

OS type and version Almalinux 9.3
Webmin version 2.111
Virtualmin version 7.10.0

I am trying to figure out how to make DANE work properly.

I enabled DNSSEC and DANE (TLSA) records for my domain and added it to my registrar.

it works.

DANE TLSA, when issuing a new certificate, comes up as invalid on various testing sites.

When restarting BIND, the values tend to validate after a short while. I dont know if this is a propagation issue or BIND needs to be restarted for the new TLSA values.

Other issue:

for every letsencrypt cert request it generates new 301 type records, and the old ones become invalid.

if I test my domain on internet.nl I get a message saying that I dont have a DANE rollover scheme in place.

There are some sites that explain records with 311 and 211 records which have the new key as well and that 301 is wrong for letsencrypt? I really dont have the knowledge or understanding.

See for example:

Please avoid “3 0 1” and “3 0 2” DANE TLSA records with LE certificates - Server - Let’s Encrypt Community Support (letsencrypt.org)

But I also read that letsencrypt has this:

–reuse-key When renewing, use the same private key as the
existing certificate. (default: False)

maybe would help?

To resolve your DANE and DNSSEC issues, consider using the --reuse-key option with Let’s Encrypt to keep the same private key during renewals, which helps maintain valid TLSA records. Also, switch from “3 0 1” TLSA records to a configuration that reuses keys, as recommended for Let’s Encrypt. This approach should reduce TLSA record changes and improve validation results.
Also Check this : learnmore-community.cloudflare.com/t/support-for-tlsa-dane-proto/9881?page=2

I don’t know where to edit the letsencrypt command, nor do I know if thats a good idea.

I was hoping that in future updates it is implemented with a rollover scheme.

if you change the TLSA records, they are overwritten at cert request currently.

The TLSA DNS records can be regenerated for a temporary fix:

1)For your domain DNS Settings, DNS Options, ‘TLSA records enabled’, choose No.
2) Redo and choose Yes

Below is what I received from an unsolicited survey email.

I am using it to restate core parts from the OP.

It is probably time to move this to an issue on github.

The first link below provides a good summary of what the issue is and how to solve it:

  1. Use --reuse-key for both certificate generation and renewal with certbot
  2. Publish the DNS TLSA record as 3 1 1 record, not a 3 0 1 or 3 0 2 record.

The second link below is a refinement for rollover for when a private key does actually change.

From the email:

The issues can be resolved by removing or updating the associated DNS
DANE TLSA records.

- "3 0 [12]" vs. Let's Encrypt:

- Best practice "3 1 1" rollover methodology:

- Monitoring code snippet:


I think this is for virtualmin team because it is not simply about changing the dns records, at renewal it creates the 301 again.

I think the command has to be adjusted.

I am really no expert, all I know is that sometimes at renewal, immediately after it will report broken DANE.

I think it is imporant for mail delivery that it works when using DANE.

So we are not in a dead zone between nameserver updates/propagation.

Yes, it shoud be handled by the Virtualmin team.

The impression I get is that as long as the private key is not changed when a 90 day LE certificate is reissued then a 3 1 1 DNS TLSA record DOES NOT NEED to be recreated, but a 3 0 1 or 3 0 2 DNS TLSA record DOES NEED to recreated.

So if the private key is changed the DNS TLSA record must be recreated. If the private key is not changed the the DNS TLSA record does not need to be changed if it is a 3 1 1 type.

With certbot, --reuse-key reuses the private key. It is possible Virtualmin already does this.

I don’t know what the command and parameters are to generate a TLSA DNS record. I assume it simple.

There have been lenghty discussions in Virtualmin Github issues. Reopening looks like a waste of time.

I checked LE settings for private key reuse (yes) and note --reuse-key is being entered in logs.

Someone needs to find specific lines in source code and request they be changed because changing them fixed the problem for them. I will have a look myself

I have proposed a three line fix in a new Virtualmin Github issue at

I have since added information to the issue which explains why LE (Let’s Encrypt) appears to involved in a protocol (TLSA DNS) that is supposed to be independent of LE. The record generation process can be made completely independent and I provide an example of this.

John Heenan

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.