摘要

  • IETF 已将 ACME 的 dns-account-01 草案送入截至 11 月 10 日的最后征询；每个账户将有自己的域名验证地址。
  • 这项设计针对多云、跨区域和迁移期间的并行领证需求，绕开多个系统争用同一个 CNAME 位置的问题。

云迁移最怕交接表上那句“旧系统先别关”。新旧两套系统都在服务同一个域名，也都要续证。按照 ACME 现行标准 RFC 8555 的 dns-01 方式，验证记录放在 _acme-challenge；如果两套系统都想通过 CNAME 把这个位置交给各自的验证服务，DNS 不会凭空长出第二个同名 CNAME。

IETF 工作组的新稿提出的办法很朴素：给账户加门牌。dns-account-01 从 ACME 账户 URL 算出一段短标签，放到 _acme-challenge 前面。甲账户的验证名归甲，乙账户的验证名归乙。证书机构从已签名请求里的账户标识算出应查的地址，再去核对那里刚写入的 TXT 摘要。两台机器终于不用在同一个 DNS 名称前排队。

门牌的算法也写明了：完整账户 URL 做 SHA-256，取前十个字节，再以 Base32 编码。它跟着账户 URL 走，因此账户密钥正常轮换时，门牌可以保留；真正回答挑战的 TXT 值仍由新令牌和账户密钥共同决定。运维团队由此获得稳定的分工地址，同时保留每次验证要重新作答的过程。

多一个门牌，也就多一份授权清单。主云、备用区域、迁移伙伴各持自己的 ACME 账户时，谁批准它接入父域的 DNS？什么时候撤掉？负责人换岗后谁还能说出某段标签属于谁？这些不是密码学细节，而是证书签发权限在组织内部如何登记、交接和收回。旧云合同结束，DNS 里的小门铃若还响着，交接就只做了一半。

草案还点出一个容易被忽略的依赖：账户 URL 的主机名、路径、协议或端口变动，都可能让既有标签失效。它建议服务端尽量保持账户标识稳定；确需迁移时，继续接受先前发出的 URL。客户端完成验证后也应清理 TXT 记录。并行领证的便利，最后要靠这些日常手续维持。

Datatracker 记录显示，第 04 版日期为 10 月 27 日，征询持续至 11 月 10 日。草案还请求在获准后把 dns-account-01 登记为 ACME 验证方法。门铃已经画进图纸，现正等公开审阅。