# DNS problem: SERVFAIL looking up CAA：Certbot 报错怎么解决

> Let's Encrypt 查询 CAA 记录时拿到 SERVFAIL，于是拒绝签发。多数是 DNSSEC 配置坏了、权威 DNS 不认 CAA 查询或者 DNS 故障，附 dig 排查命令。

Source: https://ssl.sh/zh/errors/certbot-dns-problem-servfail-caa/
Last updated: 2026-11-10

**“DNS problem: SERVFAIL looking up CAA” 的意思是：Let's Encrypt 查询你域名的 CAA 记录时没有得到答案，于是拒绝签发。** 签发证书之前，CA 必须检查 CAA 记录是否允许它签发。Let's Encrypt 的解析器去查 CAA，拿到的是 SERVFAIL（DNS 服务器故障），而不是记录列表或“没有记录”的空应答。Let's Encrypt 文档说，这最常见的原因是 DNSSEC 验证失败；其次是权威 DNS 处理不了 CAA 查询。

## 报错原文和几种变体

这段报错由 Let's Encrypt 生成，各客户端只是转述，核心都是“SERVFAIL looking up CAA”。Certbot 会原样打印 CA 返回的错误：

```text
Detail: While processing CAA for example.com: DNS problem: SERVFAIL looking up CAA for
example.com - the domain's nameservers may be malfunctioning
```

“for”后面的名字可能是上级域名（申请 `www.example.com` 时 CA 也会查 `example.com`），也可能是 CNAME 的目标。如果解析器返回了扩展 DNS 错误码，Let's Encrypt 的提示会变成另一种写法，比如 `DNS problem: looking up CAA for example.com: DNSSEC: Bogus`，直接指向 DNSSEC。解析器内部的一些故障会显示为 `DNS problem: server failure at resolver looking up CAA for example.com`。这段文字由 Let's Encrypt 服务器生成，Certbot、acme.sh、win-acme 等客户端只是转述，所以用哪个客户端看到的都一样。

## CAA 是怎么查的

RFC 8659 规定，查找 CAA 记录集时从申请的域名开始沿 DNS 名称树“往上爬”，直到找到为止（不包括根）。申请 `shop.www.example.com` 时，CA 依次查询 `shop.www.example.com`、`www.example.com`、`example.com`。Let's Encrypt 文档还说明，CAA 检查和其他 DNS 查询一样会跟随 CNAME。这条路径上任何一处返回 SERVFAIL，签发都会停下。

另外，如果域名是 7 小时之前验证的，Let's Encrypt 会在最终签发时重新检查一次 CAA，所以已缓存的验证结果也挡不住这个错误。

## 常见原因（按出现频率排序）

CAA 查询返回 SERVFAIL，最常见的原因是 DNSSEC 配置坏了，其次是权威 DNS 拒绝 CAA 类型的查询。

### 1. DNSSEC 配置坏了

最典型的场景：把域名的 DNS 从注册商默认解析迁到 DNSPod、阿里云云解析或 Cloudflare 后，注册商那里还留着旧的 DS 记录，和新服务商的密钥对不上；其他情况还有签名过期、签名程序在空应答上出错。RFC 8659 提到，至少有两款实时签名的权威 DNS 软件在返回签名的空 CAA 应答时有缺陷。检查方法：

```bash
dig CAA example.com +dnssec @1.1.1.1
dig CAA example.com +cd @1.1.1.1
```

不加 `+cd` 返回 SERVFAIL、加了 `+cd`（关闭验证）能拿到结果，就是 DNSSEC 验证失败。`1.1.1.1` 访问不了的，换成你能用的其他做 DNSSEC 验证的公共 DNS。Let's Encrypt 建议第一步用 [DNSViz](https://dnsviz.net/) 把整条信任链画出来看。

### 2. 权威 DNS 拒绝 CAA 查询

有些权威 DNS 遇到不认识的记录类型会回 NOTIMP 或 REFUSED。Let's Encrypt 指出这违反了 RFC 1035，正确的做法是返回 NOERROR 和空应答。直接问每一台权威 DNS：

```bash
dig NS example.com +short
dig CAA example.com @ns1.example-dns.net +norecurse
```

### 3. 防火墙或防 DDoS 设备丢弃查询

RFC 8659 描述了这种中间设备：它们会丢弃未知类型的 DNS 包，尤其是在认为自己正遭受攻击的时候。结果表现为超时或 SERVFAIL，而且常常时好时坏。

### 4. 子域委派到了内网或失效的 DNS

某个子域的 NS 记录指向内网 IP，或者指向已经不再托管这个区域的服务器（失效委派）。RFC 8659 说明 CA 在这种情况下会收到 SERVFAIL。用 `dig NS sub.example.com` 看委派，再逐台查询。

### 5. CNAME 目标的 DNS 有问题

`www.example.com` 用 CNAME 指向某个 CDN 或 SaaS 的域名，而对方的权威 DNS 处理不好 CAA 查询。这要由对方修复，或者你把 CNAME 改掉。

### 6. 临时故障

权威 DNS 宕机或过载。稍后重试，看看 DNS 服务商有没有故障公告。

## 怎么修

修法按原因区分：DNSSEC 问题在注册商处修 DS 记录，其他问题要让对应的 DNS 服务器正常回答 CAA 查询。

- **DNSSEC：** 到注册商那里把 DS 记录改成和当前 DNSKEY 匹配；如果区域已经不再签名，就把 DS 删掉。等旧 DS 记录的 TTL 过期再重试。
- **NOTIMP 或 REFUSED：** 让 DNS 服务商修复 CAA 查询的处理，或者把域名迁到正确支持 CAA 的服务商。
- **委派问题：** 删除或修正指向内网、已下线服务器的 NS 记录。
- **CNAME 目标：** 反馈给对应服务商，或者把这个名字指向别处。
- **临时故障：** 间隔一段时间再试，避免连续失败触发 [频率限制](https://ssl.sh/zh/errors/lets-encrypt-rate-limit/)。

查询恢复正常之后，用 [CAA 检测](https://ssl.sh/zh/tools/caa-checker/) 看看现有策略允许哪些 CA，用 [CAA 记录生成器](https://ssl.sh/zh/tools/caa-generator/) 生成记录。原理见 [CAA 记录详解](https://ssl.sh/zh/learn/caa-records/)。用 acme.sh 的话，其他验证类报错可以看 [acme.sh 验证报错](https://ssl.sh/zh/errors/acme-sh-verify-error/)。

## 迁移 DNS 服务商时怎么避免 SERVFAIL

DNSSEC 导致的 SERVFAIL 大多出在“换 DNS”这一步。稳妥的顺序是先删 DS、再改 NS、最后重新开启 DNSSEC：

1. **迁移前**，如果旧服务商开着 DNSSEC，先到注册商那里删除 DS 记录，等原 DS 记录的 TTL 过去（通常一两天）。
2. **迁移时**，在新服务商把所有记录配好，再到注册商修改 NS。
3. **迁移后**，确认解析稳定了，再在新服务商开启 DNSSEC，把新服务商给出的 DS 记录填回注册商。

反过来做，或者干脆忘了删旧的 DS，在一段时间内所有做 DNSSEC 验证的解析器都会对你的域名返回 SERVFAIL。网站访问可能因为部分用户的解析器不做验证而“看起来正常”，但 Let's Encrypt 一定会查出来。不确定域名有没有开 DNSSEC，用 `dig DS example.com +short` 查一下，有输出就说明注册商那里登记了 DS。

## 怎么确认已经修好

申请的域名、各级上级域名和 CNAME 目标的 CAA 查询都返回 NOERROR，`--dry-run` 也能走通，问题就解决了。

1. 对申请的域名、每一级上级域名和 CNAME 目标，`dig CAA example.com @1.1.1.1` 和 `dig CAA example.com @8.8.8.8` 都返回 `status: NOERROR`（有没有记录都行）。
2. DNSViz 对这个区域不再显示错误。
3. `sudo certbot renew --dry-run`（或 `certonly --dry-run`）在测试环境下能走通。