DNS-PERSIST-01 is an experimental ACME challenge for domains where you can create one public DNS TXT record but do not want to provide a DNS API for recurring changes.

Important: This beta uses Let's Encrypt Staging only. Normal browsers and applications do not trust the resulting certificate. It is stored separately and never replaces the active HTTPS certificate.

• You control a public DNS domain and can add TXT records.
• You use exact fully qualified domain names (FQDNs).
• Wildcards, IP addresses, and internal-only names are not supported.
• An untrusted staging certificate is sufficient for your test.

For production certificates, continue to use automated DNS-01, an external ACME client, or another solution described in this help section.

1. Open the Web Server configuration.
2. Under Certificate source, select Let's Encrypt DNS (Beta).
3. Start the Request Let's Encrypt DNS certificate action.
4. Enter the exact FQDNs, accept the certificate authority's terms, and choose OK.
5. A second dialog displays the complete record name and TXT value for each name.
6. Add these TXT records at the authoritative DNS provider. Copy each value completely and do not modify it.
7. Wait until public DNS resolvers return the records.
8. Choose OK in the dialog that remains open. Only now does the server check public DNS resolution and request the certificate.
9. After successful verification, the server issues the staging certificate and stores it separately from the active certificate.

Choose Cancel to discard the pending, unissued request and its local state. The server cannot remove TXT records that you have already added at your DNS provider; remove them there yourself if necessary. Cancel does not delete an issued certificate or its renewal state.

If the TXT record is not found when you confirm, Let's Encrypt has not yet been contacted at this point. The server first repeats its own DNS check. If it still fails, wait for the TTL or propagation time stated by your DNS provider and verify the displayed full name and value. A previously cached “not found” response can also remain visible until its negative-cache lifetime expires.

Because the beta creates a staging certificate only, this selection cannot be saved as the active HTTPS certificate source. Select your production certificate source again before saving; the active certificate remains unchanged. If an unfinished setup exists for different names, you can deliberately replace it. This creates new record values; remove obsolete records only after the replacement setup works.

After setup, keep the displayed TXT record in DNS. A daily Task Planner job checks the isolated staging certificate and renews it when needed without another DNS change. The job remains available for the configured beta after a production certificate source is selected again. It also warns 60 and 30 days before the persistent DNS authorization expires.

Do not remove or change the TXT record while the beta should continue renewing. Changing the ACME account, DNS provider, or domain configuration can require a new setup.

The persistent ACME account is bound to this installation's system identity. A backup can therefore only be restored with the same system identity. To move the beta setup to another system, set it up again there and use the newly displayed TXT records.

The beta deliberately does not activate its certificate and changes neither the HTTPS configuration nor the running Web Server. A successful test therefore verifies the challenge and renewal workflow but does not provide a production certificate.

A future production release requires a separate step and can require a new DNS record. Staging and production accounts and their authorizations are separate.

The IETF draft describes the experimental protocol. Before any future production use, also verify the certificate authority's current support status.