摘要

  • RFC 6844 让域名持有人可以列出获准为该名称签发证书的 CA。它最初的查找规则会跟随 CNAME 或 DNAME，再沿目标名称的父级向上搜索；因此，托管商的 CAA 策略可能进入客户域名的签发查询。
  • RFC 8659 保留普通 DNS 别名解析，却把父级查找限定在正在检查的完整域名上。这一修改更清楚地区分了客户的策略与托管服务自己的名称树。

DNS 回答之后，还有一项证书问题

设想 www.client.example 是指向 tenant.platform.example 的 CNAME。客户的名称经过共享主机的 DNS 命名空间。CA 在签发证书前还得回答一个问题：www.client.example 适用哪组 CAA 记录？

问题出在查询跨过了边界。客户管理一棵 DNS 名称树，服务商管理另一棵。解析器可以在毫秒内跟随别名从一棵树跳到另一棵树。CA 是否还要沿着服务商的父级名称向上查找，把客户没有写在自己区域中的规则也套用过来？

2013 年 1 月发布的 RFC 6844 定义了 DNS Certification Authority Authorization 资源记录，类型编号为 257。域名持有人可以指定一个或多个获准签发的 CA。符合标准的 CA 在签发前必须检查相关 CAA 记录；若请求不符合，就不得签发，除非 CA 的证书政策或操作规范规定了适用例外。

CAA 把一项签发政策放进 DNS，由域名持有人在管理名称数据的同一处发布。CA 因而可以在签发前检查域名持有人的授权。但“相关记录”究竟是什么，取决于查询如何沿 DNS 名称前进。

2013 年，查询可能走过两棵树

RFC 6844 的处理规则不只是从请求名称向父级递归。如果 CAA 查询在某个标签上没有找到记录，而该标签有 CNAME 或 DNAME 别名，算法可以先跟随目标名称并在那里重新查找。如果目标仍无记录，才回到原始名称的父级继续向上。

用虚构名称就能看清结果。假设 www.client.example 指向 tenant.platform.example，而服务商在 platform.example 发布 CAA 0 issue "issuer.example"。RFC 6844 的递归过程可能先跟随别名，再向上查到 platform.example，从而找到这条规则。托管商写在自己父级名称中的记录，因而可能进入对客户域名的签发查找。

这条规则要找到适用的 CAA 记录集，并没有把客户域名的所有权交给服务商。但 DNS 解析路径与政策继承被放在同一套递归里。客户的名字先经过服务商的别名，再可能碰到服务商的父级记录。对共享托管而言，每个客户别名都可能带来服务商高层区域里写下的规则。

2019 年，向上查找留在请求名称树中

2019 年 11 月发布的 RFC 8659 取代 RFC 6844，并改写其处理算法。CA 仍会按照普通 DNS 查询方式检查请求的完整域名，别名也可能在解析过程中被跟随。若查询没有返回 CAA 记录，算法就在被检查名称的父级标签中向上查找；它不再分别爬取遇到的每个 CNAME 或 DNAME 目标的父级树。

差别很窄，却很关键。别名目标上恰好存在的 CAA 记录，仍可能由普通 DNS 查询返回。取消的是沿目标父级再做一次独立向上搜索。客户树中的父级策略依旧可以约束客户的子域名；服务商父级的政策不会只因 CNAME 指向服务商而自动进入客户的查找。

RFC 8659 在比较旧版时说明了修改原因：如果名称很多、别名链很长，同时沿原名称和每个别名目标向上爬会造成低效；托管商也很难只为自己的完整域名设置 CAA 政策，而不把可能不想要的政策带给客户。新算法把问题收窄为：在普通 DNS 别名解析后，请求名称适用哪组 CAA 记录，而它自己的父级名称又发布了什么？

这是签发端的授权检查，不是浏览器验收

CAA 在证书签发之前发挥作用。它不要求浏览器重新判断一张已经签发的证书；更改 DNS 本身也不会撤销既有证书。标准明确规定，依赖证书作出决定的一方不得用当前 CAA 记录来验证证书。记录表达的是签发当时的授权，时间点很重要。

CAA 记录也不会自动证明 DNS 答案真实。RFC 8659 强烈建议为 CAA 使用 DNSSEC，但没有把它列为强制条件。查询被阻止、响应格式错误，或者空答复处理不当，CA 就还没有拿到可靠的政策答案。RFC 8659 的部署章节列出这些故障，因为只有签发者能取回并读懂记录时，访问控制才有用。

CAA 记录还定义了不同属性。issue 适用于普通证书；若有 issuewild，它就负责通配符证书请求。空的签发者值可以表达不允许任何 CA 为该名称签发。这些标签描述政策内容；2019 年的修订则界定了 CA 应在哪棵名称树里查找这些内容。

这就是历史上的变化：第一个 CAA 标准让域名持有人能在 DNS 中指定哪些 CA 可以签发；后来的标准更仔细地划开了持有人的名称树与托管服务商的名称树。DNS 解析仍会跟随别名，授权查找却不再把每个目标的父级名称都算作客户的父级。

文中的域名是依照算法构造的说明示例，不是某起事故。RFC 能证明标准规定的查找方式；要衡量各 CA 的实际实现，还需要关联域名与时间戳的查询日志和签发决策记录。

来源