VPN DNS 报告：写清什么才能复现

「DNS 坏了」是一个结论，而且不是别人能据此行动的结论。报告中真正有用的部分，是故障的形状：哪个名字、经由哪个解析器、得到什么响应。三个细节能把抱怨变成可复现的东西，而且只要隐去私有部分，三者都可以安全分享。下面是任何人能帮忙之前，一份 VPN DNS 报告至少需要写清的内容。

名字的类别，而不是判决

从名字本身开始分类：公开、内部、短名、完全限定名，或由某个特定后缀提供服务。公开名字能解析而内部名字失败，指向的是解析器选择，而不是可达性。所有名字都失败，指向的是通往解析器的路径，那是另一项调查、另一类证据。类别本身就承载诊断，确切字符串可以隐去。

说明故障是否要求隧道处于连接状态，还是发生在断开之后。只在 VPN 开启时坏掉的名字，问题在于按链路配置；断开之后才坏掉的名字，问题在于残留状态。报告往往漏掉这一点，然后纳闷为什么第一个建议没有用。

记录解析器路径

发给显式指定服务器的查询，和应用自身的普通查找，是两种不同的实验。说清是哪一种导致了故障，因为对手动查询能成功，只能证明那台服务器可用。下面的命令把系统路径和直接提问分开。

resolvectl status --no-pager
getent hosts host.internal
dig +short host.internal @10.20.30.53

status 输出列出了按链路的服务器和路由域，也就是 分流 DNS 做决定的地方。getent 调用走的是应用同一条路径，包括 nsswitch 顺序。直接查询绕过两者，只单独测试一台服务器。说明三者中哪个失败、哪个成功，读者就不必再猜路径。

写出受控比较

只改一个变量，并说明改了什么。公开名字能解析而内部名字失败，是选择问题；所有名字都超时，是路径问题；私有名字被解析成公网地址，是泄漏到了错误的解析器。这三件事里有两件与隧道是否连接毫无关系。声称「所有查询都坏了」的报告，通常包含一个从未做过的比较。

把解析和投递分开。名字能解析但站点仍然失败，说明 DNS 阶段已经成功，报告就该这么写，因为下一步要查路由或监听，而不是解析器。仅仅这一个区分，就能比任何日志片段更常省下一轮提问。

隐去命名空间，保留关系

内部名字可以替换，只要替换后结构仍然保留。为每台不同服务器和每个后缀分配稳定标签，并把这份映射留在共享副本之外。把每个内部主机都换成同一个占位符，恰好毁掉报告需要的证据，因为读者再也看不出某个后缀解析成功、另一个没有。地址也遵循同一规则：保留前缀关系，若策略要求则改动主机位。

通过已验证的渠道发送记录，并略去诊断从不需要的内容。密码、私钥和无关公司名不属于 DNS 问题。读者需要的是故障类别、解析器路径、确切错误，以及你做过的那一次比较。