DNS 的本质是一张分布式映射表，把人类记得住的域名翻译成机器认得的地址。BIND9 是目前部署最广的开源实现，既能当权威服务器，也能做递归缓存。下面按实际动手顺序走一遍，环境选 CentOS，命令和配置都经过验证。
装包之前先确认系统形态
在 CentOS 上装 BIND9 只有一条命令：
sudo yum install bind
CentOS 8 及之后的 Stream 版本改用 dnf，yum 仍是软链，命令照样能跑。装完别急着启动，先看两件事。一是 CentOS 7 默认不启用 bind-chroot，而 8/9 的打包方式把配置和区域文件放进了 /var/named/chroot 的挂载视图里，如果你手动把区域文件写到 /var/named/data，named 进程在 chroot 下未必看得见同一路径。二是 SELinux 处于 enforcing 时，新建的区域文件继承的是用户家目录或 /tmp 的上下文，named 读取会被拒绝，/var/log/messages 里能看到 avc denied。用 ls -Z 确认文件上下文是 named_zone_t，不对就用 restorecon -Rv /var/named 修正，或者临时 setenforce 0 验证是不是它的问题。
区域文件怎么写才不出错
区域文件承载域名与地址的对应关系，习惯放在 /var/named/data 下。新建一个：
sudo vim /var/named/data/db.test.com
内容如下：
;; BIND data file for test.com.
$TTL 604800
@ IN SOA test.com. root.test.com. (
2 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
; A records
@ IN NS localhost.
@ IN A 183.169.1.12
@ IN AAAA 2183:169:1::12
testing.test.com. IN A 183.169.1.12
testing.test.com. IN AAAA 2183:169:1::12
几个容易踩的点。所有完全限定域名必须以点结尾，test.com 和 test.com. 在 BIND 眼里是两回事，漏点会被自动拼上当前区域名。SOA 里的 Serial 每次改完区域文件都要递增，否则从服务器不会同步。NS 记录指向 localhost. 只是单机演示的权宜写法，真实环境应指向本机可解析的主机名。写完用 named-checkzone test.com /var/named/data/db.test.com 校验，输出 OK 才算语法过关，报错会直接指出行号。
让 named 认识这个区域
主配置在 /etc/named.conf，把区域声明加进去：
zone "test.com" {
type master;
file "/var/named/data/db.test.com";
};
改完先跑 named-checkconf /etc/named.conf，没输出就是配置合法。这一步比直接重启省事得多，语法错误在启动阶段只会给一句含糊的失败提示。
启动服务：
sudo systemctl start named
CentOS 7 用 systemctl enable named 设开机自启。若启动失败，systemctl status named 看退出码，再翻 /var/log/messages 或 journalctl -u named，权限和路径问题基本都在这两处暴露。
本机与跨主机验证
本机查询直接指定回环地址：
dig @localhost testing.test.com
返回结果里看 status 是否为 NOERROR，ANSWER SECTION 是否带出预期地址。想验证反向或更多记录类型，加 -t AAAA、-t NS 参数即可。
跨主机解析的前提是网络可达，两台机器互 ping 通。默认配置下 named 只监听 127.0.0.1，外部查不到。改 /etc/named.conf 的 options 段：
listen-on port 53 { any; };
listen-on-v6 port 53 { any; };
allow-query { any; };
allow-query 放开意味着任何来源都能查，公网环境务必配合防火墙限制来源网段，否则等于开放了一个可被利用的解析器。改完 named-checkconf 再 systemctl restart named，从另一台机器 dig @服务器IP testing.test.com 验证。
转发失效的真正原因
想让内网服务器把公网域名转给上游解析，在 options 里加 forwarders：
forwarders { 8.8.8.8; 114.114.114.114; };
很多人加完发现 dig 公网域名超时，把 dnssec-validation 设成 no 就好了。这个做法能通，但要知道根因：BIND 默认开启 DNSSEC 验证，需要读取根提示文件并完成信任链校验，若根提示文件缺失、路径不对，或者上游返回的响应在验证环节被判定为不安全，查询就会失败。直接关验证等于放弃防投毒能力，只适合内网测试。
更安全的排查顺序是：named-checkconf -z 检查所有区域能否加载，确认 named.root 根提示文件存在且路径正确（通常在 /var/named/named.ca），再检查系统时间是否偏差过大——DNSSEC 对时间敏感，时钟漂移同样会导致验证失败。确认这些都没问题后仍不通，再考虑临时关闭验证定位问题，而不是一上来就关。
收尾检查清单
服务起来不等于可用。按顺序过一遍：named-checkconf 无输出、named-checkzone 返回 OK、ss -lunp | grep 53 能看到 named 监听、本机 dig 返回 NOERROR、跨机 dig 能拿到答案、防火墙放行 UDP/TCP 53。每一步都有明确判定标准，比反复重启服务高效。
ID:7701
