#做作业的时候突发灵感，脑子一热写下了一篇报告#

一、前言

DNS（域名系统）是企业内网、互联网架构中最核心的基础服务之一，主要作用是将人类易记的域名解析为网络可识别的IP地址，实现网络访问的自动化与便捷化。在传统单DNS服务器架构中，一旦主DNS服务宕机、服务器故障或网络异常，整个内网域名解析服务将完全瘫痪，存在严重的单点故障风险。

为解决单点故障、提升DNS服务稳定性与可用性，企业生产环境普遍采用DNS主从架构。主服务器负责域名记录的统一管理与维护，从服务器实时同步主服务器区域数据，作为备份节点提供解析服务。当主服务器故障时，从服务器可无缝接管解析任务，保障内网业务不中断。

本次实验基于Linux环境搭建完整DNS主从架构，使用Ubuntu系统部署主DNS服务器，Rocky Linux部署从DNS服务器，openEuler作为客户端测试验证，完成内网自定义域名 xxxx.com 的解析、主从数据同步、高可用冗余测试，完整复现企业级DNS基础架构。

二、DNS主从服务器工作原理

2.1 主DNS服务器（Master）原理

主DNS服务器是整个架构的核心权威节点，拥有区域数据的最终管理权。所有内网域名解析记录（A记录、NS记录等）均在主服务器手动配置、修改与维护。主服务器会生成唯一的区域序列号（Serial），用于标识区域文件版本。

主服务器不仅对外提供域名解析查询服务，还会对外开放区域传输权限，允许授权的从服务器拉取区域数据。每次修改域名记录后，只需递增序列号，从服务器即可识别数据更新并自动同步。

2.2 从DNS服务器（Slave）原理

从DNS服务器不存储、不手动编辑任何域名解析记录，所有数据完全依赖主服务器同步。从服务器启动后会根据配置的刷新时间，定时向主服务器请求对比区域序列号。

若主服务器序列号大于从服务器本地序列号，说明区域数据已更新，从服务器自动执行区域传输同步最新数据；若序列号一致，则无需同步，节省网络资源。同步完成后，从服务器可独立提供DNS解析服务，实现主备冗余。

2.3 DNS区域传输机制

主从同步依赖DNS区域传输机制，分为两种模式：

1. AXFR 全量传输：首次同步、手动强制同步时使用，完整传输所有区域解析记录，数据全面、耗时较长。

2. IXFR 增量传输：日常定时刷新使用，仅同步变更的记录，高效轻量化。

同时需要区分核心端口差异：DNS普通解析查询使用 UDP 53端口，主从区域数据传输必须使用 TCP 53端口，这也是主从同步最常见的故障点。

三、实验环境规划

本次实验采用三节点Linux环境，角色分工明确，模拟企业内网DNS真实架构：

1. 主DNS服务器：Ubuntu 系统，IP地址 

2. 从DNS服务器：Rocky Linux 系统，IP地址 

3. 测试客户端：openEuler 系统，IP地址 

4. 自定义内网解析域名：xxxxxxx.com

5. 规划解析记录：主域名、www、ns、ro、op 等子域名A记录

四、主DNS服务器（Ubuntu）部署配置

4.1 安装BIND9服务

Ubuntu系统使用bind9作为DNS服务程序，通过apt包管理器安装核心服务，安装完成后系统会自动生成BIND基础配置目录与模板文件，为自定义区域配置提供基础环境。

4.2 主配置文件基础配置

主配置文件named.conf主要用于全局参数定义，包括监听端口、允许查询网段、引入自定义区域文件等。配置中开启全网查询权限，适配实验环境，同时加载本地区域配置文件，使自定义域名生效。

4.3 自定义正向区域文件配置

区域文件是DNS解析的核心数据文件，包含SOA、NS、A记录等核心参数：

1. SOA记录：定义区域授权信息，包含序列号、刷新时间、重试时间、过期时间、最小缓存时间，是主从同步的核心依据，每次修改记录必须递增序列号。

2. NS记录：声明当前域名的权威DNS服务器，指定主服务器节点。

3. A记录：实现域名与IP的映射，本次实验配置主域名、www、ns、ro、op等多条内网解析记录，覆盖多场景子域名解析需求。

4.4 主从同步核心权限配置

主服务器默认拒绝所有外部节点的区域传输请求，必须手动配置 allow-transfer 参数，允许从服务器IP（10.0.0.15）拉取区域数据。生产环境建议指定固定从机IP，禁止使用any参数提升安全性，实验环境可按需开放权限。

4.5 防火墙端口放行

为保证解析与同步正常，需同时放行DNS核心端口：UDP53用于常规域名解析，TCP53用于主从区域传输，缺一不可。端口放行后，主从服务器网络链路与数据交互完全通畅。

4.6 配置校验与服务生效

配置完成后，通过named-checkconf校验全局配置语法，通过named-checkzone校验区域文件合法性，无报错后重启BIND服务，确保所有配置正常加载生效。

五、从DNS服务器（Rocky Linux）部署配置

5.1 安装BIND服务

Rocky Linux系统直接安装bind服务，系统默认创建named运行用户与slaves同步目录，为区域数据同步提供基础环境。

5.2 从服务器核心参数配置

1. 监听配置：监听本机10.0.0.15网卡IP，仅响应本机DNS服务请求，避免端口冲突。

2. 查询权限：开放全网查询权限，允许所有内网客户端接入解析。

3. 从区域配置：定义xxxxxx.com为slave类型，指定主服务器IP，设置同步文件存储路径为/var/named/slaves/。

重点易错点：从服务器masters参数必须填写主服务器IP，不可填写本机IP，否则会出现SERVFAIL同步报错。

5.3 同步目录权限修复

Rocky系统默认slaves目录权限严格，named服务进程无写入权限，导致无法自动生成同步区域文件。通过修改目录属主为named用户、调整读写权限，解决同步文件生成失败问题。

5.4 主从同步触发验证

配置完成后重启named服务，可通过两种方式验证同步：自动定时刷新、手动AXFR全量传输。本次实验通过dig AXFR命令手动拉取主服务器所有区域记录，验证主从传输权限正常，重启服务后自动生成同步区域文件，主从数据同步完成。

六、客户端配置与功能验证

6.1 客户端DNS永久配置

openEuler客户端采用nmcli命令修改网卡DNS参数，替代手动修改resolv.conf文件。手动修改resolv.conf为临时生效，NetworkManager服务会自动覆盖重置；而nmcli修改网卡配置为永久生效，重启主机、重启网卡均不会丢失配置。

本次客户端配置冗余DNS顺序：主DNS→从DNS→备用DNS，实现解析故障自动切换，最大化保障解析稳定性。

6.2 基础解析功能验证

客户端通过dig命令测试各类内网域名解析，所有域名均可正常返回对应IP，状态为NOERROR。通过查询SERVER字段可溯源解析服务器，验证主、从DNS均可独立提供解析服务。

6.3 业务访问验证

在主服务器部署Apache网页服务，客户端通过curl命令访问www.xxxxxxx.com，成功返回默认网页源码，证明DNS解析可正常支撑上层业务访问，服务链路完整可用。

6.4 高可用冗余验证

模拟主DNS服务器故障场景，关闭主服务器BIND服务，客户端自动切换至从DNS服务器完成域名解析，解析服务不中断，验证主从架构的冗余备份、故障容错能力。

七、常见故障排查与问题分析

1. SERVFAIL 解析报错：核心原因是从服务器masters配置错误、主服务器未配置allow-transfer权限、TCP53端口未放行，导致区域传输失败、本地无可用解析数据。

2. NXDOMAIN 域名不存在报错：客户端DNS指向公网服务器或公共DNS，未指向自建主从DNS，无法识别内网自定义域名。

3. slaves目录为空、同步失败：同步目录权限不足，named进程无写入权限，无法生成同步区域文件，修改目录属主与权限即可解决。

4. 区域更新无法同步：修改主服务器域名记录后未递增Serial序列号，从服务器无法识别数据更新，导致同步停滞。

5. resolv.conf配置自动丢失：系统由NetworkManager管理网络，手动修改无效，必须使用nmcli命令修改网卡永久配置。

八、实验总结与生产优化建议

本次实验成功搭建了基于Ubuntu和Rocky Linux的DNS主从架构，完整实现了内网自定义域名解析、主从数据自动同步、故障冗余切换等核心功能，彻底解决了单DNS服务器的单点故障问题，深入掌握了DNS主从工作原理、区域传输机制、服务部署与故障排查方法。

主DNS服务器作为核心节点，负责所有域名数据的统一管理与更新；从服务器作为备份节点，实时同步数据并提供冗余解析，二者配合实现了DNS服务的高可用，完全适配企业内网基础服务需求。

结合实验与生产环境，给出以下优化建议：

1. 生产环境禁止使用 allow-transfer any 配置，精准指定从服务器IP，防止区域数据泄露。

2. 每次修改主服务器区域文件后，必须递增序列号并校验配置，避免同步异常。

3. 开启DNSSEC安全机制，防止域名劫持与解析污染，提升服务安全性。

4. 部署多台从DNS服务器，实现解析负载分担与多级冗余，进一步提升服务稳定性。

5. 统一使用nmcli管理网卡DNS，杜绝临时配置失效问题，保障服务长期稳定运行。