换 DNS 仍打不开网站？SERVFAIL、NXDOMAIN 与 DNSSEC 排查

网站打不开时，先记录 DNS 查询的完整状态，再决定是否更换节点或解析器。**SERVFAIL 不等于域名不存在，也不自动证明机场线路失效；如果同一解析器正常查询失败、要求跳过 DNSSEC 校验后却返回记录，就应进一步检查签名与信任链。**这是一组诊断线索，不能把未校验的答案直接当成安全修复。

作者：小仓｜资料核对日期：2026-10-11

先区分四种查询结果

浏览器的“找不到 IP”提示没有展示全部 DNS 过程。排障时应保留查询的域名、类型、解析器和返回状态，而不是只截图错误页面。

结果	能说明什么	下一步
SERVFAIL	解析服务器未能完成查询	看扩展错误，再检查校验与上游
NXDOMAIN	响应表示所查名称不存在	核对拼写、子域名和域名状态
NOERROR，但没有所需记录	查询未报错，不等于有目标 IP	核对 A、AAAA 等记录类型
超时，没有响应	没有收到可用 DNS 回复	先查解析器可达性与查询路径

SERVFAIL 与名称错误是不同的响应码，定义见 RFC 1035 第 4.1.1 节。查询超时甚至还没有拿到这些响应码，因此不应一上来就判定 DNSSEC 损坏。

第一步：固定实际使用的解析路径

先把问题写具体：哪个完整域名、哪个应用、开不开 VPN、查询 A 还是 AAAA。不要把 example.net、www.example.net 和某个 API 子域名当成同一个目标。

代理客户端可能自己解析域名，浏览器也可能使用安全 DNS。对公共解析器执行一条命令，不代表浏览器正在使用它。已有的 DNS 与 Fake-IP 排查 和 浏览器安全 DNS 排查 可以帮助核对这一层。

建议先保留原设置，用同一个工具重复一次原查询。记录中的解析器地址应与实际测试一致；测试前后同时更换节点、DNS 和浏览器，会让结果失去比较价值。

第二步：只改变 DNSSEC 检查标志

下面适用于已经安装 dig 的环境。www.example.net. 是占位名称，必须替换为出问题的完整域名；1.1.1.1 只是演示解析器，实际应先测试你使用且可达的解析器。

dig @1.1.1.1 www.example.net. A +dnssec
dig @1.1.1.1 www.example.net. A +dnssec +cdflag

第一条请求附带 DNSSEC 记录；第二条额外设置 CD 标志，请求该服务器不执行 DNSSEC 校验。+dnssec 本身不会让 dig 完成一套本地信任链验证，也不保证每个域名都已签名。这些参数的含义见 BIND 的 dig 手册。

Windows 用户如果借助 WSL 执行命令，记录中要注明测试环境。WSL 的网络与代理接入方式可能和 Windows 浏览器不同；一边成功、另一边失败时，需要先核对两边的路径，可参考 WSL2 网络与代理排查。不要把子系统的查询结果直接当成 Windows 应用的实测。

保留完整输出中的 status、flags、SERVER、回答和扩展错误，不要只用 +short 后看到一行地址就结束。若故障涉及 IPv6，再把两条中的 A 都改为 AAAA，维持相同的对照条件。

怎样解释两次结果

• 正常查询是 SERVFAIL，CD 查询返回预期记录：支持“校验环节存在问题”的判断，继续查信任链。
• 两次都是 SERVFAIL：这组结果未把问题定位到校验环节，还要看权威服务器和网络错误。
• 两次都超时：先处理 DNS 查询通道，不要用超时推断签名错误。
• 两次都有记录：这次查询没有重现校验失败，应回到实际应用的解析路径。

BIND DNSSEC 指南 使用 CD 查询区分校验故障，也明确提醒不要因为少数域名失败而长期关闭校验。上述测试不会改你的系统 DNS 设置；拿到地址后也不建议写入 hosts 绕过后续检查。

第三步：找扩展错误和信任链线索

较新的工具与支持该功能的解析器可能在 OPT PSEUDOSECTION 显示 EDE，即扩展 DNS 错误。它能补充 SERVFAIL 的原因，但并非每个响应都有。

EDE 线索	优先交给谁核对
DNSSEC Bogus	域名或解析器管理员检查校验链
Signature Expired	域名管理员检查签名续期与有效期
DNSKEY Missing	核对父区 DS 与子区 DNSKEY 是否匹配
No Reachable Authority	检查权威 DNS 的可达性和委派

这些错误的含义可查 RFC 8914。EDE 是故障补充信息，不是网站内容安全的证明；分享输出前也要检查是否含有内部域名等信息。

如果域名最近迁移 DNS 服务，旧的 DS 与新的密钥不匹配是一项具体检查方向。Cloudflare 的 DNSSEC 排障说明 解释了这类迁移问题。访问者通常无法修复目标域名的注册商或权威 DNS 配置，应把查询记录交给站方，而不是自行永久关闭校验。

第四步：比较解析器，但保留结论边界

在保持域名、记录类型和网络不变的前提下，再测试另一台可达的校验解析器。多个解析器都失败，可以把注意力转向域名与权威服务器；只有一个失败，则还要调查它的缓存、上游或网络条件。Google Public DNS 的域名排障文档 提供了这类比较方法。

另一台解析器成功不等于原问题已被修好，它可能使用不同缓存或校验策略。若只在浏览器失败，应检查应用路径；若只有旧结果持续出现，可继续看 DNS 缓存与 TTL 排查。

给站方的可填写记录

查询时间与时区：
完整域名、记录类型：
应用与 VPN 状态：
解析器地址：
正常查询状态、EDE：
CD 查询状态、EDE：
另一解析器的对照结果：
最近是否迁移 DNS 服务（站方填写）：

本文提供的是诊断顺序，没有对某个节点做实测。能复现的查询记录，比“换了 DNS 还是不行”更容易让管理员判断故障属于应用、解析器还是域名签名配置。