Issue Details

The DNS-PERSIST challenge is in draft state: https://datatracker.ietf.org/doc/html/draft-ietf-acme-dns-persist-00

More info: https://letsencrypt.org/2026/02/18/dns-persist-01

Basically, where the DNS challenge repeatedly creates and cleans up a TXT record in the DNS zone each time a validation occurs, the DNS-PERSIST challenge sets a single TXT record once for all future validations within the constraints specified by the record value.

The new challenge type is intended to streamline operations where DNS credentials are "too sensitive" to give to a web server (or it's too complex to delegate things), or where access to arbitrary external resources like a DNS provider is impractical/forbidden.

In particular, the DNS challenge for wildcards in multi-tenant setups (like "bring your own domain"-type white-labeling services) can be particularly tedious or impractical, since each tenant would have to provide their DNS credentials to be persisted with the service provider / server. With DNS-PERSIST, the tenants can set a single DNS record once and pass future challenge validations in perpetuity.

Other than potential operational benefits, there aren't really notable technical or security benefits to the DNS-PERSIST challenges.

This puts Caddy in a bit of an interesting situation since, operationally, Caddy already automates so much of the DNS challenge with minimal config. So the DNS challenge works fine.

One major benefit to DNS-PERSIST on the Caddy side though, is that no DNS provider plugins would be needed for DNS validation, including for wildcard certificates.

Since Caddy is an integrated ACME client and web server, rather than a separate ACME utility, the flow is a little bit unclear. It could be:

• When a cert is needed, and no DNS challenge is configured, CertMagic looks up DNS-PERSIST TXT record in DNS (it would have to check apex domain too for wildcards).
• If found, and is applicable, it does nothing in terms of a challenge (it just proceeds with the ACME validations).
• If not found, or record does not apply, it proceeds with usual challenge flow according to config.

However, the TXT record value requires the ACME account URL. This is known to CertMagic, as it's in the metadata file in storage next to the account key. (Account info can also be looked up by key directly, per the ACME spec.) So, CertMagic has to create the ACME account before the TXT record can be created. Slightly awkward for first run...

We can maybe alleviate this by adding an admin API endpoint, and CLI command, to print some information about the ACME account(s) in storage, and maybe even print the DNS-PERSIST TXT value to use (creating an ACME account if necessary). Then a user could set it manually and be done.

Another option is to automatically set the DNS-PERSIST record, but this requires a DNS provider plugin yet again. It only needs to be set once, but there's multiple parameters, so it would need some user input. I'm not sure if offering an automated way to set this record is worth it, tbh. I think it just makes more sense to stick with DNS-01 at that point.

Assistance Disclosure

AI not used

If AI was used, describe the extent to which it was used.

No response