Oh this is great news. Continually doing DNS updates has been quite annoying for my (admittedly overly complicated) split DNS home server setup. I would really love to use this.
If I had to guess, it'd be due to concern that not all managed DNS providers (especially the cheap webhost kind) support adding CAA records?
In case someone else wonders, yes, the CAA records appear to support limiting to not just a CA, but a specific account as well. (That was my first guess)
They do also inherit differently. Subdomains inherit CAA but not ACME challenges, so using CAA for this would not behave the same as existing DNS-01 ACME checks.
hell yeah can't wait to use this instead of the janky certbot-dns-porkbun setup I've had to use for wildcard donains. pain points identified are real glad they're doing something about it, and soon looks like!
ah yeah having an API to automate making such a record would be nice. no biggie if not tho, doesn't look too hard to set by-hand, esp if you only have to do it once
IMHO that's the best part of this. Rather than giving my server access to DNS (which may or not be able to be reasonably restricted depending on the provider) I can now configure the DNS once to give the server access to only generate certificates.
DNS 01 without API was such a pain that I had developed my own tool, agnos to handle it, which is also my most successful project to date. It looks like agnos is heading for retirement this year.
Nice. I started something last year in May to do the exact same thing (serve its own DNS records), and I took it as an opportunity to learn Rust.
A well-scoped project to learn Rust with, I thought. But I ended up running into challenges, then getting really busy and not completing it. I'll probably still release it at some point.
I noticed yours is also written in Rust, and I checked your Cargo.toml, and it's even using Hickory for DNS, same as mine :-).
I'm kinda unsure how this would work, and I think it has to do with my limited understanding of what an account or account key means in the context of LE.
I was under the impression (from their docs) that it's all just public key crypto and thus "stateless" - if I grab foo.example.com from host1 in January and don't migrate any files to host2 later, then do the HTTP challenge for foo.example.com again from host2 in August (so no renewal, a "fresh" cert) then that is either opaquely consolidated by them via the domain, or the hostname, or the email - but I could have switched the email.
Now when they talk about account key in this new challenge, what I think I understand is that you, as the one having access to the zone, provision this TXT record and allow some account key - but I don't see how you would configure this on the machine that needs the cert. Is this hidden somewhere in the DNS-01 docs that I didn't properly read?
Your client will transparently create a new "account" the first time you run it and store the private key locally. The certificates you provision will be linked to this account.
The first time I ran into this was when I was developing/debugging provisioning certificates (to be written to an appliance via an API) from a totally ephemeral container where all local state was lost between runs. I hit the rate limit for creating new accounts (mentioned here: https://letsencrypt.org/docs/rate-limits/) as I was discarding the generated account key. I then fixed it to save the key in a volume instead.
Yes, the original creation is clear, but in my example if I wouldn't transfer files it would create a separate account (I said 6 months or so, so no rate limit).
So thanks for the confirmation but I still don't see how you would deploy this with the new challenge. If you already use LE, maybe some copying of the local state would work (or setting it up with the info you find there) - but not how I would go:
step 1) set up TXT (with which account key?)
step 2) deploy (where do I get the account key from)
As much as I admire the "it just works" it feels a bit of a failure I managed to ignore the account part for 10 years ;)
freddyb | a day ago
Oh this is great news. Continually doing DNS updates has been quite annoying for my (admittedly overly complicated) split DNS home server setup. I would really love to use this.
caius | a day ago
This would solve so many hoops I've had to previously jump through. Sounds great!
LeahNeukirchen | 21 hours ago
Why aren't CAA records used for this?
varesa | 11 hours ago
If I had to guess, it'd be due to concern that not all managed DNS providers (especially the cheap webhost kind) support adding CAA records?
In case someone else wonders, yes, the CAA records appear to support limiting to not just a CA, but a specific account as well. (That was my first guess)
bglw | an hour ago
They do also inherit differently. Subdomains inherit CAA but not ACME challenges, so using CAA for this would not behave the same as existing DNS-01 ACME checks.
polywolf | a day ago
hell yeah can't wait to use this instead of the janky certbot-dns-porkbun setup I've had to use for wildcard donains. pain points identified are real glad they're doing something about it, and soon looks like!
rplacy | 10 hours ago
for some reason porkbun isn't listed in the list of domain providers that support this,
they had a link somewhere on the community forum which I cannot find anymore
ps. by this I mean "registars with API to automate it" instead of manually adding a record
polywolf | 9 hours ago
ah yeah having an API to automate making such a record would be nice. no biggie if not tho, doesn't look too hard to set by-hand, esp if you only have to do it once
kevincox | 5 hours ago
IMHO that's the best part of this. Rather than giving my server access to DNS (which may or not be able to be reasonably restricted depending on the provider) I can now configure the DNS once to give the server access to only generate certificates.
rplacy | an hour ago
from my understanding many registry providers support this dns persist approach and automation tools will catch up
so I hope to see porkbun and others in this list
johnklos | 22 hours ago
After all that setup I've done to automate things? Well, better late than never :)
jclulow | 22 hours ago
The second best time is always today!
krtab | 21 hours ago
DNS 01 without API was such a pain that I had developed my own tool, agnos to handle it, which is also my most successful project to date. It looks like agnos is heading for retirement this year.
habibalamin | 18 hours ago
Nice. I started something last year in May to do the exact same thing (serve its own DNS records), and I took it as an opportunity to learn Rust.
A well-scoped project to learn Rust with, I thought. But I ended up running into challenges, then getting really busy and not completing it. I'll probably still release it at some point.
I noticed yours is also written in Rust, and I checked your
Cargo.toml, and it's even using Hickory for DNS, same as mine :-).wink | 11 hours ago
I'm kinda unsure how this would work, and I think it has to do with my limited understanding of what an account or account key means in the context of LE.
I was under the impression (from their docs) that it's all just public key crypto and thus "stateless" - if I grab
foo.example.comfromhost1in January and don't migrate any files tohost2later, then do the HTTP challenge forfoo.example.comagain fromhost2in August (so no renewal, a "fresh" cert) then that is either opaquely consolidated by them via the domain, or the hostname, or the email - but I could have switched the email.Now when they talk about account key in this new challenge, what I think I understand is that you, as the one having access to the zone, provision this TXT record and allow some account key - but I don't see how you would configure this on the machine that needs the cert. Is this hidden somewhere in the DNS-01 docs that I didn't properly read?
varesa | 11 hours ago
Your client will transparently create a new "account" the first time you run it and store the private key locally. The certificates you provision will be linked to this account.
It is very briefly mentioned here: https://letsencrypt.org/how-it-works/#domain-validation
The first time I ran into this was when I was developing/debugging provisioning certificates (to be written to an appliance via an API) from a totally ephemeral container where all local state was lost between runs. I hit the rate limit for creating new accounts (mentioned here: https://letsencrypt.org/docs/rate-limits/) as I was discarding the generated account key. I then fixed it to save the key in a volume instead.
varesa | 11 hours ago
Other relevant sources: https://datatracker.ietf.org/doc/html/rfc8555#section-7.3 https://datatracker.ietf.org/doc/html/rfc8555#section-6.2
wink | 11 hours ago
Yes, the original creation is clear, but in my example if I wouldn't transfer files it would create a separate account (I said 6 months or so, so no rate limit).
So thanks for the confirmation but I still don't see how you would deploy this with the new challenge. If you already use LE, maybe some copying of the local state would work (or setting it up with the info you find there) - but not how I would go:
As much as I admire the "it just works" it feels a bit of a failure I managed to ignore the account part for 10 years ;)