Het gebruik van DANE om server-certificaten voor web en mail van een (extra) anker te voorzien introduceert afhankelijkheden tussen serverbeheer en DNS-management. Bij de verandering van een certificaat moet immers ook het bijbehorende TLSA record aangepast worden.
Sterker nog, een verandering in een server-certificaat vraagt om een kleine roll-over (zoals aangegeven in Appendix A.4 van RFC 6698): Het nieuwe TLSA record moet gepubliceerd worden voordat het certificaat wordt vervangen. Pas na het verlopen van de TTL, als de oude TLSA-informatie uit alle caches is verdwenen, mag het nieuwe certificaat in de server geactiveerd worden. Doe je dat eerder, dan loop je het risico dat validerende clients op basis van de oude informatie het nieuwe certificaat (nog) niet accepteren.
Automatisering
De certificaten van het populaireLet's Encrypt hebben een geldigheidsduur van 90 dagen. Volgens de ontwikkelaars is het "afdwingen van automatisering" een belangrijke reden voor deze korte geldigheidsduur. Automatisering van het opvragen en installeren van een nieuw certificaat is prima te doen met behulp van de certbot software (een ACME-client). Voor het automatisch genereren en installeren van het bijbehorende TLSA record in de DNS-server is het aanbod echter beperkt.
Gebruikers van OpenDNSSEC zouden het onlangs gepubliceerde bash-script van Dennis Baaten als startpunt hiervoor kunnen nemen. Voor BIND-installaties is het voordehandliggend om iets te bouwen rondom het nsupdate commando voor Dynamic DNS (DDNS) updates.