当前位置：首页 > news >正文

Linux DNS主从架构与RNDC远程管理实战部署指南

news 2026/8/22 20:04:30

1. 项目概述与核心价值

最近在整理服务器运维的笔记，翻到了前两年国赛里一个关于Linux DNS服务的经典题目。题目要求是搭建一个具备主从同步功能，并且集成了RNDC远程管理功能的DNS服务器集群。这个场景非常贴近生产环境，很多中小企业的内部域名解析或者是一些对解析稳定性有要求的开发测试环境，都会用到类似的架构。它解决的不仅仅是“把域名变成IP”这么基础的问题，更核心的是高可用和安全管理。主从架构保证了即使主服务器宕机，从服务器也能继续提供解析服务，避免了单点故障；而RNDC（Remote Name Daemon Control）则让管理员能够在不直接登录服务器、不重启服务的情况下，安全地重载配置、刷新缓存、查看状态，这对于维护的便捷性和安全性是质的提升。

如果你正在负责公司的IT基础设施，或者是一名运维工程师、网络管理员，甚至是一个想深入学习Linux服务搭建的爱好者，掌握这套组合拳都非常有必要。它不像一些纯理论的配置，每一步操作都有明确的产出和实际意义。接下来，我就以一个实战者的角度，带你从零开始，拆解这个“2022国赛21题”背后的完整实现，我会补充大量原题简略描述中未提及的细节、原理和踩坑经验，让你不仅能复现，更能理解每一个配置项背后的“为什么”。

2. 整体架构设计与核心思路拆解

在动手敲命令之前，我们必须先在大脑里把整个架构的蓝图画清楚。这道题的核心是构建一个“一主一从”的DNS服务体系，并让主服务器具备远程控制能力。

2.1 主从DNS的工作原理与选型考量

DNS主从同步，本质上是一种基于区域（Zone）文件的复制。主服务器（Master）是区域数据的权威来源，拥有可读写的区域数据文件。从服务器（Slave）则定期（或根据通知）连接到主服务器，拉取区域数据的副本，这个过程称为“区域传输”（Zone Transfer）。一旦传输完成，从服务器就拥有了该区域的只读副本，并可以独立对外提供解析服务。

为什么选择BIND9？在Linux世界，实现DNS服务的软件不止一个，比如dnsmasq更轻量适合缓存和DHCP集成，PowerDNS功能强大模块化。但在这个场景下，BIND (Berkeley Internet Name Domain)几乎是唯一且最标准的选择，尤其是其9.x版本。原因有三：第一，它是互联网上使用最广泛、最老牌、文档最全的DNS软件，其行为是事实上的标准；第二，它对主从同步和RNDC的支持最为成熟和稳定；第三，各类认证考试（如RHCE、国赛）和绝大多数企业生产环境，默认的技术栈就是BIND。因此，我们选用bind9这个软件包。

主从关系的逻辑：假设我们有一个内部域lab.local。主服务器（假设IP为192.168.1.10）负责维护lab.local的区域文件。从服务器（IP为192.168.1.20）被配置为lab.local的从服务器。当lab.local的区域数据在主服务器上更新后，从服务器会自动获取更新。这样，客户端无论向192.168.1.10还是192.168.1.20发起对lab.local下主机（如www.lab.local）的查询，都能得到一致的答案，并且当主服务器不可用时，从服务器依然能提供解析。

2.2 RNDC的核心价值与安全模型

RNDC允许我们通过网络向named（BIND的服务进程）发送管理命令。如果没有RNDC，你想让BIND重新加载配置文件，可能需要systemctl restart named，但这会导致服务短暂中断，或者需要登录服务器执行rndc命令（这要求命令在服务器本地执行）。

RNDC通过一个共享密钥进行认证。这个密钥是一个对称密钥，同时存储在RNDC的配置文件（rndc.conf）和BIND的配置文件（named.conf）中。当你在本地或远程执行rndc reload命令时，命令会被加密并发送到BIND服务监听的特定端口（默认953），BIND使用相同的密钥验证命令的合法性，然后执行相应操作。

安全考量：这意味着密钥的安全性至关重要。一旦密钥泄露，攻击者就可能远程控制你的DNS服务，例如清空缓存导致解析风暴，或重载恶意配置。因此，密钥文件的权限必须严格限制（仅允许named用户和root读取），并且RNDC通道应尽可能限制监听地址（如只监听127.0.0.1或管理网络IP），配合防火墙策略使用。

3. 基础环境准备与软件安装

我们假设在两台全新的CentOS 7或Rocky Linux 8服务器上操作。为什么选这两个？因为它们代表了当前企业级Linux的主流，其软件包管理（yum/dnf）和系统服务管理（systemd）方式一致且稳定。

3.1 系统初始化与网络配置

首先，确保两台服务器之间网络互通，并且主机名和静态IP已正确设置。这步是后续所有配置能成功通信的基础。

在主服务器（Master）上：

# 设置主机名，方便识别 hostnamectl set-hostname ns-master.lab.local # 配置静态IP，编辑网卡配置文件，例如 /etc/sysconfig/network-scripts/ifcfg-ens33 # 需要确保IP地址（如192.168.1.10）、子网掩码、网关正确，并手动指定DNS服务器为127.0.0.1（指向自己）或一个可靠的公共DNS（如114.114.114.114）用于初始软件包安装。 BOOTPROTO=static IPADDR=192.168.1.10 NETMASK=255.255.255.0 GATEWAY=192.168.1.1 DNS1=127.0.0.1 # 重启网络服务 systemctl restart network

在从服务器（Slave）上执行类似操作，设置主机名为ns-slave.lab.local，IP为192.168.1.20。

关键检查点：

使用ping命令互测两台服务器的IP，必须通。
使用hostname命令确认主机名已生效。
检查/etc/hosts文件，不建议在这里做主机名解析，我们即将搭建的DNS就是为了解决这个问题的。保持hosts文件干净。

3.2 BIND9软件包安装与防火墙配置

在两台服务器上分别安装BIND9及相关工具。

# 对于CentOS 7/Rocky Linux 8，使用yum或dnf sudo yum install -y bind bind-utils # 或者 sudo dnf install -y bind bind-utils

bind是主程序包，bind-utils提供了dig，nslookup，rndc等我们急需的诊断和管理工具。

安装完成后，需要配置防火墙，开放DNS服务端口。

DNS查询端口：UDP 53， TCP 53（用于区域传输等大数据量操作）。
RNDC管理端口：TCP 953（默认）。

# 如果使用firewalld sudo firewall-cmd --permanent --add-service=dns # 这会同时开放UDP/TCP 53 sudo firewall-cmd --permanent --add-port=953/tcp sudo firewall-cmd --reload # 验证规则 sudo firewall-cmd --list-all

注意事项：在生产环境中，对于RNDC端口（953），强烈建议使用--add-rich-rule限制只允许特定的管理IP地址访问，而不是对所有IP开放。例如：sudo firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="192.168.1.100" port protocol="tcp" port="953" accept'。

4. 主服务器（Master）深度配置

主服务器的配置是核心，它定义了权威区域，并允许从服务器来同步数据。

4.1 主配置文件 named.conf 详解

BIND的主配置文件通常是/etc/named.conf。我们先备份原文件，然后进行编辑。

sudo cp /etc/named.conf /etc/named.conf.bak sudo vim /etc/named.conf

以下是需要修改或添加的关键部分，我会逐段解释：

options { listen-on port 53 { 127.0.0.1; 192.168.1.10; }; // 监听本地回环和本机IP listen-on-v6 port 53 { ::1; }; // IPv6，根据需求配置 directory "/var/named"; // 工作目录，区域文件存放于此 dump-file "/var/named/data/cache_dump.db"; statistics-file "/var/named/data/named_stats.txt"; memstatistics-file "/var/named/data/named_mem_stats.txt"; recursing-file "/var/named/data/named.recursing"; secroots-file "/var/named/data/named.secroots"; allow-query { localhost; 192.168.1.0/24; }; // 允许查询的客户端网段 // --- 关键配置：允许从服务器进行区域传输 --- allow-transfer { 192.168.1.20; }; // 只允许IP为192.168.1.20的从服务器拉取区域数据 // 也可以写成 { 192.168.1.20; localhost; } 方便本地测试 recursion yes; // 是否允许递归查询。对于权威服务器，可以设为no，但为了方便内网客户端，这里设为yes。 dnssec-enable yes; dnssec-validation yes; managed-keys-directory "/var/named/dynamic"; pid-file "/run/named/named.pid"; session-keyfile "/run/named/session.key"; }; logging { channel default_debug { file "data/named.run"; severity dynamic; }; }; // RNDC控制通道配置 // 这里使用一个独立的密钥文件 `rndc.key`，通常由系统在安装时或首次启动named时自动生成在 /etc/rndc.key 或 /run/named/session.key // 我们采用更清晰的方式：在 `named.conf` 中直接包含密钥 controls { inet 127.0.0.1 port 953 // RNDC只监听本地回环，最安全 allow { 127.0.0.1; } // 只允许本机连接 keys { "rndc-key"; }; // 使用的密钥名称 }; // 引入主区域配置文件。这是一种好习惯，将区域定义分离到单独文件，便于管理。 include "/etc/named.rfc1912.zones"; include "/etc/named.root.key"; // 在这里直接定义我们的权威区域，也可以写在单独文件里再include zone "lab.local" IN { // 定义正向解析区域 lab.local type master; // 类型为主服务器 file "lab.local.zone"; // 区域数据文件，位于 /var/named/ 目录下 allow-update { none; }; // 不允许动态更新，保持简单安全 allow-transfer { 192.168.1.20; }; // 再次明确指定允许传输的从服务器，优先级高于options中的全局设置 }; zone "1.168.192.in-addr.arpa" IN { // 定义反向解析区域，对应 192.168.1.0/24 网段 type master; file "192.168.1.arpa"; allow-update { none; }; allow-transfer { 192.168.1.20; }; };

配置要点解析：

allow-transfer：这是安全的重中之重。它指定了哪些服务器被允许从本机进行区域传输（AXFR/IXFR）。务必将其限制为你的从服务器IP。如果设置为any，则任何主机都可以尝试拉取你的完整区域数据，可能导致信息泄露或成为DNS放大攻击的帮凶。
controls段落：这里我们将RNDC监听限制在127.0.0.1，这意味着只能在本机使用rndc命令。这是最安全的做法。如果需要远程管理，则需要监听管理IP，并配合防火墙和allow列表做严格限制。
区域定义中的allow-transfer：这里指定的优先级高于options中的全局设置。为每个区域单独设置是一个好习惯。

4.2 区域数据文件创建与资源记录语法

现在，我们需要在/var/named/目录下创建上面定义的两个区域文件。注意文件的属主和权限，必须允许named用户读取。

创建正向区域文件lab.local.zone：

sudo vim /var/named/lab.local.zone

文件内容如下：

$TTL 1D ; 默认生存时间，1天 @ IN SOA ns-master.lab.local. admin.lab.local. ( 2024070101 ; 序列号 Serial： 格式通常为YYYYMMDDNN，每次更新必须增大！ 1H ; 刷新时间 Refresh： 从服务器多久检查一次主服务器 15M ; 重试时间 Retry： 刷新失败后，多久重试 1W ; 过期时间 Expire： 从服务器多久无法联系主服务器则停止服务 3H ) ; 最小TTL Minimum TTL： 否定缓存时间 ; 名称服务器记录 (NS Records) @ IN NS ns-master.lab.local. @ IN NS ns-slave.lab.local. ; 地址记录 (A Records) @ IN A 192.168.1.10 ; 将 lab.local 解析到主服务器IP ns-master IN A 192.168.1.10 ns-slave IN A 192.168.1.20 www IN A 192.168.1.100 ftp IN A 192.168.1.101 mail IN A 192.168.1.102 ; 别名记录 (CNAME Record) web IN CNAME www

关键记录解释：

SOA记录（起始授权机构）：这是区域文件的灵魂。序列号（Serial）是主从同步的触发器。从服务器会对比这个号码，如果主服务器的序列号更大，就从主服务器拉取数据。每次手动修改此文件后，务必增大此序列号！我习惯用YYYYMMDDNN格式，比如2024070101表示2024年7月1日的第一次修改。
NS记录（名称服务器）：声明了这个区域的权威DNS服务器是哪几台。这里列出了主和从。
A记录（地址记录）：最基础的域名到IP的映射。
CNAME记录（规范名称）：别名记录，web.lab.local是www.lab.local的别名。

创建反向区域文件192.168.1.arpa：

sudo vim /var/named/192.168.1.arpa

文件内容如下：

$TTL 1D @ IN SOA ns-master.lab.local. admin.lab.local. ( 2024070101 ; 序列号，必须与正向区域一致或同步更新 1H 15M 1W 3H ) ; NS记录 @ IN NS ns-master.lab.local. @ IN NS ns-slave.lab.local. ; 指针记录 (PTR Records) - 将IP反向解析为主机名 10 IN PTR ns-master.lab.local. 20 IN PTR ns-slave.lab.local. 100 IN PTR www.lab.local. 101 IN PTR ftp.lab.local. 102 IN PTR mail.lab.local.

权限与属主设置：

sudo chown root:named /var/named/lab.local.zone /var/named/192.168.1.arpa sudo chmod 640 /var/named/lab.local.zone /var/named/192.168.1.arpa

named用户属于named组，chown root:named让root拥有，named组可读。chmod 640表示文件所有者可读写，所属组可读，其他人无权限。这是BIND区域文件的标准安全权限。

4.3 配置语法检查与服务启动

在启动服务前，务必进行配置语法检查，这是一个非常重要的好习惯，可以避免因配置错误导致服务无法启动。

# 检查主配置文件语法 sudo named-checkconf /etc/named.conf # 检查正向区域文件语法 sudo named-checkzone lab.local /var/named/lab.local.zone # 检查反向区域文件语法 sudo named-checkzone 1.168.192.in-addr.arpa /var/named/192.168.1.arpa

如果以上命令均无报错（输出OK），则可以启动BIND服务并设置开机自启。

sudo systemctl start named sudo systemctl enable named sudo systemctl status named # 查看状态，确认是 active (running)

首次启动排错心得：如果status显示失败，第一时间使用sudo journalctl -xe -u named查看详细的系统日志。常见错误包括：配置文件语法错误、区域文件路径或权限错误、端口被占用等。日志信息通常非常明确，能直接定位问题。

5. 从服务器（Slave）配置详解

从服务器的配置相对简单，它不需要手动创建区域文件，因为文件会从主服务器自动同步过来。

5.1 从服务器 named.conf 配置

编辑从服务器的/etc/named.conf，其options部分与主服务器类似，但allow-transfer通常设为none，因为它作为从服务器，一般不需要再被其他服务器传输数据（除非有更下级的从服务器）。

options { listen-on port 53 { 127.0.0.1; 192.168.1.20; }; listen-on-v6 port 53 { ::1; }; directory "/var/named"; allow-query { localhost; 192.168.1.0/24; }; allow-transfer { none; }; // 从服务器通常不允许二次传输 recursion yes; ... }; // RNDC配置（如果需要在从服务器本地管理） controls { inet 127.0.0.1 port 953 allow { 127.0.0.1; } keys { "rndc-key"; }; };

关键区别在于区域定义：

zone "lab.local" IN { type slave; // 类型为从服务器 file "slaves/lab.local.zone"; // 文件路径！注意是 `slaves/` 目录 masters { 192.168.1.10; }; // 指定主服务器的IP地址 }; zone "1.168.192.in-addr.arpa" IN { type slave; file "slaves/192.168.1.arpa"; masters { 192.168.1.10; }; };

重要细节：

type slave;明确指定此区域为从区域。
masters { 192.168.1.10; };指定主服务器的IP。可以列出多个主服务器IP，用分号隔开，实现多主同步（不常见）。
file "slaves/lab.local.zone";这是最易出错的地方之一。从服务器的区域文件路径必须位于/var/named/slaves/目录（或options中directory指定的目录下的slaves子目录）下。BIND进程（named用户）需要有对这个目录的写入权限。该目录下的文件会在区域传输时由BIND自动创建和更新，管理员不应手动编辑它们。

5.2 目录权限与从服务器启动

确保slaves目录存在且权限正确。

# 检查目录是否存在，通常安装bind时会自动创建 ls -ld /var/named/slaves # 如果不存在则创建，并设置正确的权限 sudo mkdir -p /var/named/slaves sudo chown named:named /var/named/slaves # 关键！让named用户拥有写入权 sudo chmod 770 /var/named/slaves

然后，同样进行语法检查并启动服务。

sudo named-checkconf /etc/named.conf sudo systemctl start named sudo systemctl enable named sudo systemctl status named

启动后，检查/var/named/slaves/目录，应该能看到从主服务器同步下来的区域文件（lab.local.zone和192.168.1.arpa）。可以使用ls -la /var/named/slaves/查看。

6. RNDC密钥生成与高级配置

虽然我们在named.conf中使用了系统可能自动生成的rndc-key，但为了更清晰地管理和实现远程控制，我们手动生成一个专用的密钥对是更好的实践。

6.1 生成RNDC共享密钥

我们使用rndc-confgen工具来生成密钥和配置片段。在主服务器上执行：

sudo rndc-confgen -a -c /etc/rndc.key

-a：自动生成密钥并写入默认文件（/etc/rndc.key）。
-c：指定输出密钥文件。

执行后，会生成一个包含密钥的/etc/rndc.key文件。查看其内容：

sudo cat /etc/rndc.key

你会看到类似这样的内容：

key "rndc-key" { algorithm hmac-sha256; secret "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX="; };

这个文件同时包含了密钥名（rndc-key）、算法（hmac-sha256）和密钥本身（secret）。

6.2 配置BIND使用自定义密钥

现在，我们需要修改主服务器的/etc/named.conf，让它使用我们刚生成的这个密钥，并允许从特定IP远程管理。

首先，确保/etc/rndc.key文件权限安全：

sudo chown root:named /etc/rndc.key sudo chmod 640 /etc/rndc.key

然后，编辑/etc/named.conf，注释掉或删除之前controls段落中关于keys { "rndc-key"; }的引用（如果之前是引用内置密钥），并改为包含密钥文件，同时修改controls段落以允许远程管理（假设管理机IP是192.168.1.100）。

// 在文件顶部或合适位置，包含密钥文件 include "/etc/rndc.key"; // 修改 controls 段落 controls { inet 192.168.1.10 port 953 // 监听本机真实IP allow { 192.168.1.100; 127.0.0.1; } // 允许管理机和本机连接 keys { "rndc-key"; }; // 引用密钥文件中定义的密钥名 };

安全强化：在生产环境，allow列表应该尽可能小，并且配合防火墙规则，只允许受信任的管理网络访问953端口。

6.3 配置RNDC客户端

在管理机（192.168.1.100）上，我们需要创建RNDC的客户端配置文件/etc/rndc.conf（如果不存在则创建），内容需要与服务器端的密钥匹配。

最简单的方式是将主服务器上/etc/rndc.key文件的内容复制到管理机的/etc/rndc.conf中。或者，手动创建：

# 在管理机（192.168.1.100）上执行 sudo vim /etc/rndc.conf

内容如下（其中的secret必须与主服务器/etc/rndc.key中的完全一致）：

key "rndc-key" { algorithm hmac-sha256; secret "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX="; }; options { default-key "rndc-key"; default-server 192.168.1.10; // 默认连接的主服务器IP default-port 953; };

同样设置好权限：

sudo chmod 600 /etc/rndc.conf

现在，在管理机上，你就可以远程控制主服务器的BIND服务了：

rndc -s 192.168.1.10 status # 查看主服务器BIND状态 rndc reload # 重载配置（如果修改了named.conf或区域文件并增加了序列号） rndc flush # 清空服务器缓存 rndc zonestatus lab.local # 查看lab.local区域的状态

实操心得：rndc reload是一个非常常用的命令。当你修改了named.conf（主配置）后，使用reload可以平滑重载配置，不会中断正在进行的查询。但请注意，修改区域文件后，除了要增大序列号，还需要执行rndc reload zone_name（例如rndc reload lab.local）来重载特定区域，或者直接rndc reload重载所有区域。

7. 功能验证与深度排错指南

配置完成后，不能只看服务状态是running就了事，必须进行全面的功能测试。

7.1 基础解析测试

使用dig或nslookup工具进行测试，它们比古老的nslookup功能更强大，输出更清晰。

在客户端（可以是同一网段内任意机器）测试正向解析：

# 查询 www.lab.local 的A记录，指定向主服务器192.168.1.10查询 dig @192.168.1.10 www.lab.local A # 查询 lab.local 的SOA记录，了解区域权威信息 dig @192.168.1.10 lab.local SOA # 查询 lab.local 的NS记录，看名称服务器列表是否正确 dig @192.168.1.10 lab.local NS

在客户端测试反向解析：

# 查询IP 192.168.1.100 对应的PTR记录 dig @192.168.1.10 -x 192.168.1.100

测试从服务器：将上述命令中的@192.168.1.10替换为@192.168.1.20，重复测试，结果应该完全一致。

关键输出解读：

在dig命令输出的ANSWER SECTION中，应该能看到正确的IP地址或主机名。
在输出的AUTHORITY SECTION中，应该能看到lab.local.的NS记录指向ns-master.lab.local和ns-slave.lab.local，并且后面跟着它们的A记录（这叫“胶水记录”，在附加段中）。
注意响应时间（Query time）和状态（status: NOERROR）。

7.2 主从同步测试

这是验证主从架构是否成功的关键。

检查从服务器区域文件：登录从服务器，查看/var/named/slaves/目录下是否生成了区域文件，并检查其内容是否与主服务器一致。
```
sudo ls -la /var/named/slaves/ sudo cat /var/named/slaves/lab.local.zone | head -20
```
重点看序列号是否与主服务器的lab.local.zone文件中的序列号一致。
修改主服务器区域文件，触发同步：
- 登录主服务器，编辑/var/named/lab.local.zone，添加一条新记录，例如：
```
test IN A 192.168.1.200
```
- 务必增大SOA记录中的序列号，例如从2024070101改为2024070102。
- 执行sudo rndc reload lab.local通知BIND重载该区域。
- 等待片刻（取决于SOA记录中Refresh时间，我们设的是1小时，但可以手动触发或等待NOTIFY消息），然后在从服务器上使用dig @192.168.1.20 test.lab.local查询，或者直接查看从服务器的区域文件/var/named/slaves/lab.local.zone，看新记录test是否已经出现。

使用RNDC命令查看同步状态：

# 在主服务器上查看区域传输状态 sudo rndc stats # 然后查看统计文件 /var/named/data/named_stats.txt，寻找关于 zone transfer 的部分。 # 或者在从服务器上，查看BIND日志 sudo journalctl -u named -f

当你重载主服务器区域后，观察从服务器的日志，应该能看到类似transfer of 'lab.local/IN' from 192.168.1.10#53: Transfer completed的成功消息。

7.3 常见问题与排查技巧实录

即使按照步骤操作，也可能会遇到问题。以下是我在多次搭建中总结的“排错地图”：

问题1：从服务器slaves/目录下没有生成区域文件。

检查1：防火墙。确保主服务器的防火墙允许从服务器IP访问TCP 53端口（用于区域传输）。sudo firewall-cmd --list-all查看，确保有--add-service=dns或明确的--add-rich-rule允许从服务器IP。
检查2：主服务器allow-transfer。确认主服务器的named.conf中，对应区域的allow-transfer列表包含了从服务器的IP（192.168.1.20）。
检查3：从服务器masters语法。确认从服务器named.conf中区域定义的masters { 192.168.1.10; };语法正确，IP无误，末尾有分号。
检查4：目录权限。再次确认从服务器上/var/named/slaves/目录的属主和权限是named:named和770。
检查5：查看日志。分别在主从服务器上运行sudo journalctl -u named -f，然后重启从服务器的named服务（sudo systemctl restart named），观察日志输出的错误信息。这是最直接的排错手段。

问题2：RNDC命令连接被拒绝。

检查1：controls段落配置。确认named.conf中controls的inet地址和allow列表包含了你的管理机IP。如果是本地测试，确保有127.0.0.1。
检查2：密钥一致性。确认管理机/etc/rndc.conf（或~/.rndc）中的secret与主服务器/etc/rndc.key或named.conf中包含的密钥完全一致，包括密钥名称。
检查3：防火墙。确认主服务器的953端口对管理机开放。
检查4：服务监听。在主服务器上运行sudo netstat -tlnp | grep :953，看named进程是否在监听953端口。

问题3：解析结果不正确或超时。

检查1：客户端DNS设置。确保测试客户端的DNS服务器地址设置成了192.168.1.10或192.168.1.20，而不是其他DNS。
检查2：区域文件语法。用named-checkzone命令反复检查区域文件，确保没有拼写错误，特别是记录末尾的“.”。例如ns-master.lab.local.（带点）和ns-master.lab.local（不带点）意义完全不同。
检查3：递归查询。如果客户端查询外部域名（如www.baidu.com）失败，检查options中recursion yes;是否设置，以及allow-query是否包含了客户端IP段。

问题4：序列号已增大，但从服务器不同步。

检查1：NOTIFY机制。BIND主服务器在区域更新后，会向该区域的NS记录中列出的所有服务器（除了自己）发送NOTIFY消息。查看从服务器日志是否有收到NOTIFY。也可以在主服务器用rndc notify lab.local手动触发通知。
检查2：手动强制刷新。在从服务器上，可以使用rndc refresh lab.local命令强制其立即向主服务器查询SOA记录并决定是否进行区域传输。
检查3：SOA参数。检查SOA记录中的Refresh时间。如果设置过长（如1D），从服务器不会立即检查。在测试时，可以临时改小（如300秒），测试完再改回。

建立一个稳定可靠的Linux DNS主从服务并集成RNDC管理，是一个系统工程，涉及网络、安全、服务配置和排错多个层面。这套配置方案经过了大量生产环境的检验，关键在于理解每个参数的意义，并做好权限与访问控制。当你看到两台服务器上的区域文件序列号保持一致，并且能同时对外提供快速、准确的解析服务时，那种成就感是实实在在的。记住，每次修改区域文件后，“增大序列号”和“重载区域”是两个必须执行的动作，养成这个习惯，能避免很多同步问题。

查看全文

http://www.cnnetsun.cn/news/4163139.html