Linux 部署 DNS 服务与转发器配置

之前的 DNS 科普文章我们聊了 DNS 的原理、工作流程和常见记录类型。这篇进入实操环节，以  openEuler 22.03 系统为例，分三步完成一个生产环境可用的 DNS 服务搭建：

1. 搭建 DNS：安装 BIND，创建一个内网测试区域，配置正向解析记录。 

2. 配置 DNS：添加 A 记录、CNAME 记录、MX 记录，验证解析是否正常。 

3. 配置转发器：让内网 DNS 服务器把外部域名（如  www.baidu.com ）的查询转发给上游 DNS（如 武汉电信  202.103.24.68 ），实现缓存加速和统一出口。 

带你完成安装→配置→转发→验证→常见问题解决的全过程，并解释背后的技术原理。

1.环境信息 

首先，确认一下操作系统环境：  

• 操作系统：openEuler 22.03 LTS  

• 内核版本：5.10.0 系列  

• BIND 版本：通过系统官方源安装

• 目标转发器：202.103.24.68 （武汉电信 DNS）  

• DNS 服务端口：UDP 53（查询服务）和 TCP 53（区域传输和大响应）

2.安装BIND及相关工具 

openEuler 22.03 作为主流信创操作系统，其官方软件源已收录 BIND。安装只需一行命令：  

yum install bind bind-utils -y 

安装完成后，检查一下已安装的软件包：

rpm -qa | grep bind  

正常会看到 bind 、 bind-utils 、 bind-libs 等包信息。

启动 BIND 服务并设为开机自启：  

systemctl start named  systemctl enable named  

检查服务运行状态：  

systemctl status named 

看到 active (running) 即表示启动成功。如果遇到服务启动失败，大概率是防火墙或 SELinux 阻挡了 53 号端口。  

3.配置防火墙开放DNS端口 

BIND 默认侦听 TCP 和 UDP 的 53 端口，需要放开防火墙规则：

# 开放 DNS 端口  firewall-cmd --permanent --add-port=53/tcp  firewall-cmd --permanent --add-port=53/udp  # 重载使规则生效  firewall-cmd --reload

1.认识BIND的配置文件结构  

openEuler 下 BIND 安装后的主配置文件为 /etc/named.conf ，辅助区域配置文件为 /etc/named.rfc1912.zones ，正向/反向区域解析文件存放在 /var/named/ 目录下。配置文件结构如下：

/etc/named.conf    主配置文件，全局选项、转发器等均在此定义/etc/named.rfc1912.zones    区域声明文件，定义管理哪些域名区域/var/named/     各区域的解析记录文件存放目录  

2.在主配置文件中声明区域  

编辑 /etc/named.conf ，在文件末尾的 include 行之前添加区域声明：

vim /etc/named.conf  

添加内容： 

zone "mugen.com" IN {    type master;                # master 表示这是主 DNS 服务器    file "mugen.com.zone";      # 区域数据文件名，存放在 /var/named/ 下    allow-update { none; };     # 禁止动态更新，生产环境通常关掉};

• type master;：这台 DNS 是 lab.local 区域的主服务器，它的解析数据是权威来源。  

• file "mugen.com.zone"; ：具体解析记录写在这个文件里。文件路径是相对于 /var/named/ 目录的，不需要写绝对路径。  

• allow-update { none; };：禁止其他设备通过网络动态增删本区域的 DNS 记录，避免误改或恶意篡改。  

3.编写区域数据文件 

创建 /var/named/mugen.com.zone 文件：

vim /var/named/mugen.com.zone  

写入以下内容：

$TTL 86400                        ; 默认缓存时间，单位秒（86400秒 = 24小时）@       IN SOA  ns1.mugen.com. admin.mugen.com. (                2025050601        ; 序列号，每次修改文件需递增，格式通常为年月日+序号                3600              ; 刷新间隔：从服务器多久向主服务器同步一次                1800              ; 重试间隔：同步失败后多久重试                604800            ; 过期时间：从服务器多久联系不上主服务器就停止响应                86400 )           ; 最小 TTL：否定缓存的有效时间@       IN NS   ns1.mugen.com.    ; 声明该区域的 DNS 服务器ns1     IN A    192.168.3.59     ; DNS 服务器自身的 A 记录www     IN A    192.168.3.59     ; Web 服务器的 A 记录mail    IN A    192.168.3.59     ; 邮件服务器的 A 记录

每行的含义如下：

关于 SOA 参数的进一步解释：刷新间隔 3600 秒（1小时）的意思是，如果未来你部署了备份 DNS 服务器，它每 1 小时过来同步一次数据。过期时间 604800 秒（7天）则是最后一道保险——备份服务器如果连续 7 天都连不上主服务器，就认为主服务器已经彻底下线，自己也不再返回可能过期的旧数据。

4.检查配置并重载服务  

先检查主配置文件语法：  

named-checkconf 

再检查区域数据文件语法：  

named-checkzone mugen.com /var/named/mugen.com.zone  

两条命令均无报错输出即表示配置正确。然后重载服务： 

systemctl restart named

1.添加 CNAME 别名记录 

编辑区域数据文件，在末尾追加：  

vim /var/named/mugen.com.zone  

追加内容：  

blog IN CNAME www  ; blog.mugen.com 指向 www.mugen.com  

• 效果：访问 blog.mugen.com 时，DNS 自动去查 www.mugen.com 的 A 记录，完成跳转。  

• 价值：将来 Web 服务器换 IP，只需改 www.mugen.com 的 IP，用户感知不到中间这一跳，blog 自动跟随，不用逐条修改。  

2.添加 MX 邮件交换记录 

继续追加： 

@ IN MX 10 mail.mugen.com.；发往 @mugen.com 的邮件由 mail 服务器接收

• 10 是优先级，数字越小越优先。如果有多台邮件服务器做冗余，可以配置 MX 20、MX 30 等依次备用。

3. 设置文件权限 

区域数据文件的所有者必须是 named 用户，否则 BIND 读不到：

chown named:named /var/named/mugen.com.zone  

4.重载并验证解析 

确认区域文件无误后重载：  

named-checkzone mugen.com /var/named/mugen.com.zone systemctl reload named  # 平滑重载，不中断服务，不清空缓存

将测试客户端（同一网段内另一台机器）的 DNS 指向 BIND 服务器。Linux 客户端编辑 /etc/resolv.conf ：  

nameserver 192.168.3.59 

用 nslookup 逐条验证：  

# 测试 A 记录  nslookup www.mugen.com  # 测试 CNAME 记录  nslookup blog.mugen.com  # 测试 MX 记录  nslookup -type=MX mugen.com  # 测试 NS 记录  nslookup -type=NS mugen.com 

至此，一个能正常解析内网域名的 DNS 服务就配置完成了。

1.为什么要配置转发器？

目前这台 BIND 只能解析 mugen.com 区域的域名。如果你在客户端执行 nslookup www.baidu.com ，BIND 会怎么做？

它会自己去全球 DNS 体系做完整迭代查询：从根服务器 → .com 顶级域 → baidu.com 权威服务器。这个过程首次查询延迟较高（几十到几百毫秒），而且每台内网设备每次查不同的外部域名，BIND 都要重复走一次完整迭代。  

生产环境的做法是：给 BIND 指定一个或多个上游转发器，让它把不属于自己管理的外部域名查询，直接转发给上游去处理，自己只管收结果和缓存。

2.为什么选择 202.103.24.68  

202.103.24.68 是湖北武汉电信的本地 DNS 节点，由运营商骨干网络承载。选择它的理由很直接——网络距离近：  

• BIND 部署在武汉本地机房或企业内网时，数据包到 202.103.24.68 只需要几跳路由。

• 解析延迟通常在 1~5 毫秒。

• 避免了跨省甚至跨运营商的 DNS 查询绕路。

其他可选的国内公共 DNS 做备用：

提醒一句：202.103.24.68 是运营商 DNS，适合内网缓存转发场景。如果你的业务场景涉及外网公共 DNS 解析质量比较、跨运营商访问，或者对 DNS 纯净度有要求（不劫持、不插入广告），也可以考虑同时配置 223.5.5.5 （阿里 DNS）或 119.29.29.29 （腾讯 DNS）等公共 DNS 作为备选。 

3.配置转发器 

编辑 /etc/named.conf ，在 options 块中添加：

im /etc/named.conf

需要修改以下几个关键配置项（其他内容保持默认或用 // 注释掉）：

① 全局侦听与访问控制

options {    # 侦听所有网络接口，不限于本机回环    listen-on port 53 { any; };    # 允许所有来源的查询请求（生产环境建议按实际网段收缩范围）    allow-query { any; };    # 启用递归查询，这是转发功能的前提    recursion yes;

recursion yes; 这一行非常关键：它允许 BIND 替客户端去外部查询。如果你不开启递归，BIND 只会返回它自己管理的权威区域数据（本地没有的查询直接拒绝），转发功能也无法生效。

② 转发器配置

转发模式对比： 

• forward first：优先尝试转发器。如果转发器没响应或者查询失败，BIND 会自动切换到自己执行完整的递归迭代查询。这个模式是默认值。

• forward only：只使用转发器。如果转发器不响应，BIND 直接返回查询失败，不自己做迭代。 

生产环境采用forward only，所有外部解析统一走 202.103.24.68 这条链路，避免绕过转发器自己出去查，方便流量审计与安全管控。如果转发器本身不稳定，可改用forward first;或添加多个转发器地址作为备用。

# 关闭 DNSSEC 验证（简化演示配置，生产环境建议保持开启） dnssec-validation no;

DNSSEC 是什么？ DNSSEC（DNS 安全扩展）通过对 DNS 解析结果做数字签名，防止缓存投毒攻击 ——即攻击者在 DNS 查询过程中插入伪造的解析结果。

关闭它的原因：如果上游转发器本身不支持 DNSSEC，可能导致部分域名的 DNSSEC 验证失败，查询直接返回 SERVFAIL 错误。生产环境如果上游支持，建议保持开启。

③ 注释或删除根提示区域 

如果配置文件中存在根区域声明（zone "."），必须将其注释掉，否则 BIND 会认为自己拥有根区域的权 威数据，转而使用根提示进行递归查询，导致转发器配置被忽略：

# zone "." IN { #     type hint; #     file "named.ca";# };

这是最常见的“明明配了转发，实际却没走转发”的原因之一。

4.检查配置并重载服务

每次修改配置文件后，先做语法检查，确认无误后再重载服务。很多服务故障的原因其实很简单：配置文件写错了，但直接重启导致服务起不来，业务中断。语法检查就是避免这个"低级错误"的最后一道防线。

# 检查配置文件语法正确性 named-checkcon

如果没有输出任何错误信息，说明配置语法通过。然后重载：

systemctl restart named

这里用了 restart（完全重启），而非 reload（平滑重载）。两者区别：restart`会完全停止 BIND 进程再重新启动，期间短暂中断 DNS 服务，所有缓存也会被清空；reload 只让 BIND 重新读取配置文件，不会中断已有查询，也不清空缓存。日常修改一般用 `reload`，但首次部署或做了大量修改时，`restart` 更保险，可以确保一个全新的运行状态。

确认服务状态正常：

systemctl status named

看到 active (running) 即表示一切正常。

1.将测试机的 DNS 指向这台 BIND 服务器  

在 Windows 客户端，在网络适配器的 IPv4 设置中，将首选 DNS 服务器填为 BIND的 IP。

2.用 nslookup 测试解析  

nslookup www.baidu.com

看到非权威应答，说明这台 BIND 并非权威 DNS，而是代你从上游转发器查到的结果。

3.验证转发器  

# 在 BIND 服务器上抓取发往转发器的 DNS 包tcpdump -i any port 53 and host 202.103.24.68 -n

然后在测试机上执行 nslookup www.163.com 。如果 BIND 服务器终端出现与 202.103.24.68 之间的 UDP 53 端口通信记录，就证明转发配置已生效，所有外部查询都通过这台武汉电信 DNS 完成的。

在实际部署中，以下问题是高发区，列几个最常见的：

问题1：服务启动失败  

# 查看 BIND 日志，快速定位原因 journalctl -u named -n 50 --no-pager 

常见原因：

• 配置文件中缺少分号；

• 区域文件路径或权限不正确

• SELinux 未放行 named 对 /var/named/ 的读写

• 防火墙拦截 53 端口导致 bind 无法绑定 

问题2：配置了转发但查询依然走递归  

这是转发配置中最常见的坑。根因通常是主配置文件中存在 zone "." IN { type hint; ... }; 声明，导致 BIND 认为自己有根提示，优先自己做递归。解决方法：将这段注释掉，然后 reload named。 

问题3：转发模式 forward only; 与 forward first; 的区别

• forward first;（默认）：转发器优先，不响应时回落自己递归，适合对解析成功率要求极高的场景。  

• forward only;：只依赖转发器，不自己做递归，适合有安全管控要求、需要统一出口审计的场景。

如果你的转发器稳定可靠，推荐用 forward only；如果转发器偶尔抽风， forward first; 更稳妥。

问题4：内网设备互相 DNS 查询太频繁，BIND 扛不住？ 

不是 BIND 的问题。单台 BIND 可轻松支撑数万 QPS，内网几百甚至几千台设备的并发查询远远达不到瓶颈。真正瓶颈通常在网络出口带宽和转发器的响应速度。未来可通过“主备 BIND + 共用转发器”架构水平扩展，几台 BIND 共享转发器出口。

本篇文章以 openEuler 22.03 + BIND 为技术栈，完整走了一遍从环境准备、安装 BIND、配置 DNS 、配置转发器到验证生效的全过程，核心要点回顾：  

• 搭建 DNS：在 openEuler 22.03 上安装 BIND，创建 mugen.com 区域，添加基础的 A 记录和 NS 记录，内网设备已可通过这台 DNS 解析自定义域名。  

• 配置 DNS：补充了 CNAME 别名、MX 邮件交换等常用记录类型，客户端逐条验证通过，DNS 自身功能完整可用。  

• 配置转发器：将外部域名查询转发给 202.103.24.68 ，实现了内网 DNS 查询的统一出口和本地缓存加速，这是生产环境最常见的部署模式。

这套方案改动量小、稳定性高，适用于企业内网、自建机房、私有云等场景。你可以直接复制区域文件的写法，替换成自己实际的 IP 和域名结构，快速部署出一台生产可用的 DNS 服务器。