4. 企业DNS服务部署

DNS 是企业网络里最容易被忽视、却最不能出问题的基础服务之一。用户访问内网门户、邮件系统、数据库中间件，第一步几乎都要经过域名解析。本节以 RHEL 上最常用的 BIND 为主线，把安装、区域配置、正反向解析、主从同步、转发器、DNSSEC 基础以及视图与访问控制串成一条可落地的部署路径。

一、安装与运行环境确认

在 RHEL 8/9 中，BIND 的服务端软件包名为 bind，配套工具在 bind-utils 中。安装前先确认主机名与网络：

hostnamectl set-hostname ns1.example.com
dnf install -y bind bind-utils
systemctl enable --now named
firewall-cmd --permanent --add-service=dns
firewall-cmd --reload

BIND 的主配置文件是 /etc/named.conf，区域数据文件默认放在 /var/named/。RHEL 默认启用 named 用户运行服务，因此区域文件属主应为 root:named，权限 640，否则加载时会报权限拒绝。SELinux 开启时，区域文件必须带 named_zone_t 上下文，可用 restorecon -Rv /var/named 修复。

二、正向解析与反向解析

正向解析把域名映射为 IP，反向解析把 IP 映射为域名，两者使用不同的区域命名规则。正向区域名就是域名本身，例如 example.com；反向区域名由网段倒序加 in-addr.arpa 构成，例如 192.168.10.0/24 对应 10.168.192.in-addr.arpa。

下面是一个正向区域文件示例，其中 @ 代表区域名，SOA 中的序列号是主从同步的判断依据，A 记录提供 IPv4 地址，CNAME 提供别名：

$TTL 3600
@   IN  SOA ns1.example.com. admin.example.com. (
        2024051501 ; serial
        3600       ; refresh
        900        ; retry
        604800     ; expire
        86400 )    ; minimum
@       IN  NS   ns1.example.com.
@       IN  NS   ns2.example.com.
@       IN  A    192.168.10.10
ns1     IN  A    192.168.10.10
ns2     IN  A    192.168.10.11
www     IN  A    192.168.10.20
mail    IN  A    192.168.10.30
ftp     IN  CNAME www.example.com.

反向区域文件使用 PTR 记录，主机号写在最左侧：

$TTL 3600
@   IN  SOA ns1.example.com. admin.example.com. (
        2024051501 3600 900 604800 86400 )
@   IN  NS  ns1.example.com.
10  IN  PTR ns1.example.com.
11  IN  PTR ns2.example.com.
20  IN  PTR www.example.com.
30  IN  PTR mail.example.com.

在 named.conf 中通过 zone 语句声明区域，type master 表示主服务器，file 指向数据文件。配置完成后用 named-checkconf 检查主配置，用 named-checkzone example.com /var/named/example.com.zone 检查区域文件，再 systemctl reload named 生效。

三、主从区域与转发器

生产环境至少部署两台 DNS，一台主、一台从。从服务器区域类型为 slave（新版本也写作 secondary），并通过 masters 指定主服务器地址。从服务器会在 refresh 到期后向主服务器查询 SOA 序列号，若主服务器序列号更大，则触发 AXFR 全量或 IXFR 增量同步。因此每次修改区域内容后，必须递增序列号，否则从服务器不会更新。

转发器用于把本机不负责的查询交给上游 DNS。在 options 中配置 forwarders，并用 forward only 表示只转发不递归：

options {
    listen-on port 53 { 127.0.0.1; 192.168.10.10; };
    allow-query     { localhost; 192.168.10.0/24; };
    forwarders      { 223.5.5.5; 114.114.114.114; };
    forward only;
    recursion yes;
};

四、DNSSEC 基础

DNSSEC 通过数字签名保证解析结果的完整性和来源真实性，核心是 DNSKEY、RRSIG、DS 三类记录。区域签名后，权威服务器返回的每条记录都附带 RRSIG，解析器用 DNSKEY 验证签名，再通过父区的 DS 记录建立信任链。BIND 中可用 dnssec-keygen 生成密钥，用 dnssec-signzone 对区域签名，并在 named.conf 中启用 dnssec-validation auto。企业内网若暂不具备完整信任链，可先启用验证但不强制失败，逐步过渡。

五、视图与访问控制

视图（view）让同一台 DNS 针对不同来源网段返回不同解析结果，典型场景是内网用户解析到私网地址、外网用户解析到公网地址。每个 view 内可独立定义 zone，匹配顺序自上而下，第一个匹配的 view 生效。访问控制主要依赖 allow-query、allow-transfer、allow-recursion 三个参数：allow-query 控制谁能查询，allow-transfer 控制谁能做区域传送（应只允许从服务器），allow-recursion 控制谁能使用递归查询，避免开放递归被利用放大攻击。

六、验证与排障

部署完成后，用 dig 逐项验证。正向查询 dig @192.168.10.10 www.example.com A，反向查询 dig @192.168.10.10 -x 192.168.10.20，主从同步可查 dig @192.168.10.11 www.example.com 是否返回相同结果。若从服务器未更新，先比对两侧 SOA 序列号，再检查 allow-transfer 与防火墙。若解析超时，检查 named 是否监听正确网卡、SELinux 是否拦截、区域文件权限是否为 root:named 640。日志集中在 /var/log/messages 与 journalctl -u named，区域加载失败通常会明确提示行号与原因。