dnsmasq 丢弃私有 DNS 应答：是重绑定保护吗？

公司的 DNS 服务器返回了预期的私有地址，但经由本地转发解析器的查询仍然失败。应答确实存在，这就排除了上游区域和记录本身。剩下的环节是解析器决定是否把该应答交回客户端。如果那个解析器是 dnsmasq，拒绝很可能已经写进日志了。

收到应答与决定返回应答是两个不同的步骤。

在两个解析器上比较同名查询

记下应用实际使用哪个解析器，以及它查询的确切主机名。然后把上游结果与转发解析器针对同一名字的事件作比较。上游没有响应、缓存中的否定应答、日志中的拒绝，三者需要三种不同的处理。

直接诊断查询里看到的地址，并不能证明应用是通过它平时的路径拿到该地址的。两次查询可能出自不同的解析器，也可能出自同一解析器但套用不同策略。在推测之前先把两个结果都写下来，因为这一步正是人们用其中一个替代另一个的地方。比较本身就是全部诊断。

读拒绝，而不是读症状

dnsmasq 的 stop-dns-rebind 选项会拒绝来自上游且符合条件的私有地址应答，并在拒绝时记录日志。这项保护有其正当理由：一个公网名字突然解析到私有地址，正是经典的重绑定攻击。但它也会与刻意私有部署的服务相撞，而你的情况就是后者。

在改动任何东西之前，先在日志里找到拒绝记录，因为消息会点明机制。

如果既没有拒绝也没有上游应答，那么重绑定保护不是你的问题，关掉它只会是一次什么都修不好、反而扩大暴露面的改动。这比原来的故障更糟，因为它移走了一道控制，却把毛病留在原地。先确认那行具体的日志。然后再决定。

把例外收窄到一个域名

对于已核实的域名，dnsmasq 手册提供的是限定到域名的例外，而不是全局开关。

rebind-domain-ok=corp.example

上面这个域名只是示例。请使用你实际管理的管理域名，并在套用前弄清该选项的匹配范围，因为后缀规则覆盖的范围不止你测过的那一台主机。路由器的配置生成器可能通过自己的控件提供同样的设置，而不是让你写原始指令。两条路都可以，只要最终的适用范围是你想要的。

针对重绑定检测的例外只做一件事：放行该域名的应答。

它并不配置 split-DNS 转发器，也不会让不可达的上游变得可达，更不会为返回的地址创建路由。这些各自是独立的需求，各有各的故障特征，在客户端上的表现也各不相同。

在不拆掉边界的前提下验证

再经转发路径查询该主机名，然后按服务平时的身份校验去连接它。DNS 例外不是接受意外证书的理由，而当两者都表现为浏览器报错时，很容易混淆。把名字和服务分开测。其中只有一个曾经是 DNS 问题。

把例外的理由放在配置旁边，写上日期和责任人。

当私有服务迁移或域名变更时重新检查。全局关闭保护会改变无关应答的处理方式，而且如果重绑定从来就不是原因，它照样会把路由或服务故障留在原地。