dnsmasq 中的 VPN 域名不是区域传送

你在客户端的 dnsmasq 配置里查找公司区域，没找到，于是断定 VPN 没有推送它的域名。被推送的是一条路由提示，而不是区域。客户端记录域名以及应当为它应答的解析器，由被管理的后端把它变成条件转发。看错地方会得出一个笃定却完全错误的诊断。

客户端接受的东西并不是网关提供的东西

网关可以提供解析器、域名以及到达该解析器所需的路由，而客户端可以三样全接受，也可以一样都不接受。导入的配置文件、辅助脚本或忽略推送选项的策略，都可能让已接受的集合为空，而服务器一侧看起来却很正常。从客户端记录的状态开始，而不是从服务器的配置开始，因为解析器实际收到的正是那个状态。如果已接受的域名缺失，后面一切都无关紧要。在检查任何缓存之前，先检查连接的 DNS 属性。

这一区别解释了大多数“域名从未到达”的报告。它被提供过，却没有被应用。

两种域名条目

一条连接可以携带普通搜索域和仅路由域，后一种以波浪号开头。搜索域既路由查询，又允许短名称展开，这在工作站上很方便，在服务器上却出人意料。仅路由域表示该后缀的查询应发往指定服务器，而不改变短名称的解析方式。把同一个域名用两种方式写并不是冗余，因为这两类条目做的是不同的事。

对于私有命名空间，你通常想要的是仅路由形式。它让公司后缀继续指向公司解析器，其余一切都不受影响。

resolv.conf 中的 localhost 不是缺陷

使用本地缓存解析器时，系统文件只指向回环地址，别无其他。该条目标识的是本地监听器，而不是管理器交给它的上游服务器。公司地址合法地不出现在该文件中。

把该条目替换成公共解析器是典型的误修。它恢复了公共名称解析，却在同一次编辑中丢掉了条件策略。

不要把两种后端混为一谈

被管理的 dnsmasq 实例和系统解析器是不同的程序，配置不同，状态视图也不同。针对其中一个的状态命令，对另一个说明不了任何有用信息。

确定管理器配置使用哪个后端，然后读该后端生成的配置，而不是碰巧存在的发行版级文件。管理器会写自己的实例配置，并支持该实例的自定义选项，所以编辑一个无关的全局文件什么也不会改变，看上去像一次没有效果的改动。在 53 端口上再启动一个守护进程比无用更糟，因为现在两个程序对端口归属各执一词。先确定所有者，再在所有者读取的位置编辑。

测试命名空间，而不只是答案

通过应用程序的正常路径，查询一个被允许的私有名称和一个公共对照名称。直接向公司服务器查询只能证明记录存在，不能证明客户端选择了那台服务器。第二次查询才是检验策略的那一次。

然后在重新连接之后和断开之后各重复一次。关联关系应当跟随连接的生命周期，私有名称应当在隧道消失时停止解析，而不是回退到为同一后缀应答的公共解析器。如果确实回退，你就发现了一处泄漏，这与被破坏的查询是不同性质的缺陷。记下哪个后端在运行、应用了哪些域名，以及每次查询返回了什么。