ietf-dane at dukhovni.org
Mon Nov 21 05:17:16 CET 2016
> On Nov 20, 2016, at 9:26 PM, John @ KLaM <john at 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
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
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:
> My problem is how to get BIND to recognize that there has
> been change.
More information about the dane-users