ACME dns-persist-01：持久化 DNS 验证机制详解

背景与动机

现状提要（2026 年 9 月更新）：dns-persist-01 已于 2025 年 10 月通过 CA/B 论坛 Ballot SC-088v3 获得合规准入，同月被 IETF ACME 工作组采纳为工作组文档。测试环境的可选项在扩大——Let's Encrypt 之外，TrustAsia、LiteSSL 于 2026 年 8 月按 draft-01 在 staging 开放支持。但生产环境目前无一家可用，Let's Encrypt 明确要等草案 issue #64 收敛。客户端方面 lego v5 已支持。验证时注意确认对方实现的草案版本，draft-00 与 draft-01 的记录写法不同。

ACME 协议自 RFC 8555 发布以来，已成为证书自动化管理的事实标准。Let's Encrypt 等 CA 通过 ACME 为数百万网站提供免费证书，极大地推动了 HTTPS 的普及。然而，现有的 http-01 和 dns-01 验证方法在某些场景下存在明显局限，难以满足现代应用的需求。

http-01 的局限

http-01 验证要求申请者在 web 服务器的特定路径下放置验证文件：

GET http://example.com/.well-known/acme-challenge/TOKEN

这种方法虽然简单，但存在以下问题：

不支持通配符证书：无法验证 *.example.com，必须逐个验证子域名
网络限制：需要 80 端口可访问，IoT 设备通常位于 NAT 后难以满足
实时性要求：必须实时响应 HTTP 请求，无法离线操作
防火墙阻挡：某些网络环境禁止入站 HTTP 流量

dns-01 的局限

dns-01 通过创建临时的 DNS TXT 记录来验证域名所有权：

_acme-challenge.example.com. 300 IN TXT "随机令牌"

虽然支持通配符证书，但仍有问题：

操作繁琐：每次验证需创建/删除记录，容易出错
DNS 传播延迟：通常需要 30-300 秒等待全球 DNS 同步
权限要求：需要 DNS 提供商的实时写权限
变更管理：企业环境中 DNS 修改需要审批流程

dns-persist-01 的解决思路

dns-persist-01 采用持久化验证记录的设计理念：

域名所有者只需在 DNS 中设置一次验证记录，该记录可在较长时间内被重复使用，用于多次证书申请和续期。

这种机制特别适合以下场景：

IoT 大规模部署：设备出厂预置验证记录，后续无需 DNS 操作即可自动续期
多租户平台：平台设置验证记录，租户独立申请证书
企业批量证书：预验证域名，支持批处理操作
通配符证书：一次验证，长期使用

dns-persist-01 简介

验证记录格式

dns-persist-01 使用特定的 DNS TXT 记录，位置固定为 _validation-persist.{domain}：

_validation-persist.example.com. 3600 IN TXT "letsencrypt.org; accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/123456; policy=wildcard; persistUntil=1798761600"

字段说明：

字段	必需	说明
`issuer-domain-name`	✅	CA 的域名标识，如 `letsencrypt.org`
`accounturi`	✅	ACME 账户 URI，RFC 8657 格式，绑定域名与特定账户
`policy=wildcard`	❌	启用通配符支持，授权颁发 `*.example.com` 证书
`persistUntil`	❌	UNIX 时间戳，记录过期时间

accounturi 是安全设计的核心。它将域名验证与特定 ACME 账户强绑定，即使攻击者获得 DNS 控制权限，也无法使用其他账户申请证书。

persistUntil 允许域名所有者控制验证记录的有效期。过期后，CA 将拒绝基于此记录的新验证请求，但已颁发的证书不受影响。

与传统方法的对比

dns-01 与 dns-persist-01 的机制差异——差别不在快多少，而在「每次都要授权」与「一次授权长期有效」这两种模型。

下面这张表按能力维度对照三种验证方式：

特性	http-01	dns-01	dns-persist-01
通配符支持	❌	✅	✅
实时 DNS 修改	不需要	需要	仅需一次
IoT 友好	❌	❌	✅
批量操作	❌	❌	✅
验证延迟	秒级	分钟级	秒级

技术原理

验证流程

dns-persist-01 的验证流程分为两个阶段：初始化阶段（只需执行一次）和证书申请阶段（可重复执行）。

dns-persist-01 的两阶段验证——第 1–3 步只在初始化时执行一次；之后每次签发与续期都从第 4 步开始，DNS 记录一动不动。

与 dns-01 不同，dns-persist-01 在证书申请阶段无需修改 DNS 记录。CA 直接查询已有的 _validation-persist 记录，验证通过后即可颁发证书。

即时验证机制

当 CA 收到证书申请时，会立即查询 DNS：

flowchart TD
    A[收到证书申请] --> B[查询 _validation-persist 记录]
    B --> C{找到匹配记录?}
    C -->|否| D[返回待处理挑战]
    C -->|是| E{accounturi 匹配?}
    E -->|否| D
    E -->|是| F{未过期?}
    F -->|否| D
    F -->|是| G[验证通过，颁发证书]

如果找到有效记录，CA 可直接返回 status: "valid"，无需等待客户端创建挑战。这大大缩短了证书申请时间，从传统的数分钟缩短到数秒。

多 CA 支持

一个域名可以同时授权多个 CA，每个 CA 只读取与自己 issuer-domain-name 匹配的记录：

graph LR
    A[_validation-persist.example.com] --> B["letsencrypt.org<br/>accounturi=..."]
    A --> C["zerossl.com<br/>accounturi=..."]
    A --> D["trustasia.com<br/>accounturi=..."]

这种设计允许域名所有者灵活选择 CA，实现多云或多供应商策略。

安全设计核心：accounturi 绑定

accounturi 是 dns-persist-01 安全设计的核心。CA 在验证时会严格检查申请者的账户 URI 是否与 DNS 记录中的 accounturi 匹配：

申请者 A 的 accounturi 与记录匹配 → ✅ 可颁发证书
攻击者 B 的 accounturi 与记录不匹配 → ❌ 拒绝申请

即使攻击者获得 DNS 控制权限，也无法使用其他账户申请证书。

验证数据复用期

dns-persist-01 允许 CA 在验证数据复用期内多次颁发证书。复用期的确定遵循以下规则：

CA 的验证数据复用期：CA 根据自身政策设定的最大复用期限
DNS TTL 约束：如果 TXT 记录的 TTL 短于 CA 的复用期，则以 TTL 为准
persistUntil 约束：如果记录包含过期时间，则以该时间为准

这种分层约束机制确保了安全性与灵活性的平衡。

与 CAA 记录的关系

dns-persist-01 与 DNS CAA（Certification Authority Authorization）记录相辅相成：

CAA 记录：指定哪些 CA 可以为域名颁发证书（控制授权）
_validation-persist：指定特定 CA 和账户的验证授权（实现验证）

两者结合使用，可以实现精细化的证书管理策略。

生态跟进情况

标准化与落地进程

dns-persist-01 的落地进程——每个节点都对应公开可查的公告、投票记录或代码提交。注意最后两条：生产部署的时间表已经因规范争议顺延。

生产部署延后的原因

Let's Encrypt 原计划 2026 年 Q2 上生产，但草案里一处设计争议——issue #64「记录应包含客户端计算的信息」——尚未收敛。他们明确表示在此之前不部署生产环境。

该决定对使用者有利。考虑到 Let's Encrypt 的部署规模，若记录格式在定稿时变更，需要更新 TXT 记录的域名将达到全网量级；等待规范稳定后再上线，可避免按早期草案接入后的返工。代价是生产可用时间尚无确切节点。

可验证的范围正在扩大：2026 年 8 月，TrustAsia 与 LiteSSL 按 draft-01 在测试环境开放支持。验证工作因此不再局限于单一 CA；对国内业务而言，增加一家可测试的本土 CA 有助于排查 DNS 传播与 API 兼容性问题。

客户端支持现状

客户端	状态	说明
lego	✅ 已支持	v5（2026 年 5 月发布）起提供，官方文档有专章
acme.sh	⏳ 讨论中	issue #6812 开放，无版本承诺
cert-manager	⏳ 讨论中	issue #8373，原计划 Q1 2026，随 CA 侧顺延
win-acme	⏳ 讨论中	issue #2849
Certbot	❓ 未表态	尚无公开的实现计划

多数客户端维护者的判断一致：等待生产环境可用后再投入开发。目前 lego v5 是唯一具备完整实现的主流客户端，也是现阶段进行测试环境验证的默认选择。

⚠️ 验证时先确认草案版本。accounturi 在 draft-00 是可选、draft-01 是必填，两版的 TXT 记录写法不同。TrustAsia 与 LiteSSL 实现的是 draft-01。稳妥做法是无条件写上 accounturi（对两版都合法），并向 CA 确认其实现版本。

应用场景详解

IoT 设备批量部署

传统方式的问题：

每台设备需要实时 DNS 操作
设备位于 NAT 后无法使用 http-01
批量部署时 DNS API 速率限制

dns-persist-01 方案：

sequenceDiagram
    participant Factory as 工厂
    participant Device as IoT 设备
    participant CA as CA 服务器
    
    Factory->>Factory: 预置 _validation-persist 记录
    Factory->>Device: 出厂（含验证记录信息）
    
    loop 每 60 天自动续期
        Device->>CA: 申请证书（dns-persist-01）
        CA->>CA: 查询已有验证记录
        CA-->>Device: 即时颁发证书
        Note over Device,CA: 无需 DNS 操作
    end

设备出厂时预置验证记录，后续自动续期无需任何 DNS 操作。

多租户平台

场景：SaaS 平台为每个租户提供独立子域名，需要自动颁发证书。

传统方案：

平台需要 DNS 写权限，安全风险高
租户申请证书需平台介入

dns-persist-01 方案：

graph TB
    Platform[平台管理员] -->|创建| Record[_validation-persist.tenant1.example.com]
    Record -->|绑定| Account[租户 ACME 账户]
    Tenant[租户] -->|使用自己账户| CA[申请证书]
    CA -->|验证| Record
    CA -->|颁发| Cert[证书]

平台只需创建一次验证记录，租户可使用绑定的 ACME 账户独立申请证书，无需平台介入。

企业批量证书

场景：企业需要为数百个内部域名申请证书。

dns-persist-01 优势：

预验证：一次性为所有域名创建验证记录
批量申请：无需等待 DNS 传播，快速颁发
自动续期：复用已有验证，无需人工干预

安全考量

主要风险

1. 持久化攻击窗口

DNS 泄露后，攻击者可长期滥用验证记录。与传统临时验证相比，持久化验证的影响时间更长。

2. 账户密钥泄露

如果 ACME 账户私钥泄露，攻击者可利用持久化验证记录持续申请证书，直到记录过期。

3. 子域名接管

启用 policy=wildcard 后，废弃子域名可能被接管并用于申请证书。

缓解措施

1. 设置合理过期时间

建议设置 persistUntil 控制记录有效期，如 1 年：

_validation-persist.example.com TXT "letsencrypt.org; accounturi=...; persistUntil=1798761600"

2. 启用 DNSSEC

保护验证记录不被篡改：

_validation-persist.example.com IN TXT "..."
_validation-persist.example.com IN RRSIG TXT ...

3. 定期监控

监控验证记录状态，及时发现异常：

flowchart LR
    Monitor[监控系统] -->|每日检查| DNS[DNS 记录]
    DNS -->|异常| Alert[发送告警]
    DNS -->|正常| Log[记录日志]

4. 严格子域名管理

使用 policy=wildcard 时，建立子域名生命周期管理，及时清理废弃子域名。

与现有方法的对比总结

graph LR
    subgraph 普通网站
        A[http-01] -->|简单快速| B[推荐]
    end
    
    subgraph 通配符证书
        C[dns-01] -->|每次都需修改 DNS| D[繁琐]
        E[dns-persist-01] -->|一次设置长期使用| F[推荐]
    end
    
    subgraph IoT/批量
        G[http-01] -->|需要 80 端口| H[不适用]
        I[dns-01] -->|实时 DNS 操作| J[困难]
        K[dns-persist-01] -->|预置验证| L[推荐]
    end

场景	推荐方法	理由
普通网站	http-01	简单，无需 DNS 操作
通配符证书	dns-persist-01	一次设置，长期使用
IoT/批量部署	dns-persist-01	设备无需 DNS 管理权限
多租户平台	dns-persist-01	平台托管，租户独立申请

总结

dns-persist-01 是 ACME 协议的一项重要演进。它不取代现有验证方法，而是为特定场景提供更适配的选项。

核心优势：

✅ IoT 设备无需实时 DNS 管理能力
✅ 批量操作无需重复 DNS 修改
✅ 预验证域名，证书申请几乎即时完成
✅ 支持多 CA 灵活选择

现在能做什么（2026 年 9 月）：

✅ 可以验证：Let's Encrypt、TrustAsia、LiteSSL 三家的 staging 环境 + lego v5，能跑通完整流程
✅ 可以准备：确认 DNS 提供商的 API 能力，把验证逻辑与业务解耦
❌ 不能上生产：所有主流 CA 的生产部署都在等草案收敛，且记录格式仍可能变动

对 IoT、多租户平台与批量签发场景，dns-persist-01 的技术方向是明确的。但在规范定稿前，合理的做法是在测试环境完成流程验证与问题排查，而非将生产流程建立在其之上。待生产环境开放后，切换成本将接近于零。

常见问题

关于 dns-persist-01 的四个疑问

术语速查

ACME 术语表——支持按分类筛选与关键词搜索，两篇 ACME 文章共用。

参考资料

IETF ACME WG · draft-ietf-acme-dns-persist（2025 年 10 月由个人草案 draft-sheurich-acme-dns-persist 转为工作组文档）
Let's Encrypt · DNS-PERSIST-01: A New Model for DNS-based Challenge Validation
Let's Encrypt 社区 · dns-persist-01 部署状态与时间表
lego · DNS-PERSIST-01 Challenge 文档
RFC 8555 · ACME Protocol
RFC 8657 · CAA Account URI Binding

内容更新至 2026 年 9 月。草案仍在演进，具体接入方式请以各 CA 官方文档为准。