Let's Encrypt提出了一种新的DNS验证模型DNS-PERSIST-01，旨在改进基于DNS的证书颁发挑战验证过程。该模型通过持久化DNS记录来简化验证流程，提高安全性和可靠性。

DNS-PERSIST-01：基于DNS验证挑战的新模型

作者：Samantha Frank · 2026年2月18日

当用户向Let's Encrypt申请证书时，服务器会通过ACME挑战验证其对域名的控制权。对于需要通配符证书或不愿将基础设施暴露在公共互联网的用户，DNS-01挑战类型长期是唯一选择。尽管DNS-01被广泛支持且久经考验，但其存在操作成本：DNS传播延迟、续期时的重复更新，以及需在基础设施中分发DNS凭据的自动化需求。

Let's Encrypt现正支持一种新的ACME挑战类型——DNS-PERSIST-01，基于IETF草案规范。该机制仍通过DNS验证，但用持久性授权记录替代了重复的控制证明，该记录绑定特定ACME账户和CA。草案称此方法"尤其适合传统挑战不实用的场景，如物联网部署、多租户平台和批量证书操作"。

DNS-01的重复验证机制

DNS-01依赖一次性令牌：客户端需在_acme-challenge.<域名>发布包含令牌的TXT记录，CA通过DNS查询验证匹配。每次授权需新令牌，导致DNS更新成为证书签发流程的常规部分。其优势是每次验证均提供域名控制权的最新证明。

实际应用中，这意味着DNS API凭据需存于签发管道中，验证需等待DNS传播，且频繁的DNS变更（大型部署中可能每日多次）成为常态。

DNS-PERSIST-01的持久授权机制

新方法通过发布持久性TXT记录实现授权，记录需包含CA标识和授权的ACME账户。例如对example.com，记录位于_validation-persist.example.com： dns _validation-persist.example.com. IN TXT ( "letsencrypt.org;" " accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/1234567890" ) 该记录可重复用于新签发和续期，从而将DNS变更移出关键路径。

安全与操作权衡

DNS-01的核心风险是DNS写入权限的广泛分发，而DNS-PERSIST-01将授权绑定至ACME账户，减少凭据暴露点，但需更严格保护账户密钥。

授权范围与时效控制

• 通配符证书：通过policy=wildcard参数扩展授权范围至*.example.com及匹配子域。
• 时效限制：可选persistUntil参数（UTC时间戳）可设置授权过期时间，但需注意监控更新。
• 多CA授权：同一DNS标签下发布多条TXT记录即可授权多个CA。

实施时间线

2025年10月，CA/B论坛投票SC-088v3通过后，IETF ACME工作组采纳该草案。目前测试工具Pebble已支持，lego-cli客户端正在开发。预计2026年Q1末上线测试环境，Q2投入生产。

Let's Encrypt是由非营利组织互联网安全研究小组(ISRG)提供的免费自动化证书颁发机构。详情可参阅2025年度报告。

以下是评论内容的总结：

支持观点

1. 解决实际痛点：多位用户认为该方案解决了证书管理的操作难题，特别是内部服务的证书申请。

   • "This should finally make certificates for internal only web services actually easier to orchestrate" (zamadatix)
   • "All that will be gone and I thank you for that!" (qwertox)

2. 简化流程：用户赞赏方案简化了DNS验证流程，减少手动操作。

   • "Pasting a challenge string once and letting its continued presence prove continued ownership is a great step forward" (csense)
   • "This will make things so much easier" (qwertox)

担忧与批评

1. 账户信息暴露风险：主要争议点是DNS记录中明文包含账户ID，可能引发安全问题。

   • "My biggest hesitation is the direct exposure of the managing account identity" (TrueDuality)
   • "Why not use a randomly generated key instead of exposing my account?" (mmh0000)

2. 缺乏隔离性：部分用户认为该方案未解决密钥泄露的根本问题。

   • "The ACME account credentials are accessible by the same renewal pipelines... so no new isolation" (Ayesh)
   • "Anything with that secret can create a cert for any domain your account controls" (jmholla)

技术建议

1. 替代方案提议：建议使用公私钥或随机ID代替账户明文。

   • "Why not using public/private key auth?" (micw)
   • "It should be a random ID associated with the account" (csense)

2. 现有解决方案：部分用户分享了当前使用的DNS验证优化方法。

   • "I limit hmac-secret to one TXT record per webserver" (jcalvinowens)
   • "I delegated _acme-challenge subdomain to a custom DNS server" (mscdex)

实施细节关注

1. 时间标准疑问：对时间戳采用UTC而非TAI提出质疑。

   • "That should be TAI, right?" (basilikum)

2. 账户创建问题：询问是否可不申请证书直接创建ACME账户。

   • "Is it possible to create an ACME account without requesting a certificate?" (chaz6)

总结显示，用户普遍认可方案的操作便利性，但对账户暴露风险存在显著分歧，并提出了多种技术改进建议。