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 6698): the new TLSA record has to be published before the certificate is replaced. The new certificate cannot be activated on the server until the TTL 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 popularLet's Encrypt are valid for ninety days. The developers say that a desire to 'force automation' is one of the main reasons for the short validity period. The requesting and installation of new certificates can easily be automated using certbot software (an ACME client). However, tooling for automatically generating and installing TLSA records on a DNS server is somewhat limited.

OpenDNSSEC users could utilise Dennis Baaten's recently published bash script as a basis for automation. For BIND installations, the most obvious solution would be to build something around the nsupdate command for Dynamic DNS (DDNS) updates.