WireGuard 不下发 DNS：自建 BIND 私有区

握手只携带密钥和允许的 IP，从不携带解析器。这里给出一份可直接使用的 BIND 9 私有区，以及让客户端真正能解析的按链路策略。

你把 WireGuard 起来了，隧道能过流量，内部域名却仍然解析不了。下一步通常是去 WireGuard 配置里找 DNS 设置，好像对端能像某些 VPN 那样把解析器推下来。它做不到。握手只携带密钥、接口地址和允许的 IP，没有为 DNS 服务器或搜索域预留任何字段。解析策略在客户端上，修复也应落在这里。

隧道与解析器是两份独立的契约

WireGuard 刻意做得很小。它按你列出的地址转发数据包并认证对端；这一层之上的事情全是你的设计。OpenVPN 能下发 dhcp-option DNS，因为它的控制通道传输配置，这个差异常让在两者之间来回切换的人栽跟头。

所以一条能用的隧道并不能说明域名解析如何。客户端可以有一条通往 10.90.0.1 的完美路由，却依然把查询发给公共解析器，于是症状看起来像“VPN 把 DNS 弄坏了”，而实际上 DNS 从未指向过 VPN。

只做权威区，不要变成递归解析器

服务端只是一个很小的权威区，不是通用解析器。本例中网关是 10.90.0.1，客户端是 10.90.0.0/24，你要访问的应用在 10.60.0.20 上应答。

把这些设置合并进已有的 options 块，不要再新建一个块：

options {
    listen-on { 127.0.0.1; 10.90.0.1; };
    listen-on-v6 { none; };
    allow-query { 127.0.0.1; 10.90.0.0/24; };
    allow-transfer { none; };
    recursion no;
};

然后声明区及其文件：

zone "corp.example" {
    type primary;
    file "/etc/bind/db.corp.example";
};
$TTL 300
@ IN SOA ns.corp.example. hostmaster.corp.example. ( 1 3600 600 604800 300 )
@      IN NS ns.corp.example.
ns     IN A  10.90.0.1
portal IN A  10.60.0.20

重新加载前先校验，因为加载时的语法错误会让它服务的每一个区一起把整个服务器拖垮：

named-checkconf
named-checkzone corp.example /etc/bind/db.corp.example

只对 VPN 接口开放 UDP 和 TCP 53。把私有权威发布到公网接口，等于同时招来查询和枚举，allow-transfer 应保持关闭，除非确实有辅助服务器需要。

让客户端指向它，按链路配置

假定连接由 NetworkManager 管理、解析器是 systemd-resolved。先读一遍现有策略，尤其是任何根路由域，因为 ~. 条目会压过你即将添加的内容。

nmcli connection modify wg-office +ipv4.dns 10.90.0.1
nmcli connection modify wg-office +ipv4.dns-search '~corp.example'

波浪号才是关键字符。它把该域标记为仅路由：corp.example 下的名字走这条链路的 DNS 服务器，且该域不会被当作短名搜索后缀追加。没有它，输入 portal 就会开始解析 portal.corp.example，这对你方便，对其他人却是意外。把波浪号放在引号内，因为不加引号的波浪号是 shell 展开，随时会指向你的家目录。

通过拥有该接口的管理器应用改动，然后重新连接。不要为同一接口再起第二个 wg-quick 实例；两个所有者会争夺路由，其中一个会在最糟糕的时刻胜出。

先验证路径，再看名字

从客户端查询该名字，并同时确认应答和给出应答的服务器：

resolvectl query portal.corp.example

如果返回 10.60.0.20，DNS 契约就算完成。如果超时，先查通往 10.90.0.1 的路由，再查防火墙规则，最后查服务器上的 allow-query。这套配置里的解析失败几乎总是可达性或 ACL，而不是区文件。要从客户端向外排查，因为服务器无法告诉你某个查询为什么从未到达。

记住应用仍然需要自己的路由和自己的服务权限。一个解析成功却指向不可达地址的名字，是穿着同样外衣的另一种故障。

仍然不自动的部分

自带解析逻辑的应用会完全无视系统解析器，再多的 nmcli 也改变不了这点。要验证 DNSSEC 的部署需要为私有区设计明确的信任锚；答案不是一句“关掉校验”的通告。用用户实际在跑的同一套客户端软件去测，而不是用某个恰好走系统解析器的工具。两者之间的差距就是整份缺陷报告。

机群可以通过其装机系统把这条客户端策略自动化，但策略仍然是带所有者的独立对象。BIND 9 参考手册 覆盖了上文用到的监听与查询控制，也是核对你所装版本行为该查的地方。

下一步：把区序号递增和检查命令写进变更流程，让任何记录修改都无法未经检查就进生产。

相关文章