主机调用虚拟机DNS：先搞清楚“路通不通”再动手
主机要用虚拟机上的DNS服务器，核心就三步：确认主机和虚拟机之间网络可达、确保虚拟机DNS服务监听在正确网卡上、把主机的首选DNS地址改成虚拟机IP。听起来简单，但相当一部分人卡在“改完不生效”上，问题多半出在网络模式或防火墙,而不是DNS软件本身。
为什么主机改了DNS却解析不了
很多人第一反应是打开网络设置，把DNS一填就完事，结果nslookup超时，浏览器打不开网页，这时候别急着怀疑虚拟机上的BIND或dnsmasq配错了，先问自己一句：主机真的能ping通虚拟机吗？
虚拟机的网络连接方式决定了主机能不能直接访问它的IP,用VMware或VirtualBox的人常踩这个坑：
- NAT模式：虚拟机藏在宿主机后面，主机访问虚拟机需要端口转发,直接填虚拟机IP当DNS大概率不通。
- 桥接模式：虚拟机和主机在同一网段，各自有独立IP,这是最省心的方式。
- Host-Only模式：主机和虚拟机私有网络互通，但不能上外网,适合纯内网解析场景。
行业共识认为，做DNS实验或内网解析，桥接模式优先，如果你非要用NAT，就得在虚拟化软件里把UDP 53端口转发到虚拟机，操作路径在VMware的“编辑→虚拟网络编辑器→NAT设置→端口转发”里,添加入站53端口指向虚拟机IP。
主机怎么把虚拟机DNS设为默认解析
确认网络通了之后，按操作系统分别处理，这里以虚拟机IP是168.1.50为例，你的实际IP以ip addr或ipconfig查到的为准。
Windows主机设置路径
图形界面：控制面板→网络和Internet→网络连接→右键当前网卡→属性→双击“Internet协议版本4”→勾选“使用下面的DNS服务器地址”→首选填168.1.50。
命令行更快,以管理员身份打开PowerShell：
netsh interface ip set dns name="以太网" static 192.168.1.50
改完用ipconfig /all确认，再用nslookup 你的测试域名 192.168.1.50验证，注意第二个参数显式指定DNS服务器,能绕开系统缓存干扰。
Linux主机设置路径
不同发行版路径不一样，别一刀切，Ubuntu 22.04以后默认用systemd-resolved，直接改/etc/resolv.conf会被覆盖，正确做法是编辑/etc/systemd/resolved.conf：
[Resolve] DNS=192.168.1.50 FallbackDNS=223.5.5.5
然后sudo systemctl restart systemd-resolved，想确认生效，resolvectl status看当前DNS指向。
CentOS或RHEL系用NetworkManager的,可以：
nmcli con mod "ens33" ipv4.dns "192.168.1.50" nmcli con up "ens33"
Debian老版本直接写/etc/resolv.conf的nameserver 192.168.1.50也能用，但要留意cloud-init或DHCP客户端会不会重写。
虚拟机搭DNS服务器主机访问不了怎么排查
这是搜索量很高的长尾场景，症状通常是主机填了虚拟机IP，但解析超时，按下面顺序查,基本能定位。
第一查：DNS服务监听地址对不对
以BIND9为例，默认配置只监听0.0.1，主机当然连不上，打开/etc/bind/named.conf.options,确认有：
listen-on { any; };
listen-on-v6 { any; };dnsmasq则检查/etc/dnsmasq.conf里有没有listen-address=192.168.1.50，或者interface=ens33，改完重启服务：sudo systemctl restart named或sudo systemctl restart dnsmasq。
用ss -tulnp | grep :53看监听状态，出现0.0.0:53或虚拟机具体IP才算对，只看到0.0.1:53,主机永远连不上。
第二查：防火墙放行53端口
虚拟机上开了firewalld的：
sudo firewall-cmd --permanent --add-service=dns sudo firewall-cmd --reload
用ufw的：
sudo ufw allow 53/tcp sudo ufw allow 53/udp
DNS查询主要走UDP 53，但区域传送和部分大响应走TCP,两个都放行省事。
第三查：主机多网卡和DNS优先级
Windows主机同时连WiFi和插网线时，系统可能按接口跃点数决定用哪个DNS。Get-DnsClientServerAddress能看每个网卡的DNS配置，Get-NetIPInterface看跃点数，想让虚拟机DNS优先，可以把对应网卡的接口跃点数调小,或者干脆临时禁用另一个网卡做验证。
Linux上resolvectl status会列出每个链路的DNS，systemd-resolved按链路优先级查询。resolvectl dns ens33 192.168.1.50可以给指定网卡单独设DNS。
跨网段场景下主机调用虚拟机DNS的实操方法
公司内网跨网段主机怎么用虚拟机DNS，这个问题比单机实验复杂一层，假设虚拟机在0.1.0/24，主机在0.2.0/24,中间隔着三层设备。
第一步，虚拟机DNS服务器要配置转发或递归，如果是内网域名解析，在BIND的named.conf.local里定义zone；如果是转发到上游，配forwarders { 223.5.5.5; };并允许allow-query { any; };或至少包含0.2.0/24。
第二步，确认路由可达，主机上ping 10.0.1.50和tracert 10.0.1.50能通，说明三层路由没问题,不通就找网络管理员加静态路由或检查ACL。
第三步，主机DNS指向虚拟机IP，但注意跨网段时防火墙策略往往更严，除了虚拟机自身防火墙，中间的三层设备或安全组也可能拦UDP 53，据工信部相关网络运行报告，企业内网故障中配置类问题占较大比例,其中访问控制策略遗漏是常见原因之一。
自建虚拟机DNS的成本账：为什么很多团队不花钱也能跑
有人会问，专门买商业DNS解析服务不省事吗，对公网域名来说确实如此，但内网解析场景不一样，一台跑BIND或dnsmasq的虚拟机，资源占用很低，512MB内存、单核就够支撑中小规模内网查询，硬件就是现有虚拟化平台里挤出来的资源,边际成本接近于零。
相比之下，商业内网DNS方案按节点或查询量计费，长期下来是一笔订阅开支，业内专家指出，内网DNS的核心诉求是可控和低延迟，自建虚拟机在这两点上优势明显，当然前提是你得把本文前面的网络和防火墙配明白,否则省下的钱会变成排查故障的时间成本。
验证与日常维护要点
配完不是就结束了。dig和nslookup是最直接的验证工具：
dig @192.168.1.50 example.internal +short nslookup example.internal 192.168.1.50
返回正确A记录说明链路通了，再在主机浏览器访问内网域名,确认应用层也正常。
日常维护注意两点：虚拟机IP别用DHCP随机分配，在虚拟化平台或系统里配静态IP，或者DHCP做MAC绑定保留；DNS服务配置文件改之前备份，BIND用named-checkconf和named-checkzone做语法检查,避免重启直接挂掉。
关于主机使用虚拟机DNS的常见疑问
主机能同时用虚拟机DNS和公共DNS吗
可以，设主备DNS即可，首选填虚拟机IP，备用填5.5.5或29.29.29，但要注意解析行为：主机查询首选DNS超时后才切备用，如果虚拟机DNS服务挂了但网络通，查询会先等超时再回落，体感上有延迟，内网域名必须在虚拟机DNS上配好,公共DNS不认你的私有域名。
虚拟机重启后IP变了导致主机DNS失效怎么办
根因是虚拟机用了DHCP且没做保留，解决办法二选一：在虚拟机系统内配静态IP，或者在虚拟化平台的DHCP服务里给虚拟机网卡MAC地址绑定固定IP，改完主机侧不用动，因为DNS地址没变，如果已经乱了，先ip addr查新IP，再改主机DNS指向,然后回头把静态IP配上。
主机nslookup指定虚拟机DNS能解析但浏览器打不开网页是什么原因
先看主机默认DNS是否真的生效，ipconfig /all或resolvectl status确认首选DNS是虚拟机IP，再看浏览器有没有开安全DNS（DoH），Chrome和Edge的设置里“使用安全DNS”如果开启，会绕过系统DNS直接走加密查询，内网域名自然解析不了，关掉即可，最后清一下主机DNS缓存，Windows用ipconfig /flushdns，Linux用resolvectl flush-caches,再试。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/792412.html
