内网DNS服务器不可用，绝大多数情况下不是设备坏了，而是配置错误、服务未启动或网络链路受阻。 只要按照“客户端-链路-服务器”的顺序逐一排查，多数问题能在十分钟内定位并解决。
内网DNS解析失败怎么办：先分清症状再动手
不少朋友一遇到“内网DNS服务器不可用”的报错，第一反应就是重启服务器，但内网DNS解析失败怎么办，关键在于先判断“是个别电脑的问题，还是全网段的问题”，这就好比家里灯不亮了，得先弄清楚是灯泡烧了还是整栋楼停电。
单台设备报错，先查客户端本身。如果只有一两台电脑提示“DNS服务器不可用”，而隔壁工位一切正常，那么问题大概率出在设备自身的网络配置或缓存上，可以按照以下顺序快速验证：
- 打开命令提示符,输入
ipconfig /all查看本机获取到的DNS服务器地址是否指向内网IP，常见错误是设备自动获取到了公网地址（如114.114.114.114），导致内网域名无法解析。 - 执行
ipconfig /flushdns清空本地DNS缓存，有时缓存的过期记录会“假装”服务器不可用，实际只是信息太旧。 - 用
nslookup 内网域名测试解析是否正常，如果返回“DNS request timed out”，说明客户端确实连不上DNS服务器的53端口。
全网段设备集体掉线，重点检查服务器和交换机。当整个办公室都上不了内网系统，且 ping 服务器IP能通但解析域名失败，基本可以断定是DNS服务本身出了问题，行业共识认为，这类故障中约七成源于服务进程崩溃或配置改动未生效，而非硬件损坏。
公司内网DNS服务器设置出错，多半是这几类原因
这里说的“设置出错”，不单指敲错一个IP地址。公司内网DNS服务器设置是个系统工程，从服务端到客户端，任何一环的“小脾气”都会让整个解析链路罢工。
服务端排查：核心服务是否在跑，配置是否被改
远程登录到DNS服务器,第一步先确认服务状态，以Windows Server为例，按下 Win + R 输入 services.msc，找到“DNS Server”服务，查看是否处于“正在运行”状态，如果服务已停止，右键启动即可，但更隐蔽的问题是：服务在跑，却解析不了任何内网域名。
这时要打开DNS管理器,检查“正向查找区域”中是否有对应域名的记录，常见故障场景包括：
- 管理员前一天在防火墙上调整了策略,顺手挡掉了UDP 53端口入站流量
- 服务器上装了安全软件,把DNS服务的核心进程给隔离了
- 区域传送配置错误,导致从主服务器同步过来的记录全是空的
别忽略事件查看器。在“Windows 日志-系统”里筛选来源为“DNS”的事件，如果看到ID为4000或4013的记录，说明服务启动时加载区域文件失败，这种情况下，即使重启服务也无济于事，需要检查区域文件是否被手动修改过格式。
客户端排查：指向错误和缓存污染是最普遍的坑
如果服务端一切正常,问题往往出在客户端“问错了人”，很多公司网络环境里，DHCP服务器会同时下发DNS地址，但部分设备（尤其是手动配置过IP的电脑）会残留旧的DNS设置，员工电脑的DNS指向了一台已退役的旧服务器IP，或者错误填写了网关地址（如192.168.1.1）。
还有一种烦人的情况是DNS缓存污染，当上游DNS返回了错误的内网IP映射，客户端就会把这个结果缓存下来，导致后续所有解析请求都指向错误位置，手动清理方法如下：
- 以管理员身份运行命令提示符
- 输入
ipconfig /flushdns清空缓存 - 输入
netsh winsock reset重置网络协议栈 - 重启网卡（禁用再启用）让新配置生效
据不少企业IT管理员反馈,这组命令能解决相当一部分“DNS服务器不可用”的假报错，如果重启网卡后仍然解析失败，可以尝试用 nslookup 指定服务器地址测试，nslookup test.company.com 192.168.10.50，如果指定IP后解析正常，说明DHCP下发的DNS地址有误，在DHCP服务器上修正即可。
内网DNS服务器连不上：网络链路与配置细节的隐形坑
服务器和客户端配置都正确,但内网DNS服务器连不上的问题依旧存在，这时要检查的是“路通不通”，以及一些容易忽略的细节。
防火墙规则对DNS的影响远超想象
多数企业在内网部署DNS时,只开放了TCP/UDP 53端口，但部分企业级防火墙默认策略会拦截「来自非信任区域的UDP请求」，如果你的DNS服务器同时承担内外网解析任务，而客户端设备被划分到了“访客VLAN”，那么即使IP可达，DNS请求也可能被防火墙静默丢弃。
排查方法很直接：在客户端执行 telnet 内网DNS服务器IP 53，如果显示无法连接，但ping能通，基本可以断定是中间设备拦截了53端口，检查三层交换机或防火墙的ACL规则，放行对应网段的53端口流量即可。
转发器配置错误导致“内网正常，外网瘫痪”
另一种典型场景是内网域名解析正常,但访问公网网站全部失败，这类问题通常出在DNS服务器的“转发器”配置上，Windows Server的DNS服务默认启用根提示，但如果管理员手动指定了转发器（比如填了个已失效的运营商DNS），就会导致外部域名解析超时。
进入DNS管理器,右键服务器名称选择“属性”，在“转发器”选项卡中检查配置，建议改为“没有转发器”让服务器直接使用根提示，或者填写多个可靠公共DNS（如5.5.5和29.29.29），修改后执行 dnscmd /clearcache 刷新服务器缓存。
内网DNS服务器设置的长期优化与故障预防
解决眼前的问题只是第一步,对于企业IT环境，内网DNS服务器设置的长期稳定性比一次性排障更有价值，毕竟每次故障都要“救火”，不如从一开始就做好防范。
建立主备架构，别让单点故障拖垮全公司
行业共识认为,超过半数的内网DNS故障源于“所有鸡蛋放在一个篮子里”，小型公司往往只用一台服务器做DNS，这台机器一旦蓝屏或者被误关，整个内网解析就瘫痪了，最经济的方案是：在另一台空闲机器（甚至虚拟机）上搭建辅助DNS服务器，并与主服务器配置区域传送，这样主服务器宕机时，客户端依然能通过备服务器完成解析。
监控与告警是二级保障
在DNS服务器上配置简单的监控脚本,定期检查服务状态和解析响应时间，一旦发现连续ping不通或nslookup返回异常，立刻向IT管理员发送告警，不用买昂贵的监控软件，用Windows自带的“任务计划程序”定时执行一条批处理命令即可实现基础告警。
定期备份区域配置
不要只在故障发生时才想起备份,每次修改DNS记录后，导出一次区域文件，具体操作：在DNS管理器中右键区域名称，选择“导出”，保存为.dns文件，导出文件用文本编辑器打开就能看懂，就算系统崩溃，也能手动恢复所有记录，这个习惯在疫情后远程办公场景里显得尤为重要很多公司在迁移办公地点时，就是因为没有备份DNS配置，导致几百人的网络整整断了一天。
常见问题快答
内网DNS服务器不可用，重启能解决吗？
如果服务进程卡死或内存泄漏,重启确实能临时恢复，但如果是配置错误或防火墙拦截，重启一百次也没用，建议先完成上文的基础排障，再决定是否需要重启。
内网DNS指向公网地址会有什么后果？
内网设备若将DNS指向公网服务器（如8.8.8.8），则无法解析内部域名（比如oa.company.com），因为公网DNS服务器的缓存里没有你内网域名的记录，它只会返回“域名不存在”，这属于典型的“内网DNS服务器设置”错误，多数情况下是把自动获取改成了手动指定导致的。
为什么换了台新交换机后，内网DNS就断续不可用？
新交换机如果启用了“DHCP Snooping”或“动态ARP检测”特性，可能会误拦DNS响应报文，尤其是网关设备同时承担DHCP和DNS分配任务时，这些安全特性会把合法的DNS应答当作异常流量丢弃，检查交换机上是否有针对UDP 53端口的过滤策略，以及DHCP Snooping的信任端口是否错误配置这是近年来企业更换网络设备后最常遇到的隐蔽问题。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/795095.html
