此页面由 Cloud Translation API 翻译。

网域问题排查

当 Google 公共 DNS 无法解析网域时，通常是由于该网域或其权威域名服务器存在问题。以下步骤有助于确定导致问题的原因，以便网域管理员可以自行解决问题。

在开始执行这些步骤之前，请在 dns.google 中查看域名，如常规问题排查页面中所述，此页面可能会引导您参考下面的特定诊断步骤。否则，请尝试执行以下所有步骤，直到找到原因。

第 1 步：检查 DNSSEC 验证问题

如果网域的 dns.google 网络查询显示 "Status": 2 (SERVFAIL) 且没有 DNSSEC 的查询成功，则说明域名服务器或其顶级域名 (TLD) 注册表（可能发布了用于注册网域的 DNSSEC 验证的 DS 记录）可能存在 DNSSSEC 问题。

注册商或 DNS 服务的变化

当网域从支持 DNSSEC 的注册商或 DNS 服务切换到不支持 DNSSEC 的网域后，就可能会发生 DNSSEC 问题。如果旧服务在 TLD 注册表中留下过时的 DS 记录，并且新服务不会在 TLD 注册表中创建新的 DNSKEY 记录（包含匹配的 DS 记录），则验证解析器（如 Google 公共 DNS）无法解析网域。

如果发生这种情况，请让您的域名注册商从 TLD 注册表中移除过时的 DS 记录。

DNSSEC 响应过大

导致 DNSSEC 问题的另一个原因可能是 DNSSEC 响应太大，无法容纳到一个 IP 数据包中，从而导致创建的碎片化响应可能会被丢弃。如果 DNSViz 显示“在 UDP 载荷大小减小之前未收到任何响应”错误，则可能是由 DNSSEC 失败导致的。响应大小可通过以下一项或多项操作缩减：

为权威域名服务器配置“最低限度的响应”
将活跃 DNSKEY 记录的数量减少到 2 或 3 条
使用 1280 或 2048 位 DNSKEY 记录（RFC 6781、StackExchange）
从 RSA 签名切换到较小的 ECDSA 签名 (RFC 8624)

另请查看第 2 步中的工具是否有任何其他 DNSSEC 问题。示例包括错误的 NSEC 或 NSEC3 否认存在记录，这些记录没有子网域（存储在外部数据库中的区域的 PowerDNS 可能具有这些子网域）或过期的 RRSIG 签名（手动配置的签名流程已损坏）。

第 2 步：检查权威域名服务器

如果 Google 公共 DNS（或任何开放式解析器）在解析网域时遇到问题，DNSViz 会显示导致该域名的问题和域名服务器问题。转到 DNSViz 网页，然后输入有问题的域名。如果 DNSViz 没有历史数据，或者只有一天以前的数据（如此处的页面所示），请点击较大的分析按钮在下方显示较小的“分析”按钮（如果该按钮尚不显示），然后点击该按钮。分析完成后，点击“继续”以显示结果。在左侧边栏中点击红色错误和黄色警告以显示详细信息，或将指针悬停在图中的对象上以在上下文中弹出该信息。

如果之前的诊断表明网域可能存在 DNSSEC 问题，请转到 DNSSEC 分析器网页，然后输入域名。如果此分析器报告 DNSSEC 错误或警告，请将指针悬停在红色 ⊗ 或黄色 ⚠👋? 图标上，以获取有关如何修复这些错误的建议。

intoDNS 网页会报告在主页面上输入的网域存在的非 DNSSEC 问题，并会显示解决这些问题的建议。

网域管理员应修复这些工具报告的大多数错误，因为这些错误不仅会导致 Google 公共 DNS 出现问题，还会导致其他解析器出现问题。

第 3 步：检查委托问题

Google 公共 DNS 是一种以父项为中心的解析器，它仅使用从父级网域的引荐来源返回的域名服务器。如果 TLD 中的域名服务器名称和胶水地址已过时或不正确，这可能会导致委托问题。

如果 DNSViz 或 intoDNS 报告有关 TLD 中委托的域名服务器和子网域本身中存在的域名服务器之间不一致的警告，则可能需要先解决这些问题，然后 Google 公共 DNS 才能解析该域名。如果这些工具报告注册网域 (NXDOMAIN) 不存在，请检查该网域是否已过期或因任何原因处于暂停状态。

如果解析网域的域名服务器名称失败，也可能会发生委托问题。检查 dns.google 上域名服务器的 A 和 AAAA 记录，看看域名服务器是否存在问题。

第 4 步：检查是否有大型响应

DNS 依赖 UDP 来传输其大部分流量。较大的 UDP 数据报容易碎片化，而且 UDP 碎片化的传输也会不可靠。这是 2020 年 DNS 标记日的重点，这项工作旨在提升全球 DNS 的可靠性。Google 公共 DNS 已参与了这项工作，并限制了其通过 UDP 接受的 UDP 响应的大小。使用您自己的命令提示符或 Google Cloud Shell 尝试以下查询：

$ dig +short example.com NS
ns1.example.com
ns2.example.com
$ dig +dnssec +nocrypto +bufsize=1400 +timeout=1 @ns1.example.com example.com A
...
$ dig +dnssec +nocrypto +bufsize=1400 +timeout=1 @ns1.example.com example.com TXT
...
$ dig +dnssec +nocrypto +bufsize=1400 +timeout=1 @ns1.example.com example.com DNSKEY
...
$ dig +dnssec +nocrypto +bufsize=1400 +timeout=1 @ns1.example.com com DNSKEY
...

针对各种记录类型的以下查询指定了：

+dnssec: 启用 DNSSEC，尤其是在 DNSSEC 验证需要的情况下返回所需的记录。它们会大幅增加结果的大小。这会模拟 Google 公共 DNS 的行为。
+bufsize=1400: 限制允许的 UDP 缓冲区空间。这模拟了 2020 年 DNS 标记日期间 Google 公共 DNS 的行为。
+timeout=1: 将超时时间设为 1 秒。这会模拟 Google 公共 DNS 的行为。
@ns1.example.com: 要查询哪个权威服务器 - 请保留 @ 符号，但将其替换为您自己的网域的权威服务器，如第一个命令所示。

观察输出结果；您会看到如下一行代码：

;; Truncated, retrying in TCP mode.: 这表示响应大于所请求的 UDP 缓冲区空间大小，因此响应被截断，客户端改用 TCP 进行响应。您的权威服务器应该能够处理 TCP 端口 53 上的 DNS 流量。（请参阅要求实现实现必须同时支持 UDP 和 TCP 传输的 RFC 7766。）
;; MSG SIZE rcvd: 2198: 如果有超过 1400 个手机号码，这再次表明响应较大。
;; Query time: 727 msec: 如果有超过 500 个数字，响应速度慢（尤其是响应时间接近或超过 1 秒的响应）可能会被 Google 公共 DNS 舍弃。这在一些时间使用 UDP 尝试（之后是 TCP 尝试）的情况下尤其有用。服务器和客户端的地理位置可能会极大地影响延迟时间。
;; connection timed out; no servers could be reached: 尤其是在执行某些查询时，这表明服务器无法及时响应 DNS 查询。

您可以尝试以下查询变体：

添加 +tcp 参数。: 这会强制 dig 立即使用 TCP，您可以检查权威服务器是否以这种方式直接处理 TCP 查询。
移除 +bufsize=1400 参数。: 这会恢复dig的默认行为（气泡 4096）。如果您的查询在此设置下运行失败，但停用此设置，则表示您的服务器无法正确处理 TCP 故障切换。依靠 UDP 传输大型响应有时只有在时候才能起作用。最佳做法是为 DNS 支持 TCP 传输。
在每个域名服务器上重复此操作。: 上面的示例有两个权威域名服务器（ns1 和 ns2）。某些问题由不同的服务器返回不同的答案导致。在所有权威服务器上重复相同的查询，检查它们是否能够一致地响应。

如果所有查询都较小（不超过 1400 字节）、快速（最好为 500 毫秒或更快）且可靠（可通过 TCP 和 UDP 运行），则无需担心响应大小；请阅读其他问题排查部分。即使响应速度较快，来自地理位置很远的查询也可能会更慢。

如果其中任何一项检查失败（较大、速度慢、不可靠），主要措施是：A) 确保您的服务器在响应超出所请求的 UDP 缓冲区大小和 B 时进行响应，这样 B 可以处理后续的 TCP 查询重试。以下工具可帮助您诊断 DNS 可靠性问题：

DNSViz
DNSSEC 调试程序
EDNS 合规性测试工具
DNS 检查工具 - 请务必取消选中“CD”（停用 DNSSEC 复选框）

如果这些工具发现任何错误或警告，请务必解决这些问题。另外，请务必阅读本网站上的所有其他问题排查说明。

第 5 步：检查其他公共解析器是否解析该域名

如果您在执行上述步骤后没有找到任何问题的原因，请在命令提示符下运行以下命令，将 example.test. 替换为相关网域（并保留结尾的点）：

Windows

nslookup example.test. resolver1.opendns.com.
nslookup example.test. dns.quad9.net.
nslookup example.test. one.one.one.one.

macOS 或 Linux

dig example.test. '@resolver1.opendns.com.'
dig example.test. '@dns.quad9.net.'
dig example.test. '@one.one.one.one.'

这些命令使用 OpenDNS、Quad9 和 Cloudflare 1.1.1.1 的 DNS 解析器。如果其中两个地址以及 Google 公共 DNS 都出现了解析失败的问题，则问题可能出自网域或其域名服务器。

如果您从多个公共解析器获得成功的结果，则表示 Google 公共 DNS 可能存在问题。如果问题跟踪器上未报告相应网域（或其 TLD）存在类似问题，您应该向我们报告此问题，包括报告中的命令输出和诊断页面文本或屏幕截图。