内网域名解析不必购买商业DNS设备，用一台Linux服务器部署dnsmasq或BIND9，十分钟就能搞定，局域网内所有机器都能用上自定义的“机器名.内网”域名。
很多人觉得搭DNS是件特别“重”的事，动不动就想到要搞一套复杂的Windows Server活动目录，在内网环境里，我们绝大多数需求只是“把几个服务地址变成好记的名字”，或者“给几十台测试机做统一解析”，这类场景，用轻量级的dnsmasq就够了，只有当你需要复杂的域名分区、视图转发或者严格的主从同步时，才轮到BIND9出手，下面我直接按需求分层来聊,你照着抄作业就行。
哪种方案更适合你的内网环境
动手之前，先花一分钟想清楚你要解决什么问题,这决定了你该装哪个软件。
轻量场景：用dnsmasq做缓存和基础解析
如果你只是想让内网机器能通过gitlab.local访问GitLab，或者想拦截一部分广告域名，dnsmasq是首选，它的配置文件是一行行的address=/域名/IP，逻辑极其简单，几乎没有学习成本，资源占用也极低，一台树莓派或者虚拟机都跑得动，行业共识认为，超过80%的中小企业内网DNS需求,dnsmasq完全可以覆盖。
中大型场景：用BIND9做权威解析和智能转发
如果公司网络里有多个网段，不同部门需要看到不同的解析结果（比如开发环境与生产环境隔离），或者你想做一个真正意义上的内网根域，那么BIND9会更合适，它支持zone文件、ACL权限控制、view视图拆分，功能非常完整,但配置语法相对复杂。
省事思路：AdGuard Home的Web界面
说到内网DNS服务器搭建，其实还有第三条路AdGuard Home，它自带网页管理界面，添加DNS重写记录只需要在表单里填IP和域名，还能顺带看查询日志和拦截统计，如果你不想碰命令行，这是最“傻瓜”的方案。
dnsmasq搭内网DNS服务器的详细操作
下面进入实操，假设你手头有一台Ubuntu 22.04系统的服务器，IP是168.1.10,我们要让它成为全网段的DNS服务器。
安装与基础配置
第一步，SSH登录服务器,更新软件源后直接安装：
sudo apt update sudo apt install dnsmasq -y
装完之后先停掉服务，因为默认配置会直接读取系统resolv.conf,可能会干扰我们的手动设定：
sudo systemctl stop dnsmasq接下来编辑主配置文件/etc/dnsmasq.conf,把默认的解析逻辑改掉：
sudo nano /etc/dnsmasq.conf找到并注释掉默认的resolv-file行,添加如下内容：
# 监听所有网卡
listen-address=0.0.0.0
# 允许所有内网客户端查询
no-dhcp-interface=
# 本地域名后缀
domain=local
# 上游DNS指向公共DNS或公司出口DNS
server=223.5.5.5
server=119.29.29.29
# 开启日志，方便排查
log-queries
log-facility=/var/log/dnsmasq.log这份配置的意思是：我监听所有网卡，遇到无法解析的域名，就转发给阿里和腾讯的公共DNS。domain=local则明确了我们内网使用.local作为顶级后缀。
添加内网解析记录
关键的一步来了，在配置文件末尾追加你想要的解析记录，格式是ip地址在前，域名在后：
address=/gitlab.local/192.168.1.20
address=/wiki.local/192.168.1.21
address=/jenkins.local/192.168.1.22这样，客户端请求gitlab.local时，就会直接返回168.1.20，不会走外网，如果你需要做泛解析（即所有.dev.local都指向某台机器）,可以写成：
address=/dev.local/192.168.1.30启动服务并验证
保存配置后启动服务,并设置开机自启：
sudo systemctl start dnsmasq
sudo systemctl enable dnsmasq验证方法分两步,先在DNS服务器本机测试：
nslookup gitlab.local 127.0.0.1能返回168.1.20就说明服务正常，然后找一台内网机器，把它的DNS服务器地址改为168.1.10，再执行同样的命令，如果通了,说明内网DNS搭建成功。
防火墙放行
别忘了开放UDP和TCP的53端口：
sudo ufw allow 53/tcp
sudo ufw allow 53/udpBIND9配置企业级内网域名解析
当你的需求上升到“需要主从同步”或者“多视图”时，dnsmasq就显得力不从心了，BIND9虽然配置繁琐，但能力上限高,这里只说单机权威DNS的配置路径。
先安装：
sudo apt install bind9 -yBIND的配置文件放在/etc/bind/目录，我们重点关心named.conf.local这个文件，编辑它，定义一个叫intranet.local的zone：
zone "intranet.local" {
type master;
file "/etc/bind/db.intranet.local";
};然后创建zone文件，BIND的zone文件格式和dnsmasq完全不同，需要手动写SOA记录和NS记录，这里给出一个常见的正向解析文件模板,你需要修改邮箱地址和域名序列号：
$TTL 86400
@ IN SOA ns1.intranet.local. admin.intranet.local. (
2026021501 ; 序号，改配置后要递增
3600 ; 刷新时间
1800 ; 重试时间
604800 ; 过期时间
86400 ) ; 最小TTL
@ IN NS ns1.intranet.local.
ns1 IN A 192.168.1.10
www IN A 192.168.1.80
db IN A 192.168.1.81保存后，用named-checkzone命令检查语法：
sudo named-checkzone intranet.local /etc/bind/db.intranet.local一切正常的话，重启服务并做与dnsmasq相同的验证即可，注意，BIND9的配置逻辑要求你相当精确地掌握DNS协议，比如代表当前域，A记录是IPv4地址映射,这些概念不容出错。
Windows内网环境如何配置客户端解析
服务器端搭好了，客户端的配置才是真正交付给用户的一环，如果你的规模不大，可以直接在每台机器的网卡属性里改DNS,但更高效的做法是去路由器或DHCP服务器里统一下发改好的DNS地址。
手动修改与DHCP分发
以Windows 10/11为例，路径是：设置 -> 网络和Internet -> 更改适配器选项 -> 右键网卡属性 -> 双击IPv4协议 -> 勾选“使用下面的DNS服务器地址”，填入168.1.10，在路由器后台的DHCP设置里，通常也能找到DNS服务器选项,改成内网IP即可。
用hosts文件的适用场景
需要明白一个区别：如果只有两三台机器需要访问内网域名，那根本不用搭DNS，直接改各自机器的C:WindowsSystem32driversetchosts文件就行，搭DNS的价值在于集中管理，当你要修改某个服务IP时，只需要改一处，所有客户端自动生效,而不必挨个去改hosts。
内网DNS服务搭建后的排障指南
经常遇到的情况是，搭建教程都跟了，服务也起来了，但客户端就是解析不成功,这里列出几个高频问题。
- 检查防火墙是否放行53端口,很多测试不通过都是因为云服务器安全组没有放行。
- 用
dig gitlab.local @192.168.1.10来对比nslookup的结果，dig输出信息更详细,能看到具体的查询状态和返回的A记录。 - 查看dnsmasq日志
/var/log/dnsmasq.log，看查询是否到达服务器,以及被转发到了哪里。 - 确认客户端的“主DNS后缀”没有配置错误,有时候Windows机器自带的上网后缀会干扰短域名的解析。
- 如果你的服务器本身是双网卡，注意
listen-address=0.0.0.0是否生效，可以用ss -lunp | grep 53监听命令查看端口是否绑定到所有网卡。
关于内网域名解析的常见故障还有一点很值得提：上游DNS服务器的选择，如果你的内网需要访问某些外网域名，而上游DNS无法递归查询，那么所有解析都会失败，此时建议将上游DNS地址设置为你本地运营商的DNS，或者你可以写一个server=/cn/114.114.114.114之类的规则,针对特定后缀走不同上游。
内网DNS服务器搭建常见问题解答
Q：dnsmasq和BIND9哪个更适合拿来搭内网DNS服务器？
A：少于50台机器、只需A记录解析，直接用dnsmasq；需要多视图、主从同步、严格ACL控制的场景，选BIND9，前者的配置只有几行,后者的zone文件规则与应用需要额外学习时间。
Q：内网域名解析配置好了，但是重启路由器后失效怎么办？
A：通常是因为路由器自身也下发DNS给客户端，且下发的地址优先级高于你手动配置的，需要进入路由器后台，将DHCP服务中的DNS服务器地址固定为你的内网DNS服务器IP，并确保该地址是静态IP,不会因DHCP租约变化而变动。
Q：内网DNS解析不了外网域名是什么原因？
A：逐一排查上游DNS转发是否配置正确，服务器自身能否通过53端口访问公共DNS，以及本地防火墙的出口规则是否拦截了UDP/53流量，排除这三项后,问题大多能定位。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/748453.html
