如何配置Unbound DNS主从服务器实现高可用？

在构建一个稳定可靠的网络服务架构时，域名系统（DNS）的高可用性至关重要，DNS 作为互联网的“电话簿”，其解析服务的任何中断都可能导致网站不可访问、服务中断等严重后果，Unbound 作为一款高性能、安全且开源的 DNS 解析器，虽然以其递归和缓存功能闻名，但它同样具备提供权威 DNS 服务的能力，通过配置 Unbound 的主从架构，我们可以为关键的内部或外部域名服务实现冗余备份和负载均衡，从而显著提升整个 DNS 基础设施的健壮性。

Unbound 简介

Unbound 是一款由 NLnet Labs 开发的验证型、递归且缓存型的 DNS 解析器，它设计初衷是注重安全、隐私和性能，与传统的 BIND 不同，Unbound 默认不提供权威 DNS 服务功能，其核心优势在于快速、安全地为客户端递归查询互联网域名，从 1.5.0 版本开始，Unbound 引入了 auth-zone 模块，使其能够作为权威名称服务器，为特定区域（Zone）提供权威应答,这为实现主从架构奠定了基础。

主从架构的核心概念

主从架构是一种经典的高可用设计模式，在 DNS 服务中应用广泛,它包含两种角色：

• 主 DNS 服务器（Master）：作为权威数据的源头，管理员在主服务器上创建和修改区域文件（Zone File），这些文件包含了特定域名的所有 DNS 记录（如 A、AAAA、CNAME、MX 等）,主服务器负责响应来自从服务器的数据同步请求。

• 从 DNS 服务器（Slave）：作为主服务器的副本，从服务器会定期向主服务器发起查询，检查区域数据是否发生变化，如果发现更新，从服务器会发起一次区域传输，将最新的区域文件复制到本地，从服务器不直接处理记录的修改,所有变更都必须在主服务器上进行。

这种架构带来的好处是显而易见的：

1. 高可用性：当主服务器因维护或故障下线时，从服务器可以无缝接管解析请求,确保服务不中断。
2. 负载均衡：客户端的 DNS 查询请求可以被分散到主从多台服务器上,减轻单一服务器的压力。
3. 容灾能力：在异地部署从服务器，可以在主数据中心发生灾难时,保障核心域名服务的持续运行。

Unbound 主从架构配置实战

假设我们有两台服务器，主服务器 IP 为 168.1.10，从服务器 IP 为 168.1.11，我们要为域名 internal.local 配置主从解析。

主服务器配置

在主服务器上，我们需要启用 auth-zone 模块，并定义要提供权威服务的区域，编辑 /etc/unbound/unbound.conf 文件：

server:
    # ... 其他通用配置 ...
    # 允许来自特定网络的查询
    access-control: 192.168.1.0/24 allow
    # 允许进行区域传输的从服务器IP
    provide-xfr: 192.168.1.11 internal.local
auth-zone:
    # 定义区域名称
    name: "internal.local"
    # 指定区域文件的存放路径
    zonefile: "/etc/unbound/zones/internal.local.zone"
    # 作为主服务器，此选项无需设置
    # master: 
    # 允许通知从服务器更新
    allow-notify: 192.168.1.11

创建区域文件 /etc/unbound/zones/internal.local.zone：

$ORIGIN internal.local.
$TTL 3600
@   IN  SOA ns1.internal.local. admin.internal.local. (
        2025102701  ; Serial
        7200        ; Refresh
        3600        ; Retry
        1209600     ; Expire
        3600 )      ; Minimum TTL
    IN  NS  ns1.internal.local.
    IN  NS  ns2.internal.local.
ns1 IN  A   192.168.1.10
ns2 IN  A   192.168.1.11
www IN  A   192.168.1.100
api IN  A   192.168.1.101

配置完成后，重启 Unbound 服务。

从服务器配置

在从服务器上，配置更为简单，我们只需告诉它从哪个主服务器获取区域数据即可，编辑 /etc/unbound/unbound.conf 文件：

server:
    # ... 其他通用配置 ...
    access-control: 192.168.1.0/24 allow
auth-zone:
    name: "internal.local"
    # 指定主服务器的IP地址
    master: 192.168.1.10
    # 从服务器不需要手动创建zonefile，Unbound会自动下载并管理
    # zonefile: "/etc/unbound/zones/internal.local.zone" 

重启从服务器上的 Unbound 服务，服务启动后，它会自动连接到 168.1.10，请求 internal.local 的区域数据，并将其存储在内存中（如果配置了 zonefile，则会保存在磁盘上）。

主从服务器角色对比

为了更清晰地理解两者的区别,下表小编总结了主从服务器的核心差异：

验证与故障排查

配置完成后，可以使用 dig 命令进行验证，首先在从服务器上查询,确保它能正确解析：

dig @192.168.1.11 www.internal.local

如果返回的 A 记录与主服务器上的配置一致,说明同步成功。

如果同步失败,应首先检查以下几点：

1. 网络连通性：确保从服务器能 ping 通主服务器。
2. 防火墙规则：DNS 区域传输使用 TCP 端口 53，请确保主服务器的防火墙允许来自从服务器 IP 的 TCP 53 端口入站流量。
3. 配置语法：使用 unbound-checkconf 命令检查两台服务器上的配置文件语法是否正确。
4. 日志文件：查看 Unbound 的日志（通常位于 /var/log/unbound/ 或系统日志中），其中通常会包含详细的错误信息，如权限拒绝、连接超时等。

相关问答FAQs

Unbound 主要是一款递归 DNS 解析器，为什么还要用它来搭建权威服务器的主从架构？

答：这是一个很好的问题，触及了 Unbound 的设计定位，确实，Unbound 的核心优势在于递归解析，而像 BIND 这样的软件在权威服务领域更为传统和强大，在某些特定场景下，使用 Unbound 搭建权威服务是合理且高效的，在企业内部网络中，可能需要为少量内部域名（如开发环境、测试服务）提供解析，使用 Unbound 的 auth-zone 功能，可以在同一套软件中同时提供递归和权威服务，简化了部署和管理，避免了同时运行两套不同 DNS 软件的复杂性，对于中小型、对性能和安全有较高要求的内部环境，Unbound 的主从架构提供了一个轻量级、一体化且足够可靠的解决方案。

在 Unbound 主从同步过程中，如果主服务器上的区域记录更新了，从服务器是如何知道并同步的？

答：Unbound 从服务器通过两种机制来感知主服务器的变化并触发同步：

1. 定时刷新：在区域文件的 SOA（Start of Authority）记录中，有一个 Refresh（刷新）字段，从服务器会以此值为间隔，定期向主服务器查询 SOA 记录，如果发现主服务器返回的 SOA 记录中的序列号比本地存储的序列号要新，从服务器就会发起一次区域传输请求,以获取最新的数据。
2. 通知机制：这是一种更主动的方式，当主服务器上的区域文件发生变更并重载后，它会根据配置中 allow-notify 指令所列出的从服务器 IP，主动向这些从服务器发送一个 NOTIFY 消息，从服务器收到通知后，会立即向主服务器查询 SOA 记录以确认变更，并随即发起区域传输，这种方式比被动等待刷新要快得多，能确保数据变更被迅速同步，在实际部署中，通常两种机制会同时工作,以保证同步的及时性和可靠性。