Dora NodaEvery certificate a self-hosted PaaS issues for a tenant's custom domain today depends on the same fragile handshake: prove control of that domain's DNS again, every single renewal, forever. On February 18, 2026, Let's Encrypt published a challenge type designed to end that handshake for good — and it names "multi-tenant platforms" as the exact use case it was built for.
The new challenge is called DNS-PERSIST-01. Instead of publishing a fresh TXT record for every issuance, a tenant publishes one persistent authorization record, once, and a platform can issue and renew that domain's certificate indefinitely without touching the tenant's DNS again. The CA/Browser Forum's ballot defining it — SC-088v3 — passed unanimously in October 2025; the IETF ACME working group adopted the draft the same month. Staging rollout lands late Q1 2026, production in Q2.
What the Record Actually Looks Like
DNS-PERSIST-01 replaces the classic DNS-01 dance — generate a random token, publish it as _acme-challenge.<domain>, wait for propagation, let the CA check it, delete it, repeat next renewal — with a single standing record at a fixed location. For a domain example.com, the tenant publishes:
_validation-persist.example.com. TXT "letsencrypt.org; accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/1234567890"That one record authorizes exactly one ACME account at one CA — in this case, whichever account the platform uses to issue Let's Encrypt certificates — to issue and renew certificates for example.com forever, with no further DNS changes required. Two optional parameters extend the default behavior:
policy=wildcardbroadens the authorization from just the validated FQDN to also cover*.example.comand any subdomain matching that suffix — useful if a tenant later wants a wildcard cert without publishing a second record.persistUntil=<unix-timestamp>caps the authorization to a UTC expiry instead of leaving it valid indefinitely — the platform's main lever for turning "forever" back into "until we say otherwise."
Let's Encrypt's own announcement is explicit that this isn't aimed at solo domain owners: the spec is "particularly suited for environments where traditional challenge methods are impractical, such as IoT deployments, multi-tenant platforms, and scenarios requiring batch certificate operations." A platform issuing certificates for thousands of tenant-brought domains is precisely the batch-operations case the CA/Browser Forum ballot was written to serve.
The Workaround This Replaces
To see why that matters, look at what a self-hosted PaaS has to do today to issue TLS for a tenant's own domain — app.customerdomain.com pointed at the platform, not a platform-owned subdomain. DNS-01 is already the right challenge type for this (it works regardless of what's sitting in front of the tenant's origin — a CDN, a WAF, anything), but it demands DNS write access on every renewal, and a multi-tenant platform has two unappealing ways to get it:
| Approach | What it requires | What it costs the platform |
|---|---|---|
| Direct DNS API credentials | Tenant hands the platform an API token scoped to their DNS zone | Platform stores and rotates one live credential per tenant, forever; a leaked token exposes that tenant's whole zone, not just certificate issuance |
| CNAME delegation trick | Tenant creates _acme-challenge.customerdomain.com → _acme-challenge.customerdomain.com.platform-acme.net, a one-time setup step | Platform avoids holding tenant credentials, but every renewal still writes and deletes a token record on the platform's own delegated zone, at fleet scale, on a schedule |
| DNS-PERSIST-01 | Tenant publishes one _validation-persist TXT record, once | Platform never writes to DNS again after initial setup — for that domain, for as long as the record exists |
The first two rows describe the actual state of the art today: cert-manager — the tool most self-hosted, Kubernetes-based PaaS platforms already use for certificate lifecycle — tracks DNS-PERSIST-01 support as an open feature request (issue #8373), planned for the same late-Q1-2026 window Let's Encrypt targeted for staging. Until that ships, every multi-tenant platform running DNS-01 today is running one of the first two rows.
Why the Timing Compounds the Case for Fleet Scale
The case for eliminating per-renewal DNS writes gets stronger, not weaker, over the next two years, because Let's Encrypt is separately cutting its default certificate lifetime — first from 90 days to 64, then down to 45 — as part of the same push toward automation-first issuance. Renewals under a 90-day certificate happen around day 60; under a 45-day certificate, they happen around day 30, roughly doubling how often a renewal fires over a year.
Run that against a concrete fleet number. A self-hosted PaaS with 5,000 tenant custom domains on the CNAME-delegation model, renewing every 60 days, performs on the order of 30,000 DNS write-then-delete cycles a year across delegated zones. Move to 45-day certificates and that climbs to roughly 60,000 — twice the DNS API surface for the exact same tenant count, with the exact same cert content.
Under DNS-PERSIST-01, none of that scales with renewal frequency at all: the one-time record a tenant published stays valid regardless of how often the underlying certificate gets reissued, because reissuance under an existing persistent authorization needs no new DNS interaction. The rate-limit budget Let's Encrypt allocates per account — 300 new orders every 3 hours, a token bucket refilling one slot every 36 seconds — is already sized for this: renewals routed through ACME Renewal Info are exempt from it entirely, and DNS-PERSIST-01 removes the DNS-side bottleneck that used to be the practical constraint on hitting that budget at all.
The Tradeoff: A Standing Credential Where an Expiring One Used to Be
None of this is free. A persistent authorization record is, by construction, a persistent standing credential — and that changes what a compromised ACME account key can do. Under classic DNS-01, an attacker who steals a platform's ACME account key still needs live DNS write access to each tenant zone to actually issue a fraudulent certificate; the per-renewal TXT record naturally expires, and a platform that rotates DNS credentials on a schedule bounds the blast radius of any single leaked token.
Under DNS-PERSIST-01, that second barrier is gone for every domain with a live _validation-persist record. A compromised account key lets an attacker issue certificates for every one of those domains immediately, with zero further DNS interaction required — the standing authorization was already published, waiting to be used by whoever holds the account key. The exposure isn't "how many DNS credentials leaked," it's "how many tenants has this platform ever onboarded."
Removing the TXT record isn't an immediate fix either: any authorization the CA already validated and cached remains usable for the CA's normal validation-reuse window regardless of whether the record still resolves. The clean recovery path — deactivating the ACME account outright — is immediate but irreversible, and it takes down every domain under that account at once, not just the compromised ones. That's a platform-wide outage traded for a platform-wide fix.
A self-hosted PaaS adopting DNS-PERSIST-01 for tenant custom domains should treat the account key with the same operational seriousness as a production database credential, and lean on the two levers the spec actually gives:
- Set
persistUntilinstead of accepting indefinite validity. Forcing periodic re-authorization — say, annually — turns a standing credential back into one with a bounded lifetime, at the cost of a one-time re-publish step per tenant when it lapses. - Rotate the ACME account key on a schedule, and monitor issuance volume for anomalies. A sudden spike in certificate requests against a single account, especially across domains that shouldn't be renewing yet, is the signal that DNS-01's expiring credentials used to make unnecessary to watch for.
- Watch Certificate Transparency logs for the account, not just the platform's own issuance queue. Every certificate any CA issues gets logged publicly; a platform that diffs CT log entries against its own issuance records catches a fraudulent cert issued with a stolen account key within minutes of it existing, rather than waiting for a tenant to report something wrong.
What This Looks Like in a Deploy-From-Git Platform
Concretely, this changes one step in the custom-domain flow a git-push PaaS already has to support. Today, a tenant adding app.customerdomain.com to a platform like Bex.co is typically walked through creating a CNAME delegation record, and the platform's domain-reconciliation controller — the piece that watches an App custom resource for a customDomains field and drives certificate issuance to match — has to re-run a DNS-01 challenge against that delegated zone on every renewal. Under DNS-PERSIST-01, that same reconciler instead checks once for a _validation-persist record at setup, and from then on treats the domain as "certificate-ready" without any further DNS round-trip — the reconciliation loop still runs on its normal schedule, but it stops needing to write anything to reach a passing state.
Where This Stands
The tools aren't fully there yet — cert-manager's support is still an open issue, and production issuance from Let's Encrypt itself doesn't land until Q2 2026 — but the standard is settled, unanimously approved, and aimed explicitly at this use case. A self-hosted PaaS issuing certificates for thousands of tenant domains has a good reason to track cert-manager #8373 now, and an equally good reason to design the account-key rotation and CT-monitoring practice in from the start, before the first _validation-persist record ever gets published.
Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own, custom tenant domains included. Star the repo on GitHub or deploy your first app today.