Should organisations use persistent DNS validation records or recreate them every time?

When persistent DNS validation records make sense

Persistent DNS validation records are the practical choice when certificate issuance is frequent, multiple teams need a stable renewal path, or the DNS workflow is already tightly governed. They reduce churn and make automation easier, but they also create a standing dependency on the DNS zone and on any reusable tokens, delegated records, or automation that can update those records.

The core question is not whether persistence is “safer” in the abstract, but whether the organisation can keep that validation path tightly controlled over time. If the record is left in place, the security of the record, the zone, and the renewal process become part of the trust boundary for every future issuance.

That is why persistent records fit mature environments better than ad hoc ones. They work best when ownership is clear, DNS changes are logged and reviewed, and the same control assumptions will remain true across many renewals rather than a single event.

Why recreating validation records can reduce exposure

Recreating validation records for each issuance reduces persistence, which narrows the window in which a validation artifact can be reused or abused. That approach can be attractive when renewals are infrequent, when DNS administration is loosely controlled, or when the organisation wants each issuance to require a fresh, deliberate action.

The trade-off is operational friction. More manual steps mean more chances for renewal failures, delayed issuance, and inconsistent implementation across environments. If teams regularly miss renewal windows or reintroduce bespoke workarounds, the “safer” approach can become the more failure-prone one.

In practice, the choice is often about whether the organisation prefers a steady, governed automation path or a shorter-lived but more hands-on control pattern. Both can work, but each makes a different assumption about the maturity of DNS operations and change discipline.

Choosing the right pattern for your renewal and governance model

Persistent records are usually better when certificate turnover is predictable, DNS ownership is centralised, and the same record can be safely reused without broadening access beyond what is necessary. Recreated records are better when you want explicit renewal events, stronger separation between issuance cycles, or less standing exposure if a validation token or delegated record is compromised.

The deciding factor should be the combination of renewal frequency, blast radius, and operational control. If the validation record is long-lived but poorly governed, persistence is a liability. If it is long-lived and tightly controlled, persistence is often the more reliable design.

IANA is useful here because DNS validation depends on stable, correctly managed domain and record behaviour, and that stability only helps when the underlying zone administration is sound. For teams building a broader control baseline around DNS change management and access discipline, ISO/IEC 27002:2022 Information Security Controls provides the right implementation context for governed operational controls.

Risk and Threat Considerations

Persistent DNS validation records increase exposure if the zone, delegated update path, or reusable token is overexposed. An attacker or careless operator does not need to defeat the issuance system itself if they can alter the standing validation mechanism or abuse a long-lived record that was meant to be reused.

Failure mechanism: A durable validation record can become a reusable control point if DNS write access, token handling, or delegation is broader than intended, allowing unauthorized renewals or misdirection of validation.

Impact: Certificate issuance may continue on an insecure basis, renewal workflows may be silently trusted, and the organisation may lose confidence in the integrity of its domain validation process.

Practitioner Guidance

Decision rule: Use persistent records only when the DNS zone owner can demonstrate tight change control, limited write access, and reliable monitoring of validation-related changes. If those conditions are not present, favour recreating the record or redesigning the renewal workflow.

What to verify: Confirm who can update the record, whether any delegated token or automation credential is reusable, and whether the record is protected by review, logging, and rotation discipline. The answer is not just “can this be automated,” but “can it stay trustworthy after six months of normal operations.”

Practitioner takeaway: Persist only what you can govern for the full life of the certificate, because a convenient validation record is a control if and only if its reuse remains tightly bounded and observable.

Related resources from NHI Mgmt Group

• How do organisations reduce the dwell time of exposed credentials at scale?
• Should organisations replace standing privileges with time-bound elevation for every use case?
• How should security teams govern non-human identities that have persistent access?
• Why do leaked secrets remain such a persistent NHI risk?