By March 15, 2029, maximum certificate lifetimes will fall to 47 days (down from 398), and domain validation reuse will drop to 10 days, with step-downs in 2026 and 2027 along the way. The challenge is no longer a small, snaggy setup concern; it’s now a design choice of what you need to renew.
This is a practical decision-making and comparison guide to assess the options and select that which has demonstrated to ensure the smooth flow of certificates.
Which ACME Method Should You Use?
HTTP-01 will work if you keep port 80 open and you have a certificate authority that is able to access the specific path on your server. When a wildcard needs to be used, or the host itself is unreachable from the public network, the DNS-01 will become the practical solution. TLS-ALPN-01 is designed to work when only you control TLS termination on 443, and port 80 is closed.
DNS-PERSIST-01 is changing the game. You don’t write a new TXT record every validation; rather, you publish one authorisation that is valid forever, attaching a domain to a particular CA and ACME account.
The next time there’s a renewal of the DNS object, it renews without any further DNS changes and eliminates a recurring write, propagation delay, and credential distribution for DNS-01. Make a selection based on the constraint you cannot eliminate.
Key Takeaways
HTTP-01 is designed to work with a normal web server that does not require wildcard certificates and does not open up port 80. The method is only more complicated if the path becomes unreachable: The certificate authority is responsible for fetching a file from a known file path.
DNS-01 supports wildcard certificates and any host that you can’t reach on the public internet. It is a control mechanism that relies on a temporary TXT record, which is effective even when an inbound connection to the server is not possible.
If no other port is available, and you are the complete TLS terminator, then TLS-ALPN-01 applies. Validation happens during a specific handshake, so once a CDN or load balancer intercepts TLS, the method fails.
DNS-PERSIST-01 is ideal for environments where the number of records is high or if you need to keep records to a minimum, but want to minimise the time it takes to update the records each time they expire. One such continuing authorisation record eliminates the need for those repeated writes and credentials.
What Each ACME Method Actually Proves
The four mechanisms mentioned above are all in effect for Domain Control Validation (DCV). Each one is merely a measure of control on a different level.
The HTTP-01 “firewalls” establish control of the Web content.
A one-time token is used to demonstrate control of the DNS zone in DNS-01.
TLS-ALPN-01 is used to control and prevent the TLS endpoint.
DNS-PERSIST-01 allows you to persistently authorise a specific CA and ACME account on the DNS zone.
Side-by-Side Comparison of All Four Methods
| Challenge | Validates via | Wildcards | Port needed | DNS writes | Best for | Renewal overhead |
| HTTP-01 | HTTP file on port 80 | No | 80 | None | Public web servers with open port 80 | Low |
| DNS-01 | Temporary TXT record | Yes | None | Every validation | Wildcards or unreachable hosts | Medium |
| TLS-ALPN-01 | Special TLS handshake | No | 443 | None | Closed port 80 with full TLS control | Low |
| DNS-PERSIST-01 | Persistent authorization record | Yes | None | Once (setup only) | High-volume or restricted-DNS environments | Very low |
Which Method Should You Choose?
Start with the constraint you cannot remove. The first match in the list below usually gives you the method that will keep working.
| If this is true | Use | Why |
| You need a wildcard | DNS-01 or DNS-PERSIST-01 | Only DNS methods can validate a wildcard |
| Host is not reachable from the public internet | DNS-01 or DNS-PERSIST-01 | CA queries public DNS and never contacts the host |
| Port 80 is closed and cannot be opened | TLS-ALPN-01 or a DNS method | HTTP-01 requires port 80 |
| CDN or managed load balancer terminates TLS | DNS method | You cannot control the ALPN protocol on their terminator |
| DNS updates are manual or owned by another team | HTTP-01 | Avoids credentials and propagation delays |
| None of the above applies | HTTP-01 | Simplest option with fewest failure points |
Use a staggered starting point, working down the rows in sequence. If the wildcard or unreachable host turns up, then the two DNS methods remain the only outstanding ones. HTTP-01 is removed further (usually TLS-ALPN-01 too) by closed port 80 or a third-party TLS terminator. In the absence of all those constraints, of course, HTTP-01 is the lowest-friction option.
- If both your CA and ACME client support it, use DNS-PERSIST-01 rather than DNS-01. Persistent authorisations continue to eliminate recurring DNS writes, propagation, and credential distribution waits while also supporting wildcards and unreachable hosts.
- Order of constraints starting from the top in each environment. To specify a DNS method, you must first choose a wildcard or unreachable host. Next, closed port 80 or third-party TLS termination. If none of those constraints is stipulated, then resort to HTTP-01.
- Useful rules for mixing methods without conflict in a single fleet. Public web server(s) can continue to run on HTTP-01 and wildcard & internal host(s) can run on DNS-PERSIST-01 or DNS-01. Match up each certificate with the constraint that it is related to.
Also Read: Setting Up SSL Auto-Renewal with Different ACME Clients: Step-by-Step Guide
Why was DNS-PERSIST-01 introduced? What’s New?
Problem with classic DNS-01
The classic DNS-01 tries to force the record to be re-created on each validation. In 2029, certificate lifetimes were reduced to 47 days and the reuse of domain validation to 10 days, so that the write frequency would nearly always be 1. By 2029, the write frequency would become almost 1 (with 47 days for certificate lifetime and 10 days for a domain to be validated again).
Propagation delay is added with each correction. Your automation has to locate the record you’ve started for it to be shown to the certificate authority for them to confirm control, and this becomes a timing-sensitive operation when you’re renewing your certificate.
Additionally, the process also introduces DNS credentials on the issuance path. Those credentials must travel with every ACME client that renews certificates, increasing the attack surface and complicating change management across a fleet. As often as revalidation, there is a rapid rise in operational cost.
How DNS-PERSIST-01 works
DNS-PERSIST-01 uses a set of short-lived challenge records, which are replaced by a single long-lived TXT record published at `_validation-persist`. The records are only made once. For each subsequent certification and renewal, the CA picks up the password from it.
The record includes a CA identifier and an `accounturi` parameter, which specifies that the authorisation is bound to a particular ACME account. That authorisation could be used with that CA to get certificates for that domain.
Two optional parameters narrow down the range. With policy=wildcard, the authorisation includes wildcard certificates and matching subdomains. If “persistUntil” is specified, it becomes a Unix timestamp, after which the record does not grant any authorisations. With either parameter, it’s an authorisation for the precise name until the record is removed.
Operational impact and status
After setting the TXT record, you don’t need to set it again. The updates, propagation, and credentials in the issuance path are all unnecessary when renewals follow.
On each renewal, security focus moves from protecting DNS write access on all servers to protecting the ACME account key. Anyone with the key will be able to request certificates for the domain you have registered up to when you delete the record or disable the account.
The method was added to the Baseline Requirements by the CA/Browser Forum ballot SC-088v3, which was initiated in late 2025. The related draft is still being developed by the IETF ACME working group. Let’s Encrypt has declared support and tested it; it’s production-ready, to a limited degree, as of “late 2026”, but review and verify CA capabilities before using.
Also Read: DNSSEC Validation for SSL Certificates: CA/B Forum Ballot SC-085 Changes in March 2026
DNS-PERSIST-01 vs DNS-01: What’s the Difference?
With Classic DNS-01, you have to submit a validation proof once a time for each validation. Your client publishes a new token, waits for it to propagate, and deletes the token once verified by the certificate authority that it’s under your client’s control.
Instead, DNS-PERSIST-01 is used for the case of persistent authorisation. One standing record is still there, and the certificate authority just performs a fresh inspection again to see if there still is a similar authorisation.
Both contrast and contrast effect are implemented under frequent revalidation. ‘Nearly every certificate has to be renewed every 47 days, which is limited to 10 days for domains. One-time tokens result in unnecessary DNS rewrites and time risk. Eliminating both is achieved by a persistent record.
While both DNS-01 and DNS-PERSIST-01 give control using DNS, they have vastly different requirements regarding your operations. There are some nuances here, and the following table details the changes that become noticeable when renewals begin to be performed more regularly.
| Aspect | DNS-01 | DNS-PERSIST-01 |
| DNS label | _acme-challenge | _validation-persist |
| Record purpose | One-time token | Persistent authorization |
| DNS writes required | Every validation | Once during setup |
| Propagation delays | Possible on every renewal | Eliminated after setup |
| Credentials in pipeline | Usually required on every renewal | Required only during setup |
| Security focus | Protect DNS write access | Protect ACME account key |
| Wildcard support | Yes | Yes (with policy=wildcard) |
DNS-01 validates all the validations, as each new one is a new transaction, and a new record and configuration will be required to create it. DNS-PERSIST-01 migrates those that take a single setup step. Once the records are formed, there is no longer any dependency on DNS write access or propagation time. The duty of security to protect changes: you no longer need to keep the DNS credentials; you keep the ACME account key, which is authorised by the persistent record.
Conclusion
With shorter certificate lifetimes and domain re-use periods of 10 days, dependable ACME automation is a crucial necessity. Pick the method according to the infrastructure requirements, not the owner’s tastes.
If there is a choice of which DNS-PERSIST-01 one would prefer, it should be one that is supported by both the certificate authority and the client. It cuts down on rehash operational work and leaves renewals untended. Make thoughtful selections for certificates to renew automatically in the future.
