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.


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.


  • Friday 15 March 2019

    Internet security

    Google Chrome to warn users about typosquat domain names


    Spotting fake URLs isn't easy

    Read more
  • Monday 27 November 2017


    Enhanced SIDN website helps more people register .nl domain names


    Five thousand leads a month referred to registrars

    Read more
  • Thursday 18 October 2018

    Internet security

    Is your business hack-proof?


    Take the test!

    Read more


Your browser is too old to optimally experience this website. Upgrade your browser to improve your experience.