CAA 记录应授权你实际使用的签发者

Sun, 23 Aug 2026 00:00:00 +0000

认证机构授权（CAA）记录让域名持有者声明，哪些证书颁发机构可以为该域名签发证书。只有当记录与真实续期路径一致、且操作者理解策略如何从父级名称继承时，它才有用。

检视当前策略

查询确切主机名及其父名称：

for name in www.example.test example.test test; do
 printf '== %s\n' "$name"
 dig +noall +answer CAA "$name"
done

叶子处空的应答不一定意味着没有适用策略。根据 DNS 规则，CAA 处理可能继续向上。诊断变更时使用权威应答，并与至少一个递归解析器比较。

记录使用如 issue 或 issuewild 等标签与一个签发者域值：

example.test. 3600 IN CAA 0 issue "letsencrypt.org"

该值是授权标识，不是证书里的显示名。在证书颁发机构的当前文档中确认它。通配符授权可能需要单独的 issuewild 策略。

在当前证书健康时添加或收紧 CAA。从整上一个 TTL 等待，查询权威与递归应答，并运行 ACME 客户端支持的暂存或续期测试。准备好回滚记录。

不要在过期事故期间添加限制性记录，除非签发者路径已验证。一条语法正确但错误的策略，会把自动续期变成硬失败。

CAA 检查发生在签发时，而不是每次 HTTPS 请求。因此证书监控必须同时覆盖当前过期与续期尝试。把有效的 DNS 应答随 ACME 失败一起记录，而不是只记录一条笼统的授权错误。

RFC 8659 — DNS Certification Authority Authorization，CAA 查询与属性语义，已核验 2026-08-23。
Let’s Encrypt: CAA，签发者标识与运维指引，已核验 2026-08-23。

Sat, 22 Aug 2026 00:00:00 +0000

改一条地址记录很容易，预测每个解析器何时停止使用旧应答却很难。时间到活性（TTL）值随 DNS 响应传播，并控制缓存可复用的时长。在迁移那一刻降低 TTL，并不能改写更早被缓存下来的应答。

如果既有记录是一天的 TTL，至少要在计划切换前一个旧 TTL 时就把它降低。这样在旧端点仍然权威时，缓存有时间去取较短的值。确切间隔应写进变更计划，而不是在迁移中即兴执行。

记录来自权威服务器与至少一个递归解析器的应答：

dig +noall +answer www.example.test A
dig @1.1.1.1 +noall +answer www.example.test A

递归解析器显示的剩余 TTL 是它当前缓存状态的证据。不同解析器合理地显示不同的剩余值。

切换期间，保持旧端点与新端点都能为预期主机名提供服务。TLS 名称、重定向与应用配置在两侧必须一致。权威记录改变后立刻移除旧端点，会给仍持有先前应答的客户端造成本可避免的停机。

否定应答也会被缓存。一个最近返回 NXDOMAIN 的名字，其出现可能很慢才可见，因为根据区域的权威数据，否定响应可能仍留在递归缓存里。

一旦权威与具有代表性的递归应答都指向新端点，且旧缓存窗口已过，就恢复正常 TTL。在变更记录中保留旧值、新值、权威应答与回滚条件。