起因

上个月， 有个同事提到，有用户反应 我们的内网服务域名 goofy.app 及其子域名在新加坡办公室无法访问，但是我从新加坡的家里用企业虚拟专用网络（办公 VPN）一直可以访问，其他中国区办公室的同学表示也都可以访问。

排查

回到新加坡的办公室后，我开始排查问题，随便挑了一个 https://foo.goofy.app/ 测试， 确实打不开：

$> curl https://foo.goofy.app/ curl: (6) Could not resolve host: foo.goofy.app

直接看到的问题是，foo.goofy.app 的 DNS 无法解析。那直接用 IP 访问网络通不通呢？

➜ ~ curl -i 10.*.*.* -H "host: foo.goofy.app" HTTP/1.1 200 OK Server: nginx Date: Tue, 31 Aug 2021 10:39:20 GMT Content-Type: text/html; charset=utf-8 ...

是可以的，那么在稍稍做了一些尝试之后，目前知道的情况是：

• ✅ 中国办公网可以访问

• ✅ 新加坡办公 VPN 可以访问

• ❌ 新加坡办公室不可以访问

• ✅ 网络层链路通

• ❌ DNS 无法解析

• ❌ 新加坡公网不可以访问

• ❌ 网络层链路不通（服务使用内网 IP，符合预期）

• ❌ DNS 无法解析

非常明显，如果新加坡办公室 DNS 可以正确解析域名，理论上网站就可以正常打开。那我们就从 DNS 入手。

猜想 0：内网 DNS 配置有误

既然这个域名指向的都是内网服务，是不是这个域名在内网的解析配置有错误呢？询问这个域名的管理员后发现，其实这个域名并不是内网域名，在公网就可以解析，只不过都是指向的内网地址。这里我们找一个在线 DNS 测试站点解析一下 A 记录：https://ping.sx/dig?t=foo.goofy.app

从 ping.sx 的全球各个第三方测试节点返回的结果表明，foo.goofy.app 确实是可以在公网解析的，不过也是只有中国大陆可以解析。

小知识：在很多情况下，内网域名不需要在公网解析，此时为了安全与速度，很可能会在内网 DNS 中直接返回解析结果，而不需要查询上游公网 DNS。

猜想 1：GeoDNS

那么，是不是 DNS 平台通过 GeoDNS 配置使得 DNS 只能在中国大陆解析呢？问了一下 DNS 的负责同学，并没有开启相关的设置。实际上用 EDNS Subnet 也可以验证这一点：（随便假装了个在中国大陆的 IP 段）

➜ ~ dig foo.goofy.app @8.8.8.8 +subnet=114.114.114.0/24 +short (空结果)

小知识：GeoDNS 是一种 DNS 扩展，可以使得 DNS 服务器根据用户所在的不同区域解析出不同的结果。它通过 EDNS（Extension Mechanisms for DNS） 实现。

猜想 2：跨境链路问题

托管在中国大陆境内的域名不能在境外解析，可不可能是跨境网络抖动呢？让我们 dig + trace 一下看看再说。

trace 可以一路 trace 到 CNAME 再试试 dig 一下 NS：

中国区以外也是空的，看样子是这些 DNS 不约而同地在从.app查goofy.app的 NS 时候就掉链子了。可是.app的 NSns-tld1.charlestonroadregistry.com不在中国大陆，并没有跨境，所以应该不是这个原因。

小知识：dig命令除了常规解析域名的用法外，还可以通过+trace选项使它在本地完整执行 DNS 迭代查询并输出日志，以便排查问题

小知识：域名的NS记录代表 Name Server，它指向的是托管这个域名子域名的服务器地址。比如:dig bytedance.com ns +short的返回值为：vip4.alidns.com.``vip3.alidns.com.说明如果要查询bytedance.com的子域名，请联系vip4.alidns.com或者vip3.alidns.com

猜想 3：.app TLD NS 故障

运维同学表示可能是.appTLD 的 NS 坏了，不过我随便找了个 get.app 域名测试没有问题（那是当然的了）：

➜ ~ dig get.app ns @8.8.8.8 +short ns4.zdns.google. ns1.zdns.google. ns3.zdns.google. ns2.zdns.google.

小知识：TLD 指 Top Level Domain，顶级域。比如常见的.com,.cn,.net都是顶级域。在 DNS 查询中，终究会迭代查询到顶级域的 NS 服务器。如果它故障了，会导致这个顶级域下的几乎所有域名大规模无法解析。

猜想 4：DNSSEC 配置错误

此时问题似乎陷入僵局，有没有什么情况下，可能导致部分用户解析结果为空呢？有。如果对 DNS 比较熟悉的同学可能听说过 DNSSEC，这是一个用于保证 DNS 解析不被劫持的安全扩展。如果 DNSSEC 的配置出错，可能会导致解析结果被认作无效并丢弃，就像 HTTPS 的证书配置有误会导致网站无法打开一样。我们去在线 Google DNS 解析一下试试，这里解析可以给出比较详细的解析结果：https://dns.google/query?name=goofy.app&rr_type=A

这里错误就很明显了，DNSSEC validation failure，DNSSEC 验证失败。关掉 DNSSEC 验证后，可以正确解析:

点开解析失败结果中的链接，可以看到更详细的解析过程：

https://dnsviz.net/d/goofy.app/dnssec/

可以看到这里 DNSSEC 有报错。

https://dnssec-analyzer.verisignlabs.com/goofy.app 的结果也类似。

问题解决

DNS 运维同学帮忙看了一下 DNS 管理后台，里面有一个不知道哪里来的 sha256 的 key，删除后问题解决

All Green！

复盘分析

发生了啥？

• 一句话解释：DNSSEC 配置错误导致全球大部分 DNS 服务器都丢弃了解析结果，解析失败。

那为什么之前只在中国大陆能解析，而境外 DNS 全军覆没？

• 因为中国大陆 DNS 服务器绝大多数都关闭了 DNSSEC 校验

• 即使 DNSSEC 配置歪了，只要不校验就不会丢弃结果

• 这是一个不幸的巧合，负负得正

• 而海外 DNS 基本上都默认开启了 DNSSEC 校验，所以国际（几乎）清一色解析失败

• 少数海外 DNS 没开 DNSSEC 校验，所以恰巧能解析

那具体是哪里配坏了？

域名的DS记录中配置了一条错误的 Hashed KSK（SHA-256 key），导致 DNSSEC 信任链被破坏。这条错误的记录可能是在我们把域名从最开始的托管方 get.app 处迁移到目前 DNS 时候一并迁移过来的。而删除这条DS记录等同于告诉下游 resolver 这个域名不需要 DNSSEC 校验，所以删了就好了。

小知识：DNS 的 DS 记录（Delegation Signer） 是 DNSSEC 信任链的一部分，用于把每一层域名的 NS 串联起来（与 HTTPS 证书链原理类似）

排查过程能否更有效？

可以：

1. 一开始就可以用 https://dns.google 测试，可以直接发现问题
2. 其实 dig 命令中一开始就返回了 SERVFAIL。而根据 DNSSEC 的标准，这就是 DNSSEC 验证失败的返回值。

有没有考虑过其他修复方案？

有：

• 尝试本地编辑 hosts 文件

• 治标不治本，而且*.goofy.app 多如牛毛，不可能全加上

• 在纯内网 DNS 解析

• 运维同学表示.app 是一个新的顶级域，需要单独支持，代价太大

• 开启 DNSSEC 并正确配置

• 理论上可行，但是由于 DNS 递归请求到 .app 的 NS 需要跨境，要是签名过的请求被干扰则小概率导致解析失败。

• 先跑起来再说