在 ACME 协议的最新演进中，DNS-Persist-01 作为一种持久化 DNS 验证方法正逐步进入工程实践视野。该验证模型通过在域名 DNS 区域中设置长期有效的 TXT 记录，使证书颁发机构（CA）能够在首次验证后持续复用授权结果，从而避免每次证书签发都需执行实时 DNS 查询的运维负担。然而，这种持久化设计在安全模型层面引入了与传统 DNS-01 截然不同的假设与风险敞口，本文将从攻击面分析的视角，系统评估 DNS-Persist-01 对 ACME 安全的工程影响。
核心安全假设的范式转移
DNS-Persist-01 的技术设计基于一组明确的安全假设，这些假设与传统 ACME 验证方法存在本质差异。传统 DNS-01 挑战的核心假设是实时证明—— 域名控制者在挑战期间临时创建特定内容的 TXT 记录，CA 通过即时查询验证后，该记录即失效，整个过程通常在数分钟内完成。这种设计确保了验证的新鲜度（freshness），每次证书签发都需要一次独立的控制证明。
相比之下，DNS-Persist-01 采用了持久化证明模型。根据 IETF draft-sheurich-acme-dns-persist-01 规范，验证记录被部署在 _validation-persist.<domain> 标签下，包含颁发机构域名（issuer-domain-name）和账户 URI（accounturi）两个关键参数。一旦该记录成功写入 DNS 区域并通过 CA 验证，后续所有使用同一 ACME 账户的证书申请都可以直接复用该授权，无需再次修改 DNS。这种设计将安全假设从「实时控制证明」转变为「授权状态存续」，本质上是一种信任延期机制。
这一范式转移带来的最深远影响是证明新鲜度的丧失。在 DNS-01 模型中，攻击者若要在未获得域名控制权的情况下获取证书，需要在极短的时间窗口内完成 DNS 欺骗或篡改；而在 DNS-Persist-01 模型中，攻击窗口被扩展到授权的整个生命周期，可能长达数月甚至数年（取决于 CA 的验证数据复用策略）。规范明确指出，CA 可以基于其「验证数据复用周期」（Validation Data Reuse Period）决定何时需要重新验证，这意味着在极端情况下，一次成功的 DNS-Persist-01 验证可以支撑长期的证书签发。
攻击面的重新分布
DNS-Persist-01 最为显著的安全工程特征是攻击面的重新分布。在传统的 DNS-01 部署模式中，域名运营者通常需要将 DNS API 写权限凭证分发到多个自动化节点（证书管理服务器、持续集成流水线、边缘计算节点等），以支持实时的挑战响应。这种分布式凭证部署策略导致 DNS 写权限的暴露面相当广泛，任何一个节点被攻破都可能导致 DNS 记录被恶意修改，进而被用于证书欺诈。
DNS-Persist-01 在这一维度上实现了显著的暴露面收窄。由于验证记录一旦创建即可长期复用，域名运营者不再需要频繁修改 DNS，DNS API 写凭证的调用频率和使用范围大幅降低。这意味着攻击者能够获取 DNS 写权限的入口点数量和利用窗口都会相应减少，从操作层面降低了供应链攻击的风险。这一特性使得 DNS-Persist-01 特别适合那些 DNS 修改流程冗长、变更审批严格的组织环境，例如存在严格变更管理流程的企业网络或遵循合规要求的金融机构。
然而，攻击面并未消失，而是发生了转移。DNS-Persist-01 将核心安全依赖从 DNS 基础设施转移到了 ACME 账户密钥的安全性上。根据规范的安全考量章节，DNS-Persist-01 验证记录明确绑定了特定的 ACME 账户 URI，这意味着ACME 账户私钥成为新的关键资产。一旦攻击者成功窃取了账户私钥，其可以完全绕过 DNS 层面的操作，直接利用已存在的持久化验证记录签发任意证书，而域名所有者可能毫不知情。
这种攻击面的转移带来了工程实践层面的深刻变化。在 DNS-01 场景下，即使账户密钥泄露，攻击者仍需获得域名 DNS 的写权限才能完成验证；而在 DNS-Persist-01 场景下，账户密钥泄露直接等同于证书签发能力的丧失。这种单点故障的迁移要求运营者重新审视账户密钥的存储、分发和轮换策略。
持久化记录的额外攻击向量
除了核心的账户密钥依赖问题，DNS-Persist-01 的持久化特性还引入了若干额外的攻击向量。首先是验证记录的生命周期风险。由于验证记录在 DNS 中存续期间始终有效，攻击者若在某一时刻获得了 DNS 区域的管理权限（例如通过社会工程、凭证泄露或供应链攻击），不仅可以利用现有的验证记录，还可以在原始账户所有者不知情的情况下持续签发证书。规范明确指出，即使域名运营者删除了验证记录，已分发的证书在 CA 的验证数据复用周期内仍然有效，这种撤销延迟进一步放大了潜在危害。
其次是多颁发机构共存场景下的交叉验证风险。DNS-Persist-01 支持在同一个域名下为多个 CA 分别部署验证记录，这一设计虽然提升了灵活性，但也引入了安全边界问题。如果某个 CA 的系统被攻破，攻击者可能利用该 CA 的验证记录为其他域名签发证书（前提是那些域名也部署了对应的记录）。虽然规范通过 issuer-domain-name 参数实现了记录级别的隔离，但跨 CA 的授权管理仍然需要域名运营者具备清晰的治理策略。
第三是通配符与子域名验证的范围风险。DNS-Persist-01 引入了 policy=wildcard 参数，允许通过单一验证记录同时覆盖基础域名、通配符证书（如 *.example.com）以及所有子域名。这一设计虽然简化了运维，但实质上扩大了潜在的攻击影响范围 —— 一旦基于 policy=wildcard 的验证记录被恶意利用，攻击者可以获取整个域名空间的证书，而不仅仅是单一子域。
工程化安全参数与缓解措施
基于上述攻击面分析，将 DNS-Persist-01 投入生产环境需要实施一套系统性的安全工程措施。在账户密钥保护层面，ACME 账户私钥应当被视为与私有证书同等敏感的高价值资产进行管理。具体而言，应当优先采用硬件安全模块（HSM）或云服务商提供的密钥管理服务（KMS）存储账户密钥；对于密钥轮换，虽然 DNS-Persist-01 规范设计为 accounturi 在轮换后保持不变（验证记录无需更新），但运营者应当建立定期轮换机制，并在发现可疑活动时立即执行密钥吊销和账户停用。
在监控与检测层面，应当建立针对证书签发行为的持续监控体系。CA 通常会提供证书透明度日志（Certificate Transparency Log）的集成接口，通过监控这些日志可以及时发现异常签发请求。此外，DNS 区域的变更监控同样不可或缺 —— 任何对 _validation-persist 记录的添加、修改或删除操作都应当触发告警，即使这些操作来自授权的自动化系统。
在DNS 基础设施安全层面，DNSSEC 的部署应当被视为 DNS-Persist-01 的必要配套措施。DNSSEC 通过为 DNS 记录提供加密签名，能够有效抵御 DNS 欺骗和缓存投毒攻击，确保 CA 查询到的验证记录真实可信。规范明确建议 CA 在验证过程中应当检查 DNSSEC 签名的有效性。此外，多视角验证（Multi-Perspective Issuance Corroboration，MPIC）作为一种从多个网络位置并发查询 DNS 的技术手段，能够有效检测局部网络层面的攻击（如 BGP 劫持或 DNS 欺骗），对于面向公共互联网的证书签发场景具有重要的工程价值。
在验证记录生命周期管理层面，persistUntil 参数为域名运营者提供了直接控制验证记录有效期的能力。工程实践建议将 persistUntil 与证书生命周期对齐或设置为更短的周期（例如 30 至 90 天），以确保即使发生账户密钥泄露，攻击者的利用窗口也能被有效限制。同时，运营者应当在证书续期工作流中同步更新 persistUntil 参数，并建立到期提醒机制，避免因记录意外过期导致的服务中断。
安全模型的选择框架
综合以上分析，DNS-Persist-01 并非 DNS-01 的简单替代，而是针对特定运维场景的安全优化。其适用性取决于组织对以下因素的综合考量：DNS 变更的运维成本是否显著高于账户密钥的保护成本、是否需要支持高频证书签发的自动化场景、以及组织是否具备完善的账户密钥管理和监控能力。
对于 DNS 凭证分布广泛、变更流程冗长的大型组织，DNS-Persist-01 通过收窄 DNS 写权限暴露面能够带来实质性的安全改善；但前提是必须同步强化 ACME 账户密钥的保护级别，并建立完善的监控与应急响应机制。对于安全边界清晰、账户密钥管理能力成熟的团队，持久化验证模型代表了 ACME 协议在工程实用性上的重要进步，但部署时仍需审慎评估通配符策略和多 CA 共存场景下的风险。
资料来源：IETF draft-sheurich-acme-dns-persist-01 规范文档（https://datatracker.ietf.org/doc/html/draft-sheurich-acme-dns-persist-01）