1. 项目概述CentOS下的域名解析配置到底要做什么第五个年头做Linux运维最常见的需求之一就是“帮我把域名解析配置上”。这句话在上线部署、内网服务联调、测试环境搭建里反复出现。尤其是新买了一台CentOS服务器业务程序部署完了域名却迟迟解析不了业务访问全靠IP硬拼——这时候就需要把域名的解析配置梳理清楚。我说的“CentOS配置域名解析”实际上涵盖了两种最常见的情况一是把某个域名解析到一台CentOS服务器的IP地址也就是常说的A记录、CNAME记录配置让用户可以通过域名而不是一长串IP访问你的服务二是在这台CentOS服务器上自建一个DNS解析服务通常用BIND 9为整个内网提供域名解析能力管理一批内部域名和主机的对应关系。简单说这篇文章要解决的是域名解析的原理、CentOS上如何安装配置DNS服务端、如何配置正向与反向解析、如何做客户端侧验证以及我在真实环境里踩过的那些坑。如果你是刚入门Linux运维不久的新手或者正在给公司内网搭一套自己的DNS这篇文章可以当个参考手册如果你已经有几年经验可以直接跳到“常见问题与排查技巧”那节我把自己遇到的典型故障都整理成了速查表应该能帮你少走弯路。2. 方案设计先弄懂解析过程再决定用哪种配置方案2.1 域名解析的本质一本分布式的电话本无论做什么配置先把原理过一遍才不会犯迷糊。DNSDomain Name System本质上就是一台巨大的电话本服务器把“人类能记住的域名”比如example.com翻译成“网络能够路由的IP地址”比如192.168.1.10。当你访问某个域名的时候解析请求是按照“客户端 → 本地DNS服务器 → 根服务器 → 顶级域服务器 → 权威DNS服务器”这条链路逐级查询的。最终找到那个真正“说了算”的权威DNS服务器它返回一条A记录把域名和IP绑定起来你的浏览器才能找到对应服务器。在CentOS上配置域名解析本质上有两种方向客户端方向修改本机的DNS指向/etc/resolv.conf让这台机器把域名解析请求发送到指定DNS服务器比如所在内网的DNS服务器或公共DNS服务商。服务端方向在这台CentOS上安装并配置DNS服务BIND让这台机器变成“权威DNS服务器”对外为某个域名提供解析记录。别人查这个域名时最终会找到你这台机器来拿IP地址。这篇文章重点讲的是第二种——在CentOS上自建DNS服务解决内网域名解析的问题。因为第一种改resolv.conf太简单了三分钟就能讲完真正考验技术的是搭建一个能稳定对外服务的DNS解析服务。2.2 自建DNS还是使用公共DNS为什么选BIND有人可能会问现在云服务商、域名注册商都自带DNS解析服务直接在后台添加解析记录不就行了为什么非要在CentOS上自己搭一套我实际工作中遇到的主要是这些场景内网环境无法访问外网比如某公司内部办公网与互联网隔离内部业务系统互相调用需要解析内部域名公共DNS根本查不到这些域名。需要解析自定义的内部域名后缀比如 .local、.lan或者公司内部独有的业务域名这些域名在公网不存在只有内网自建DNS能够提供解析。需要精细化控制解析行为比如在测试环境做域名劫持、负载均衡轮询、根据来源IP返回不同结果公共DNS服务商后台给不了这么细粒度的控制。在这些场景下BINDBerkeley Internet Name Domain是Linux平台上最经典的DNS服务程序。CentOS的官方软件仓库里直接提供了bind、bind-utils、bind-chroot这几个包安装配置都很成熟社区资料也最丰富遇到问题搜索解决方案几乎都能找到。虽然不是性能最强的DNS服务器性能和并发方面更极致的方案还有PowerDNS、Knot等但对绝大多数的中小型内网场景来说BIND完全够用了。2.3 配置文件层次主配置、区域配置、区域数据BIND的核心机制可以简单理解成三层主配置文件 /etc/named.conf定义服务怎么运行监听哪些端口和地址、允许谁查询、转发配置等同时声明这个服务器负责哪些“区域”zone。区域配置文件定义某个具体域名的解析数据。比如example.com这个区域会有对应的一个文件来存放NS记录、A记录、MX记录等IP段的反向解析如1.168.192.in-addr.arpa也是一个单独的区。缓存与转发机制BIND既可以是权威服务器自己说了算也可以是递归服务器帮客户端去上游DNS查。生产环境里通常一个内网DNS同时承担两种角色对自己负责的域名提供权威答案对不认识的域名向上游转发或递归查询。理解了这三层关系你就知道配置从哪下手了先改主配置声明区域再为每个区域准备对应的数据文件最后用语法检查工具验证无误后重启服务三件事而已。注意既然选择了BIND前提是这台CentOS服务器的IP地址必须是固定静态的而不是DHCP动态获取的。DNS服务器和动态IP的组合是个灾难客户端缓存了错误IP排查起来能让人崩溃。3. 环境准备安装BIND并完成基础配置3.1 安装bind及配套工具在CentOS 7和CentOS 8 / Stream上软件包安装方式是一样的我平时两种版本都在用。登录服务器后先更新一下软件索引再安装bind。dnf update -y dnf install -y bind bind-utils bind-chroot如果你用的是CentOS 7把dnf换成yum就行包名完全一样。这里顺便说一下bind-utils这个包非常关键。它里面包含了dig、nslookup、host这些域名查询工具后面的验证步骤全都靠它们。bind-chroot则会把BIND的默认路径做一个隔离把服务限制在一个专门的目录环境下从安全角度更稳妥。但chroot模式会让配置文件的路径变一层新手容易绕晕。我的建议是测试环境或者初次练习可以先不装bind-chroot减少路径绕来绕去的负担生产环境强烈建议保留chroot隔离安全底线不能丢。如果你之前已经装过、但不确定装的是什么版本可以用这个命令查看rpm -qa | grep bind named -v正常情况下会输出“BIND 9.x.x”。看到版本号说明BIND已经就位。3.2 检查端口、防火墙和SELinux状态DNS服务默认走UDP和TCP的53端口。UDP 53负责正常查询TCP 53负责区域传送和超大响应传输。安装完bind后还不能直接启动先把三个环境因素检查到位否则启动后会发现各种诡异问题。防火墙检查firewall-cmd --state firewall-cmd --list-all如果firewalld在运行且你需要对外提供DNS服务放行53端口firewall-cmd --permanent --add-port53/tcp firewall-cmd --permanent --add-port53/udp firewall-cmd --reload如果用的是传统的iptables就自行添加对应规则。这一步经常被漏掉最后在服务器本机dig能通、换台机器就不通十有八九是防火墙拦了。SELinux检查getenforce如果是Enforcing状态BIND默认策略可能会限制它读写主配置、区域文件。虽然CentOS自带了一套适用于named的SELinux策略但有时候自定义了区域文件的路径或权限还是会碰到Permission Denied。临时调试可以先setenforce 0看能不能复现问题但生产环境不要长期关闭SELinux应该调整布尔值或文件上下文来放行。还要确认系统里没有别的进程占用53端口ss -lnp | grep :53如果之前有dnsmasq或者别的DNS服务占用着53端口BIND会启动失败报“address already in use”这时候需要先停掉之前的服务进程。3.3 修改主配置文件named.confBIND主配置文件的默认路径是/etc/named.conf。安装完成后系统会生成一个默认配置但里面的监听地址、允许查询网段都是最保守的设置不能直接满足内网解析需求。我先给一个适合内网自建DNS场景的最小可用配置你可以直接参考修改vim /etc/named.confoptions { listen-on port 53 { any; }; listen-on-v6 port 53 { any; }; 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; allow-query { any; }; recursion yes; allow-recursion { 192.168.0.0/16; 127.0.0.1; }; dnssec-enable no; dnssec-validation no; }; logging { channel default_debug { file data/named.run; severity dynamic; }; }; zone . IN { type hint; file named.ca; }; include /etc/named.rfc1912.zones; include /etc/named.root.key;这里面有一个地方专门说明一下allow-query { any; }表示允许所有客户端向这台DNS服务器查询域名allow-recursion收窄到内网网段避免被外部机器利用做递归查询放大攻击。dnssec-enable和dnssec-validation我直接关掉了是因为在内网场景中许多自定义区域没有DNSSEC签名开着反而会导致解析被拒绝。如果你的环境需要DNSSEC再单独开启也不迟。写完后可以用named-checkconf检查主配置语法named-checkconf /etc/named.conf没有任何输出说明语法正常。这个检查习惯要养成我见过太多人改完配置直接重启服务、结果服务起不来的情况其实就是多一个检查步骤的事。4. 正向解析配置把域名解析到IP的完整实操4.1 正向区的作用与配置思路所谓正向解析就是“域名 → IP”。你要让客户端通过访问www.example.local找到 IP 为192.168.10.5的服务器就需要在BIND里添加一个名为example.local的区域并在区域数据文件里写入这条www的 A 记录。在BIND里配置一个正向区需要做两件事在主配置中声明区域创建该区域的区域数据文件。4.2 手工声明一个区域为了不破坏RHEL系自带的named.rfc1912.zones文件结构我习惯新建一个独立的区域配置文件然后在主配置中include它。创建一个区域配置vim /etc/named.rfc1912.zones在文件末尾添加上下面的内容如果已经存在默认的localhost区域不用动zone example.local IN { type master; file example.local.zone; allow-update { none; }; };解释每个字段的含义type master这个区域由本机作为权威主服务器数据文件是权威来源。file example.local.zone指向区域数据文件的文件名。如果没写绝对路径默认都在主配置里directory指定的/var/named目录下。allow-update { none; }禁止动态DNS更新。除非你有特殊需求比如配合DHCP做动态注册否则都建议保持none避免区域数据被外部请求篡改。4.3 编写正向区域数据文件然后创建对应的数据文件vim /var/named/example.local.zone写入如下内容$TTL 1D IN SOA ns1.example.local. root.example.local. ( 2025012301 ; serial更新序号 1D ; refresh从服务器刷新时间 1H ; retry失败重试时间 1W ; expire数据过期时间 3H ) ; minimum最小TTL IN NS ns1.example.local. ns1 IN A 192.168.10.2 www IN A 192.168.10.5 db IN A 192.168.10.6这段配置要稍微展开说明$TTL 1D表示默认的生存时间是1天意思是客户端和下级DNS服务器在一天内可以缓存这条记录。如果网站IP需要频繁变更把TTL调小到300秒左右可以加速缓存失效和更新。代表当前区域名也就是 example.local。SOA记录是整个区域的“源头信息”其中ns1.example.local.是主权威DNS服务器的名字root.example.local.是管理员的邮箱这里把邮箱的替换成点号括号里的五个数字是区域版本信息分别是序列号serial、刷新时间refresh、重试时间retry、过期时间expire、最小缓存时间minimum。特别注意ns1.example.local这条记录的最后都有一个点.。在DNS区域数据文件里绝对域名需要以点结尾如果漏掉这个点BIND会认为它是一个相对当前区域的名称自动拼上example.local后缀结果完全变样。这个点是新手最容易忽略的地方也是最常见的“配置了但解析不出来”的元凶。NS记录声明了区域的权威DNS服务器是谁这里指到ns1.example.localns1、www、db这些是主机记录每条对应一条A记录把域名映射到具体的IP地址。提醒区域数据文件里的IP地址、域名写完后最好逐项核对一遍。这类文件没有智能纠错一个IP少打一位数字排查的时候要发现可不容易。4.4 检查区域文件并重新加载服务写完数据文件千万别急着重启服务。先用两个语法检查工具做静态校验named-checkzone example.local /var/named/example.local.zone如果输出类似“zone example.local/IN: loaded serial 2025012301”说明文件语法正确、能够正常加载。确认无误后重新加载服务不需要重启减少服务中断时间systemctl reload named如果你改了named.conf之后才做这步建议直接用restart或者先reload、再观察状态systemctl restart named systemctl status named到这一步正向解析配置已经完成但还没结束——你需要验证它是否真的生效。4.5 用dig验证正向解析结果验证是最高优先级的一步。我一般会在BIND服务器本机上先查一次再去客户端机器上查一次避免“服务端自己好使、别人全挂”这类边界问题。在服务器本机执行dig 127.0.0.1 www.example.local正常回包中ANSWER SECTION部分会显示;; ANSWER SECTION: www.example.local. 86400 IN A 192.168.10.5看到这个说明正向解析链路已经通了一半。如果只想快速看结论用dig short www.example.local能直接输出IP地址。再测试一下NS记录dig 127.0.0.1 example.local NS确保NS记录返回的是你配置的ns1.example.local。5. 反向解析配置让IP地址也能查出域名5.1 反向区的作用反向解析的作用正好和正向相反是把IP地址解析成域名。例如你拿到一个IP 192.168.10.5想知道它对应哪个域名就用反向查询。在邮件服务器反垃圾过滤、日志审计、网络故障定位这些场景中反向解析是高频需求。不过要提醒一下内网自建DNS的反向解析只对你自己负责的IP网段有意义。公网IP的反向解析权限掌握在ISP手里你没法通过自建BIND直接控制。5.2 配置反向区的两个步骤反向解析也要声明区域。IP 192.168.10.0/24这个网段对应的反向区域名是10.168.192.in-addr.arpa也就是把IP倒过来写加上in-addr.arpa后缀。在named.rfc1912.zones文件里继续添加zone 10.168.192.in-addr.arpa IN { type master; file 192.168.10.zone; };然后创建反向区域数据文件vim /var/named/192.168.10.zone内容参考$TTL 1D IN SOA ns1.example.local. root.example.local. ( 2025012301 1D 1H 1W 3H ) IN NS ns1.example.local. 5 IN PTR www.example.local. 6 IN PTR db.example.local.看到没有反向文件里的主机名变成了IP的最后一段记录的格式是PTR记录。例如5 IN PTR www.example.local.表示 192.168.10.5 对应域名www.example.local.。同样用named-checkzone做校验named-checkzone 10.168.192.in-addr.arpa /var/named/192.168.10.zone然后reloadsystemctl reload named验证反向解析dig -x 192.168.10.5 127.0.0.1能查到PTR记录说明反向配置完成。这里有个常被忽略的细节两条PTR记录末尾的域名必须和正向区域里那条A记录完全一致不能把点漏掉不能大小写不一致。如果正向A记录里写的是www.example.local.反向PTR里写成www.example.local少个点BIND会把域名拼成www.example.local.10.168.192.in-addr.arpa之类的鬼东西解析结果自然不对。6. 客户端配置与联调让其他机器也用上你的DNS6.1 Linux客户端修改DNS配置DNS服务搭建好了其他机器要能够通过它解析域名。Linux客户端的DNS配置写在 /etc/resolv.conf 里修改方式如下vim /etc/resolv.conf把这个文件改成nameserver 192.168.10.2 domain example.local search example.localnameserver指定这台客户端使用的DNS服务器IPsearch用于“短域名自动补全”。比如你在内网直接敲ping web系统会自动尝试解析web.example.local体验很好。不过要提醒在 CentOS 7 / 8 里如果系统使用了 NetworkManager 管理网络resolv.conf 文件可能被NetworkManager自动覆盖。你改了之后过一小会儿又变回去。解决办法有两种其一修改网卡配置文件把DNS永久写入。在 /etc/sysconfig/network-scripts/ifcfg-eth0具体ifcfg文件名取决于你的网卡名里增加DNS1192.168.10.2然后重启网络服务systemctl restart NetworkManager其二按网段推送DNS比如路由器或DHCP服务器上把分配给客户端的DNS指到这台BIND服务器。这样不管客户端从哪获取IP拿到的都是同一个DNS配置更省事。6.2 Windows客户端侧验证如果是Windows办公机器打开“网络和共享中心 → 更改适配器设置 → 右键当前网卡 → 属性 → 协议版本4(TCP/IPv4)”然后把首选DNS服务器填成BIND服务器的IP比如192.168.10.2。配置完成后用命令行验证nslookup www.example.local正常会返回名称: www.example.local地址: 192.168.10.5。如果提示找不到主机先排查看网络通不通、防火墙是否放行、配置是否写错。6.3 联调时应该做哪些检查客户端配置完后我通常按下面这个顺序过一遍先检查客户端能不能ping通DNS服务器IP解决网络连通性问题。用telnet或nc测试UDP/TCP 53端口是否可达解决防火墙和端口问题。用nslookup/dig查询一个正向和一个反向解析记录解决配置和数据文件问题。在客户端和服务器上分别查询一次对比结果解决地域/缓存不一致的问题。比如在客户端上执行dig 192.168.10.2 www.example.local用指定去哪个DNS服务器查询这样能避免走到系统默认的resolv.conf逻辑排查更精准。7. 常见问题与排查技巧实录我踩过的坑都在这里7.1 服务起不来日志报权限拒绝这个问题最容易发生在启用了SELinux的环境里。named进程试图写区域文件或读取自定义路径时SELinux直接拒绝服务根本启动不了。我当时遇到的场景是自己手工在/var/named/下创建的文件属主看起来没问题权限也是644但named一样报Permission Denied。排查命令journalctl -u named -n 50或者看/var/log/messages会看到类似下面的报错dns_master_load: open: /var/named/example.local.zone: permission denied解决方案是调用SELinux提供的布尔值开关允许named写主区域文件setsebool -P named_write_master_zones 1如果问题依旧再看文件的SELinux上下文是不是被改了比如从别的目录拷来的文件ls -Z /var/named/example.local.zone正常应该是named_zone_t类型。如果不是手动修正restorecon -v /var/named/example.local.zone7.2 客户端能解析但总是超时BIND服务端收到查询请求也返回了结果但客户端在这中间出现了超时。这种情况优先怀疑防火墙。防火墙虽然放行了UDP 53但某些情况下比如默认拒策略把UDP相关回包拦了表现就很怪异。稳妥的做法是确认放行规则同时覆盖TCP和UDPfirewall-cmd --permanent --add-servicedns firewall-cmd --reload如果服务器前还有云安全组或硬件防火墙也要一并放行53端口。我在一次多网卡服务器维护中遇到过DNS服务器本机内网IP可以解析但其他网段的客户端总是超时后来才发现是安全组策略里只放行了某个网段的53端口其余网段全被拦了。7.3 resolv.conf一直自动变回去CentOS里NetworkManager对DNS配置的管控很强。手工修改/etc/resolv.conf后只要重启网络服务或者重启系统Content可能就被覆盖回之前的设置。这个问题的根治办法是修改ifcfg网卡配置里的DNS1/DNS2参数或者用nmcli设置nmcli con mod eth0 ipv4.dns 192.168.10.2 nmcli con up eth0改完以后再验证cat /etc/resolv.conf此时看到nameserver已经是新地址才算彻底保住。7.4 正向能解析反向却查不到反向解析不出结果原因往往是反向区域名称写错。比如IP是10.168.192区域名要倒过来写成10.168.192.in-addr.arpa很多人会漏掉arpa后缀或把顺序写错。另一个隐形原因是区域数据文件里PTR记录的域名末尾少了点号。参考前面提到的绝对域名以点结尾的规则逐项检查。建议在named.conf和区域文件修改后全部执行一次named-checkzone 10.168.192.in-addr.arpa /var/named/192.168.10.zone如果输出加载成功基本可以排除语法层面的问题。7.5 修改了记录但客户端还在用旧IPDNS缓存是解析故障里的大头。你改了A记录客户端查到的还是旧IP大概率是缓存问题。影响缓存的因素主要有三个解析请求经过的递归DNS服务器有缓存需要等待TTL自然过期客户端操作系统有本地DNS缓存Windows的ipconfig /flushdns可以清掉浏览器自身有DNS缓存Chrome的net-internals可以清。因此如果预计要改IP建议在变更前把TTL调低比如300秒等变更后确认稳定再把TTL调回正常值。这是我做域名迁移总结出来的经验初期没低TTL一个旧IP被缓存了整整一天用户全部访问异常。7.6 常见问题速查表问题现象可能原因排查命令/手段解决建议服务启动失败端口被占用ss -lnp | grep :53停止冲突进程或改BIND监听端口服务启动失败配置语法错误named-checkconf根据报错行号和内容修正配置查询报REFUSEDallow-query未放行客户端IP查看named.conf修改allow-query或allow-recursion查询报SERVFAIL区域文件加载失败named-checkzone重点检查域名末尾点号、权限查询超时防火墙未放行53端口firewall-cmd --list-all放行tcp/udp 53端口记录改动不生效TTL或缓存未过期dig noall answer调低TTL、逐层清理缓存反向查不到PTR域名末尾少点named-checkzone反向文件检查绝对域名结尾点SELinux权限错误区域文件上下文不对ls -Z /var/named/*.zonerestorecon或调整布尔值7.7 排查前的通用准备碰到DNS解析问题第一步不要急着改配置先在故障机器上做一个基线测试dig trace www.example.local这条命令会一步步展示从根服务器开始的完整查询链路你能直观看出问题出在哪一级是区域文件没加载还是递归上游断了或是权威服务器不回包。再配合下面几条命令抓取现场dig ANY example.local 127.0.0.1 dig NS example.local 127.0.0.1 rndc statusrndc status能显示BIND当前的运行状态、版本和配置信息也是排查利器。8. 扩展方向与我的个人体会域名解析配置这件事看起来就是把几个文件写好但真正价值在于你把这套基础服务搭稳了以后后续能扩展很多能力。比如给BIND配置“域名转发”把特定后缀的域名转给上级DNS解析其他域名转发给公共DNS实现内外网域名解析的融合。再比如配合DHCP服务器做动态DNS更新让客户机拿到IP的同时自动注册主机名客户端用主机名就能互相访问省掉手工维护DNS记录的精力。还可以在BIND里配置访问控制列表实现基于来源IP的解析策略内网和访客网络看到的结果不一样这种精细控制在一些企业场景里很实用。我个人的习惯是每次搭建完DNS服务都要备份一套配置和数据文件用 git 管理起来。因为DNS服务的配置总是“一劳永逸”之后又突然变动有版本控制回溯起来非常舒服。最后再分享一条实操技巧做任何DNS变更前先在本地跑一次dig把当前结果存下来改完配置再跑一次做对比。这样每次变更前后的差异一目了然不会稀里糊涂改完发现结果没变化还不知道问题出在哪个配置块里。DNS问题排查讲究的就是步步有依据记录和对比是成本最低、收益最高的两个习惯。