DNS-PERSIST-01 Explained: A Simpler, Safer Path to Certificate Automation

Certificate automation has quietly become one of the most important disciplines in modern infrastructure. As certificate lifetimes shorten and estates grow, the manual approach of requesting and installing certificates by hand has stopped being viable. Automation is now the norm, and the mechanisms that underpin it deserve attention because small design choices have outsized operational consequences.

A recent addition to the CA/Browser Forum Baseline Requirements, a domain control validation method named DNS-PERSIST-01, is one of those choices. It is a modest-sounding change with a useful effect: it can simplify automation and reduce the attack surface at the same time. This article explains what it changes, how it compares to the familiar ACME DNS-01 method, and what it means for the way you design automation.

A quick recap: why DNS validation matters

Before a certificate authority issues a certificate, it has to confirm that the requester controls the domain. One of the most common ways to prove this is through DNS: the requester publishes a specific record, and the CA checks for it. DNS validation is popular precisely because it can be automated end to end, without touching the web server, which is why it sits at the heart of so many automated pipelines.

How DNS-01 works today, and where it strains

The widely used ACME DNS-01 method works by having the client publish a fresh, challenge-specific TXT record for each issuance, then remove it afterwards. This works well, but it carries an implication: your automation needs ongoing write access to DNS in order to create and tear down those records repeatedly. That standing access is convenient, but it is also a point of risk and a dependency that has to be managed and secured.

What DNS-PERSIST-01 changes

DNS-PERSIST-01 takes a different approach. Instead of rotating records for every issuance, it allows a single persistent TXT record per domain and certificate authority pair. Once that record is in place, repeated issuance against the same domain and CA no longer requires the automation to keep writing to DNS.

The benefits follow directly from that. Reducing the need for ongoing DNS write access narrows the attack surface, because there is less standing privilege for an attacker to target or misuse. It also simplifies the automation itself, since the workflow no longer has to manage the create-and-delete cycle for every renewal. For estates with frequent renewals, that is a meaningful reduction in moving parts.

It is worth being precise about scope. DNS-PERSIST-01 is an addition to the available methods, not a replacement for ACME DNS-01, and policy support is still settling, with Chrome Root Program updates expected to land around early 2026. The practical takeaway is to understand the option and design for it where it fits, not to assume an immediate wholesale switch.

What it means for your automation design

The arrival of a new validation method is a reminder that automation architecture is a design decision, not a default. A few questions are worth asking of any automated issuance setup.

• How much standing access does your automation hold, and could a persistent-record approach reduce it?
• Are your validation methods chosen deliberately, or inherited from whatever a tool defaulted to?
• If a validation method or policy changes, how quickly could you adapt without disruption?

These are exactly the questions a mature certificate lifecycle management practice should be able to answer. The validation method is one layer; the broader discipline is knowing what you have, how it renews, and how resilient that process is. Our piece on why traditional certificate management is no longer enough sets out why that discipline matters as estates scale.

‍