摘要

  • 第 13 版是活跃的 DNSOP Internet-Draft，目标为 Best Current Practice；它不是 RFC、批准或实现证据，Datatracker 还标明需要修订稿。
  • 特定服务签发的唯一令牌出现在正确 DNS owner name 下，可以证明一次 challenge 与记录之间的窄因果关系，但不会自行说明完整权限范围。
  • 一次性 token、TXT 的 TTL、应用 grant、持久 CNAME 委托、DNS 更新 credential 与域名所有权是不同生命周期。
  • 离场检查必须证明旧记录已清、更新能力已撤、未来 challenge 无法完成、应用权限已失效；域名换主还必须开启新的所有权 epoch。

删除证据不等于删除能力

DNS 控制验证把一个复杂问题压缩成易于自动化的动作。服务商向某个用户和域名签发 Unique Token，用户把它放进指定 TXT，服务商查询并比对。只要 token 足够唯一，随机 token 也足够不可预测，它就能支持一条明确事实：这次签发之后，有人让该值出现在相关 DNS 名称下。

draft-ietf-dnsop-domain-verification-techniques-13 推荐使用面向应用的下划线前缀 owner name。服务商必须比对自己针对该域名签发的 token。如果同一名称有多个 TXT，至少需要找到一个匹配值。这个机制适合证书、托管、自定义域名以及其他需要域名控制证明的服务。

问题出在成功以后。平台常把 token 视为一次性对象，却把 DNS 写权限交给长期运行的自动化账号。旧 token 失效，只说明这段字符串不再接受；只要写权限还在，账号仍能响应下一次 challenge。

因此退出控制不能只搜索 TXT。它必须检查谁仍能在挑战子树创建记录，API key 是否撤销，CI/CD secret 是否轮换，中间服务是否还接收请求，以及服务商是否仍把该账户当作当前域名控制者。

owner name 是授权界面的一部分

应用专属 label 不只是避免与主机名冲突。它向 DNS 管理者提示谁在索取证明。通用 challenge 名称让多个服务共享一块模糊表面，一次记录可能被不同平台解释成不同授权。

草案讨论 service confusion：恶意服务可以把另一家服务商的 challenge 伪装成自己的 onboarding 步骤。DNS 管理者如实写入 token，真正获得授权的却是另一个服务。技术匹配完全成功，人的意图却没有到达决策点。

因此提供商身份、产品和服务必须清晰。若同一平台有多个权限层级，新应用应考虑不同 label。公开说明应回答：这个记录会允许签发一次证书、长期绑定域名、代答未来 challenge，还是访问已有账户资源？

敏感账号信息不必写进公开 DNS。受保护的授权记录可以保存用户、资源与范围，并用 transaction ID 与 DNS token 关联。DNS 侧保持服务可辨识和 token 可验证。

“已验证域名”不是单一权限

控制同一域名可能触发截然不同的后果：证书签发、邮件路由、自定义 hostname、托管配置、社交身份或长期委托。它们的爆炸半径、期限和撤销方式不同。

现有 challenge 不一定表达细粒度 scope。服务商若把一个 match 当作多个产品的通行证，DNS 管理者就无法知道其动作实际批准了什么。问题不是 DNS 答错，而是权限合同没有随请求到达。

创建记录前，应展示可读授权语句：提供商、服务、账户、域名、资源、scope、一次性或持久、到期与撤销方法。审批针对这段语句；TXT 证明相关 DNS 操作已经发生。两份证据用同一 challenge ID 关联。

自动化可在批准范围内完成机械步骤，却不应替人扩大含义。若产品后来增加新功能，应重新授权，而不是把旧的“verified”状态继承到新权限。

token 经过多重身份边界

用户在应用里发起请求。DNS 管理者可能属于另一团队。中间商可能托管 CNAME 目标。权威 DNS 发布记录。resolver 返回答案。应用最终把验证结果写入账户。

每一层都有独立身份。登录用户不必然有权要求 DNS 变更。能修改 DNS 的账号不必然拥有应用账户。中间商能回答 challenge，不等于其合同仍有效。查询得到正确值，也不保证 grant 绑定到正确用户。

收据至少保存：用户与账户 ID、challenge、域名、owner name、token digest、提供商、服务、requested scope、签发和到期、权威回答、CNAME 链、resolver 观察、策略版本、验证决定与 grant ID。

DNSSEC 在部署并正确验证时可以提高对响应完整性的信心，但它不会补写产品 scope。应用登录可以验证用户，却不能证明 DNS 管理者看过完整授权。每个边界只签自己的事实。

多条 TXT 需要指明到底匹配了哪一条

同一 owner name 可以有多个 TXT。新旧 token、不同用户和不同流程可能并存。服务商只记录 “found” 会丢掉决定性的 RDATA。

审计需要确切匹配值、对应签发记录、观察时间、TTL、CNAME 与同时出现的其他值。TXT RDATA 若由多个 character-string 组成，比较时要拼接，收据应保存参与比较的规范化值，而不是依赖展示格式。

过期 token 即使不再有效，也应清理。它们增加歧义、扩大 DNS 响应，并可能被未来流程错误重用。清理失败还是 ownership 信号：若没人知道谁可删除，委托很可能已脱离治理。

expiry 只控制其中一只时钟

一次性验证完成后通常无需继续保留 record。服务商必须说明 token 有效多久、何时可删除。草案允许可选 expiry 元数据，值可以是时间或 never，也允许把策略留在带外文档。

token 接受期限、TTL、服务商复验周期、应用 grant 期限、会话期限、DNS 更新 credential 期限与域名注册 epoch 完全不同。expiry 到点不会自动删除 grant，删除 TXT 也不会撤销 API key。

关闭动作要逐项产生证据：token 已拒绝、权威记录已消失、缓存窗口已过、复验已停、credential 已撤、应用权限已关闭、服务结果不再依赖旧委托。缺一项就不能用“清理完成”概括。

对于 expiry=never，必须有 named owner、业务理由、复审日期与撤销演练。无限期不是没有生命周期，而是需要更严格生命周期。

CNAME 把一次证明变成未来能力

委托式验证可以用 CNAME 把 challenge 引向中间商。它适合频繁续期，让中间商把持久授权转换为多次 one-off 响应。效率来自未来无需每次请 DNS 管理者操作。

这也意味着授权对象不再是当前 token，而是可生产响应的过程。登记表要写明中间商、最终服务、允许的域名和 scope、账户、credential、复验频率、审计日志和退出步骤。

合同终止与 DNS 删除可能分离。取消订阅后 CNAME 仍在；删 CNAME 后中间商账号仍在；关账号后应用 grant 仍在。退出测试要发出一个新 challenge，证明旧路径无法完成，同时确认既有权限已经失效。

持久委托应定期续权。仅仅“记录还存在”不能替代当前意图。人员离职、供应商切换或产品扩权都触发重新评估。

域名换主必须切断账户继承

域名会出售和转移。新所有者可能从备份恢复旧 TXT，也可能按服务商提示重新写入曾经使用的值。对于持久验证，平台可能把它误解为原用户仍有权。

更危险的是账户 reactivation。若新用户验证域名后自动获得旧用户的消息、配置、secret 或历史资源，今天的 DNS 控制就被当成了昨天的账户所有权。

服务商需要 ownership epoch。注册转移、账户变化或休眠资源恢复应创建新 epoch、新 token 和新 grant。旧资源冻结，只有单独的 transfer/recovery 证据才能迁移。

合法收购当然可以保持连续性，但它需要显式决定与纠正路径。TXT 不是整套数字资产的产权证明。

公共后缀揭示 scope 的分母

在 public suffix 层验证可能影响大量独立租户。草案通常建议不要允许 ICANN division 公共后缀的 ownership verification；私有后缀可能有合理用途，但要加额外检查。

能在某个子节点写入，不代表能代表后缀下所有用户。Validator 应识别 registrable boundary、实际委托 zone 与申请者真正拥有的更新权限。

DNS record 只证明一个节点的状态。应用 privilege 可能覆盖许多名称和资源。两者的差值必须在授权界面显示，不能等查询成功后再猜。

运输真实性与权限语义缺一不可

服务商应按 threat model 防止伪造或操纵 DNS 回答。权威查询、DNSSEC 验证或 resolver 多样性可以改善对所见记录的信心。它们解决的是回答是否可信，不是产品 scope 是否正确。

反过来，清晰 scope 也不能弥补从错误域名接受 token。最终决定需要 DNS 证据和权限合同都通过，并共享同一用户、域名和 transaction。

日志应把 query、CNAME、权威 owner、TTL、时间与安全状态放在 DNS receipt；把账户、资源、scope、grant 与到期放在 application receipt。绿色 DNS 允许授权逻辑继续，不替代授权逻辑。

草案状态限制结论

证据冻结时，第 13 版是 DNSOP 活跃 Internet-Draft，目标为 Best Current Practice。Datatracker 显示工作组提出 issue，需要 revised I-D；IESG 尚未批准，也没有 RFC。

这些来源建立官方文本和流程状态，不证明厂商实现、部署、攻击、未经授权证书、账户接管或实际事故。开篇是构造案例，用于暴露收据缺口。

未来版本可能改变措辞、要求或示例。因此监控文档状态也是治理的一部分；产品不能把草案编号包装成永久合规标签。

把“制造证明的能力”纳入撤销

完整 inventory 不只列出当前 TXT，还列出可创建它们的身份：DNS API token、服务账号、CI secret、中间商账户、CNAME 委托、自动化 job 与人类角色。

授权时记录最小 scope 和有效期。运行中记录每次新 challenge 的签发、响应与 grant。退出时撤销 credential、删除委托、拒绝新 challenge、关闭 grant，并从外部路径验证。

系统必须允许“不知道”。如果无法证明某 credential 已撤销，就把关系标为 unresolved，而不是依据 TXT 缺失自动结案。保留不确定性比制造绿色状态安全。

领导层应问的是下一次 challenge

旧 token 已经失效并不难。真正的问题是：离场主体还能否完成下一次验证？如果能，授权仍在。如果不能，应用是否仍保留旧 privilege？两条都需要测试。

应保留最窄事实：某次活跃 challenge 的值曾在预期 DNS 名称被观察到。用户身份、服务范围、未来写能力、持久委托、域名 epoch 和业务结果各自需要证明。

来源