Letsencrypt-dane-tlsa-bind9
Ice recently had to switch CA, I was using Startcom but recent events make them unaccuptable. I have decided to go with Letsencrypt. This works for most things but is giving me some headaches with DANE/TLSA.
I can generate the tlsa for my dns ( bind 9) using Victor's tlsagen script. I direct the output into a file which I will be included in the DNS zone file using ($include). I am not going the CSR route so I am assuming that if I do this whenever certbot is run I should wind up with an upto date tlsa record.
My problem is how to get bind to recognise that there has been change.
Is this a workable idea? What have I got wrong?
TIA John A
Quoting "John @ KLaM" john@klam.ca:
I am not going the CSR route so I am assuming that if I do this whenever certbot is run I should wind up with an upto date tlsa record.
You will have an uptodate tlsa record, the problem is, everyone else won't. They will have the old cached value without this new entry. For this purpose, I do a cold rolling, and wait 2 weeks before I use the new certificate and key. It's the same idea as rotating your zsk and ksk keys.
My problem is how to get bind to recognise that there has been change.
Instead of dropping it in a file, use nsupdate.
On Nov 20, 2016, at 9:26 PM, John @ KLaM john@klam.ca wrote:
I've recently had to switch CA, I was using Startcom but recent events make them unacceptable. I have decided to go with Letsencrypt. This works for most things but is giving me some headaches with DANE/TLSA.
I can generate the tlsa for my dns ( bind 9) using Victor's tlsagen script. I direct the output into a file which I will be included in the DNS zone file using ($include).
With signed zones, BIND typically does not load zone data from a text file. Instead, in most deployments, a compiled form of the zone file is maintained, which is updated as records are periodically re-signed.
If you need to make manual changes to the text zone file, you need to reload (re-compile) the text zone file and make sure that you've also incremented the SOA serial number since the last change to the text file. That would be:
# rndc reload "example.com"
I am not going the CSR route so I am assuming that if I do this whenever certbot is run I should wind up with an up-to-date tlsa record.
This is possible, but very much not recommended:
1. When not keeping the public key stable, you MUST pre-publish the new TLSA record along with the old, a few TTLs *prior* to deploying the new server certificate.
Otherwise, outages result when remote caches still contain the old data, but the server's certificate has changed. If the script fails to insert the new record the outages last longer than the TTL.
2. You also need to ultimately remove the stale records once the new certificate and key are deployed.
The whole certbot thing happens unattended and any errors are rather in the process break email delivery. So my recommendation is to in fact do CSR thing, and handle actual key rotation interactively, when you are prepared to check all the steps.
Thus I highly recommend the approach outlined in:
http://postfix.1071664.n5.nabble.com/WoSign-StartCom-CA-in-the-news-td86436....
My problem is how to get BIND to recognize that there has been change.
participants (3)
-
John ＠ KLaM -
Patrick Domack -
Viktor Dukhovni