I am an ACME client author, and I'm looking to add dns-persist-01 support to my client. While I am aware that test servers based on, e.g., Pebble, could be used at the moment, I wonder if there is a more concrete indication of
it's working in staging right now, but it's using draft-00 version
nether pebble and boulder is doing precheck at order creation time. (and LE is not planning to do that)
I think the only public statement is at the end of this blog post:
Which says they have "a production rollout targeted for some time in Q2 2026".
Thanks!
Are there any updates to this?
We're in Q2 now and it would be helpful to be able to plan if this is "soon" or, as another community politely puts it, "Voron soon".
The specification is still evolving, so it is somewhat difficult to predict. It may end up shipping in Q3, if consensus on some open issues do not resolve quickly at IETF.
Personally I think it should be safe to ship the draft-00 spec in production at end of Q2.
The CAB/F forum vote is approved, so "legally" there is no problem issuing certificates based on a DNS-PERSIST-01 validation.
The missing consensus is how certain objects should be populated (issuer-domain-names, caaIdentities, meta etc).
And also how the "accounturi" privacy mechanism (that is optional for CA's to support - where subscribers get a per-domain accounturi in the challenge object).
Since the missing consensus is on optional objects, that is NOT required by the CAB/F forum, I feel its safe to ship the draft-00 spec. CAB/F allows approving a DNS-PERSIST-01 object based on the caaIdentities object (basically, an domain accepted for DNS-PERSIST-01 MUST be present in caaIdentitites array), and since letsencrypt only have one object in that array: "letsencrypt.org" - it should not be a difficult decision to take.
Another thing would be if the caaIdentitites object would contain a lot of legacy entries where it could be a operational and security related decision to not allow DNS-PERSIST-01 to be provisioned on legacy objects for security reasons.
The optional features (accounturi privacy, meta objects like issuerDomainNames and caaIdentitites, and issuer-domain-names in the challenge object) can be shipped in production later.
According to section 7.5 paragraph 2 of draft-ietf-acme-dns-persist-00, that would not be a suitable issuer-domain-name as the domain is not signed with DNSSEC. I don't see why DNSSEC is a recommendation however it might be an issue for deploying that version of dns-persist.
There is also work on how wildcard will be validated. Aaron has posted about wanting an "ADN" to be set by the ACME Client. See: Will Let's encrypt support tree climbing for dns-persist-01 records? - #6 by aarongable
Personally I feel there is enough substantial differences to wait. It is difficult for ACME Client authors to make clear to their users which draft is supported and how things should work. We saw this with ARI, for example.
I read that requirement as - that the CA must protect the infrastructure behind "issuer-domain-name" with robust security measures - so a attacker could not spoof lets say:
acme-v02.api.letsencrypt.org IN A [ATTACKER IP]
as that could pose unacceptable security risks if a malicious party is able to impersonate Letsencrypt ACME server and then give a attacker-controlled "accounturi" that links the record to a attacker. (something that is not possible for normal validations since those validations rely on a offline-computed part involving the account public key).
Technically - an attacker could host an fake ACME server, that always respond with a accounturi present in the real Letsencrypt ACME server as belongning to the attacker, regardless of which public key a subscriber sends. The subsriber would then put the accounturi of the attacker in his record (think it as a "phishing" or "social engiinering" thing) which would give the attacker access to issue certificates for his domain.
The "issuer-domain-name" should however be considered a opaque value that identifies the CA. It does in fact not need to be a domain name, it could be like:
4d434f6d36c01ca04fc932a0bb77442fd2471a3ff82d3684798d99ae19f88eea.invalid
(which is the sha256 hash of the word "letsencrypt").
Which means DNSSEC-securing the issuer-domain-name itself, would not give any security advantage, since the client is not supposed to make any requests to issuer-domain-name
The important thing is that the domain name is present in the CPS/CP - thats a requirement for CAB/F forum.
ADN is also such a optional feature that can be added to Lets Encrypt after the rollout of DNS-PERSIST-01.
Currently, accounturi is still missing from the challenge object in the staging environment. However, there is a commit that adds it.
For tests using lego and other clients that support the current draft-01 and are currently failing on staging, I am waiting for it to be activated.
dehydrated works without accounturi (but no support for ARI):
You're going to need to be patient. The draft is still going through changes and pending a somewhat large update for 02. I have a feeling many developers both client and server side are waiting to put a lot of effort into code until it stabilizes.
I would also expect changes to show up in Pebble before Boulder.
Yep, I am waiting a little longer. Started implementing draft 01 but got frustrated 
I believe that accounturi has been added to boulder. But tests with my
acmeleaf(1) does show that even staging is not giving accounturi yet.
Anyways, please take your time (to LE), and good luck to all of us;
really waiting for dns-persist-01 to be real.
I didn't mean to sound impatient, but there hasn't been any further information since the blog post - not even that draft-00 is already active on staging. And at least draft-01 has already been implemented in boulder, and as far as I can see, the corresponding commit is already included in the current staging system.
Hello !
Still no info on this ?
Any idea when it will be ready ?
Thanks
We will not be deploying dns-persist-01 until Record should include client-computed information · Issue #64 · ietf-wg-acme/draft-ietf-acme-dns-persist · GitHub is resolved.