Hacker News Reader

Comment by secret-noun | Hacker News Reader

> The key advantage of [DNS-PERSIST-01] is that the DNS TXT entry used to demonstrate control does not have to change every renewal.

> We expect DNS-PERSIST-01 to be available in 2026

Very exciting!

https://datatracker.ietf.org/doc/html/draft-sheurich-acme-dn...

View on HN

Big news for both the lazy homelab admin that can set a TXT once and ultimately be more secure without spraying DNS Zone Edit tokens all over their infra AND for the poor enterprise folks that have to open a ticket and wait 3 weeks for a DNS record.

Very true. I have been in both roles.

a perhaps non-obvious option is to CNAME (or NS) the `_acme_challenge` record from your main zone to another zone you can control better and can't affect production traffic the same way the main zone could. `acme-dns` is a neat little tool for exactly this, that has an https api for your ACME client to request a cert from, and a dns server to respond to dns-01 challenges from your provider.

Yep, being able to “redirect” the “challenge record” is very handy in some cases. Did a writeup here with some examples of how it can be arranged: https://hsm.tunnel53.net/article/dns-for-acme-challenges/

Absolutely, this works well. Where it's approved :)

Yeah, I have all my _acme_challenge as their own zone so that BIND can auto increment the serial number without going through the pain of locking/unlocking the entire domain and hoping you don't end up with stale data that stops syncing.

That said, I like that the current system proves that you have control of the domain at the time of renewal, and I'm not sure how setting a one-off token would achieve the same.

It will help that side of the process (although, as a sibling has noted, you can CNAME your way into a better-controlled update service), but the challenge of automating cert changes for various non-HTTP services, including various virtual or physical boxes with funky admin interfaces, remains. I don't expect that vendors will do much about that, and it will end up on admins' plates, as usual. There will be much grumbling, but fewer solutions.

There are quite many solutions. For very funky systems, you can use a cert tied to a private CA. Then you can control the cert lifetimes. Or place them behind a reverse proxy that is easier to control.

Why dont providers offer dns api keys restricted to txt records?

Very good question. On e.g. AWS one could probably do something like that with a custom Lambda…? Still, would be very convenient if there was some IAM rule for that.

desec.io allows you to create (through the api) tightly-scoped tokens that can only update the "_acme-challenge.subdomain.example.com" domain needed for DNS-01 challenges.

I switched to them from cloudflare dns for that specific functionality and it works great.

https://dns.he.net/ does. Each record can have its own secret. You can also use this for things like A records to do dynamic DNS.

This replaces an anonymous token with a LetsEncrypt account identifier in DNS. As long as accounts are not 1:1 to humans, that seems fine. But I hope they keep the other challenges.

I really would have felt better with a random token that was tied to the account, rather than the account number itself. The CA side can of course decide to implement it either way , but all examples are about the account ID.

That seems worth suggesting to the acme working group mailing list, if it hasn't already been discussed there.

I don't expect we'll ever remove the other validation methods, and certainly have no plans to do so.

There are pros and cons of various approaches.

Accounts are many to one email address. Each of my servers have an individual account attached to the same email address.

Thank god. The only remaining failure mode I’ve seen with LE certs recently is API key used to manipulate DNS records for the DNS-01 challenge via some provider (Cloudflare etc.) expiring or being disabled during improper user offboarding.

Reply on news.ycombinator.com