Mastodawn

Matthew Saunders Brown Feb 20

Michał "rysiek" Woźniak · 🇺🇦

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.

Michael W Lucas

@rysiek ooooh!

"Musty Bits" McGee Feb 20

@mwl @rysiek indeed!

Ollivier Robert 🇺🇦😷🌈Feb 19

@rysiek More DNS to break ... Hoo Rah! 😆

*_jߍyrope Feb 19

@Michał "rysiek" Woźniak · 🇺🇦 As a complete diy-ing amateur in this field i sympathize with any approach that makes it easier.

@rysiek soon we are back in the late 90s where you got a cert for anything if you could prove that you're willing to pay for it...

Michał "rysiek" Woźniak · 🇺🇦Feb 19

@florian I don't see how that's the case

Epic Null Feb 19

@rysiek Does this mean easier access to certs without an api to create cert records? Sweet!

Michał "rysiek" Woźniak · 🇺🇦Feb 19

@Epic_Null easier access to *wildcard* certs, yes.

John-Mark Gurney Feb 20

@Epic_Null
More like easier/better cert access to those who can't dynamically/programmatically change their DNS, for reasons like their DNS provider doesn't support it or their IT department refuses to allow it.
@rysiek

Michał "rysiek" Woźniak · 🇺🇦Feb 21

@encthenet @Epic_Null the big thing are wildcard certs.

Epic Null Feb 21

@rysiek @encthenet ironically that's what I was trying to geet last weekend.

Owl Eyes Feb 21

@rysiek @encthenet @Epic_Null it will be a game-changer when it comes out

Epic Null Feb 23

@d1 @rysiek @encthenet Given I now need a cert for an email cert on a domain that matches the rest of my site and have a single IP to service all subdomains but also multiple subdomains...

Yeah. It will be.

@rysiek This is awesome. I will absolutely use DNS-PERSIST-01 as soon as CertManager ships an alpha. https://github.com/cert-manager/cert-manager/issues/8373

#acme #tls #kubernetes #dns #certs

DNS-PERSIST-01 challenge support (planned for late Q1 2026) · Issue #8373 · cert-manager/cert-manager

Is your feature request related to a problem? Please describe. Let's Encrypt is developing a new challenge that could make ACMEv2 clients not having to activelly participate in passing a challenge....

GitHub

Cassandrich Feb 20

@rysiek WOW! This is game-changing! Is there a fork of acme-tiny with support for it yet, or any other equally minimalist implementation?

Cassandrich Feb 20

@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? 🤔 😁

Neal Gompa (ニール・ゴンパ)

@dalias @rysiek Then there's no model for bad-actor revocation. That would be incredibly terrible.

Cassandrich Feb 20

@neal @rysiek Sure there is. Expiration of the RRSIG.

mirabilos Feb 20

@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.

Cassandrich Feb 20

@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).

mirabilos Feb 20

@neal @rysiek @dalias this was about revocations

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

Irenes (many)Feb 20

@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)

Cassandrich Feb 20

@ireneista @rysiek 30 years ago there was no DNSSEC so it was a non starter.

Irenes (many)Feb 20

@dalias @rysiek oh, fair

Garrett Wollman Feb 20

@dalias @ireneista @rysiek 20 years ago, though...

Michał "rysiek" Woźniak · 🇺🇦Feb 21

@wollman @dalias @ireneista and yet here we are

Cassandrich Feb 21

@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.

Garrett Wollman Feb 21

@dalias @ireneista @rysiek I mean, I've been running it in production for about that long. Certainly more than 15 years.

Michał "rysiek" Woźniak · 🇺🇦Feb 20

@dalias correct me if I'm wrong but you're basically describing DANE (RFC 6698)?

Cassandrich Feb 20

@rysiek Yes, thanks for explaining my joke to me. 😁 It was a snarky way of saying "what if we actually made use of DANE?"

Michał "rysiek" Woźniak · 🇺🇦Feb 20

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

It's been a long year.

Cassandrich Feb 20

@rysiek No worries, it's fun when that happens. 😁

Michał "rysiek" Woźniak · 🇺🇦Feb 20

@rysiek Honestly this is great news but sadly we don't use DNS verification we use HTTP verification

Michał "rysiek" Woźniak · 🇺🇦Feb 20

@snow I might switch from HTTP to DNS-PERSIST-01 as that makes it possible to issue wildcard certs.

Plus, it does not require any HTTP endpoint to be exposed. Which means it is perfect for services on the intranet, not exposed to the Internet, for example.

maxolotl Feb 23

@rysiek @snow I'm curious, what's prevented you from using DNS-01 challenges? Those also don't require any exposed HTTP endpoint.

@mxl @rysiek Anything exposed to the Internet uses HTTP challenges anything not gets a certificate issued by my home labs internal CA as they use private unregistered domains. Like lab.fox when internally connected to my router and snow.owo when connected to my tailscale network

@mxl @rysiek I prefer using my private CA for internal stuff as I can make my certificate last as long as I want and I don't have to own the domain

Michał "rysiek" Woźniak · 🇺🇦Feb 23

@mxl @snow but they require write-enabled API on the part of the DNS hosting, which is rarely a given.

maxolotl Feb 23

@rysiek Fair, and even if they do allow writes each provider needs bespoke support from the ACME client.

Michał "rysiek" Woźniak · 🇺🇦Feb 23

@mxl there are certain standardized APIs, but they are not widely supported in my experience

Ollivier Robert 🇺🇦😷🌈Feb 20

@rysiek thanks for the ref, I implemented it yesterday :)

Michał "rysiek" Woźniak · 🇺🇦Feb 20

@Keltounet w00t!

@rysiek This will be great for both my mastodon and other infrastructure! Looking forward to it.