东京节点解析验签缺口：我用 unbound 给公网和内网解析分了流

前几天我给东京那台主力节点做了一次体检，查出来一个平时完全感觉不到的缺口：这台机器解析域名的时候，根本不验证 DNS 签名。也就是说，不管域名带的签名是好的、坏的、过期的还是压根没有，它一律放行。平时上网一切正常，就是因为这个缺口藏得太深，不专门测根本发现不了。这篇就记一下我是怎么发现、怎么确认、最后怎么修的。

先说是怎么发现的。我拿 dnscheck.tools 的测试域名做了几组对照：有效签名的三个样本都能正常访问，这本该如此；但坏签名、过期签名、缺失签名九个样本，居然也全部返回成功。这就很不对了，验签要是真开着，这九个里一个都不该通过。为了排除是我测试方法的问题，我又用同一个连接去走了 1.1.1.1 和 8.8.8.8 的加密解析，六个无效签名对照全被拒绝了。两边一对比，问题就定位清楚了：不是测试方法不对，是这台节点自己的解析路径没有验签。

接下来是查根因。代理本身没有配 DNS，走的是系统解析：系统解析器指向云厂商内网的上游，而那个上游是不做 DNSSEC 验证的，机器上也没有任何信任锚。链条捋下来就明白了，解析请求从机器出去，到内网上一路都是明文且不验签，坏签名自然畅通无阻。知道这一点之后，我先做了两个小试验来验证判断，而且都特意控制在不影响现有连接的前提下做，做完立刻回滚。

第一个试验是只给内网解析开验签。结果有效签名直接 SERVFAIL，也就是 fail closed：没有信任锚，验签机器宁可拒绝也不放行。这个结果其实是个好信号，说明验签逻辑本身是严的，缺的只是锚点和上游。但单改这一处没法上线，因为内网域名还得靠内网解析认，验签上游不认内网名。

第二个试验是把上游切到 8.8.8.8 和 9.9.9.9 再开验签。结果很干净：好签名通过还带 AD 标志，坏签名全被拒，加密通道的证书校验也正常。但内网名直接 NXDOMAIN，云内网的域名解析断了。两个试验合起来，结论就一个：单一解析器没法两头兼顾，必须分流，公网走严格验签的上游，内网继续走云内网。

最后的方案是新起一个 unbound，只监听回环地址，不碰代理本身。公网查询走 DoT 加密上游，证书身份校验开着，严格验签，客户端发来的不校验标记也绕不过去；内网只给实际需要的两个私有后缀开了例外，其他一律不放宽。接入之前，我先在未接入生产的本地端口上把验证矩阵跑全：三个好签名全部通过且带 AD，九个坏签名全部被拒，带不校验标记的坏签名照样被拒，内网名解析正常，常用域名也不受影响。验证全过之后，才把系统解析切到 unbound，整个过程服务器没重启、代理没重启也没重载、长连接一条没断。持久化也写了 netplan 的改动和护栏文件，但特意没有当场应用、没有重启网络来演练，运行时改动管现在，文件管下次开机。回退办法也留好了，指回原来的内网解析、停掉 unbound 就行。

这次折腾下来，有几个体会值得记下来。第一，配置里写了“验签”不等于真验签，一定要拿坏签名实测，好的坏的都测一遍才算数。第二，fail closed 是优点不是故障，坏签名被拒、偶尔首查超时但重试同样被拒，都是“宁可不答也不给坏答案”，这恰恰是验签在起作用。第三，生产环境别为了验证就重启，先在不用的本地端口上验完再接入，验证和接入分两步走，风险小得多。第四，分流的时候例外越少越好，只给真正需要的私有后缀开例外，别图省事搞全局放宽，不然分流就白做了。

如果你手里也有海外小机器，不妨也拿 dnscheck.tools 那几组测试域名跑一遍：好签名能过是应该的，坏签名、过期签名、缺失签名要是也全过了，那就是解析链上缺了验签，值得花一个晚上按上面这个思路查一遍。平时感觉不到的缺口，往往就是最该补的那种。