Skip to content

wfe/ra/va/pa: Add support for draft-ietf-acme-dns-persist-00#8660

Open
beautifulentropy wants to merge 5 commits intomainfrom
add-dns-persist-support
Open

wfe/ra/va/pa: Add support for draft-ietf-acme-dns-persist-00#8660
beautifulentropy wants to merge 5 commits intomainfrom
add-dns-persist-support

Conversation

@beautifulentropy
Copy link
Member

@beautifulentropy beautifulentropy commented Mar 6, 2026

Warning

This PR depends on: eggsampler/acme#31. Once it has been merged we'll need to update go.mod and re-vendor.

Implement the dns-persist-01 ACME challenge type as specified in draft-ietf-acme-dns-persist-00. This challenge proves domain control via a persistent DNS TXT record at _validation-persist.<domain> containing the CA's issuer domain name and the subscriber's account URI.

The following optional features are deliberately not implemented:

  • Just-in-Time Validation (section 4.2): Would require the RA to perform validation at order creation time, adding latency and complexity to NewOrder with no current operational need.
  • Subdomain validation via policy=wildcard (sections 5 and 6): as implemented, the policy tag gates wildcard certificate issuance but does not enable TXT records further up the domain hierarchy to satisfy subdomain authorizations. The draft has no mechanism for the subscriber to indicate which Authorization Domain Name (ADN) they want to validate at, so the server would have to walk up the domain tree. We've proposed that clients include an ADN field in their challenge POST payload to solve this. We'll wait to see if the draft adopts some form of ADN negotiation before implementing this functionality.
  • Authorization reuse (section 7.8): The spec caps reuse to the TXT record's TTL, and the BRs (section 3.2.2.4.22) caps it at 10 days. Since typical TTLs are seconds to minutes, re-validating on every order is simpler and avoids the need to plumb through and enforce TTL values.

Fixes #8527

@beautifulentropy beautifulentropy force-pushed the add-dns-persist-support branch 2 times, most recently from 8d96489 to 6e93913 Compare March 6, 2026 20:46
@beautifulentropy beautifulentropy marked this pull request as ready for review March 6, 2026 21:34
@beautifulentropy beautifulentropy requested a review from a team as a code owner March 6, 2026 21:34
@github-actions
Copy link
Contributor

github-actions bot commented Mar 6, 2026

@beautifulentropy, this PR appears to contain configuration and/or SQL schema changes. Please ensure that a corresponding deployment ticket has been filed with the new values.

@github-actions
Copy link
Contributor

github-actions bot commented Mar 6, 2026

@beautifulentropy, this PR adds one or more new feature flags: DNSPersist01Enabled. As such, this PR must be accompanied by a review of the Let's Encrypt CP/CPS to ensure that our behavior both before and after this flag is flipped is compliant with that document.

Please conduct such a review, then add your findings to the PR description in a paragraph beginning with "CPS Compliance Review:".

@letsencrypt letsencrypt deleted a comment from github-actions bot Mar 6, 2026
@letsencrypt letsencrypt deleted a comment from github-actions bot Mar 6, 2026
@beautifulentropy beautifulentropy force-pushed the add-dns-persist-support branch from 6e93913 to 6adb2e9 Compare March 9, 2026 16:02
Copy link
Contributor

@aarongable aarongable left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A few comments, mostly small. One big comment on the structure of validateDNSPersist01 itself, so I haven't done a detailed review of its corresponding unit tests yet. Will do that review when they're broken out into helper-level tests.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Implement dns-persist-01

2 participants