HTTP 验证文件可访问，证书仍失败：检查 CAA 查询的 SERVFAIL

ACME HTTP-01 挑战文件能返回 200，申请证书却报 DNS problem: SERVFAIL looking up CAA。这时失败信息指向 DNS 的 CAA 查询：Web 服务能提供文件，并不表示 CA 已完成所有签发检查。

CAA 用于限制哪些 CA 可以签发域名证书。没有设置 CAA，和查询 CAA 失败，是两回事。Let’s Encrypt 可以处理正常返回“没有这种记录”的查询；查询出错时，却不能据此判断域名允许签发。

按报错里的名称查询，不只检查 A 记录

下面是供读者使用的 DNS 查询示例，域名与服务器名称需替换为实际值：

dig example.com CAA
dig example.com NS
dig @ns1.example.net example.com CAA +norecurse

第一条查看当前递归解析器的结果，第二条辅助识别域名使用的权威服务器。第三条直接向其中一台权威服务器查询；应逐个检查实际委派的服务器，并留意响应是否具有权威性。子域名没有单独委派时，需要使用它所在区域的服务器，不能把空的 NS 回答当成没有 DNS 服务。

重点看 status、Answer、Authority 和是否超时，不要只看有没有一行 CAA：

NOERROR 且没有 CAA 回答，可能是该名称没有 CAA 数据；这不是 SERVFAIL。CAA 还可能从父名称或 CNAME 目标取得，仍需确认完整适用范围。
权威查询本身返回 SERVFAIL、NOTIMP，或者一直超时，应先处理该服务器的查询行为或可达性。
权威服务器正常，而验证型递归解析器报 SERVFAIL，需要查 DNSSEC 验证及否定回答的签名，不能立即认定 CA 的缓存坏了。

多个权威服务器结果不一致时，不能用其中一台正常作为全部恢复的证明。证书验证可能命中仍然错误的服务器。

有些旧 DNS 实现或前置防火墙对不认识的记录类型直接报错或丢弃。若服务器针对 CAA 查询异常，而 A、AAAA 查询正常，就应把这组差异交给 DNS 服务管理员核对。仅能添加 A 记录，不代表服务器可以拒绝其他类型的合法 DNS 查询。

确认没有 DNSSEC 配置时，也仍要检查权威服务是否把未知类型当成未实现操作。适当的无数据回答不应是 NOTIMP。调整 DNS 软件或过滤规则前保存配置，按服务流程验证并部署；不要仅为签发一张证书关闭所有 DNS 防护。

有 DNSSEC 时，否定回答也需要正确的验证链。即使 A 记录能验证，空的 CAA 回答仍可能触发签名相关问题。应修复签名、委派或服务状态，而不是把关闭验证作为续期方案。

如果只是想明确允许 Let’s Encrypt，区域文件中的简单记录示例为：

example.com. IN CAA 0 issue "letsencrypt.org"

这是授权策略变更，不是通用 SERVFAIL 修复命令。修改前核对现有 issue、issuewild、账户和验证方式限制，以及其他服务正在使用的 CA；不能把原有策略直接覆盖成单条记录。存在 CNAME 的名称也不能同时添加普通 CAA 数据。

DNS 变更前保留区域配置和授权策略，检查后再按管理流程同步；回退需恢复原策略，并考虑缓存中的旧答案不会立即消失。恢复标准是各权威服务器对有关名称的 CAA 查询正常，递归验证结果也一致，随后证书申请或续期成功。先在测试环境核对，避免不断重跑生产申请；签发成功后仍需确认服务加载了预期的新证书。