Oh this is wonderful news:

DNS-PERSIST-01: A New Model for DNS-based Challenge Validation
https://letsencrypt.org/2026/02/18/dns-persist-01.html

> Instead of publishing a new challenge record for each issuance, you publish a standing authorization in the form of a TXT record that identifies both the CA and the specific ACME account you authorize to issue for this domain.

#DevOps #SysAdmin #InfoSec

DNS-PERSIST-01: A New Model for DNS-based Challenge Validation

When you request a certificate from Let’s Encrypt, our servers validate that you control the hostnames in that certificate using ACME challenges. For subscribers who need wildcard certificates or who prefer not to expose infrastructure to the public Internet, the DNS-01 challenge type has long been the only choice. DNS-01 works well. It is widely supported and battle-tested, but it comes with operational costs: DNS propagation delays, recurring DNS updates at renewal time, and automation that often requires distributing DNS credentials throughout your infrastructure.

@rysiek WOW! This is game-changing! Is there a fork of acme-tiny with support for it yet, or any other equally minimalist implementation?
@rysiek BTW here comes the next-stage idea: What if we simplify this further and just bypass the need for a CA entirely, storing a hash of the certificate's public key directly in DNS for clients to query and validate certs against? 🤔 😁
@dalias @rysiek Then there's no model for bad-actor revocation. That would be incredibly terrible.
@neal @rysiek Sure there is. Expiration of the RRSIG.

@dalias @neal @rysiek haha, as if anyone would fix anything in DNS.

Someone is directing their MX at a host in their domain whose A RR points to my home connection, and neither the registrar nor their hoster do anything, and when phoning them they were incapable of understanding the problem. When I told them that they are sending their mails to me they asked "you’re reading our mails?" as if they’d go to the police over it…

This has been since years.

@mirabilos @neal @rysiek That anecdote has nothing to do with anything wrong in DNS just human stupidity. Yet snark like this every time folks try to solve a problem that requires DNS just prevents the problem from being solved and preserves market for slimy middlemen. Any approach to certificates tied to domain names involves DNS. You can just do it directly and with full domain owner autonomy, or with a bunch of extra steps in between each with failure modes that can lead to compromises by involving irresponsible middlemen (CAs).

@neal @rysiek @dalias this was about revocations

when the domain owner knowingly publishes wrong data, a CA can revoke

@dalias @rysiek right???? also why didn't we do that 30 years ago and skip all this fuss

(as far as we can tell, the answer is mostly that once CAs existed they were highly incentivized to protect their business model)

@ireneista @rysiek 30 years ago there was no DNSSEC so it was a non starter.
@dalias @ireneista @rysiek 20 years ago, though...
@wollman @ireneista @rysiek I don't think the modern, actually working DNSSEC is that old, is it? The early drafts were a pile of mistakes.
@dalias @ireneista @rysiek I mean, I've been running it in production for about that long. Certainly more than 15 years.
@dalias correct me if I'm wrong but you're basically describing DANE (RFC 6698)?
@rysiek Yes, thanks for explaining my joke to me. 😁 It was a snarky way of saying "what if we actually made use of DANE?"

@dalias sorry, I did not pick up on the sarcasm there! 😬

It's been a long year.