He doesn't go much into the actual automation process, but I think that's easy enough with a periodic (once a week?) cron job to check/perform renewal status. Such a script would perform the following; unblock port 53/udp, enable acme-dns service, run renewal process, block port 53/udp, disable service upon completion.
Don't forget to create the cname record in your dns zone (cloudflare, or where ever) that it tells you.
What i'm still not entirely clear on is why one needs a permanent (or for as long as you want it to keep renewing) CNAME record _acme-challenge.subdomain.domain.tld record in the first place in the dns zone.
Since the request for lookup of such record ultimately gets passed down to the acme-dns service (running locally on your machine), which has already associated the _acme-challege.subdomain.domain.tld to a distinct username/password hash in addition to a subdomain hash (fc31d598-4138-49b3-bb26-505dd17dab88.acme.domain.tld. It can query its database and update the txt then respond accordingly to certbot.
Because for many people, the adding of such a CNAME isn't easily done automated. Or isn't prefered due to security concerns.
If you add the CNAME for every renewal again and again through an API, you might as well change the CNAME to the TXT record required for the renewal immediately and skip the whole acme-dns part.
The resource record requested is actually a TXT record, but because of the CNAME it gets passed to the acme-dns host. So you really really need the CNAME
Also, I'm sure @joohoi would like to hear which parts of the Github page are confusing and which details you were missing
I had a little trouble wrapping my head around acme-dns too; maybe my topic from a few years ago will be helpful to you too:
It's been working very well for me for almost three years.
The CNAME record is necessary because (when using DNS validation, which is the only way Let's Encrypt will issue wildcard certs), Let's Encrypt will always look for a TXT record at _acme-challenge.domainname. You can't tell it to look anywhere else, just as you can't tell it to use a port other than 80 for HTTP validation. But in both cases, you can redirect. For HTTP, you can send a 301 redirect to somewhere else. For DNS, you do that with a CNAME record.
To clarify here, that somewhere else MUST use port 80 or 443.
Our implementation of the HTTP-01 challenge follows redirects, up to 10 redirects deep. It only accepts redirects to “http:” or “https:”, and only to ports 80 or 443. It does not accept redirects to IP addresses. When redirected to an HTTPS URL, it does not validate certificates (since this challenge is intended to bootstrap valid certificates, it may encounter self-signed or expired certificates along the way).
Ok.. That's the connection I wasn't making. In theory, is making acme-dns authoritative for yourdomain a possibility? That is, resolutions not able to be made at the primary server get passed onto acme-dns?
As far as I know, that's not a possibility in the DNS system. One can add multiple authorative DNS servers (well, it's standard to have at least two configured), but a resolver will randomly choose between one of those.
What's your objection against a simple CNAME for the _acme-challenge (sub)subdomain to the acme-dns instance?
No objection. Was simply curious if it was possible to move the entire resolution process off the primary authoritative server.
I use cloudflare which has the global api key and the more limited api token which can be customized for access to various control. Unfortunately it's not granular enough to allow access to subdomain zone records only (or even to specific types of zone records). If it was then acme-dns would not be needed. Sort of like going from point a-b rather than a-b by way of c-d-e-f-g first.
It is, but not using acme-dns--that's a limited-purpose server that only serves very limited A and NS records (essentially only for itself), and the validation TXT records. You'd need to run a general-purpose DNS server locally, and in that case, acme-dns no longer makes much sense.
