1.1.1.1 由谁运营？信任之前先核查 DNS 地址

你把 1.1.1.1 粘贴进 VPN 的 DNS 字段，页面打开了，教程看起来也就被验证了。这个观察比感觉上要窄：应用表现不同，而这次改动还没有说明是谁回答了查询，也没有说明旧配置为什么失败。照抄的教程常把某个熟悉的公共地址称作“VPN 的 DNS”，这是关于归属的主张，而不是关于可达性的主张。核实这个地址代表什么只需五分钟，却能避免一次理由错误的永久改动。

能用的设置不等于身份

设置字段里的地址是一个端点，而端点总有运营方。这两件事彼此独立，而人们跳过的恰恰是第二件。就最常被照抄的那一对地址而言，答案公开：Cloudflare 把 1.1.1.1 和 1.0.0.1 作为自家解析器地址公布，并列在它的 官方地址参考 中。所以运营方的名字应当写在地址旁边，而不是另起一篇教程。

在隧道开着的时候填入这对地址，并不会让 VPN 公司变成它的运营方，也不会让流量变得匿名。查询离开你的机器，去往一家公布该地址段的公司；这家公司可能名声不错，却仍然不是教程暗示的那一方。说明里的标签与现实中的运营方是两个不同的主张。两者都没有告诉你，中间的这段网络路径由谁运营。

要确认一对地址或一个加密端点，请使用解析器自己公布的参考。其他厂商的推荐可能合法，但“由谁推荐”“经由谁到达”和“由谁运营”依然是三种不同的关系。

比较一条记录所需的三件事

一份可供复核的记录把三个问题分开：查询应当由谁接收、这次交换是明文还是加密、应当由哪条路径承载。厂商名称填不了第二、第三项，国家标签也一项都填不了。改动之前把这三项写下来，改完再逐项对照。这三项不能互相替代，把它们当成一项，正是猜测变成文档的方式。

真正把可用设置变成有据可查的决定的，是这个对照。没有对照，下一个人继承到的只是一个没有理由的地址。先读下面表格的第三列，因为多数自信的解释恰恰止步于此。

表格故意很短。它的要点是：每一项回答的是不同的问题，没有任何一个字段能填满三项。

本地转发器掩盖了真正的上游

把路由器当作 DNS 的设备，指向的其实是一个转发器。那个地址标出的是查询的下一个接收者，而不是最终作答的解析器。本地存根解析器又多加了一步，而且它出现在每一份状态输出里，很容易被当成真正的答案。

存根会把查询转发给同一份输出里也列出的上游，通常列在更下面。对运营方下任何结论之前，先把整条链读完，因为第一行并不是全部答案。否则你就是在把前台当成公司。

resolvectl status | grep -A4 'Current DNS Server'
dig +short CH TXT whoami.cloudflare @1.1.1.1
dig example.com | grep -E '^;; SERVER'

第二条命令使用解析器的回显名称（如果运营方公布了），报告它看到的来源地址。第三条命令指出实际作答的服务器，那往往不是你配置的地址。写下运营方之前，先把三份输出都对照一遍。

加密 DNS 改变的是可见内容，而不是谁在看见

DNS over HTTPS 与 DNS over TLS 保护客户端与解析器之间的交换。解析器仍然会读到被问到的每一个名字，因为作答就是它的工作。变化的是谁能观察这次交换：本地网络看到的只是与一个端点之间的连接，而不是一串明文查询。

不变的是信任关系，它依然指向运营该端点的那家机构。自带安全 DNS 设置的浏览器可能完全绕过操作系统的解析器。要把两者当成可能互相矛盾的两种配置，而不是同一个设置被应用了两次。

私有名称又需要单独做一次决定。工作隧道可能把选定域名交给组织内部的解析器，用公共服务替换它，可能让内部查询失败，也可能把内部名称暴露给不该看的一方。在替换整个适配器的设置之前，先核查域名策略。

把观察保持得尽量窄

真要对照时，保留旧配置，一次只改一个设置。记录应用、操作、解析器策略，以及重新连接后公共名称和允许的私有名称是否仍能解析。带两处改动的对照，两处都证明不了。把结果写在下一个能找到它的地方，就写在设置本身旁边。

resolvectl query intranet.corp.example
resolvectl domain
dig +short @1.1.1.1 example.com

如果应用开始正常工作，就把结论控制得和证据一样小。那次改动只帮到了一次测试，它并不说明上一个解析器是否有恶意、隧道是否坏了，也不说明另一台设备是否需要同样的替换。真正持久的结果，是一份你能说清运营方和目的的配置。