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