Don't forget TLSA record after replacing TLS certificate

The use of DANE to provide an (extra) anchor for web and mail server certificates introduces dependencies between server management and DNS management. The reason being that, when a certificate is changed, the associated TLSA record needs to be modified.

Indeed, a server certificate change implies a minor rollover (as described in Appendix A.4 to RFC 6698Link opens in new tab): the new TLSA record has to be published before the certificate is replaced. The new certificate cannot be activated on the server until the TTLLink opens in new tab has expired and the old TLSA information has been flushed from all caches. If the new certificate is activated too soon, you run the risk that validating clients will not accept it due to a mismatch with the old information.

Automation

Certificates generated using the popularLink opens in new tabLet's EncryptLink opens in new tab are valid for ninety days. The developers say that a desire to 'force automation' is one of the main reasons for the short validity periodLink opens in new tab. The requesting and installation of new certificates can easily be automated using certbot softwareLink opens in new tab (an ACME clientLink opens in new tab). However, tooling for automatically generating and installing TLSA records on a DNS server is somewhat limited.

OpenDNSSECLink opens in new tab users could utilise Dennis Baaten's recently published bash scriptLink opens in new tab as a basis for automation. For BIND installations, the most obvious solution would be to build something around the nsupdate command for Dynamic DNS (DDNSLink opens in new tab) updates.