1. 项目概述与核心需求拆解先把这个标题翻译成大白话你不是要“装个软件”你要做的是在局域网里自建一台“DNS电话本服务器”让所有设备都通过它来查询域名对应的IP地址并且还要支持正向解析域名→IP和反向解析IP→域名两个方向的查询。我最早接到这个需求是在给某公司做内部办公网络改造的时候当时内网有好几个业务系统都跑在不同IP的服务器上大家访问全靠记IP经常有人填错。后来统一上了自建DNS把oa.company.local、erp.company.local这种内部域名全部纳入管理体验才真正稳定下来。这篇文章面向的是有基础Linux操作经验、但没怎么碰过DNS的读者。内容围绕三个问题展开DNS服务器到底怎么装、正反向解析文件怎么写才不出错、以及实际运维中那些不踩一遍根本不知道的坑。我会用最常用的BIND 9来做演示因为它是目前Linux生态下最成熟、文档最全的DNS服务软件没有之一。先说清楚一个概念DNS的“正向解析”和“反向解析”不是两个可选功能而是同一套数据在不同方向的查询方式。正向是把www.example.com翻译成192.168.1.10反向是把192.168.1.10翻译回www.example.com。反向解析在邮件服务器反垃圾过滤、网络故障排查、安全审计这几个场景里几乎是刚需所以正规的DNS服务器配置一定是两边都要做的。2. 环境准备与BIND安装2.1 实验环境说明与拓扑规划我这次演示用的是一台纯净的CentOS 7虚拟机IP地址固定为192.168.56.10关闭了系统自带的firewalld和SELinux实验环境下必须关生产环境建议用放行规则代替直接关闭。你需要准备的是一台Linux服务器Ubuntu/Debian系命令略有差异但后面的配置文件完全通用。在安装之前先把网络拓扑设计清楚。我规划的域名叫example.local这是专门给内网使用的保留域名后缀不会和公网域名冲突强烈建议大家用.local或自定义内部后缀不要为了省事直接拿公网域名来建内网解析否则后续和公网DNS冲突时你会非常痛苦。实验环境里我准备了三台模拟服务器主机名IP地址规划用途ns1.example.local192.168.56.10DNS主服务器本机www.example.local192.168.56.20Web服务器模拟mail.example.local192.168.56.30邮件服务器模拟注意example.local是一个典型的内部测试域名如果你在公司生产环境建议先向网络管理部门确认内网域名规范避免和已有的DHCP、AD域控产生冲突。2.2 安装BIND及依赖组件BIND的全称是Berkeley Internet Name Domain是目前互联网上应用最广泛的DNS服务器软件。在CentOS/RHEL系统上安装包名称为bind相关的工具包是bind-utils。# 更新系统软件源建议先做 sudo yum update -y # 安装DNS主程序 sudo yum install -y bind bind-utils # 验证版本 named -v在Ubuntu/Debian系统上对应的命令是sudo apt update sudo apt install -y bind9 bind9utils bind9-doc装完之后你会得到一个名为named的系统服务以及核心配置文件/etc/named.conf。这个文件就是DNS服务器的总入口所有区域zone的声明都在这里完成。安装完成后先不要启动服务因为默认配置只监听本机回环地址且没有声明任何自定义区域先改配置再启动是最稳妥的顺序。2.3 主配置文件的基本修改打开/etc/named.conf你看到的默认配置里有一个最基本的zone .定义那是根域提示不要动它。我们只需要做三处修改添加监听地址、允许查询网段、声明自定义区域。sudo vim /etc/named.conf改动后的关键部分如下options { listen-on port 53 { 127.0.0.1; 192.168.56.10; }; listen-on-v6 port 53 { ::1; }; 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_memstats.txt; allow-query { 192.168.56.0/24; localhost; }; recursion yes; dnssec-enable yes; dnssec-validation yes; /* 转发器用于解析非内网域名 */ forwarders { 8.8.8.8; 223.5.5.5; }; };这一段里最关键的是listen-on port 53和allow-query。前者决定了DNS服务从哪个网卡接口接收请求如果你只写127.0.0.1那么局域网其他机器是没办法查这台服务器的。后者控制哪些IP可以发起递归查询写成内网网段192.168.56.0/24是常规操作。forwarders这一段也很重要当内网机器要解析的是baidu.com这类公网域名时这台DNS服务器会自己作为客户端去请求8.8.8.8或223.5.5.5然后把结果缓存在本地。如果你所在的公司有上游DNS要求这里应该改成公司指定的服务器地址。3. 正向解析配置全流程3.1 区域声明与配置文件关联正向解析的核心是“把域名转换成IP”。在BIND的体系里每定义一个解析区域就要在named.conf里声明一个zone并在后面指明该区域的数据文件路径。我定义的区域名称是example.local方式如下zone example.local IN { type master; file example.local.zone; allow-update { none; }; };type master表示这台服务器是该区域的主服务器权威服务器。file example.local.zone指定区域数据文件的文件名实际路径为/var/named/example.local.zone因为directory已经指定为/var/named。allow-update { none; }禁止动态更新实验环境下设为none即可生产环境如需配合DHCP动态更新再另行配置。写好之后一定要用named-checkconf检查配置语法sudo named-checkconf /etc/named.conf没有输出就代表通过。这一步非常重要很多新手直接修改完就重启服务结果服务起不来查半天才发现是分号漏写或者括号不匹配。named-checkconf就是我们的第一道防线。3.2 正向区域数据文件详解接下来创建/var/named/example.local.zone这是整个正向解析中最核心的部分。BIND的区域数据文件有一套严格的记录格式先看完整内容$TTL 1D IN SOA ns1.example.local. admin.example.local. ( 2024062001 ; serial 1D ; refresh 1H ; retry 1W ; expire 3H ) ; minimum IN NS ns1.example.local. ns1 IN A 192.168.56.10 www IN A 192.168.56.20 mail IN A 192.168.56.30 ftp IN CNAME www.example.local.逐行拆解一下方便你理解每行到底在做什么第一行$TTL 1DTTL是Time To Live表示这条解析记录在别的DNS服务器缓存里的存活时间是1天。TTL设置太小比如30秒会导致查询频繁、压力增大设置太大比如7天则会让域名变更生效很慢。内网环境用1天是比较折中的选择。SOA记录Start of Authority区域的起始授权记录是整个区域文件的“定盘星”。它的格式是 IN SOA 主DNS服务器名 管理员邮箱含点号 ( 序列号 刷新时间 重试时间 过期时间 最小TTL )这里要特别注意两个细节。第一主DNS服务器名ns1.example.local末尾必须有一个英文句点这叫FQDN完全限定域名写法表示从根域开始的完整域名。如果忘了这个点BIND会在后面自动补上区域名变成ns1.example.local.example.local.后果就是NS记录指向错误。第二管理员邮箱admin.example.local里的必须写成英文点号因为在DNS记录里有特殊含义代表当前区域名本身所以adminexample.local要写成admin.example.local。序列号 serial我写的是2024062001格式是“日期当天修改次数”。这个数字必须每次修改区域文件后递增否则从服务器或缓存不会刷新数据。这是运维中最常见的一个失误改了文件忘了递增序列号结果客户端始终拿到旧解析结果。NS记录Name Server记录指明该区域内哪台服务器是权威。这里我们只有一台主DNS所以只写了一条指向ns1.example.local。A记录Address记录正向解析的核心记录把主机名映射到IPv4地址。注意主机名www没有末尾点号它是一个相对名称BIND会自动补全为www.example.local。你可以理解为“简写”。CNAME记录别名记录把ftp.example.local指向www.example.local。这样访问FTP和访问Web在DNS层面落到同一个IP后续如果Web服务器换了IP只需要改A记录CNAME不需要动。3.3 文件权限与配置语法检查创建一个空文件并写入上述内容后最关键的一步是权限设置。BIND出于安全考虑默认拒绝普通用户读取区域文件防止数据库信息泄露而且named进程运行在named用户下。如果文件属主和权限不对服务启动时会报open: permission denied。# 切换属主 sudo chown root:named /var/named/example.local.zone # 设置权限660表示属主可读写属组可读写 sudo chmod 640 /var/named/example.local.zone # 使用named-checkzone检查区域文件语法 sudo named-checkzone example.local /var/named/example.local.zonenamed-checkzone这个工具会帮你逐行解析区域文件指出语法错误、缺失记录等各种问题。正常情况下的输出会显示zone example.local/IN: loaded serial 2024062001 OK出现OK就说明这个区域文件可以被BIND正常加载。这里我想多啰嗦一句named-checkconf和named-checkzone是两套不同的检查机制前者查主配置文件逻辑后者查区域数据文件语法两个都要做缺一不可。我见过太多人只检查了其中一个就重启服务结果照样起不来的情况。3.4 启动服务与正向解析验证配置完成后启动服务并设置开机自启sudo systemctl start named sudo systemctl enable named # 查看状态 sudo systemctl status named然后使用dig命令验证正向解析dig 192.168.56.10 www.example.local后面指定要查询的DNS服务器地址。正常的响应里ANSWER SECTION会显示www.example.local. 86400 IN A 192.168.56.20说明解析结果正确。如果没有ANSWER记录优先排查三件事区域文件是否加载成功、服务是否在运行、查询地址是否写对了。再测一下CNAMEdig 192.168.56.10 ftp.example.local返回结果里应该看到ftp.example.local. is an alias for www.example.local.并且最终解析到192.168.56.20。4. 反向解析配置全流程4.1 反向区域声明与网段理解反向解析和正向解析是镜像关系正向是“域名→IP”反向是“IP→域名”。它依赖一种特殊格式的区域名把IP地址反转后加上in-addr.arpa。比如我们要反向解析的网段是192.168.56.0/24那么区域名写为zone 56.168.192.in-addr.arpa IN { type master; file 192.168.56.zone; allow-update { none; }; };注意区域的命名规则必须把IP地址反着写。192.168.56变成56.168.192最后加上固定的in-addr.arpa后缀。这是因为DNS解析是树状结构从根域开始一层层向下查找反向解析需要从IP的最左侧网络号部分开始逐级进入。这个概念初看很绕你只要记住反向区域的名称永远是把IP地址部分倒序排列。4.2 反向区域数据文件编写创建/var/named/192.168.56.zone内容如下$TTL 1D IN SOA ns1.example.local. admin.example.local. ( 2024062001 ; serial 1D ; refresh 1H ; retry 1W ; expire 3H ) ; minimum IN NS ns1.example.local. 10 IN PTR ns1.example.local. 20 IN PTR www.example.local. 30 IN PTR mail.example.local.这里的核心记录类型是PTRPointer Record指针记录。10代表IP192.168.56.10因为区域名本身已经包含了192.168.56部分所以只需要写最后一位主机号。PTR后面跟的是完整的、带末尾点的域名名称。举个例子说明如果反向解析192.168.56.20DNS服务器会先解析20.56.168.192.in-addr.arpa然后从这条PTR记录中找到结果www.example.local.。检查权限并验证语法sudo chown root:named /var/named/192.168.56.zone sudo chmod 640 /var/named/192.168.56.zone sudo named-checkzone 56.168.192.in-addr.arpa /var/named/192.168.56.zone4.3 重启服务并测试反向解析修改了named.conf添加新区域后需要重启服务才能加载新配置sudo systemctl restart named使用dig -x参数进行反向解析测试dig 192.168.56.10 -x 192.168.56.20-x是dig的快捷反向查询参数它会自动帮你把IP转换成20.56.168.192.in-addr.arpa格式。正常输出中ANSWER SECTION应该显示20.56.168.192.in-addr.arpa. 86400 IN PTR www.example.local.这就代表反向解析成功了。另外也可以用host命令快速验证host 192.168.56.20 192.168.56.10输出类似20.56.168.192.in-addr.arpa domain name pointer www.example.local.就说明整个反向链路是通的。5. 客户端配置与全网生效5.1 Linux客户端DNS指向服务器配得再好如果客户端不指向它一切都是白搭。Linux客户端的DNS配置在/etc/resolv.confsudo vim /etc/resolv.conf写入以下内容nameserver 192.168.56.10 search example.localnameserver指定首选DNS服务器地址search是域名搜索后缀。当你直接执行ping www时系统会先尝试www如果不带点号还会自动尝试www.example.local这对内网访问非常方便。注意在部分使用NetworkManager管理的系统上直接编辑/etc/resolv.conf会被覆盖。稳定做法是在网卡配置文件里通过DNS1192.168.56.10来指定或者使用nmcli命令修改。这个细节坑过很多人如果你的配置改了重启后丢失大概率就是这个问题。5.2 Windows客户端DNS指向Windows系统在“控制面板→网络和 Internet→网络连接→更改适配器设置”里找到正在使用的网卡右键属性双击“Internet协议版本4TCP/IPv4”在首选DNS服务器处填上192.168.56.10。改完不用重启执行ipconfig /flushdns清一下本地DNS缓存即可生效。5.3 通过ping和nslookup做完整性测试配置完成后建议按以下顺序做一轮完整验证# 1. 正向解析连通性 ping www.example.local # 2. 反向解析验证 nslookup 192.168.56.20 # 3. 递归查询公网域名验证转发器是否生效 nslookup www.baidu.com 192.168.56.10第一项能通说明A记录OK第二项能返回www.example.local说明PTR记录OK第三项能返回公网IP说明递归查询和转发器配置OK。三项全过这个DNS服务器就真正意义上“上岗”了。6. 运维避坑指南与高阶扩展6.1 高频踩坑问题速查表以下是我每次做DNS配置时都会特别注意的几个高频问题整理成表格方便你对照排查问题现象可能原因解决办法服务启动失败日志报 permission denied区域文件权限不合格chown root:named chmod 640解析无结果日志报 zone not loaded区域文件语法错误或序列号异常named-checkzone 检查修正语法内网能解析但公网域名全部失败forwarders 配置缺失或上游DNS不可达检查 named.conf 的 forwarders 段修改了区域文件但解析结果不变未递增serial序列号把serial改成更大的数重启生效其他机器查询无响应listen-on 没监听内网IP确认 options 中 listen-on 包含内网IP查询超时且系统日志有DNSSEC相关报错上游递归DNS不支持DNSSEC实验环境可临时 dnssec-validation no这里特别解释一下序列号和缓存的问题。DNS原理决定了它是有缓存的即便你修改了区域文件并且重启了服务客户端本地和其他中间DNS的缓存没到期之前解析结果还是旧的。所以内网维护时如果改了IP地址建议等一个TTL周期或者主动在客户端执行systemd-resolve --flush-cachesLinux或ipconfig /flushdnsWindows清缓存。6.2 主从同步配置思路生产环境如果只有一台DNS服务器一旦宕机全网解析立即瘫痪。因此在正规一点的架构里至少会部署两台DNS主从配合。主服务器改动区域文件后通过allow-transfer把数据同步给从服务器zone example.local IN { type master; file example.local.zone; allow-transfer { 192.168.56.11; }; };从服务器配置几乎一样只需要把type master改为type slave并指定主服务器地址zone example.local IN { type slave; file slaves/example.local.zone; masters { 192.168.56.10; }; };从服务器会自动向主服务器同步区域数据file字段是本地存储副本的位置注意slave目录权限要单独设置。设置好之后可以在主服务器上手动触发一次区域传送检测rndc reload example.local然后去从服务器上查看区域文件是否有更新。6.3 日志与监控配置建议BIND默认把日志写入/var/log/messages排查问题总是翻系统日志比较费劲。我建议单独配置一个DNS日志通道方便集中查看logging { channel dns_log { file /var/log/named/dns.log versions 3 size 5m; severity info; print-time yes; }; category queries { dns_log; }; category general { dns_log; }; };versions 3 size 5m表示保留3份轮转日志每份最大5MB。这样查询日志、错误日志都会单独记录到/var/log/named/dns.log排查问题效率会高很多。在生产环境我还习惯加一个监控脚本定时检测named进程状态和各区域解析结果异常时直接告警推送这是确保DNS高可用的最后一环。7. 从实验中沉淀的核心经验最后聊点我自己的体会。做DNS配置这件事技术难度其实不高真正考验人的是对细节的敏感和排查问题的耐心。我从最早的各种踩坑到现在能快速定位问题最大的收获有三点第一任何改动都必须跑一遍named-checkconf和named-checkzone这两条命令节省的时间远超花在输入上的时间第二区域文件里的末尾点号、序列号递增、文件属主权限这三个点牢记在心能帮你躲掉至少八成的低级故障第三配置完成后一定要从“客户端视角”测试而不是只在服务器本机自测因为本机回环查询通过的案例不代表局域网内其他机器真的能用。DNS服务器一旦上线就是所有网络服务的基石。你在上面省下的每一个细节功夫都会在未来的某次故障里加倍偿还。希望这篇配置实录能帮你少走弯路把DNS配置这件事真正做成“一次性正确”。 
长河君 · 2026/10/16 6:28:08 · 阅读 1.2k Linux下用BIND 9搭建DNS服务器：正反向解析配置全攻略
1. 项目概述与核心需求拆解先把这个标题翻译成大白话你不是要“装个软件”你要做的是在局域网里自建一台“DNS电话本服务器”让所有设备都通过它来查询域名对应的IP地址并且还要支持正向解析域名→IP和反向解析IP→域名两个方向的查询。我最早接到这个需求是在给某公司做内部办公网络改造的时候当时内网有好几个业务系统都跑在不同IP的服务器上大家访问全靠记IP经常有人填错。后来统一上了自建DNS把oa.company.local、erp.company.local这种内部域名全部纳入管理体验才真正稳定下来。这篇文章面向的是有基础Linux操作经验、但没怎么碰过DNS的读者。内容围绕三个问题展开DNS服务器到底怎么装、正反向解析文件怎么写才不出错、以及实际运维中那些不踩一遍根本不知道的坑。我会用最常用的BIND 9来做演示因为它是目前Linux生态下最成熟、文档最全的DNS服务软件没有之一。先说清楚一个概念DNS的“正向解析”和“反向解析”不是两个可选功能而是同一套数据在不同方向的查询方式。正向是把www.example.com翻译成192.168.1.10反向是把192.168.1.10翻译回www.example.com。反向解析在邮件服务器反垃圾过滤、网络故障排查、安全审计这几个场景里几乎是刚需所以正规的DNS服务器配置一定是两边都要做的。2. 环境准备与BIND安装2.1 实验环境说明与拓扑规划我这次演示用的是一台纯净的CentOS 7虚拟机IP地址固定为192.168.56.10关闭了系统自带的firewalld和SELinux实验环境下必须关生产环境建议用放行规则代替直接关闭。你需要准备的是一台Linux服务器Ubuntu/Debian系命令略有差异但后面的配置文件完全通用。在安装之前先把网络拓扑设计清楚。我规划的域名叫example.local这是专门给内网使用的保留域名后缀不会和公网域名冲突强烈建议大家用.local或自定义内部后缀不要为了省事直接拿公网域名来建内网解析否则后续和公网DNS冲突时你会非常痛苦。实验环境里我准备了三台模拟服务器主机名IP地址规划用途ns1.example.local192.168.56.10DNS主服务器本机www.example.local192.168.56.20Web服务器模拟mail.example.local192.168.56.30邮件服务器模拟注意example.local是一个典型的内部测试域名如果你在公司生产环境建议先向网络管理部门确认内网域名规范避免和已有的DHCP、AD域控产生冲突。2.2 安装BIND及依赖组件BIND的全称是Berkeley Internet Name Domain是目前互联网上应用最广泛的DNS服务器软件。在CentOS/RHEL系统上安装包名称为bind相关的工具包是bind-utils。# 更新系统软件源建议先做 sudo yum update -y # 安装DNS主程序 sudo yum install -y bind bind-utils # 验证版本 named -v在Ubuntu/Debian系统上对应的命令是sudo apt update sudo apt install -y bind9 bind9utils bind9-doc装完之后你会得到一个名为named的系统服务以及核心配置文件/etc/named.conf。这个文件就是DNS服务器的总入口所有区域zone的声明都在这里完成。安装完成后先不要启动服务因为默认配置只监听本机回环地址且没有声明任何自定义区域先改配置再启动是最稳妥的顺序。2.3 主配置文件的基本修改打开/etc/named.conf你看到的默认配置里有一个最基本的zone .定义那是根域提示不要动它。我们只需要做三处修改添加监听地址、允许查询网段、声明自定义区域。sudo vim /etc/named.conf改动后的关键部分如下options { listen-on port 53 { 127.0.0.1; 192.168.56.10; }; listen-on-v6 port 53 { ::1; }; 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_memstats.txt; allow-query { 192.168.56.0/24; localhost; }; recursion yes; dnssec-enable yes; dnssec-validation yes; /* 转发器用于解析非内网域名 */ forwarders { 8.8.8.8; 223.5.5.5; }; };这一段里最关键的是listen-on port 53和allow-query。前者决定了DNS服务从哪个网卡接口接收请求如果你只写127.0.0.1那么局域网其他机器是没办法查这台服务器的。后者控制哪些IP可以发起递归查询写成内网网段192.168.56.0/24是常规操作。forwarders这一段也很重要当内网机器要解析的是baidu.com这类公网域名时这台DNS服务器会自己作为客户端去请求8.8.8.8或223.5.5.5然后把结果缓存在本地。如果你所在的公司有上游DNS要求这里应该改成公司指定的服务器地址。3. 正向解析配置全流程3.1 区域声明与配置文件关联正向解析的核心是“把域名转换成IP”。在BIND的体系里每定义一个解析区域就要在named.conf里声明一个zone并在后面指明该区域的数据文件路径。我定义的区域名称是example.local方式如下zone example.local IN { type master; file example.local.zone; allow-update { none; }; };type master表示这台服务器是该区域的主服务器权威服务器。file example.local.zone指定区域数据文件的文件名实际路径为/var/named/example.local.zone因为directory已经指定为/var/named。allow-update { none; }禁止动态更新实验环境下设为none即可生产环境如需配合DHCP动态更新再另行配置。写好之后一定要用named-checkconf检查配置语法sudo named-checkconf /etc/named.conf没有输出就代表通过。这一步非常重要很多新手直接修改完就重启服务结果服务起不来查半天才发现是分号漏写或者括号不匹配。named-checkconf就是我们的第一道防线。3.2 正向区域数据文件详解接下来创建/var/named/example.local.zone这是整个正向解析中最核心的部分。BIND的区域数据文件有一套严格的记录格式先看完整内容$TTL 1D IN SOA ns1.example.local. admin.example.local. ( 2024062001 ; serial 1D ; refresh 1H ; retry 1W ; expire 3H ) ; minimum IN NS ns1.example.local. ns1 IN A 192.168.56.10 www IN A 192.168.56.20 mail IN A 192.168.56.30 ftp IN CNAME www.example.local.逐行拆解一下方便你理解每行到底在做什么第一行$TTL 1DTTL是Time To Live表示这条解析记录在别的DNS服务器缓存里的存活时间是1天。TTL设置太小比如30秒会导致查询频繁、压力增大设置太大比如7天则会让域名变更生效很慢。内网环境用1天是比较折中的选择。SOA记录Start of Authority区域的起始授权记录是整个区域文件的“定盘星”。它的格式是 IN SOA 主DNS服务器名 管理员邮箱含点号 ( 序列号 刷新时间 重试时间 过期时间 最小TTL )这里要特别注意两个细节。第一主DNS服务器名ns1.example.local末尾必须有一个英文句点这叫FQDN完全限定域名写法表示从根域开始的完整域名。如果忘了这个点BIND会在后面自动补上区域名变成ns1.example.local.example.local.后果就是NS记录指向错误。第二管理员邮箱admin.example.local里的必须写成英文点号因为在DNS记录里有特殊含义代表当前区域名本身所以adminexample.local要写成admin.example.local。序列号 serial我写的是2024062001格式是“日期当天修改次数”。这个数字必须每次修改区域文件后递增否则从服务器或缓存不会刷新数据。这是运维中最常见的一个失误改了文件忘了递增序列号结果客户端始终拿到旧解析结果。NS记录Name Server记录指明该区域内哪台服务器是权威。这里我们只有一台主DNS所以只写了一条指向ns1.example.local。A记录Address记录正向解析的核心记录把主机名映射到IPv4地址。注意主机名www没有末尾点号它是一个相对名称BIND会自动补全为www.example.local。你可以理解为“简写”。CNAME记录别名记录把ftp.example.local指向www.example.local。这样访问FTP和访问Web在DNS层面落到同一个IP后续如果Web服务器换了IP只需要改A记录CNAME不需要动。3.3 文件权限与配置语法检查创建一个空文件并写入上述内容后最关键的一步是权限设置。BIND出于安全考虑默认拒绝普通用户读取区域文件防止数据库信息泄露而且named进程运行在named用户下。如果文件属主和权限不对服务启动时会报open: permission denied。# 切换属主 sudo chown root:named /var/named/example.local.zone # 设置权限660表示属主可读写属组可读写 sudo chmod 640 /var/named/example.local.zone # 使用named-checkzone检查区域文件语法 sudo named-checkzone example.local /var/named/example.local.zonenamed-checkzone这个工具会帮你逐行解析区域文件指出语法错误、缺失记录等各种问题。正常情况下的输出会显示zone example.local/IN: loaded serial 2024062001 OK出现OK就说明这个区域文件可以被BIND正常加载。这里我想多啰嗦一句named-checkconf和named-checkzone是两套不同的检查机制前者查主配置文件逻辑后者查区域数据文件语法两个都要做缺一不可。我见过太多人只检查了其中一个就重启服务结果照样起不来的情况。3.4 启动服务与正向解析验证配置完成后启动服务并设置开机自启sudo systemctl start named sudo systemctl enable named # 查看状态 sudo systemctl status named然后使用dig命令验证正向解析dig 192.168.56.10 www.example.local后面指定要查询的DNS服务器地址。正常的响应里ANSWER SECTION会显示www.example.local. 86400 IN A 192.168.56.20说明解析结果正确。如果没有ANSWER记录优先排查三件事区域文件是否加载成功、服务是否在运行、查询地址是否写对了。再测一下CNAMEdig 192.168.56.10 ftp.example.local返回结果里应该看到ftp.example.local. is an alias for www.example.local.并且最终解析到192.168.56.20。4. 反向解析配置全流程4.1 反向区域声明与网段理解反向解析和正向解析是镜像关系正向是“域名→IP”反向是“IP→域名”。它依赖一种特殊格式的区域名把IP地址反转后加上in-addr.arpa。比如我们要反向解析的网段是192.168.56.0/24那么区域名写为zone 56.168.192.in-addr.arpa IN { type master; file 192.168.56.zone; allow-update { none; }; };注意区域的命名规则必须把IP地址反着写。192.168.56变成56.168.192最后加上固定的in-addr.arpa后缀。这是因为DNS解析是树状结构从根域开始一层层向下查找反向解析需要从IP的最左侧网络号部分开始逐级进入。这个概念初看很绕你只要记住反向区域的名称永远是把IP地址部分倒序排列。4.2 反向区域数据文件编写创建/var/named/192.168.56.zone内容如下$TTL 1D IN SOA ns1.example.local. admin.example.local. ( 2024062001 ; serial 1D ; refresh 1H ; retry 1W ; expire 3H ) ; minimum IN NS ns1.example.local. 10 IN PTR ns1.example.local. 20 IN PTR www.example.local. 30 IN PTR mail.example.local.这里的核心记录类型是PTRPointer Record指针记录。10代表IP192.168.56.10因为区域名本身已经包含了192.168.56部分所以只需要写最后一位主机号。PTR后面跟的是完整的、带末尾点的域名名称。举个例子说明如果反向解析192.168.56.20DNS服务器会先解析20.56.168.192.in-addr.arpa然后从这条PTR记录中找到结果www.example.local.。检查权限并验证语法sudo chown root:named /var/named/192.168.56.zone sudo chmod 640 /var/named/192.168.56.zone sudo named-checkzone 56.168.192.in-addr.arpa /var/named/192.168.56.zone4.3 重启服务并测试反向解析修改了named.conf添加新区域后需要重启服务才能加载新配置sudo systemctl restart named使用dig -x参数进行反向解析测试dig 192.168.56.10 -x 192.168.56.20-x是dig的快捷反向查询参数它会自动帮你把IP转换成20.56.168.192.in-addr.arpa格式。正常输出中ANSWER SECTION应该显示20.56.168.192.in-addr.arpa. 86400 IN PTR www.example.local.这就代表反向解析成功了。另外也可以用host命令快速验证host 192.168.56.20 192.168.56.10输出类似20.56.168.192.in-addr.arpa domain name pointer www.example.local.就说明整个反向链路是通的。5. 客户端配置与全网生效5.1 Linux客户端DNS指向服务器配得再好如果客户端不指向它一切都是白搭。Linux客户端的DNS配置在/etc/resolv.confsudo vim /etc/resolv.conf写入以下内容nameserver 192.168.56.10 search example.localnameserver指定首选DNS服务器地址search是域名搜索后缀。当你直接执行ping www时系统会先尝试www如果不带点号还会自动尝试www.example.local这对内网访问非常方便。注意在部分使用NetworkManager管理的系统上直接编辑/etc/resolv.conf会被覆盖。稳定做法是在网卡配置文件里通过DNS1192.168.56.10来指定或者使用nmcli命令修改。这个细节坑过很多人如果你的配置改了重启后丢失大概率就是这个问题。5.2 Windows客户端DNS指向Windows系统在“控制面板→网络和 Internet→网络连接→更改适配器设置”里找到正在使用的网卡右键属性双击“Internet协议版本4TCP/IPv4”在首选DNS服务器处填上192.168.56.10。改完不用重启执行ipconfig /flushdns清一下本地DNS缓存即可生效。5.3 通过ping和nslookup做完整性测试配置完成后建议按以下顺序做一轮完整验证# 1. 正向解析连通性 ping www.example.local # 2. 反向解析验证 nslookup 192.168.56.20 # 3. 递归查询公网域名验证转发器是否生效 nslookup www.baidu.com 192.168.56.10第一项能通说明A记录OK第二项能返回www.example.local说明PTR记录OK第三项能返回公网IP说明递归查询和转发器配置OK。三项全过这个DNS服务器就真正意义上“上岗”了。6. 运维避坑指南与高阶扩展6.1 高频踩坑问题速查表以下是我每次做DNS配置时都会特别注意的几个高频问题整理成表格方便你对照排查问题现象可能原因解决办法服务启动失败日志报 permission denied区域文件权限不合格chown root:named chmod 640解析无结果日志报 zone not loaded区域文件语法错误或序列号异常named-checkzone 检查修正语法内网能解析但公网域名全部失败forwarders 配置缺失或上游DNS不可达检查 named.conf 的 forwarders 段修改了区域文件但解析结果不变未递增serial序列号把serial改成更大的数重启生效其他机器查询无响应listen-on 没监听内网IP确认 options 中 listen-on 包含内网IP查询超时且系统日志有DNSSEC相关报错上游递归DNS不支持DNSSEC实验环境可临时 dnssec-validation no这里特别解释一下序列号和缓存的问题。DNS原理决定了它是有缓存的即便你修改了区域文件并且重启了服务客户端本地和其他中间DNS的缓存没到期之前解析结果还是旧的。所以内网维护时如果改了IP地址建议等一个TTL周期或者主动在客户端执行systemd-resolve --flush-cachesLinux或ipconfig /flushdnsWindows清缓存。6.2 主从同步配置思路生产环境如果只有一台DNS服务器一旦宕机全网解析立即瘫痪。因此在正规一点的架构里至少会部署两台DNS主从配合。主服务器改动区域文件后通过allow-transfer把数据同步给从服务器zone example.local IN { type master; file example.local.zone; allow-transfer { 192.168.56.11; }; };从服务器配置几乎一样只需要把type master改为type slave并指定主服务器地址zone example.local IN { type slave; file slaves/example.local.zone; masters { 192.168.56.10; }; };从服务器会自动向主服务器同步区域数据file字段是本地存储副本的位置注意slave目录权限要单独设置。设置好之后可以在主服务器上手动触发一次区域传送检测rndc reload example.local然后去从服务器上查看区域文件是否有更新。6.3 日志与监控配置建议BIND默认把日志写入/var/log/messages排查问题总是翻系统日志比较费劲。我建议单独配置一个DNS日志通道方便集中查看logging { channel dns_log { file /var/log/named/dns.log versions 3 size 5m; severity info; print-time yes; }; category queries { dns_log; }; category general { dns_log; }; };versions 3 size 5m表示保留3份轮转日志每份最大5MB。这样查询日志、错误日志都会单独记录到/var/log/named/dns.log排查问题效率会高很多。在生产环境我还习惯加一个监控脚本定时检测named进程状态和各区域解析结果异常时直接告警推送这是确保DNS高可用的最后一环。7. 从实验中沉淀的核心经验最后聊点我自己的体会。做DNS配置这件事技术难度其实不高真正考验人的是对细节的敏感和排查问题的耐心。我从最早的各种踩坑到现在能快速定位问题最大的收获有三点第一任何改动都必须跑一遍named-checkconf和named-checkzone这两条命令节省的时间远超花在输入上的时间第二区域文件里的末尾点号、序列号递增、文件属主权限这三个点牢记在心能帮你躲掉至少八成的低级故障第三配置完成后一定要从“客户端视角”测试而不是只在服务器本机自测因为本机回环查询通过的案例不代表局域网内其他机器真的能用。DNS服务器一旦上线就是所有网络服务的基石。你在上面省下的每一个细节功夫都会在未来的某次故障里加倍偿还。希望这篇配置实录能帮你少走弯路把DNS配置这件事真正做成“一次性正确”。