Ubuntu Unbound 部署可以为小型可信局域网提供带 DNSSEC 验证的递归解析器，无需开放公网服务。本文采用 Ubuntu 24.04 LTS amd64 的维护软件包，2026 年 10 月 11 日核验版本为 1.19.2-1ubuntu3.10。更新可能改变修订号，应检查本机 Ubuntu 仓库，不固定过时版本。作者未进行完整端到端实测。［1］

关键要点

先在回环运行，再绑定一个实际 LAN 地址及最小授权网段。

保留 Ubuntu 的信任锚、服务身份和 chroot 安排。

DNSSEC 验证签名数据，不加密 DNS，也不会自动过滤广告。

先明确指定解析器查询，再只切换一台客户端并保留原设置。

Ubuntu Unbound 部署适合你的任务吗？

你需要拥有主机和局域网管理权，并能维护递归解析器。按自建责任指南分配更新、日志、访问策略和恢复责任。若需要出口地址或另一条流量路径，先比较 DNS 与 VPN 的角色：解析器回答名称，不承载全部应用流量。

Unbound 不自动成为广告拦截服务，DNS 过滤有独立的策略与流程。主机原本无法解析时，应先检查 Ubuntu 解析链；通用设备排障顺序可区分应用与 DNS 故障。

本文是小型递归解析器，不是转发配置、路由器部署或公网 DNS。递归需要获准通过出站 UDP、TCP 53 访问权威服务器。网络不允许时采用经批准的替代方案，不关闭其控制。通过网络所有者现有地址管理流程，为主机保留稳定 LAN 地址。

记录软件包、Unbound 主配置和 includes、单元及 drop-in、启用状态、防火墙、地址、路由和解析器所有权。私密备份放在有效 include 目录外，保留独立管理连接。如果现有 Unbound 或自动化管理器拥有这些路径，先协商，不再粘贴冲突的 server 块。

步骤 1：核对 53 端口和 Ubuntu 软件包

安装前检查监听及系统 DNS。systemd-resolved 可能绑定 127.0.0.53，它不同于 127.0.0.1；通配监听则可能与两者冲突。不要为腾端口关闭系统解析器或改写 /etc/resolv.conf。［6］

sudo ss -lntup 'sport = :53'
resolvectl status
ip -4 address
ip -6 address
sudo apt-get update
sudo apt-get install unbound dnsutils
apt-cache policy unbound
unbound -V
sudo unbound-checkconf /etc/unbound/unbound.conf
sudo systemctl status unbound.service --no-pager

安装可能启动服务，应立即核对实际监听和状态。出现意外宽泛监听就停止并调查。原本已经安装时保留其基线。apt-cache policy 显示安装及候选版本；unbound -V 显示程序构建，不一定包含完整 Ubuntu 包修订号。

新增文件前，读取 /etc/unbound/unbound.conf 的 include 指令和 /etc/unbound/unbound.conf.d/。确认软件包现有根信任锚及可访问的状态目录，保留原安排。不重复 auto-trust-anchor-file，不盲目初始化另一信任锚，不设 username: ""，也不删除 chroot 来消除权限错误；应在包的设计范围内修正权限及路径。［2］［6］

上游最新版手册可解释概念，字段和默认值以 Noble 软件包手册为准。其示例和版本可能不同。除非管理员有意配置，否则信任锚维护与加固继续由发行包负责。［2］［3］

步骤 2：先在回环建立 Unbound 私有 DNS 解析器

协调现有 interface 和 ACL 指令后，用提权编辑器创建原本不存在的 /etc/unbound/unbound.conf.d/reader-lan.conf，属主 root、权限 644。确认主文件确实包含此目录。只添加以下小范围块，保留软件包其他文件：

server:
    interface: 127.0.0.1
    port: 53
    access-control: 127.0.0.0/8 allow
    access-control: 0.0.0.0/0 refuse
    access-control: ::/0 refuse
    hide-identity: yes
    hide-version: yes
    verbosity: 1
    log-queries: no

宽泛 IPv4、IPv6 ACL 是拒绝来源，不是监听地址；更具体的回环允许优先。这里只明确增加 IPv4 回环接口，不要求入站 IPv6 监听。其他 include 仍可能增加接口或 ACL，必须核对合并后的配置与真实套接字。［2］

先验证有效文件再重启。unbound-checkconf 应退出零，但不证明答案、网络、DNSSEC 或防火墙安全。［4］

sudo unbound-checkconf /etc/unbound/unbound.conf
sudo systemctl restart unbound.service
sudo systemctl status unbound.service --no-pager
sudo ss -lntup 'sport = :53'
dig @127.0.0.1 example.com A

用 sudo journalctl -u unbound.service -n 30 --no-pager 查看有限诊断。指定回环的查询应由目标进程返回 DNS 响应，状态和答案分开解释；NOERROR 无所问记录也可能正常。绑定失败就处理实际地址冲突，权限失败就检查包管理路径，不用 0.0.0.0 绕过问题。

步骤 3：将 Unbound 访问控制限制在一个 LAN

回环工作后再替换练习文件。下方 192.168.50.2 及后续查询都换成主机真实稳定 LAN IPv4。192.168.50.0/24 换成实际最小授权网段，不假设所有私有地址都属于自己的局域网。

server:
    interface: 127.0.0.1
    interface: 192.168.50.2
    port: 53
    access-control: 127.0.0.0/8 allow
    access-control: 192.168.50.0/24 allow
    access-control: 0.0.0.0/0 refuse
    access-control: ::/0 refuse
    hide-identity: yes
    hide-version: yes
    verbosity: 1
    log-queries: no

只能绑定已分配地址。避免 0.0.0.0、::、宽泛私网许可及路由器端口映射；ACL 由最具体匹配决定。此例不添加 IPv6 接口或客户端许可，如需要，应另行设计真实接口、最小前缀和策略。不混淆入站监听、出站 IPv6 查询和 AAAA 答案。［2］

重新检查有效配置，重启服务，核对 UDP 和 TCP 监听。接口变更需要重启，不假设 reload 会新建套接字。沿用现有防火墙管理方式；需要许可时，只允许授权网段到本机 LAN 地址 UDP、TCP 53，记录确切新增项，保留管理通道，不清空或停用共享防火墙。ACL 与防火墙属于不同层。

若 UFW 已启用并管理策略，最小规则为：

sudo ufw allow proto udp from 192.168.50.0/24 to 192.168.50.2 port 53 comment 'unbound-lan'
sudo ufw allow proto tcp from 192.168.50.0/24 to 192.168.50.2 port 53 comment 'unbound-lan'

执行前替换示例网段和地址，不为运行命令启用 UFW。由其他管理者负责时，采用其等效流程。

步骤 4：验证答案、DNSSEC、缓存及拒绝访问

在一台获授权 LAN 测试客户端使用 dig，先明确查询服务器，不改系统 DNS：

dig @192.168.50.2 example.com A
dig @192.168.50.2 example.com A +tcp
dig @192.168.50.2 example.com AAAA
dig @192.168.50.2 com. SOA +dnssec
dig @192.168.50.2 dnssec-failed.org A +dnssec
dig @192.168.50.2 dnssec-failed.org A +dnssec +cdflag

检查服务器地址、状态、记录类型及标志。com. SOA 等签名正例在验证成功时应提供认证数据和 ad。dnssec-failed.org 是故意损坏的例子，仍为 bogus 时应返回 SERVFAIL；加 +cdflag 后结果变化可帮助区分验证失败与连接故障。CD 仅用于诊断，不作为正常客户端策略。这些是预期现象，不是本文断言的实时结果。［2］［5］

读者检查	预期现象	不符时的处理
授权客户端明确发 UDP、TCP 查询	响应来自选定 LAN 地址	分别核对两种传输的监听与规则
有效签名正例	验证成功，认证数据有 `ad`	检查时间、信任锚、日志及测试域是否仍签名
已知 bogus 查询不带 CD	仍为 bogus 时 `SERVFAIL`	核对有效验证器和测试域条件，不关闭验证
TTL 到期前重复可缓存正例	缓存答案可能显示递减 TTL	预取、到期和不同缓存路径会影响观察
受控的网段外来源可到达监听	本 ACL 返回 `REFUSED`	防火墙丢弃可能超时，核对真实来源和策略
IPv4、IPv6 套接字清单	只有预期监听	声称边界正确前核对全部 includes 和防火墙地址族
重启后发新查询	授权解析恢复	基线未恢复则回到安全配置

拒绝检查应使用真正独立且获授权的来源。一次超时不证明所有未授权网络均被排除；不为得到拒绝响应而开放公网或加宽泛许可。没有受控来源时，将此项记为未执行。

观察缓存时，成功后短时间内重复相同名称、类型和 class，比较 TTL 与显示的服务器。较低查询耗时不是基准测试，调度、其他网络缓存、预取和上游条件都可能变化。DNSSEC 保护签名数据真实性，不保护查询机密性。本例关闭查询日志，但诊断仍可能含地址，应私下保存。

步骤 5：只切换一台客户端并演练恢复

明确查询通过后，记录一台客户端原 DNS 值及其管理者：DHCP、NetworkManager、networkd、VPN 或其他受支持管理器。通过其支持界面将该客户端 DNS 改为真实 LAN 解析器。路由器和其他客户端不变。核对有效解析状态与普通应用查询；应用自带 DoH 可能绕过系统 DNS，浏览器可用不证明系统使用 Unbound。

恢复先通过同一管理者还原客户端原 DNS，并验证普通解析。只删除记录中的本练习防火墙新增项，再恢复保存的 Unbound 配置。如果本次新建 reader-lan.conf 且以前不存在，只删此文件，保留包的信任锚及其他 includes。验证有效基线，按原状态重启或停止服务，恢复原启用状态，再核对监听、系统解析器、答案和管理访问。

既有部署流程若改过单元或 drop-in，也须恢复，并在重启前执行 sudo systemctl daemon-reload。只有基线证明本次新增且无人依赖才移除软件包。不删除已有安装的信任锚状态，不盲改 /etc/resolv.conf。恢复有疑问就停止变更，使用独立管理路径。

若想在这个解析器前加一层过滤，按域名分流上游的 AdGuard Home可以把指定域名转给 Unbound。

总结

回环解析成功后才添加明确的 LAN 监听。
分别验证两种传输、签名验证、拒绝访问和客户端有效 DNS。
先恢复客户端，再窄范围恢复主机服务及策略。

常见问题（FAQ）

这会创建开放的公网解析器吗？

目标配置只绑定具体私有接口并允许一个授权网段。仍需检查合并配置、监听、防火墙地址族及上游 NAT，片段不能证明整个部署边界。

必须关闭 systemd-resolved 吗？

不必。先核对真实绑定与解析链；不同显式回环地址可共存，实际冲突需要按所有权修正。［6］

DNSSEC 会加密查询吗？

不会。它验证签名 DNS 数据；本文递归 UDP/TCP 配置没有增加客户端加密传输，也不向网络隐藏查询。

为什么 TCP 和 UDP 都要检查？

DNS 两者都使用。UDP 答案不能证明 TCP 在大响应或其他受支持交换需要时正常。

AAAA 答案证明有 IPv6 监听吗？

不能。记录类型、入站传输地址族和出站解析连通性是不同属性，应直接检查套接字。

第二次查询更快能证明性能提高吗？

不能。可受控观察缓存行为，但一次耗时差异不是可靠基准或性能比较。

应立即改路由器 DNS 吗？

不应。先验证一台客户端及恢复；全网分发在本文范围外，需要独立维护和回退计划。

免责声明：仅管理获授权主机和网络，遵守适用法律与政策。本文是文档支持的步骤和预期读者检查，不是作者部署记录、兼容认证或性能保证。

来源:

Ubuntu noble-updates Unbound package — https://packages.ubuntu.com/noble-updates/unbound
Ubuntu noble unbound.conf manual — https://manpages.ubuntu.com/manpages/noble/man5/unbound.conf.5.html
NLnet Labs home resolver guide — https://unbound.docs.nlnetlabs.nl/en/latest/use-cases/home-resolver.html
NLnet Labs configuration checker — https://unbound.docs.nlnetlabs.nl/en/latest/manpages/unbound-checkconf.html
Google Public DNS: DNSSEC failure example — https://developers.google.com/speed/public-dns/docs/troubleshooting/domains
NLnet Labs resolver configuration — https://unbound.docs.nlnetlabs.nl/en/latest/getting-started/configuration.html

Sources checked 2026 年 10 月 11 日。

延伸阅读:

Ubuntu Unbound 部署：限制局域网 DNS 访问并验证恢复