Automating DNS Validation with CertSecure Manager: Persistent DCV and DNS Connectors

Domain Control Validation (DCV) is the step where a Certificate Authority confirms that whoever requested a certificate actually controls the domain it is for. For most teams it has been a once-a-year task, handled quietly alongside a renewal. That assumption no longer holds. The CA/Browser Forum mandate has locked in a fixed schedule that cuts certificate lifetimes from 398 days today to 47 days by 2029, and it tightens how long domain validation evidence can be reused at the same time. When a certificate has to be reissued every six to seven weeks, the validation behind it has to keep pace.

Two capabilities make that pace sustainable: persistent DCV (the DNS-PERSIST-01 method), a validation method that lets a domain be re-verified against a single record that is published once, and DNS connectors, which automate the DNS changes that validation still requires. This article explains what each is, the exact deadlines forcing the change, the operational math behind them, and a practical path to prepare.

The deadlines driving the change

In April 2025 the CA/Browser Forum approved Ballot SC-081v3, titled “Introduce Schedule of Reducing Validity and Data Reuse Periods,” with 29 votes in favor and none opposed. The ballot, originally proposed by Apple, sets a phased reduction in both the maximum lifetime of publicly trusted TLS certificates and the period during which validation data may be reused. Every publicly trusted TLS certificate is affected, across DV, OV, and EV, including wildcard and multi-domain (SAN) certificates.

Effective date	Max TLS validity	DCV reuse period	SII reuse (OV/EV)
Through Mar 14, 2026	398 days	398 days	825 days
Mar 15, 2026	200 days	200 days	398 days
Mar 15, 2027	100 days	100 days	398 days
Mar 15, 2029	47 days	10 days	398 days

Validity and DCV reuse limits apply based on the date a certificate is issued, not the date an order is placed.

The Subject Identity Information (SII) reuse window for OV and EV certificates also drops from 825 days to 398 days on March 15, 2026. This change ends the “set it and forget it” model for high-assurance certificates. For the full set of related mandates, including the separate Chrome dual-EKU deadline of June 15, 2026, see our analysis of the CA/Browser Forum mandate. The same shift is also changing when to rely on a public versus a private CA.

Why shorter certificates break manual domain validation

The challenge does not come from the certificate itself. It comes from the frequency of reissuance. Consider an organization with 1,000 publicly trusted certificates. Today, at 398-day validity, that estate generates roughly 1,000 renewal events a year. By 2029, at 47-day validity, the same estate generates more than 8,000 renewal events a year, which represents an eightfold increase in identical work.

Validation is affected even more directly. When the DCV reuse window falls to 10 days while certificates last 47 days, domain ownership has to be re-proved roughly 35 times per year, per domain. Email-based validation and one-off HTTP file placement cannot run at that cadence. The teams most exposed are those managing large estates, SAN certificates that aggregate many domains under one validation, and wildcard domains. The exposure is greatest where DNS ownership is split across networking, infrastructure, and platform teams, and where every change waits on a change-management ticket.

The implication is clear. At machine-paced renewal frequencies, manual certificate management is no longer viable, and scaling certificate operations through automation becomes the baseline. The question is which form of automation removes the most operational risk.

What is Domain Control Validation (DCV)?

Domain Control Validation is the process a CA uses to confirm that a certificate applicant controls the domain named in the request. The CA/Browser Forum Baseline Requirements define several accepted methods. The three in common use are:

• DNS-based validation requires the applicant to publish a TXT record under the domain, which the CA then checks. This is the only method that handles wildcard domains and scales cleanly through automation.
• HTTP-based validation requires the applicant to place a file at a known path on the web server. It works for single hosts but becomes awkward across distributed or load-balanced fleets.
• Email-based validation requires the applicant to respond to a message sent to a domain contact. This method is human-gated and is being phased out for automated issuance.

For organizations operating at scale, DNS-based validation is the practical choice. It works for wildcards, it can be driven entirely through APIs, and it underpins the automated issuance protocols that the new timeline effectively makes mandatory, most notably ACME and its DNS-01 challenge. Persistent DCV and DNS connectors both build directly on this DNS-based foundation.

What is persistent DCV (DNS-PERSIST-01)?

Persistent DCV is a DNS-based validation method that removes the need to create and tear down a DNS record for every issuance. It was added to the Baseline Requirements as section 3.2.2.4.22, titled “DNS TXT Record with Persistent Value” and widely referred to as DNS-PERSIST-01, through Ballot SC-088v3, and became an allowed method in November 2025. It was proposed by Amazon Trust Services and endorsed by Google Chrome, DigiCert, and Sectigo, among others.

The mechanics are straightforward. Instead of provisioning a fresh, temporary record for each validation event, the domain owner publishes a single account-scoped TXT record once, at the label _validation-persist.[domain]. That record identifies the applicant’s CA account. From then on, the CA performs recurring validation checks against the same record automatically, with no further DNS changes required. Importantly, persistent DCV does not weaken domain ownership verification. The CA/Browser Forum requires it to provide security equivalent to existing DNS-based methods. It changes when and how verification happens, moving from event-driven checks to continuous, automated re-validation. CAs remain bound by the same 10-day reuse cap, and persistent DCV means the underlying record never has to be rebuilt to satisfy it.

The record itself encodes who is authorized to issue. A persistent TXT record takes the form:

_validation-persist.example.com IN TXT 
    "authority.example; 
     accounturi=https://authority.example/acct/123; 
     persistUntil=1782424856"

The record name identifies the domain; authority names the CA; accounturi identifies the ACME account authorized to issue (per RFC 8657, and stable across key rotations under RFC 8555 Section 7.3.5); and the optional persistUntil sets an expiry. The CA then re-checks this single record on each issuance.

The operational saving scales with the estate. An organization validating 100 domains four times a year performs roughly 400 DNS changes annually under conventional DNS-01, compared with 100 one-time records under persistent DCV.

One trade-off warrants explicit attention. Because a standing record authorizes issuance, the asset to protect shifts from DNS write access to the ACME account key. Treat that key as a sensitive credential, monitor the persistent record for unexpected changes, and note that issuance can be revoked immediately by deactivating the ACME account (RFC 8555 Section 7.5.2).

Traditional DCV vs. persistent DCV

Traditional DNS-based DCV	Persistent DCV (DNS-PERSIST-01)
A unique, temporary TXT record is created for each issuance event.	A single persistent TXT record is published once at _validation-persist.
The record is added, validated, then removed or rotated every cycle.	The CA re-checks the same record on each issuance; no DNS change needed.
DNS coordination is repeated at every renewal, which is the failure point that scales with frequency.	DNS coordination happens once at setup; renewals are decoupled from DNS work.
Becomes 8x more frequent as validity shrinks to 47 days.	Frequency of issuance no longer drives DNS workload.

What are DNS connectors?

Persistent DCV reduces how often DNS changes are needed; DNS connectors handle the changes that remain. A DNS connector is an integration between a certificate lifecycle platform and a DNS provider that lets the platform create, update, and validate TXT records programmatically, through the provider’s API, rather than asking a DNS administrator to make each change by hand.

This matters because the slowest part of DNS-based validation is usually not the DNS lookup but the human handoff. A certificate team requests a record, a networking team schedules the change, an approval window passes, and only then can validation complete. At annual cadence that delay is tolerable. At a cadence of dozens of validations per domain per year, it becomes the dominant source of both operational drag and outage risk, because a renewal can fail outright if its validation record is not in place in time. Connectors remove the handoff: the platform talks directly to the DNS provider and the record appears, is validated, and is managed without a ticket.

How persistent DCV and DNS connectors work together

The two capabilities are complementary, not interchangeable. Persistent DCV eliminates DNS touchpoints during the renewal cycle. DNS connectors automate the DNS changes that are still necessary, including publishing the initial persistent record and onboarding new domains. Used together, they give a team two distinct levers:

• Where a persistent record can be used, DNS changes during renewal are removed entirely, so issuance frequency no longer drives DNS workload.
• Where a DNS change is still required (new domains, initial setup, providers without persistent support), a connector executes it automatically, with no manual coordination.

The net effect is a validation workflow that scales cleanly as both certificate volume and renewal frequency rise, which is exactly what the 2027 and 2029 deadlines demand.

Guidelines: what to do before the deadlines arrive

The window to prepare is open but narrowing, and the first milestone of 200-day validity is already in effect. The organizations that transition cleanly are the ones that build the automation now, not those reacting when 100-day certificates make manual workflows untenable in 2027. A practical sequence:

1. Inventory the certificate estate. Discover every publicly trusted certificate, with particular attention to those expiring after March 15, 2026. Discovery gaps, which are certificates that nobody remembers, are the single largest source of silent outages.
2. Review aging DCV records. Identify validation data approaching its reuse expiration so renewals do not fail for want of current evidence.
3. Prioritize SAN and wildcard domains. These carry the highest coordination overhead and the greatest sensitivity under compressed timelines.
4. Adopt persistent DCV for established domains. Publish persistent records now, before renewal frequency forces the change at scale.
5. Automate DNS execution with connectors. Connect your DNS providers so initial setup and new-domain onboarding never depend on manual record changes.
6. Standardize on automated issuance. Treat public TLS issuance as a continuous service driven by ACME or an equivalent protocol, and set a policy deadline to retire manual renewals.

CertSecure Manager v3.3: CA-agnostic DNS-01 automation

CertSecure Manager is Encryption Consulting’s vendor-neutral certificate lifecycle management platform. Its CA-agnostic design means a single control plane discovers, issues, renews, and governs certificates across every authority an organization uses, so the validity and validation changes ahead are handled centrally rather than authority by authority, and a certificate can be reissued from a different CA if one is disrupted.

This neutrality matters most at the public-trust layer, where the 47-day timeline has the greatest impact. CertSecure Manager integrates natively with the major public trust providers, including DigiCert, GlobalSign, Sectigo, Let’s Encrypt, and Google Public CA, alongside private authorities such as Microsoft AD CS, AWS Private CA, and HashiCorp Vault. Whichever public CA issues a given certificate, discovery, issuance, renewal, and validation are governed from the same console.

For organizations looking to manage or automate DNS-01 validation specifically, CertSecure Manager v3.3 is built for exactly this transition. Encryption Consulting is actively supporting teams to:

• Onboard their public DNS providers by connecting the providers that host your DNS zones, so that DNS-01 challenge records are created and verified programmatically across a broad range of providers. This removes the manual handoff between certificate and DNS teams.
• Manage DCV through scheduled automation by running recurring domain validation aligned to the renewal cadence that 100-day and 47-day certificates demand, so that DNS-01 evidence stays current without per-cycle intervention.
• Keep validation CA-agnostic by applying the same DNS-01 automation regardless of which public CA issues the certificate, so that consolidating or switching providers does not require rebuilding the validation workflow.
• Build automation-ready workflows across the estate through continuous discovery, policy enforcement, and zero-touch renewal agents, so that renewals at machine pace do not translate into proportional manual effort.

A look at the DNS section of CertSecure Manager shows how this comes together in practice:

Figure 1. DNS provider onboarding and DNS-01 connector configuration

Figure 2. DNS-01 domain validation with CertSecure Manager

The objective is the operational model the new timeline assumes: domain validation treated as a coordinated, automated system rather than a one-off task repeated at every renewal. Engaging early through inventory, DNS provider onboarding, and scheduled DCV automation gives teams a prioritized roadmap well before the mandatory thresholds take effect.

Key takeaways

• TLS certificate validity falls to 200 days (2026), 100 days (2027), and 47 days (2029); DCV reuse falls to 10 days by 2029, set by CA/Browser Forum Ballot SC-081v3.
• At 47-day validity with 10-day reuse, domain ownership must be re-proved roughly 35 times per year per domain, which is far beyond what manual validation can sustain.
• Persistent DCV, the DNS-PERSIST-01 method introduced by Ballot SC-088v3 and allowed since November 2025, lets a domain be re-validated against a single TXT record published once at _validation-persist, with no per-renewal DNS change and no loss of security.
• DNS connectors automate the DNS changes that remain; together with persistent DCV they make validation scale with frequency.
• CertSecure Manager v3.3 helps organizations onboard public DNS providers and run scheduled DCV automation across a CA-agnostic estate, ahead of the mandatory deadlines.

How Encryption Consulting can help

Encryption Consulting is an applied-cryptography and PKI specialist. Beyond providing CertSecure Manager, our PKI Services Practice helps organizations operationalize the move to shorter certificate lifetimes end to end, from first inventory to fully automated, CA-agnostic domain validation. We help teams to:

• Assess 47-day readiness. Discover every publicly trusted certificate, surface the discovery gaps that cause silent outages, and build a prioritized migration roadmap against the 2026 to 2029 milestones.
• Automate DNS-01 validation. Onboard your public DNS providers and stand up scheduled, CA-agnostic domain validation, including persistent DCV (DNS-PERSIST-01) for established domains, so that renewals are decoupled from manual DNS work.
• Deploy and integrate CertSecure Manager. Stand up the platform across your public and private CAs, with renewal agents for zero-touch renewal on web servers, load balancers, and internal applications.
• Design and operate PKI. This covers PKI design and implementation, along with managed options through PKI-as-a-Service and HSM-as-a-Service, including protection of the ACME account keys that persistent DCV makes security-critical.
• Stay standards-aligned and crypto-agile. This means CA/Browser Forum compliance, RFC-aligned validation, and post-quantum readiness, so that the automation you build now carries through the next transition.

To assess your certificate estate against the 47-day timeline and build a DNS-01 automation roadmap, talk to Encryption Consulting’s PKI Services team.

Conclusion

The trajectory is fixed. By 2029, public TLS certificates will last 47 days and domain validation evidence will expire every 10 days. This turns what was once an annual formality into a continuous operational task. Manual DNS updates and email-based validation cannot keep that pace. Persistent DCV (DNS-PERSIST-01) removes the per-renewal DNS change for established domains, and DNS connectors automate the changes that remain; together they let domain validation scale with issuance frequency instead of breaking under it.

The organizations that navigate this transition smoothly will be the ones that prepare before the thresholds take effect. They inventory their estate, onboard their DNS providers, and move domain validation onto scheduled, CA-agnostic automation now, while 200-day certificates still leave room to adjust. Domain validation is becoming background infrastructure; the task ahead is making it run cleanly before the 2027 deadline forces the issue.

Related reading from Encryption Consulting

Further resources on the deadlines, protocols, and automation discussed above:

• The CA/Browser Forum mandate covers the validity cuts, the June 2026 dual-EKU deadline, and what they require.
• Public CA vs. Private CA explains when to use each and how to build automation for the 47-day timeline.
• Choosing a certificate enrollment protocol compares ACME, EST, SCEP, and CMP for short-lived certificates.
• What is the ACME protocol explains how challenge-response validation, including DNS-01, actually works.
• ACME clients on Linux covers Certbot, acme.sh, DNS provider coverage, and where central governance fits.
• Scaling certificate lifecycle operations with automation shows how to turn frequent renewals into an event-driven, hands-off process.
• CertSecure Manager v3.3 details what the release adds for the higher renewal cadence.
• Centralizing Let’s Encrypt and DNS-01 issuance with CertSecure Manager covers DNS-01 challenge validation across public DNS providers, governed centrally.