3 ms·

Once dns-persist-01 becomes available/usable[1], it should make dns validation even easier. [1]: https://letsencrypt.org/2026/02/18/dns-persist-01 https://lets

Once dns-persist-01 becomes available/usable[1], it should make dns validation even easier. [1]: https://letsencrypt.org/2026/02/18/dns-persist-01 https://letsencrypt.org/2026/02/18/dns-persist-01

isomorphic 3mo ago
Thank you, I was unaware of that. It looks like it's already support in the acme.sh client, but there is a Let's Encrypt discussion saying it's still pending at LE: https://community.letsencrypt.org/t/dns-persist-01-deployment-status-and-timeline/246468/9 https://community.letsencrypt.org/t/dns-persist-01-deploymen... I wonder if the interim version has been rolled out to some CAs.
mrl5 3mo ago
OP here. Actually I tried to use it but apparently prematurely -> https://github.com/acmesh-official/acme.sh/issues/7085#issuecomment-4887449610 https://github.com/acmesh-official/acme.sh/issues/7085#issue... Once it's supported I think my next iteration will be DNS persist + internal ip addresses on the public zone. Thank you all for comments and feedback! It's cool to see real interest in this blog post
theK 3mo ago
I never understood the issue with DNS-01. if you have a process that you trust to maintain a zone's TLS identity what is the big deal about letting it control a record in that zone?
- sigio 3mo ago
  You can even put it in a seperate zone (which I do) by using a CNAME for _acme-challenge.domain.tld. I have it to a seperate subdomain, which is served by a seperate desec.io account, which is only used for this specific subdomain.
  - blueflame7 3mo ago
    [dead]
  - mrl5 3mo ago
    TIL, thanks! This makes dns challange automation more approachable for me. I always had an issue with API keys which scope can't be limited to TXT records. This seems to be a nice workaround ... and it is even already documented at https://github.com/acmesh-official/acme.sh/wiki/DNS-alias-mode https://github.com/acmesh-official/acme.sh/wiki/DNS-alias-mo...
- nijave 3mo ago
  We have a few subdomains for white labeling 3rd party SaaS where we do what is basically the AWS ACM equivalent and add a persistent record from a vendor. With this setup, I don't have to grant 3rd parties DNS access. I actually made a webhook that allows per hostname API keys to wrap dnsimple because they only had per zone keys and I didn't want each VM to have access to the entire zone. These challenges would have solved that by allowing the DNS record automation to pull record values from the VM instead of having the VMs push values. I think someone told me dnsimple might have more granular keys now but I haven't checked. Iirc we have the same concern with external-dns at work (some things need subdomains on the TLD but we don't want to give external-dns access to the whole zone so we usually cname the TLD subdomain to a per environment zone external-dns is allowed to update). With this, we could have the same pull based setup that applies arbitrary rules to decide if a requested record should be created. I think the main takeaway is allowing pull instead of push model Could be achieved with cnames but it's an extra layer of indirection to deal with and doesn't fully solve the "semi trusted 3rd party" case
  - bowersbros 3mo ago
    You could already do that by setting a _acme-challenge alias CNAME record, so you can point it to a domain that they control. It's a bit finnicky and the new setup definitely looks better for whitelabelling, but there are current workarounds; although it does still involve client DNS access, you can put it onto a zone that has no risks
  - aeden 3mo ago
    Our current level of granularity allows you to give read or write access to a specific zone, but it does not go down to the level of giving read or write access to a specific RRset type yet, if that's what you're looking for.
    - nijave 3mo ago
      Yeah, specific RRset
xg15 3mo ago
At this point, can't we make a standard that skips the middlemen and just embeds the certificate directly inside the DNS entry? It seems the challenge system is converging towards that anyway.
- zeeZ 3mo ago
  That would be DANE with TLSA (RFC 6698, not the stock ticker symbol). You've still got just another chain of trust with the DNSSEC requirement, and the recent DENIC outage breaking that for the entirety of .de isn't the greatest advertisement :D
  - tptacek 3mo ago
    It's also a dead letter: browsers won't implement it (they did at one point, and then withdrew it).
    - TAlborough 3mo ago
      [flagged]
  - xg15 3mo ago
    Yes, which goes back to the old question: why the heck are we using a bunch of insecure systems with awkward bolted-on workarounds instead of just using DNSSEC?
  - deleted 3mo ago
    [deleted]
  - xg15 3mo ago
    (To explain that some more: The current "way to go" with fully automated cert issuance is delegating its trust to DNS anyway - so we might as well get rid of CAs and use the DNSSEC chain of trust directly, with TLS certs linked to it.)
ivlad 3mo ago
Or, just use IPv6 and host Internet services in a routable address. Then, use ACLs at web server / proxy / L7 lb level to allow acme-challenge unauthenticated but everything else authenticated. Lets encrypt supports IPv6 for validation.

Once dns-persist-01 becomes available/usable[1], it should make dns validation even easier. [1]: https://letsencrypt.org/2026/02/18/dns-persist-01 https://letsencrypt.org/2026/02/18/dns-persist-01

isomorphic 3mo ago

Thank you, I was unaware of that. It looks like it's already support in the acme.sh client, but there is a Let's Encrypt discussion saying it's still pending at LE: https://community.letsencrypt.org/t/dns-persist-01-deployment-status-and-timeline/246468/9 https://community.letsencrypt.org/t/dns-persist-01-deploymen... I wonder if the interim version has been rolled out to some CAs.

mrl5 3mo ago

OP here. Actually I tried to use it but apparently prematurely -> https://github.com/acmesh-official/acme.sh/issues/7085#issuecomment-4887449610 https://github.com/acmesh-official/acme.sh/issues/7085#issue... Once it's supported I think my next iteration will be DNS persist + internal ip addresses on the public zone. Thank you all for comments and feedback! It's cool to see real interest in this blog post

theK 3mo ago

I never understood the issue with DNS-01. if you have a process that you trust to maintain a zone's TLS identity what is the big deal about letting it control a record in that zone?

sigio 3mo ago
You can even put it in a seperate zone (which I do) by using a CNAME for _acme-challenge.domain.tld. I have it to a seperate subdomain, which is served by a seperate desec.io account, which is only used for this specific subdomain.
- blueflame7 3mo ago
  [dead]
- mrl5 3mo ago
  TIL, thanks! This makes dns challange automation more approachable for me. I always had an issue with API keys which scope can't be limited to TXT records. This seems to be a nice workaround ... and it is even already documented at https://github.com/acmesh-official/acme.sh/wiki/DNS-alias-mode https://github.com/acmesh-official/acme.sh/wiki/DNS-alias-mo...
nijave 3mo ago
We have a few subdomains for white labeling 3rd party SaaS where we do what is basically the AWS ACM equivalent and add a persistent record from a vendor. With this setup, I don't have to grant 3rd parties DNS access. I actually made a webhook that allows per hostname API keys to wrap dnsimple because they only had per zone keys and I didn't want each VM to have access to the entire zone. These challenges would have solved that by allowing the DNS record automation to pull record values from the VM instead of having the VMs push values. I think someone told me dnsimple might have more granular keys now but I haven't checked. Iirc we have the same concern with external-dns at work (some things need subdomains on the TLD but we don't want to give external-dns access to the whole zone so we usually cname the TLD subdomain to a per environment zone external-dns is allowed to update). With this, we could have the same pull based setup that applies arbitrary rules to decide if a requested record should be created. I think the main takeaway is allowing pull instead of push model Could be achieved with cnames but it's an extra layer of indirection to deal with and doesn't fully solve the "semi trusted 3rd party" case
- bowersbros 3mo ago
  You could already do that by setting a _acme-challenge alias CNAME record, so you can point it to a domain that they control. It's a bit finnicky and the new setup definitely looks better for whitelabelling, but there are current workarounds; although it does still involve client DNS access, you can put it onto a zone that has no risks
- aeden 3mo ago
  Our current level of granularity allows you to give read or write access to a specific zone, but it does not go down to the level of giving read or write access to a specific RRset type yet, if that's what you're looking for.
  - nijave 3mo ago
    Yeah, specific RRset

xg15 3mo ago

At this point, can't we make a standard that skips the middlemen and just embeds the certificate directly inside the DNS entry? It seems the challenge system is converging towards that anyway.

zeeZ 3mo ago
That would be DANE with TLSA (RFC 6698, not the stock ticker symbol). You've still got just another chain of trust with the DNSSEC requirement, and the recent DENIC outage breaking that for the entirety of .de isn't the greatest advertisement :D
- tptacek 3mo ago
  It's also a dead letter: browsers won't implement it (they did at one point, and then withdrew it).
  - TAlborough 3mo ago
    [flagged]
- xg15 3mo ago
  Yes, which goes back to the old question: why the heck are we using a bunch of insecure systems with awkward bolted-on workarounds instead of just using DNSSEC?
- deleted 3mo ago
  [deleted]
- xg15 3mo ago
  (To explain that some more: The current "way to go" with fully automated cert issuance is delegating its trust to DNS anyway - so we might as well get rid of CAs and use the DNSSEC chain of trust directly, with TLS certs linked to it.)

ivlad 3mo ago

Or, just use IPv6 and host Internet services in a routable address. Then, use ACLs at web server / proxy / L7 lb level to allow acme-challenge unauthenticated but everything else authenticated. Lets encrypt supports IPv6 for validation.