虚拟机DNS代理配置的核心思路是：让宿主机或内网DNS服务器接管虚拟机的DNS请求，通过转发规则同时处理公网域名和内网域名解析；内网域名解析失败时，优先检查虚拟机的DNS指向是否可达、代理服务是否正常转发、以及内网域名的权威记录是否完整。
为什么虚拟机老是解析不了内网域名
先搞清楚问题出在哪一环，才能对症下药，大部分情况下，虚拟机解析不了内网域名，不是虚拟机本身坏了,而是它的DNS请求压根没送到正确的地方。
排查链路：从虚拟机到DNS服务器
虚拟机发起域名解析请求，路径是这样的：虚拟机 → 虚拟网卡 → 虚拟交换机 → 宿主机网络 → 内网DNS服务器（或DNS代理），这条链路上任何一环出问题,都会导致解析失败。
- 第一步，在虚拟机里ping网关地址,确认网络通不通。
- 第二步，检查虚拟机的DNS配置,是不是指向了内网DNS服务器。
- 第三步，在虚拟机上执行
nslookup 内网域名 内网DNSIP,强制指定DNS服务器测试。 - 第四步，如果指定DNS服务器能解析，但虚拟机默认配置解析不了,问题就在DNS代理或转发规则上。
最常见的坑：虚拟机用了公网DNS
很多人在虚拟机里图省事，直接把DNS设置为8.8.8或114.114.114，然后发现内网域名怎么都解析不了，原因很简单：公网DNS服务器上根本没有你们公司内网域名的记录，行业共识是，内网域名必须由内网DNS服务器或DNS代理来解析,公网DNS只负责公网域名。
另一个常见坑：VMware或Hyper-V的虚拟网络模式选错了
在VMware Workstation里，虚拟机使用NAT模式时，默认会通过宿主机转发DNS请求，这时候如果宿主机的DNS配置不对，虚拟机的解析就会出问题，桥接模式相对好一些，虚拟机直接获取局域网IP和DNS，而在Hyper-V里，默认交换机（Default Switch）自带NAT，DNS转发逻辑和VMware NAT类似,容易出现解析超时的情况。
虚拟机DNS代理配置步骤详解
既然要配DNS代理，就得知道代理的逻辑：虚拟机把DNS请求发给代理，代理根据域名后缀决定转发到公网DNS还是内网DNS，这个方案的好处是，虚拟机里只需要配一个DNS地址,不用区分内网外网。
用dnsmasq做轻量级DNS代理
dnsmasq是目前最常见的轻量级DNS转发工具，配置简单，性能足够中小企业使用,适合部署在宿主机或一台专门的Linux服务器上。
- 安装：
apt install dnsmasq或yum install dnsmasq - 编辑
/etc/dnsmasq.conf，核心配置项有这么几个：listen-address=192.168.1.10指定监听地址,让局域网内虚拟机可以访问。server=8.8.8.8设置上游公网DNS。server=/corp.local/192.168.1.5指定内网域名的解析交给内网DNS服务器。address=/internal.example.com/10.10.10.5直接返回静态IP,不依赖上游。
- 重启服务：
systemctl restart dnsmasq
配置完成后，把虚拟机的DNS指向dnsmasq所在的IP即可，需要特别注意的是，server=/corp.local/192.168.1.5 这一行的意思是，只有以 corp.local 结尾的域名才会转发到内网DNS服务器，其他域名一律走公网DNS,这个分流逻辑非常实用。
用Windows Server的DNS转发器
公司里用Windows Server做域控的话，DNS转发器是现成的功能,不需要额外安装软件。
- 打开DNS管理器，右键服务器名称 → 属性 → 转发器。
- 点击“编辑”，添加公网DNS地址，
5.5.5。 - 在正向查找区域里创建内网域名区域,添加对应的A记录。
这样配置之后，虚拟机的DNS指向Windows Server的IP，内网域名走本地区域记录，公网域名走转发器，据部分企业环境反馈，Windows DNS管理起来更直观,就是性能和dnsmasq相比稍微重一些。
路由器或防火墙内置DNS代理
OpenWrt、爱快、ROS（RouterOS）等软路由系统都内置DNS转发功能，配置方式大同小异,以OpenWrt为例：
- 网络 → DHCP/DNS → 常规设置。
- 在“DNS转发”里填写内网DNS服务器地址，格式是
168.1.5。 - 在“Address”里可以写静态域名映射，
/router.local/192.168.1.1。
这种方式的好处是，虚拟机的DHCP租约里直接下发网关地址作为DNS，虚拟机不需要单独配置DNS，IP和DNS一起分配，省事很多。
内网域名解析失败怎么排查
配置做完不代表万事大吉，虚拟机解析不了内网域名的情况时有发生，按下面的顺序排查,能省下不少时间。
先看DNS代理日志
日志是排障的第一步，dnsmasq的日志默认在 syslog 里,查看命令：
tail -f /var/log/syslog | grep dnsmasq- 如果看不到日志，检查dnsmasq配置里是否开了
log-queries选项。
Windows DNS服务器的日志在事件查看器 → 应用程序和服务日志 → DNS Server,里面记录了每个查询的响应状态。
再查虚拟机的DNS解析顺序
Linux虚拟机里，/etc/resolv.conf 中DNS配置的优先级高于系统默认路由，如果这个文件里的DNS地址写错了，其他配置都是白搭，NetworkManager管理的系统，/etc/resolv.conf 可能是软链接，直接修改会被覆盖,需要在NetworkManager的配置里改。
Windows虚拟机则在“网络适配器 → IPv4属性”里设置，注意不要勾选“退出时验证设置”，否则不小心点了“验证”会导致DNS重置。
测试工具怎么用
nslookup适合单次查询测试,能显示解析结果和响应时间。dig能查看完整的查询过程,包括本地DNS缓存是否命中。ping只能测试IP连通性,不能区分是网络问题还是DNS问题。
实际测试时，建议先执行 nslookup <内网域名>，再执行 nslookup <公网域名>，对比两者结果，如果内网解析失败而公网解析正常,基本可以确定是代理的分流规则没写对。
内网域名设计不合理导致解析失败
有些企业的内网域名用的是 .com 或 .cn 这类公网后缀，office.company.com，这种情况下，DNS代理收到解析请求时，不知道这个域名应该走内网还是公网，转发到公网DNS后返回的结果可能是错误的IP,又或者超时。
规避方法很简单：内网域名统一用 .local、.lan、.internal 之类的私有后缀，并在DNS代理里明确指定这个后缀的转发目标，如果已经用了公网后缀，就需要在每个需要解析的虚拟机 hosts 文件里手动绑定IP，治标不治本,不推荐大面积使用。
内网DNS代理搭建方案的选型建议
不同规模的场景，适合方案不同，没有绝对的好坏,根据实际环境大小选择即可。
| 场景 | 推荐方案 | 优点 | 缺点 |
|---|---|---|---|
| 家庭虚拟化环境（PVE/ESXi） | dnsmasq | 资源占用极低，配置简单 | 功能单一，无图形界面 |
| 中小企业（少于200台设备） | Windows DNS或dnsmasq | 管理方便，支持域名分流 | Windows DNS需要授权 |
| 中大企业（多分支互联） | 独立DNS代理设备或Bind | 性能强，支持view视图 | 配置复杂，需要专业维护 |
具体到虚拟机DNS代理配置，家庭用户推荐dnsmasq直接跑在宿主机上，稳得很，中小企业如果已经有Windows域控，没有必要额外搭一套代理服务器，域控自带DNS角色直接解决，规模再大一些的公司，可以用Bind的view功能做内外部DNS分离,这是业内比较成熟的做法。
DNS代理的缓存策略也会影响体验
DNS代理的缓存时间直接决定了解析速度和TTL更新频率，dnsmasq默认缓存大小是150条，对于小型网络够用，虚拟机和容器多了之后建议调整缓存大小，Windows DNS的缓存是自动管理的,基本不需要手动干预。
较大的TTL值能减少上游DNS服务器的查询压力，但内网域名更新IP后生效变慢，如果内网服务频繁调整IP，建议把TTL设置成300秒左右，平衡性能和时效性，这种细节在实际运维中经常被忽略,但影响却很明显。
虚拟机批量部署时怎么同步DNS配置
批量场景下，一台一台改DNS设置效率太低，如果用OpenStack、Kubernetes这类平台，有现成的DNS配置下发机制，普通虚拟机环境可以借助Ansible批量修改,或者用DHCP统一分配。
在VMware vSphere环境中，可以在虚拟机模板里就把DNS配置写死，后续克隆出来的虚拟机自带正确的DNS指向，这个操作在模板定制规范（Customization Specification）里可以预先设定,避免每台虚拟机手动修改。
内网域名解析失败时的心态调整
遇到虚拟机解析不了内网域名，先别急着重启网络或重装系统，多数情况下就是配置细节的问题，按排查逻辑一步步来，很快就能定位,复杂的系统问题往往背后是不起眼的配置错误。
一个容易忽略的细节：防火墙拦截UDP 53端口
DNS查询默认走UDP 53端口，代理服务器的防火墙如果拦截了来自虚拟机网段的53端口流量，虚拟机发出去的DNS请求就会被静默丢弃，抓包分析的话，你会看到虚拟机的网卡一直在发查询请求,但没有任何响应返回。
检查时用iptables -L -n（Linux防火墙）或Windows高级防火墙里的入站规则，确认UDP 53是允许访问的。
DNS代理服务挂了怎么办
代理服务进程如果崩溃，虚拟机的DNS解析会直接罢工，添加一个cron定时任务，每隔几分钟检测进程状态，挂了就自动拉起,这是Linux环境里的常规做法。
Windows服务自带重启机制，在服务属性里的“恢复”选项卡设置成“如果服务失败，重新启动服务”即可。
常见问题解答
Q: 虚拟机DNS配置成宿主机IP可以吗？
A: 可以，但前提是宿主机上跑了DNS代理服务，直接把虚拟机DNS指向宿主机IP，宿主机本身没有监听53端口，解析必然失败，在宿主机上部署dnsmasq或Windows DNS服务后,虚拟机DNS才能正常指向宿主机。
Q: 为什么虚拟机能够解析公网域名，但内网域名总是超时？
A: 这种情况通常是DNS代理的分流规则没有正确匹配内网域名后缀，公网域名通过上游DNS正常解析，而内网域名因为没有对应的转发规则，被错误地转发到了公网DNS服务器，自然得不到正确结果，检查代理配置中server=/内网域名/内网DNS地址这一行是否写对。
Q: 虚拟机DNS代理配置好了，内网域名解析失败还有其他原因吗？
A: 可以考虑一下内网DNS服务器自身是否正常，在代理服务器上直接执行dig @内网DNS地址 内网域名，如果这里也解析失败，问题出在内网DNS服务器或它所依赖的上游区域，而不是代理配置，内网DNS服务器的区域数据文件损坏、服务未启动、下游区域传输故障,都会直接导致解析失败。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/623600.html
