属于你自己的 DNS 解析器。
那份没人想过要搬走的日志。

“我自己的 DNS 服务器”这句话背后，其实藏着两种完全不同的机器，而几乎每一篇教程都会教你搭错那一种。在安装任何东西之前先把这一点想清楚，因为这决定了你搭出来的，究竟是一件隐私工具，还是别人隐私政策的一个代理。

转发器 会把你的查询原样转交给另一个解析器——通常是 Cloudflare、Google、Quad9 或者你的 ISP——然后缓存返回的结果。它简单、快，但会把你整条查询流交给单独一个第三方。凡是以“现在把你的上游设成 1.1.1.1”收尾的教程，搭出来的都是这一种。

递归解析器 则会亲自完成这项工作。要找到 mail.example.com，它先问根服务器谁在管理 .com，再问 .com 服务器谁在管理 example.com，最后向 example.com 自己的域名服务器索取记录。三到四次简短的对话，面对三到四个不同的运营方，彼此互不知晓对方的情况。开启 QNAME 最小化之后，它做得更进一步：只向根服务器询问 .com，只向 .com 服务器询问 example.com。完整的域名只会被透露给唯一一方——也就是托管该域名的那一方，而它反正三十毫秒之后就会收到你的连接。

右边这两列并不是竞争关系——它们是同一套方案的两个组成部分。AdGuard Home 占用 53 端口，负责应用屏蔽列表、终结加密传输；Unbound 则在它后面的回环地址上负责解析工作。这两半谁也做不好对方的活，而整条链路加起来大约只占用一百 MB 内存。

如果这一页你只记住一件事，那就记住这句：一个把请求转发给公共 DNS 提供商的解析器，并没有让你的 DNS 变得私密。它只是把日志挪动了一跳，还给你的维护清单里添了一台服务器。递归，才是这一切真正的重点。

Unbound 是 NLnet Labs 出品的一款支持校验、递归、带缓存的解析器。它几乎在所有发行版里都有软件包，互联网上很大一部分服务器已经在运行它，而且开箱即用就是递归模式——你得费一番额外的功夫，才能把它变成转发器。把它和根提示软件包一起安装，这样它就能知道根服务器在哪里，而不需要从任何地方去抓取列表：

apt update && apt install -y unbound dns-root-data
unbound -V | head -2

dns-root-data 软件包会把根提示安装到 /usr/share/dns/root.hints，把 DNSSEC 根信任锚点安装到 /usr/share/dns/root.key，并通过正常的软件包渠道保持两者更新。这是获取它们那种略显无聊、但正确的方式；用 cron 任务从某个 URL 下载 root.hints，则是那种迟早会悄无声息失败的方式。

/etc/unbound/unbound.conf.d/nb-resolver.conf

server:
    # ---- Who may ask. Deny first, allow narrowly.
    interface: 127.0.0.1@5335
    interface: 10.8.0.1
    access-control: 0.0.0.0/0 refuse
    access-control: ::0/0 refuse
    access-control: 127.0.0.0/8 allow
    access-control: 10.8.0.0/24 allow

    # ---- Privacy of the recursion itself.
    qname-minimisation: yes
    qname-minimisation-strict: no
    hide-identity: yes
    hide-version: yes
    rrset-roundrobin: yes

    # ---- DNSSEC. The anchor is maintained by the dns-root-data package.
    auto-trust-anchor-file: "/var/lib/unbound/root.key"
    root-hints: "/usr/share/dns/root.hints"
    harden-dnssec-stripped: yes
    harden-glue: yes
    harden-below-nxdomain: yes
    harden-large-queries: yes
    harden-short-bufsize: yes
    aggressive-nsec: yes
    val-clean-additional: yes

    # ---- Do not be a reflector, even by accident.
    refuse-any: yes
    ratelimit: 1000
    ip-ratelimit: 200
    edns-buffer-size: 1232

    # ---- Cache. This is where the 4 GB actually earns its keep.
    msg-cache-size: 128m
    rrset-cache-size: 256m
    cache-min-ttl: 60
    cache-max-ttl: 86400
    prefetch: yes
    prefetch-key: yes
    serve-expired: yes
    serve-expired-ttl: 3600

    # ---- Never chase a name that has no business being on the internet.
    private-address: 10.0.0.0/8
    private-address: 172.16.0.0/12
    private-address: 192.168.0.0/16
    private-address: 169.254.0.0/16
    private-address: fd00::/8
    private-address: fe80::/10

    num-threads: 2
    so-reuseport: yes
    verbosity: 0
    logfile: ""

remote-control:
    control-enable: yes
    control-interface: /run/unbound.ctl

其中有四行才是真正在做事的，值得逐一说一句。

• 01access-control: 0.0.0.0/0 refuse ——对互联网的默认回答是“不”。它之后的每一条，都是你刻意写下的例外。正是这一行，在防火墙都还来不及出手之前，就先一步挡住了步骤 02 里说的那种放大攻击。
• 02qname-minimisation: yes ——询问根服务器时问的是 .com，而不是完整的主机名。这就是 RFC 9156，在当前版本的 Unbound 中默认开启，也是递归解析器实际泄露的信息比示意图看起来更少的原因。严格模式请保持关闭：仍有少数配置有误的区，会在严格模式下出问题。
• 03refuse-any: yes ——ANY 查询会用最小的问题换来最大可能的应答，而这正是放大攻击想要的效果。没有任何正当用途需要它。
• 04serve-expired: yes ——当权威服务器无法访问时，先把过期的应答发出去，再在后台刷新，而不是直接失败。正是这项设置，让一次远端的故障不会在家里每个人看来都像是网络断了。

留意这两个监听地址。回环地址上的 5335 端口，是下一步 AdGuard Home 要用到的；10.8.0.1 是隧道地址，这样如果你决定跳过过滤这一层，VPN 上的客户端也能直接查询 Unbound。如果你还没有运行 WireGuard，暂时先删掉第二行接口配置——如果地址在这台机器上并不存在，Unbound 是不会启动的。

启动它，并验证它确实在正常工作：

unbound-checkconf
systemctl restart unbound && systemctl enable unbound

apt install -y dnsutils
dig @127.0.0.1 -p 5335 nordbastion.com +short

# DNSSEC: the first must come back with the "ad" flag set,
# the second must FAIL — its signatures are deliberately broken.
dig @127.0.0.1 -p 5335 dnssec-tools.org +dnssec | grep -E 'flags:|status:'
dig @127.0.0.1 -p 5335 dnssec-failed.org  | grep 'status:'

第一条应答里的 ad 标志，说明 Unbound 已经从根开始一路校验了签名链，而且校验通过。第二条出现 SERVFAIL，说明校验拒绝了一条被篡改的应答，而不是把它原样传给了你。如果第二条返回的是一个地址而不是 SERVFAIL，说明校验并没有真正开启，这时首先该检查的就是信任锚点。

一个谁都连不上的解析器没有用，一个谁都能连上的解析器则是步骤 02 里说的那种失败模式。恰好有两个好答案，而大多数人最终会两个都用上——在家里和笔记本电脑上用隧道，在手机上以及那些会过滤 UDP 的网络上用加密 DNS。

方案 A——通过 WireGuard。 这是两者中更好的一个，也是本指南一直指向WireGuard 指南的原因。端口 53 对互联网始终不可见，查询本身也从不会以任何形式穿越不受信任的网络，而且没有证书需要续期。如果这台 VPS 已经是你的 VPN 出口，那么在每个对端的配置里只需要加一行：

# On the client, in the [Interface] section of the peer config:
DNS = 10.8.0.1

有一个容易咬人的细节：在 Linux 上，wg-quick 是通过 resolvconf 或 systemd-resolved 来设置这个地址的，如果两者都没装，它会悄无声息地什么也不做，而隧道本身却依然能完美地建立起来。隧道建好之后，用 resolvectl status 检查一下，或者读一下 /etc/resolv.conf——一条能正常工作、却还配置着旧解析器的隧道，正是这整套练习想要杜绝的那种泄露。

方案 B——DNS-over-TLS 与 DNS-over-HTTPS。 当设备无法一直挂在隧道上时，就需要它。这两者都靠证书完成身份验证，也就意味着需要一个主机名：把一条 A 记录指向这台 VPS，然后要么让 AdGuard Home 直接持有证书，要么把它放在一个已经替你终结了 TLS 的反向代理后面。监听端口分别是 DoT 用的 853/tcp 和 DoH 用的 443/tcp。

ufw allow 853/tcp                     # DNS-over-TLS
ufw allow 443/tcp                     # DNS-over-HTTPS
# 53/udp is still NOT open on the public interface. It never will be.
ufw status

给 DoH 端点一个猜不到的路径——AdGuard Home 允许你把它部署在 /dns-query/<random> 之下，给每个人分配不同的路径，就意味着可以逐个撤销某个人的访问权限，而不用为此给其他所有人都轮换一遍。这算不上什么强身份验证，但它能让一个公开的监听端点，不至于沦为一个多绕了几步的开放解析器。

路由器这一行，是需要认真想一想的。通过 DHCP 把你的解析器分发出去，能一次性覆盖家里的每一台设备，包括那些根本没有设置界面的设备——但这样一来，从路由器到 VPS 这一跳，就变成了穿越公网的明文 DNS，而这恰恰是你原本想要阻止的事。要么在路由器本身上运行隧道，要么就接受最后一段是不加密的，把递归带来的好处当作这次的收获。

还有最后一项值得了解的配置：一个开启了 DNS-over-HTTPS 的浏览器，会使用它自己的解析器，并悄悄无视系统设置，无论隧道是否存在。Firefox 和 Chrome 在部分地区都默认开启这项功能。要么把浏览器也指向你自己的端点，要么关掉它的 DoH，让它老老实实跟随操作系统的设置。

一个私人解析器是实实在在的改善，但它不是隐身斗篷。任何把它当成隐身斗篷来兜售的人，都是在兜售别的什么东西。以下是把上面这一切都做完之后，依然可见的部分，因为搞清楚剩余暴露面的形状，正是真正的防护和自我安慰之间的区别。

连接依然会发生。 查询完成一毫秒之后，你的设备就会向刚刚查到的那个地址发起一条 TCP 连接。任何监视你链路的人，都能看到这个地址。对于拥有独享 IP 的站点来说，这个地址就等于这个站点。加密 DNS 抹去的是那个问题，而不是那个答案。

TLS 握手通常会把站点的名字说出来。 几乎每一次 HTTPS 连接开始时，Server Name Indication 都是以明文发送的，所以一个被动的观察者照样能读到主机名。Encrypted Client Hello 能解决这个问题，但部署得并不均衡——只有当浏览器和站点都支持它时，名称才会被隐藏；只要有一方不支持，名称就不会被隐藏。不要想当然地以为它已经启用。

现在解析器的运营者是你，而你只是一个人。 你的解析器与之对话的每一台权威服务器，看到的都是同一个 IP 地址在询问它所管辖的区。在很多个区里反复出现，这个 IP 就有了一种独特的模式，而这个模式就是一个家庭。这正是第一章里说的匿名集合代价，而唯一能削弱它的，是这个 IP 无法被追溯到某个名字——也就是一台无 KYC、以加密货币支付的 VPS——理想情况下，最好还是你流量本来就已经从中流出的那同一个 IP。

一如既往，服务商能看到这些数据包。 这台 VPS 运行在别人的硬件上、别人的数据中心里。NordBastion 不会检查客户流量，透明度报告和预警金丝雀声明也说明了如果被要求这样做会发生什么——但诚实地从架构角度来说：一台你租来的机器，也是一台别人在物理上能够触及的机器。自建带来的改变在于：不再有产品层面的查询日志，不再有数据分析管道，也不再有一份可以被悄悄修改的隐私政策；有的只是一个把缓存保存在 RAM 里的进程，由你自己配置，运行在一个你刻意选择的法域之内。

你真正买到的东西，精确地说是这样：关于你的行为数据里最丰富、成本又最低的那个来源，不再被一个以收集它为商业模式的一方所收集。这是一个很有限的主张，但它是真实的。当威胁模型需要 Tor 时，这一页上的任何东西都替代不了 Tor——真到那个地步，下面的洋葱服务指南才是接下来诚实的阅读方向。