VPN DNS 过滤：拦截域名挡不住广告

一条 dnsmasq 规则就能用 NXDOMAIN 回答一个域名，整个机制仅此而已。它从不读取 HTML，不检查请求路径，也看不到应用已经建立的连接上发生了什么。因此把它和浏览器扩展相比，其实是把两件不同的事放在一起比。一个决定域名能否解析，另一个决定解析之后发生什么。

域名过滤究竟控制了什么

选项 address=/metrics.example/ 的末尾斜杠后什么都不写，解析器便会对该域名及其子域返回 NXDOMAIN。把地址留空是关键的：它既不会把客户端送往无关的替换服务器，也不会把 loopback 地址伪装成真正的目的地。dnsmasq 手册把这种写法描述为否定应答，而不是重定向。

这条规则能做的一切，都来自那一个决定。向这个解析器发问的客户端会得到否定应答；向另一个解析器发问的客户端得到的则是那个解析器给出的答案。过滤器并不知道应用本来会使用哪条路径、哪个查询字符串或哪个账号。

这种粒度很重要，因为一个主机名常常承担多种用途。登录端点、图片和跟踪可以共用一个域名，而一条删除整个域名的规则可能把某个工作流一并删掉。域名级别的策略必须接受这种取舍，或者选择更窄的域名。

客户端拦截器不同在哪里

浏览器扩展在请求发出之前就看到了它，因此可以匹配 URL 路径、取消某个具体请求，并隐藏本应显示结果的元素。它可以放行 example.com/article 而拒绝 example.com/ads/，这是任何 DNS 应答都无法表达的。这种路径级视角正是解析器根本不具备的能力。这也是为一款工具编制的过滤列表在另一款里很少表现一致的原因。

代价是覆盖范围。这种保护只存在于一个浏览器、一个配置文件、一台设备里，用户换到另一个应用时它就消失了。配置在网关上的 DNS 过滤器覆盖所有使用该网关解析器的设备，包括无法安装任何扩展的设备。

两种安排单独来看都不完整。DNS 过滤器删不掉页面已经发出的标识符，浏览器扩展也无法保护一个从不加载它的应用。

解析器路径决定了这一切是否成立

VPN 可以通告一台 DNS 服务器，却仍然收不到每一条查询。配置了加密 DNS 的浏览器、自带解析器的应用，或者处在绕过网关的网络路径上的设备，都会去别处查询。移动平台越来越多地提供私人 DNS 设置，它会悄悄覆盖隧道所建议的配置。

所以要测的是路径，而不是策略。先从网关直接查询目标解析器，再从客户端查询并作对比，然后观察本该被拦截的域名在用户运行的应用里是否真的失败。

缓存应答和已打开的套接字会让结果变得嘈杂。已经加载过资源的页面在规则变更后仍会继续工作，因此新建连接比重新加载旧标签页更可靠。

宣布结果之前，两个方向都要测

请使用一个故意被拦截的文档域名、一个被允许的公共域名，以及服务所需的一个私有域名：

$ dig +short metrics.example @10.40.0.53
$ dig +short example.com @10.40.0.53
$ dig +short intranet.corp.internal @10.40.0.53

被拦截域名返回空应答、公共域名返回正常地址、内部域名返回私有地址，三者合起来说明过滤、上游解析和本地记录都在工作。如果三者全部失败，你面对的是上游或监听器的问题，而不是过滤器。

对内发布任何结论时都要把话说窄。这是解析器上的域名过滤，不是内容检查，不是路径过滤，也不承诺无人被跟踪。请把策略归属、例外路径和查询保留期限与规则一并写清，因为记录每一次查询的过滤器本身也有隐私成本。