在 ACME 协议（Automated Certificate Management Environment）生态中，DNS-01 挑战长期以来是自动化证书颁发的事实标准，尤其适用于无法通过 HTTP 验证的场景。然而，随着证书生命周期从传统的 90 天缩短至 Let’s Encrypt 推行的 47 天乃至更短，每一次续期都意味着需要在 DNS 中创建、更新并随后清理 TXT 记录。这种高频的 DNS 变更操作在多域名、多租户或 DNS 变更受限的环境中逐渐成为运维瓶颈。DNS-Persist-01 作为 IETF 草案中定义的新型挑战类型，正是为解决这一痛点而生 —— 它通过引入持久化 DNS 记录状态，让一次域名控制验证可以复用于多次证书颁发，从根本上改变了传统 DNS-01 校验的交互模式。
持久化验证的核心设计理念
DNS-Persist-01 的核心创新在于将域名控制验证从「每次颁发都需要 Fresh Token」的范式，转变为「一次性建立持久授权关系」的模型。在传统 DNS-01 中，ACME 服务器为每一次证书订单生成一个随机 Token，客户端需要将该 Token 写入 _acme-challenge.<domain> 的 TXT 记录中，服务器通过验证该临时记录的存在性来确认域名控制权。验证完成后，该记录通常需要被删除或替换为下一次的新 Token，这种「创建 - 验证 - 销毁」的循环确保了验证的时效性，但也意味着每一次续期都必须执行完整的 DNS 变更流程。
DNS-Persist-01 则采用了一种完全不同的思路：客户端在首次验证时创建一个长期有效的 DNS TXT 记录，该记录不仅包含域名信息，还绑定了特定的证书颁发机构（CA）身份和 ACME 账户标识。一旦该记录被 CA 验证通过，后续针对同一域名、同一 CA、同一账户的证书订单可以直接复用这条持久化记录，无需再进行任何 DNS 变更操作。这种设计在技术上实现了一次验证、多次使用的效果，尤其适合证书生命周期较短、续期频繁的场景。
技术实现细节与协议规范
根据 IETF 草案的定义，DNS-Persist-01 挑战在 ACME 协议中引入了几个关键字段。服务器在返回授权对象时，会包含一个类型为 dns-persist-01 的挑战对象，其中最重要的字段是 issuer-domain-names，这是一个数组，列出了当前支持的证书颁发机构标识（如 letsencrypt.org）。客户端需要从中选择一个目标 CA，然后在 DNS 中创建一个特定的 TXT 记录来响应挑战。
该 TXT 记录被放置在「授权域名名称」（Authorization Domain Name）下，通常的形式是在域名标签前加上特定前缀，例如 _validation-persist.example.com。这个前缀的具体形式在草案演进过程中可能有所调整，但其设计意图是明确的：与传统的 _acme-challenge 记录区分开来，专门用于持久化验证方法。TXT 记录的内容需要编码若干关键信息，包括所选择的颁发机构标识、进行验证的 ACME 账户标识（通常通过账户 URI 或其哈希形式），以及可选的策略参数如是否允许通配符证书、记录的失效时间等。
验证流程分为两个阶段。在初始订单阶段，客户端发起证书请求后，ACME 服务器创建包含 dns-persist-01 挑战的授权对象。客户端解析挑战内容，选择目标 CA，构建符合规范格式的 TXT 记录并发布到 DNS 中。服务器查询该记录，验证其内容是否符合预期（包括语法正确性、语义完整性等），如果通过，则将对应的授权状态标记为 valid。在后续订单阶段，当客户端再次为同一域名请求证书时，服务器会首先检查是否存在符合策略要求的 dns-persist-01 TXT 记录。如果记录存在且仍然有效（例如未过期、CA 标识匹配、账户标识匹配），服务器可以直接复用该授权，跳过挑战创建和验证的步骤，整个过程不涉及任何 DNS 变更。
当不存在符合条件的持久化记录时，服务器会回退到标准的 ACME 授权流程，返回一个 pending 状态的授权对象，其中包含 dns-persist-01（或其他类型的）挑战供客户端完成。这种设计保证了向后兼容性：即使持久化验证失败或不可用，系统仍然可以依靠传统的 DNS-01 或 HTTP-01 方式完成验证。
运维层面的实际收益
从运维角度审视，DNS-Persist-01 带来的改变是深远的。在传统模型下，每一次证书续期都依赖于 DNS API 的可用性和正确的记录变更操作。任何 DNS 传播延迟、API 限流、网络中断都可能导致验证失败，进而影响服务的可用性。尤其在多域名证书或泛域名证书的场景中，一次续期可能涉及数十乃至上百个域名的 DNS 变更，任何一个环节的问题都会导致整体失败。
持久化验证模型极大地简化了这一流程。管理员只需在初始阶段完成一次 DNS 记录的配置和验证，后续的续期操作完全在 ACME 协议层面完成，不再需要与 DNS 服务商进行交互。这对于以下几类场景尤为有价值：其一是 IoT 设备或嵌入式系统，这类设备的 DNS API 访问能力通常受限或不可行；其二是多租户平台，平台运营方需要为大量租户批量颁发证书，频繁的 DNS 变更会带来巨大的运维负担；其三是 DNS 变更审批流程严格的组织，这类组织中每一次 DNS 记录的变更都需要经过人工审批，无法满足短周期证书的自动化续期需求。
此外，持久化验证还降低了 ACME 客户端的复杂度。传统客户端需要实现完整的 DNS 记录创建、验证等待、记录清理的逻辑，而支持 DNS-Persist-01 的客户端只需在首次验证时创建记录，后续流程中可以假设授权已经建立。客户端侧甚至可以缓存授权状态，避免每次订单都进行完整的授权查询。
安全模型的变迁与风险考量
DNS-Persist-01 在提升运维效率的同时，也引入了安全模型层面的重要变化，其中最核心的权衡在于「验证新鲜度」（Proof of Freshness）与「运维便利性」之间的取舍。传统 DNS-01 的每次新 Token 机制确保了验证的即时性：即使攻击者在某一时刻获得了域名控制权，他也只能在有限的时间窗口内利用该窗口期来伪造验证。DNS-Persist-01 放弃了这一属性，转而依赖于 ACME 账户密钥的长期安全性。
具体而言，持久化授权的安全性现在主要取决于 ACME 账户密钥的保护程度。如果攻击者窃取了账户私钥，他可以利用任何已存在的 dns-persist-01 授权记录立即颁发证书，而无需获得域名的 DNS 控制权。这意味着攻击窗口不再局限于验证发生的那几分钟，而是扩展到整个授权有效期。在传统的 DNS-01 模型下，即使攻击者获取了 ACME 账户密钥，通常仍需要配合 DNS 控制权才能完成验证；而在持久化模型下，账户密钥的泄露直接等同于域名证书颁发权的泄露。
基于这一安全模型的转变，部署 DNS-Persist-01 时需要采取额外的防护措施。首先是 ACME 账户密钥的保护应被视为与私钥同等重要，建议使用硬件安全模块（HSM）或专用的密钥管理服务来存储账户密钥，并实施严格的访问控制策略。其次，DNSSEC 的部署变得更为关键：由于验证结果的有效期大幅延长，攻击者有更充足的时间尝试 DNS 欺骗或缓存投毒。草案明确建议在 dns-persist-01 记录上启用 DNSSEC 验证，以防止篡改和伪造。
另外，持久化授权的撤销机制也需要特别关注。当需要终止某个 CA 对域名的持久授权时，管理员必须主动从 DNS 中删除相应的 TXT 记录，而非仅仅依赖 ACME 协议的账户注销或订单撤销。这意味着需要建立完善的生命周期管理流程，确保当账户不再使用或策略变更时，及时清理遗留的持久化记录。
工程落地的参数配置与监控要点
对于计划采用 DNS-Persist-01 的团队，以下工程实践值得关注。在 DNS 记录配置层面，记录的 TTL（Time To Live）设置需要在「长期有效性」与「变更灵活性」之间取得平衡。建议初始 TTL 设置为较长的值（如 86400 秒即 24 小时），以确保授权的稳定性；但同时应在记录元数据中记录创建时间和预期失效时间，以便后续管理和审计。记录格式应严格遵循草案规范，当前推荐的结构包含：ca-identifier（所选择的 CA 域名）、account-uri（ACME 账户 URI）、可选的 persist-until（失效时间戳，采用 Unix 时间格式）以及 policy-flags（策略标志位）。
在 ACME 客户端选择上，需要确认客户端是否已支持 DNS-Persist-01 挑战类型。截至目前，主流客户端如 cert-manager 已在 Issue 中规划了 2026 年的支持计划，部分实验性实现可以在 GitHub 社区中找到。如果使用尚不支持该类型的客户端，可以考虑在传统 ACME 客户端之上封装一层持久化管理逻辑：首次部署时使用支持 DNS-Persist-01 的工具完成初始验证，后续续期则依赖持久化授权的复用。
监控体系的构建同样重要。建议在 DNS 监控中增加对 _validation-persist 前缀 TXT 记录的专项监控，包括：记录是否存在、记录内容是否被意外修改、记录是否接近预期的失效时间等。此外，ACME 账户的活动审计也应纳入安全监控范围，异常的大量证书颁发请求可能指示账户密钥泄露。
总结与适用场景评估
DNS-Persist-01 代表了 ACME 协议在应对短周期证书时代的重要演进，它通过持久化 DNS 验证状态，显著降低了高频续期场景下的运维复杂度和技术风险。对于 DNS 变更受限、自动化能力参差不齐或追求极致运维效率的组织，这一新模型提供了切实可行的工程化路径。然而，运维便利性的提升并非没有代价：安全模型从「每次验证即时性」转向「账户密钥长期保护」，这要求团队重新审视密钥管理策略、加强对 DNSSEC 的依赖，并建立更完善的授权生命周期管理机制。
综合来看，DNS-Persist-01 最适合以下场景：需要批量管理大量域名的多租户平台、DNS API 访问受限或成本敏感的 IoT 环境、以及对自动化效率有极端需求的持续集成持续部署流水线。对于安全边界敏感或密钥管理能力尚未成熟的团队，建议在充分评估风险后审慎引入，或者在非关键域名上先行试点，积累运营经验后再逐步推广。
参考资料
- IETF draft-ietf-acme-dns-persist-00, Automated Certificate Management Environment (ACME) Challenge Types for DNS Persistence
- Let's Encrypt Challenge Types Documentation
- Scott Helme, "DNS-PERSIST-01; Handling Domain Control Validation in a short-lived certificate world"