It's unfortunate that most ACME related DNS api providers are only optimized for challenge TXT record manipulation because changing the DNS records is the hard part.
[As a generic solution for any acme client, supporting a pre-deployment hook/task (with custom wait time) and a daily hook/task would provide a basic way to do this]
That's basically it, but it can take 24-48 hours to happen correctly.
Just quoting the docs by @karolyi, since few people read them:
As mentioned in the related certbot issue, this tool manages the rollover the following way, when a certificate renewal is due:
Daneupdate (hooking into certbot) gets a newly signed key and certificate, puts it into the upcoming directory
Immediately places a TLSA record next to the original one
Waits for 24 hours (customizable) to pass for DNS caches to expire, then moves the certificate from the upcoming directory and set it as live (by symlinking to the latest version, also done by hooking into certbot internals)
After another 24 hrs (also configurable), it is assumed that the respective daemons have reloaded and are using the new certificate
At which point, the 'old' TLSA record can be cleared.
There is no way to correctly handle that propagation and requirements with Certbot hooks alone. The hooks risk race conditions in which a service would recognize a new certificate - before being primed - and reload services. IIRC, the outgoing certificate needs to be "live" while the upcoming certificate is primed, and both must briefly coexist. This is just not something you can shoehorn into a standard Certbot system - they have competing and incompatible needs and protocols .
If you use Certbot to only renew the certificate (files) and not for any deployment then you can entirely separate the concerns and completely avoid modifying certbot at all.
For what it's worth, the original Certbot team (like in 2015) did want Certbot to be able to generate these records itself in some official way, but I don't think it's ever been a priority or appeared on any roadmap because these technologies are so rarely used. (another example of something that we wanted that fell by the wayside was an installer for lighttpd, which was moderately popular at the time Certbot development started)
In principle, if we ever get an official way to do it, I think that would be a nice fulfillment of a loose thread from the original creation of Certbot. But I don't think the Certbot team will ever commit to implementing it themselves.
For my own interest (as I'm no longer part of the Certbot development team), is it possible to do this in a fully generic way for every issued certificate, or is there anything specific about the host system or deployment model? For example, does it need to encode TCP port numbers or protocol IDs in some way? I haven't really looked at the details of DANE in many years.
I am 100% against modifying Certbot and/or leveraging private methods in 3rd party projects. My comment about "standard certbot" was meant to address standard usage and installation patterns.
The most compatible ways to use Certbot to eliminate the race conditions, IMHO, is to either:
use --config-dir to completely isolate the DANE certificates from the normal system
use a custom --cert-name to control what names the DANE certs use, (so there could be --cert-name=dane-mail.example.com that is isolated from the default mail.example.com cert used for https services).
Remember, with DANE, the DNS record has a hash of the active certificate that must match the https certificate. So these two services are tightly coupled and need to be kept in sync.
While it would be possible to just use the default Certbot install and cert names, that would require a lot of analysis and bookkeeping in the DANE deployment tools, you still have the issue where the initial phase of updating a DANE certificate (certbot renew) can cause the non-DANE processes (e.g. apache/nginx) to detect a change in a certificate they use and reload, and you still have an issue where someone (or automated systems) deciding to renew the HTTPS cert for mail.example.com can likely impact the DANE system if that is mid-update. While it is certainly possible to orchestrate everything within a single standard Certbot installation, the amount of coding and bookkeeping/state-maintaining to do this properly quickly becomes onerous.
Using --config-dir will completely decouple the DANE system from the standard install. Using --cert-nameshould offer enough isolation, though it would probably need to be configured to not renew automatically as well (as the daneupdate binary would be invoking it on demand or via cron).
(another example of something that we wanted that fell by the wayside was an installer for lighttpd, which was moderately popular at the time Certbot development started)