续期突然被拒：CAA 逐级向上、最近一条胜、查不到不等于放行

直接答案

「证书昨天还能续，今天突然说 CAA 不让签，可我没动过 DNS。」

CAA（Certification Authority Authorization）是挂在 DNS 上的一份授权声明：域名持有人用它告诉 CA「谁可以给我签证书」。它在签发前被查一次，之后就不再参与任何判断。所以「续期失败」不是证书坏了，而是这一次签发请求没通过授权检查——而检查的对象是此刻的 DNS。

四个最容易判断错的地方，先摆出来：

问题	规则	常见误判
记录配在哪一层才算数	从被签发的具体域名逐级向父域找，找到第一个 CAA RRset 就停	「配在注册域就管所有子域」——只有子域上没另配时才成立
同一标签有多条记录	加法：任一条允许即可	「多条取交集」「后写的覆盖先写的」
issue 与 issuewild	两条独立分支，通配符请求里只要出现 issuewild，issue 全部失效	「配了 issuewild 就管所有证书」
查询本身失败	无法判断是否存在禁止记录，通常按阻止处理	「查不到就是没有记录，等于放行」

还有一条不属于「规则」但同样会挡签发：记录的值。空值、畸形值、带参数的约束，三者的效果各不相同，详见第五节。

一、CAA 断言的是「授权」，不是「证书有效」

先把边界划清，否则后面每一条都会被过度推广。

RFC 8659 的摘要说得很直接：CAA 让域名持有人指定「一个或多个被授权为该域名签发证书的 CA」，目的是降低误签发的风险（reduce the risk of certificate mis-issue）。它是签发的前置条件，不是充分条件——原文：

Conformance with a published CAA record is a necessary, but not sufficient, condition for the issuance of a certificate.

也就是说，CAA 通过只代表「这家 CA 被允许签」，不代表「这次签发一定合规」。同一份文档还有三句更硬的限定：

• 有效性取决于签发方是否遵守：The effectiveness of CAA records as an access control mechanism is thus dependent on observance of CAA constraints by Issuers.
• 不防「被授权 CA」误签：The use of CAA records does not prevent mis-issue by an authorized CA——它降低的是「不该签的 CA 签了」，不是「该签的 CA 乱签」。
• 不能被用来验证书：Relying Parties MUST NOT use CAA records as part of certificate validation. 浏览器不会因为你配了 CAA 就更信任你的证书；反过来，CAA 写错了也不会让已签发的证书失效。

对一人公司的含义：CAA 是签发时刻的一道闸，不是运行时的安全检查。 它挡不住已经发出去的证书，也挡不住被授权 CA 内部的流程问题；它能挡住的是「别家 CA 替你签」。

二、查找：从具体名字逐级向上，找到第一个 RRset 就停

这是所有 CAA 问题的起点，也是最容易想当然的一步。原文的查找算法只有五行伪代码：

RelevantCAASet(domain):
  while domain is not ".":
    if CAA(domain) is not Empty:
      return CAA(domain)
    domain = Parent(domain)
  return Empty

配套的说明是：The search for a CAA RRset climbs the DNS name tree from the specified label up to, but not including, the DNS root "." until a CAA RRset is found.

RFC 自己给了两个例子，正好是两种结局：

场景	逐级查询	结果
X.Y.Z 全层级都没有记录	X.Y.Z 空 → Y.Z 空 → Z 空 → 到根之前停止	Empty，不限制签发
A.B.C，只有 B.C 上有 issue example.com	A.B.C 空 → B.C 命中	提前结束，用 B.C 那一条

注意第二行：一旦某一级命中，就不再往上找。所以父域上那条「只允许某家 CA」的记录，管不到已经在子域上单独配了记录的域名。

Let’s Encrypt 的文档把同一件事写成了操作语言：CA 会「尊重离被签发域名最近的那条 CAA 记录」（the CA will always respect the CAA record closest to the domain name it is issuing a certificate for），顺序是具体名 → 父域 → 注册域，stopping at the first CAA record it finds。它给的例子是：example.org 上只允许某家 CA，但 api.example.org 托管在云厂商、在子域上另配一条，就能覆盖父域的授权，只放开这一个子域。

两个附带的结论：

• 不要只查注册域。 你要查的是「这次要签的那个名字」——包括证书里 SAN 列出的每一个名字。原文要求：Issuers MUST verify authorization for all the FQDNs and Wildcard Domain Names specified in the request. 一张证书里加了一个新子域，只要那个子域的授权不通过，整张证书就签不下来。这解释了「主域一直没事，加了 api. 之后续期开始失败」。
• CAA 查询跟随 CNAME。 RFC 的伪代码在定义 CAA(X) 时就写明要「chasing aliases」；Let’s Encrypt 写得更直白：CAA checking follows CNAME redirects, just like all other DNS requests. 如果 community.example.org 是 example.forum.com 的 CNAME，CA 会看 example.forum.com 上的记录——你在原名字上配的那条不生效。

三、多条记录是加法：加一条不会盖掉另一条

同一个标签可以出现多次。这时不是「取交集」，也不是「最后一条生效」，而是并集。RFC 的原话是 CAA authorizations are additive，并给了一个反直觉的等价关系：

CAA authorizations are additive; thus, the result of specifying both an empty issuer-domain-name and a non-empty issuer-domain-name is the same as specifying just the non-empty issuer-domain-name.

Let’s Encrypt 的表述更接近操作现场：they are additive: if any one of those records allows the CA to issue, then it is allowed.

由此可以推出两个日常现象（推论，非原文）：

1. 「我又加了一条给新 CA，旧的怎么还在生效」——因为旧记录没删，两条都在授权集合里，加法不会让新的挤掉旧的。
2. 「想只允许 A，加一条 B 的禁止就行了吧」——不行。CAA 没有「拒绝某家 CA」的标签；要收紧，只能删掉允许它的那条记录，或者把整个 RRset 换成只授权 A 的写法。

反过来，「有 CAA 记录」不等于「有限制」。RFC 明确：如果 Relevant RRset 里没有任何限制签发的标签（例如只有 iodef，或者只有 CA 不认识的标签），CAA does not restrict issuance。所以「我的域名有 CAA 记录」这句话本身不构成任何结论——要看的是标签和值。

四、issue 与 issuewild：两条分支，四种组合

issue 管普通域名，这一点没有争议。争议都出在通配符上。RFC 8659 §4.3 定了三条规则：

• issuewild 的语法与 issue 相同，但只授权签发通配符证书；
• 处理非通配符请求时，每条 issuewild 都必须被忽略（MUST be ignored）；
• 处理通配符请求时，只要 Relevant RRset 里出现至少一条 issuewild，每条 issue 都必须被忽略。

而「没有 issuewild 时 issue 也管通配符」——这是 Let’s Encrypt 文档里的表述：issue 记录「在没有任何其它记录时，同时控制普通签发和通配符签发」（it controls both normal ... and wildcard ... issuance in the absence of any other records）。所以只有当你需要对通配符区别对待时，才需要 issuewild。

把 RFC 的三个例子并排，四种组合就清楚了：

RRset	普通域名（wild.example.com）	通配符（*.wild.example.com）
只有 issue "ca1"	只 ca1	只 ca1（issue 兼管）
issue "ca1" + issuewild "ca2"	只 ca1	只 ca2
只有 issuewild "ca2"	任何 CA 都可以	只 ca2
issuewild "ca2" + issue ";"	谁都不行	只 ca2

第三行是最容易踩的：RFC 的原文是「请求只允许 ca2 为 *.wild3.example.com 签发」，紧接着一句 It permits any Issuer to issue for "wild3.example.com" or "sub.wild3.example.com".——因为你只写了通配符的规则，普通域名那一侧没有任何限制。想收紧普通域名，得再加一条 issue；想全禁，就用下一节的空值。

五、三种「值」的陷阱：空值、畸形值、参数

标签对了、位置对了，仍然可能被挡——问题出在值上。这三种情况的效果完全不同，但报错时看起来都像「CAA 不允许」。

5.1 空值：CAA 0 issue ";" 是明确的「禁止签发」

RFC 写得很清楚：FQDN owners can use an issue Property Tag with no issuer-domain-name to request no issuance. 示例就是 CAA 0 issue ";"——值为空，等价于「任何 CA 都不得签发」。

这条常被用来做「临时冻结」：某个子域准备下线、或者怀疑被滥用时，先把它锁死。但它也是最容易被误留的一条：上线时忘了删，半年后续期失败，而所有人都不记得配过。

5.2 畸形值：等同空值，也就是「禁止」，不是「忽略」

这条最反直觉。原文：

An issue Property Tag where the issue-value does not match the ABNF grammar MUST be treated the same as one specifying an empty issuer-domain-name.

RFC 给的例子是 CAA 0 issue "%%%%%"——注释直接写 forbids issuance。也就是说，值写错一个字符，不是「这条记录无效所以跳过」，而是「这个域名禁止签发」。多打一个空格、把分号写进域名、复制时带了不可见字符，结果都是同一个。

这也是「昨天还好好的」最可能的解释之一：记录没变，但签发端对值的解析变了，或者你改的那条记录本来就在生效路径上。

5.3 参数：写在 CA 的命名空间里，写了不等于生效

issue 的值可以带分号分隔的参数，例如 ca.example.net; account=230123。RFC 8659 对参数归属说得很干脆：The semantics of parameters to the issue Property Tag are determined by the Issuer alone.

RFC 8657 把两个通用参数（accounturi、validationmethods）的语义定下来了，同时留下两条硬约束：

• 无效或不认识的 accounturi 会让整条 Property 不可满足：A Property with an invalid or unrecognized "accounturi" parameter is unsatisfiable. 同一属性里出现多个 accounturi，同样不可满足。
• 不能假设限制生效：Domains configuring CAA records for a CA MUST NOT assume that the restrictions implied by the "accounturi" and "validationmethods" parameters are effective in the absence of explicit indication as such from that CA.

换句话说：你写 ;validationmethods=tls-alpn-01，只有在那家 CA 明确声明支持这个参数时才是「只允许 tls-alpn-01」；没声明时，这条约束可能被忽略（授权比你想象的宽），也可能因为不满足而挡住签发（比想象的严）——两种都不是你能假设的。RFC 8657 §5.2 把原因写透了：参数是 CA 自己的命名空间，由 CA 决定认哪些、怎么解释。

Let’s Encrypt 的文档列了它自己支持的取值（http-01、dns-01、tls-alpn-01）与 accounturi 的 URI 形态。这是它的文档，不是通用约定——换一家 CA，同样的写法含义可能不同。

六、128 关键位：不认识就不得签发

CAA <flags> <tag> <value> 里的 flags 通常写 0。写成 128 时，置的是「签发方关键位」（Issuer Critical Flag）。RFC 特意解释了这组位序容易搞混的地方：按 DNS 惯例 bit 0 是最高位，所以 a value of 128 means that bit 0 is set。

置位之后的规则是强制性的：

A CA MUST NOT issue certificates for any FQDN if the Relevant RRset for that FQDN contains a CAA critical Property for an unknown or unsupported Property Tag.

RFC 的例子是 CAA 128 tbs "Unknown"：除非签发方实现了 tbs 这个标签的处理规则，否则不得为 new.example.com 签发——不管 issue 那一条写得多宽松。

这条的设计意图是给未来留扩展位，但它有一个副作用，RFC 自己在 §5.6 里写出来了：CA 可能利用关键位，让客户发布一些「挡住竞争对手、但客户本意是授权多家」的记录（A CA could make use of the critical flag to trick customers into publishing records that prevent competing CAs from issuing certificates）。RFC 认为实际影响有限（竞争对手会发现并告知客户），但对一人公司的操作含义很直接：

从 CA 后台一键生成的 CAA 记录，要逐字读一遍再贴。 尤其是出现 128 的行——它不是「更安全」，而是「只有认识这个标签的签发方才能签」。

七、查询失败也会挡住签发

前面六节都在讲「记录写了什么」。但真实故障里，很大一部分是记录根本没被读到。

Let’s Encrypt 的文档说它每次签发前都查 CAA（checks CAA records before every certificate we issue），并且明确：出错时无法判断是否被允许——there's no way to tell whether we are allowed to issue for the affected domain，因为可能存在一条禁止记录，只是被错误遮住了。所以「查询失败」不能当成「没有记录」。

RFC 8659 §6 把常见成因列成了一节，四条都值得记住：

成因	表现	出处要点
中间盒丢弃未知类型的 DNS 包（尤其是抗 DDoS 设备）	查询超时，或本地递归返回 SERVFAIL	may be configured to drop DNS packets of unknown types
权威服务器对不认识的类型回 NOTIMP／REJECTED	SERVFAIL	正确行为应是 RCODE 0（No error condition）
子域被委派到私网地址的 nameserver	SERVFAIL	A CA MAY interpret that as preventing issuance.
DNSSEC 签名或验证有问题（尤其是空响应）	SERVFAIL	签名过的空响应与伪造响应含义不同

Let’s Encrypt 侧给了同一组现象的分诊顺序：SERVFAIL 最常见的原因是 DNSSEC 验证失败，建议先用 DNSSEC debugger（它点名了 dnsviz.net）；如果没有启用 DNSSEC 却拿到 SERVFAIL，第二可能的原因是权威服务器对未知类型回了 NOTIMP——那是违反 RFC 1035 的，应当回 NOERROR 加空响应；再往后是权威服务器本身故障。超时则通常是「nameserver 前面有防火墙，把未知 qtype 的查询丢了」。

它还专门纠正了一句流传很广的话：Your DNS provider does not need to specifically support CAA records; it only needs to reply with a NOERROR response for unknown query types (including CAA).——DNS 商不需要「支持 CAA」，只需要对不认识的类型老实回一个空答案。

关于 DNSSEC 再补一句，避免过度推广：RFC 说 CAA 记录的 DNSSEC 认证 is strongly RECOMMENDED but not required；但同时要求 An Issuer MUST NOT issue certificates if doing so would conflict with the Relevant RRset, irrespective of whether the corresponding DNS records are signed. 没签名不是免死金牌，签了名也不是通行证。

八、十分钟取证：三组命令与一张判读表

目标不是「把记录改对」，而是先确定是记录在挡，还是查询在挡。以下命令为示例，example.org 与 ns1.example.net 请替换成你的域名与权威服务器（命令与判读顺序属编辑判断）。

第一组：沿查找路径逐级查

dig CAA www.example.org +noall +answer +comments
dig CAA example.org     +noall +answer +comments
dig CAA org             +noall +answer +comments

从要被签发的那个名字开始，一级一级往上，直到看见第一个非空答案。+comments 是为了看 status:——NOERROR 且 ANSWER: 0 与 SERVFAIL 是两件完全不同的事。

第二组：绕开本地缓存，直接问权威服务器

dig NS example.org +short
dig CAA example.org @ns1.example.net +noall +answer +comments

本地递归的缓存会掩盖「权威侧已经坏了」这件事；直接问权威服务器，才能看到 NOTIMP、REJECTED 或干脆没回应。如果权威侧正常、递归侧异常，问题在中间的解析链路（含 DNSSEC）。

第三组：先看有没有 CNAME，再决定查哪个名字

dig www.example.org CNAME +short

有 CNAME 时，CAA 要看的是目标名字上的记录（RFC 的查找算法要 chasing aliases，Let’s Encrypt 也明确跟随重定向）。在有 CNAME 的名字上配 CAA，本身就是矛盾的——同一个名字不允许既有 CNAME 又有其它记录。

判读表

你看到的现象	更可能的原因	下一步
逐级都是 NOERROR + 空答案	没有 CAA 策略，不限制签发	去查别的原因（验证方式、限额、域名状态）
某一级有记录，且值正常	就是这一条在管	对照第四节看是普通还是通配符分支
记录存在，但值是空的或畸形	等同「禁止签发」	改值，别加新记录去「覆盖」
记录里带 ; 参数	参数是否生效取决于该 CA 的文档	查 CA 对参数的声明，别假设
记录里有 128 的行	不认识该标签的 CA 一律不得签发	逐字确认这个标签是不是你要的
权威服务器回 NOTIMP／REJECTED	DNS 商违反 RFC 1035	提工单要求回 NOERROR 空响应，或换商
查询超时	权威服务器前有防火墙丢未知类型	找 DNS 商确认防火墙规则
SERVFAIL + 已启用 DNSSEC	签名或验证问题（空响应尤其常见）	用 DNSSEC debugger 定位
子域委派到私网 NS	CA 侧只能拿到 SERVFAIL	改用可公网解析的 NS（split-horizon）

改完之后怎么确认？ 来源没有给 TTL 与缓存时长的口径，本文不写「多久生效」。可核的做法是：改完立刻用第二组命令直接问权威服务器（绕开缓存），确认权威侧返回的就是你想要的值；再用第一组命令从外部递归查一遍，两者一致再触发签发。至于递归侧什么时候刷新，取决于记录的 TTL 与解析器的缓存策略——这一点请以你 DNS 商的文档为准。

九、十二项上线检查

1. 列出所有会被签发的名字。 主域、www、每一个 API 子域、每一个通配符——证书 SAN 里的每一个都要单独过一遍查找路径。
2. 对每个名字跑一遍第一组命令，记录「命中在哪一级」。
3. 确认没有 CNAME 与 CAA 共存的名字；有 CNAME 的，去目标名字上查。
4. 逐条读值：有没有空值 ";"、有没有畸形字符、有没有多余空格。
5. 逐条读参数：accounturi／validationmethods 是否被该 CA 明确支持；accounturi 是否只有一条且格式正确。
6. 逐条读 flags：出现 128 的行，确认标签是你认识的、且确实想让它成为硬约束。
7. 确认普通与通配符两侧都被覆盖：只写 issuewild 的 RRset，普通域名那一侧是放开的。
8. 确认「加一条」没有变成「放开一条」：加法语义下，新增授权不会收紧旧授权。
9. 从权威服务器直接查一遍，确认不是递归缓存给你的假象。
10. 确认 DNS 商对未知 qtype 回 NOERROR，而不是 NOTIMP。
11. 把「谁可以签」写成一行注释留在仓库里，包括为什么有那条 ";"（如果有）。
12. 在证书到期前留出足够时间做这次核对——CAA 错误不会自己消失，而续期失败通常只在到期前几天才被发现（这一条属编辑判断）。

十、六种误读，与本周能做的五件事

误读一：「配了 CAA 就能阻止所有错误签发。」 它降低的是「未授权 CA 签发」的风险，且有效性取决于 CA 是否遵守；被授权的 CA 误签，CAA 管不了（RFC §5.3）。它也不能用来验证已有证书。

误读二：「没有 CAA 记录就禁止签发。」 Relevant RRset 为空即不限制。真正会「禁止」的是空值 ";" 或畸形值，两者长得很像「有记录」，效果却相反。

误读三：「查询出错=没有记录=放行。」 Let’s Encrypt 明确说错误时无法判断是否存在禁止记录。SERVFAIL、NOTIMP、超时都可能挡住签发。

误读四：「CAA 只查注册域。」 是从具体 FQDN 逐级向上、命中即停；子域一条记录就能覆盖父域。反过来，父域的记录管不到已单独配置的子域。

误读五：「多条 issue 取交集。」 是加法，任一允许即可。想收紧只能删记录或换整个 RRset，不能靠「再加一条」。

误读六：「128 等于更安全。」 128 是「关键位」：不认识该标签的 CA 一律不得签发。它把兼容性当成了代价换强制性，不是普适的加固手段。

本周能做的五件事：

1. 把「这次要签的所有名字」列成一张表，对每个名字跑一遍 dig CAA，标出命中层级。这张表以后每次加子域都要更新。
2. 搜一遍 ";" 和 128。这两类记录最容易被复制粘贴带进来，也最容易在半年后突然生效。
3. 把 CAA 的检查加进证书巡检，和到期时间放在同一张卡上——续期失败和证书过期是两件事，但发现时间通常是同一个。
4. 向 DNS 商确认一件事：对未知 qtype 是回 NOERROR 还是 NOTIMP。这一句话能排掉一整类「偶发续期失败」。
5. 别照抄 CA 后台生成的记录。至少读一遍 flags、标签和参数，再决定要不要贴。

如果只能记住一件事：CAA 不是「有没有记录」的问题，是「沿着查找路径，第一个被读到的那个 RRset 说了什么」的问题。

---

边界说明：本文关于 CAA 的规则陈述全部来自 RFC 8659、RFC 8657 与 Let’s Encrypt 的 CAA 文档，三份来源均于 2026-10-31 逐条访问并验证为 HTTP 200（字节数见「来源」）。不写「CAA 能阻止所有错误签发」——RFC 明说有效性取决于签发方遵守，且不防被授权 CA 误签，Relying Party 也不得用它做证书校验；不写「没有记录就禁止签发」——空 RRset 不限制；不写「查询出错等于没有记录」；不写「CAA 只查注册域」或「多个 issue 取交集」；不写「CAA 必须配 DNSSEC」——原文是 strongly RECOMMENDED but not required；不写任何具体 CA 名单、价格或「多久生效」的时长（来源未给 TTL 与缓存口径）；不把 128 描述成「禁止所有 CA」，它的效果是「不认识该标签的签发方不得签发」。文中标注为编辑判断的有：第三节由加法语义推出的两个日常现象、第八节的命令与判读顺序、第九节第 12 项、第十节的五件事。示例域名沿用 RFC 的保留示例域，不对应真实站点；本文不重复证书生命周期、ARI 与监控信号（见《续期从不报错》一篇），也不重复 DNS 切换与 TTL 取证（见《改一条 A 记录不是发布》一篇）。

来源

以下页面均于 2026-10-31 逐条访问并验证为 HTTP 200；字节数为当日抓取的实际大小。

1. RFC 8659: DNS Certification Authority Authorization (CAA) Resource Record核查于 2026/10/31（200，96 151 B）：CAA 的定义与目的（reduce the risk of certificate mis-issue）；Conformance with a published CAA record is a necessary, but not sufficient, condition；Relying Parties MUST NOT use CAA records as part of certificate validation；§3 的 MUST check for publication of a Relevant RRset／MUST NOT issue a certificate unless ...／CAA does not restrict issuance（只有 iodef 或不认识的标签时）／Issuers MUST verify authorization for all the FQDNs and Wildcard Domain Names／逐级向上查找与 RelevantCAASet 伪代码；§4.2 的 CAA authorizations are additive、空 issuer 值 request no issuance、畸形值 MUST be treated the same as one specifying an empty issuer-domain-name、参数语义 determined by the Issuer alone；§4.3 的三条 issuewild 规则与四个示例（含只写 issuewild 时普通域名放开）；§4.5 的 128 关键位与 tbs 示例、a value of 128 means that bit 0 is set；§5 的 dependent on observance of CAA constraints by Issuers；§5.1 的 strongly RECOMMENDED but not required 与 irrespective of whether the corresponding DNS records are signed；§5.3 的 does not prevent mis-issue by an authorized CA；§5.6 的关键位滥用；§6 的四类查询故障（中间盒丢未知类型、NOTIMP／REJECTED、私网 NS 委派、DNSSEC 空响应）。
2. Certification Authority Authorization (CAA) - Let’s Encrypt核查于 2026/10/31（200，36 493 B）：CAA 的用途与「默认任何公共 CA 都可签发」的背景；建议把记录配在注册域；the CA will always respect the CAA record closest to the domain name／stopping at the first CAA record it finds／子域覆盖父域的例子；CAA checking follows CNAME redirects；记录格式 CAA <flags> <tag> <value>；issue 在无其它记录时兼管通配符、issuewild 只在需要区别对待时使用；同标签多条 additive: if any one of those records allows the CA to issue, then it is allowed；letsencrypt.org 为其 CAA 标识域；validationmethods（http-01／dns-01／tls-alpn-01）与 accounturi 参数；checks CAA records before every certificate we issue；出错时 there's no way to tell whether we are allowed；DNS 商只需对未知类型回 NOERROR；NOTIMP 属 RFC 1035 违规；SERVFAIL 先查 DNSSEC（dnsviz.net）再查 NOTIMP 再查 NS 故障；超时多为前置防火墙丢弃未知 qtype。
3. RFC 8657: CAA Record Extensions for Account URI and ACME Method Binding核查于 2026/10/31（200，64 601 B）：accounturi 与 validationmethods 两个参数的语义；A Property with an invalid or unrecognized "accounturi" parameter is unsatisfiable／多个 accounturi 同样不可满足；validationmethods 只在所用验证方法被列出时授权；§5.2 参数属 CA 命名空间、MUST NOT assume that the restrictions ... are effective in the absence of explicit indication；§6 说明该文档只规定推荐语义、CA 可自行选择是否采纳。