云主机DNS解析失败怎么办?

上星期有个读者在后台给我留言，说他公司的云主机突然出毛病了。现象很奇怪，服务器上的网站能正常访问，但是服务器自己往外发请求就不行，比如想调用第三方支付的接口，或者想用命令下载一个安装包，全部提示未知的主机名。他说他折腾了一整天，重启了好几次，甚至把云主机重置了，问题还是没解决。我问他你看过DNS配置文件没有，他说什么是DNS配置文件，我在云控制台里没找到这个选项。

这个对话让我意识到一个问题，很多用云主机的朋友，尤其是平时主要忙业务开发的人，对网络底层的细节其实不太熟悉。DNS这个东西，说简单也简单，就是把域名翻译成IP地址的一个服务，但说复杂也复杂，一旦出了问题，你连上网查资料都费劲，因为浏览器也打不开任何网站。今天咱们就好好聊一聊，云主机DNS解析失败到底是怎么回事，以及遇到之后该怎么一步步排查和修复。

先讲一个我自己亲身经历过的案例。去年帮一个做内容分发业务的客户处理过一次故障，他们的云主机是用来做数据采集的，每天要从几十个不同的API接口拉取数据。有一天早上，他们的监控系统突然报警，显示所有的采集任务都失败了。我登录上去一看，现象跟前面那个读者说的一模一样，用浏览器访问任何网站都正常，但是服务器命令行里执行任何涉及域名解析的命令都会卡住半天，最后返回一个无法解析的错误。客户当时的第一反应是云服务商的网络出问题了，差点就要提工单投诉了。我劝住了他，我说你先别急，咱们先在自己的机器上查一查。

我做的第一件事，是在那台云主机上执行了一个最简单的连通性测试，但不是测试域名，而是测试一个公共的IP地址。比如用命令去ping一个知名的公共DNS服务器的IP，比如八点八点八点八。你猜怎么着，ping这个IP是完全通的，没有任何丢包。这说明什么，说明云主机的网络本身是没问题的，数据包能出去也能回来，问题就出在把域名转换成IP这个环节上。

那接下来就要定位到底是哪个环节出了问题。DNS解析失败的根源大致可以分为几类，一类是配置问题，一类是服务问题，一类是网络策略问题，还有一类是软件层面的问题。我们一条一条来看。

配置问题是最常见的，也是最容易修复的。在Linux系统里，DNS解析的配置文件放在一个特定的位置，这个文件告诉系统当你输入一个域名的时候，应该去找哪个DNS服务器来帮你翻译。很多人不知道的是，这个文件的格式其实很简单，每行一个配置项，其中最重要的就是那一行，后面跟着DNS服务器的IP地址。如果这个文件里的DNS服务器地址写错了，或者这个文件本身被修改过权限导致无法读取，那系统就不知道该找谁去解析域名了。我遇到过好几次这样的情况，有的同事在配置网络的时候手一抖把IP写错了，或者从某个教程里复制过来一个已经废弃的DNS地址，结果解析就失败了。修复方法很简单，用管理员权限编辑这个文件，把里面的地址改成你能用的公共DNS或者云服务商提供的内部DNS，保存退出之后一般不用重启，下次解析的时候就会生效。

还有一种配置问题是这个文件里多了一行配置，比如配置了一个超时的参数，但值设置得太小，导致在网络稍微有点延迟的时候就放弃了查询。或者配置了轮询的顺序，但第一个DNS服务器响应太慢，系统在等它超时的过程中看起来就像卡住了一样。这些细节问题用肉眼不太好发现，有一个简单的办法，就是用系统自带的查询工具手动指定一个DNS服务器去解析一个域名，如果不指定服务器而直接解析失败，但指定了某个服务器就能成功，那基本上可以确定是配置文件里的DNS地址有问题。

说回刚才那个客户的案例，我打开他的文件一看，发现问题了。他为了让访问某些海外服务更快一些，手动修改过这个文件，把其中一个DNS服务器地址改成了某个第三方的公共DNS，但这个地址前不久因为业务调整停止了解析服务。更麻烦的是，他原来的配置文件里只写了这一个DNS服务器，没有备用地址，所以当这个服务器不可用的时候，系统没有地方可以问，所有的域名解析请求就全部失败了。我帮他把这个地址删掉，换成另外两个稳定可靠的公共DNS地址，再保存退出，问题立刻就解决了。

接下来讲第二种情况，就是DNS服务本身出问题了。有时候不是你的配置有错，而是你配置的那个DNS服务器自己挂了。这种情况虽然不常见，但确实会发生。比如某个公共DNS服务遭受了攻击，或者临时做了维护升级，你发给它的解析请求它要么不响应，要么返回错误的结果。怎么判断是不是这个问题呢，很简单，你手动换一个DNS服务器试试看。在你的云主机上临时指定一个其他的公共DNS地址，如果换了之后解析正常了，那说明之前的那个DNS服务确实有问题。这时候你可以选择继续用新的DNS服务器，或者等原来的服务恢复后再改回去。

还有一种情况比较隐蔽，就是你的云主机所在的网络环境里，存在一个所谓的DNS劫持或者DNS污染。有些网络设备会拦截你的DNS请求，然后返回一个错误的IP地址给你，让你访问不到真正的网站，或者跳转到某个广告页面。判断这个问题的方法也不难，你在一台不受同一网络限制的机器上，比如你家里的电脑，去解析同一个域名，如果得到的IP地址和你在云主机上解析到的结果不一样，而且你在云主机上得到的那个IP明显是不正常的，那很可能就是遇到了劫持。这时候你需要联系云服务商，让他们检查一下底层网络的配置，或者考虑换一种加密的DNS协议来绕过劫持。

第三种情况是网络策略层面的问题。现在很多云服务商提供了安全组和网络访问控制列表的功能，你可以精细地控制哪些流量能进能出。如果你的云主机所在的安全组规则里，不小心把出去到DNS服务端口上的流量给禁止了，那么你的DNS请求根本发不出去，自然也收不到任何回应。还有一种情况是某些企业网络环境里会部署防火墙，只允许云主机访问特定的几个DNS服务器，其他的全部拦截。如果你临时换了一个不在白名单里的DNS地址，那就算你本机配置得再正确，请求也会被防火墙挡住。排查这类问题需要用一些网络抓包工具，在云主机上看一下发出去的DNS请求有没有得到回应，如果发现请求发出去了但是收不到返回包，那多半是中间的某个网络设备把包给丢了。

第四种情况是云主机上的软件层面的问题。比如系统里某些缓存机制出了故障，或者解析相关的服务进程卡死了。我记得有一次帮朋友排查，他的云主机上装了某个安全软件，这个软件会在后台监控所有的DNS请求，做一些域名过滤和威胁情报查询。这个软件本身有一个bug，在处理某些特殊格式的域名时会死锁，导致所有的后续解析请求全部被阻塞。把那个安全软件临时关掉之后，解析马上就恢复了。所以如果你的排查走到了这一步，可以考虑一下最近有没有安装过什么新的软件，或者有没有升级过系统的某些组件，尝试在安全模式下启动系统，用最小的软件集合来测试DNS解析是否正常。

还有一种比较极端的情况，就是云主机上的系统文件被篡改了，比如把标准库文件替换成了恶意版本。这种情况下DNS解析失败可能是攻击者故意造成的，目的是让你无法下载安全补丁，无法更新杀毒软件，也无法访问安全社区去查解决方案。如果你发现你的云主机无论如何都无法正常解析域名，而且你已经按照上面所有的方法排查过了都不行，那就要考虑系统是不是已经被入侵了。这时候最好的办法不是继续修，而是赶紧备份重要数据，然后重装系统。

我再说一个容易被忽略的点，就是云主机的系统时间。DNS解析过程中有一个环节会验证证书的有效性，如果你系统的时间跟真实时间差得太多，比如差了好几年，那么证书验证就会失败，导致解析看起来像是失败了，实际上是安全机制阻止了你。检查一下系统时间是否正确，如果不对的话用时间同步服务校准一下，很多DNS解析的怪问题就这么解决了。

前面那个读者后来告诉我，他按照我说的方法检查了一遍，发现问题是出在另外一个地方。他的云主机上跑着一个自动化的运维脚本，那个脚本每天凌晨会从某个内部地址更新配置文件，有一次更新的时候把DNS配置文件给覆盖成了错误的版本。他当时没有开配置管理工具，也没有做版本控制，所以这个错误一直没被发现。后来他把这个脚本改了一下，在覆盖配置文件之前先做一次校验，只当内容确实有变化的时候才更新，这样就避免了每次更新都无脑覆盖的问题。

经过这么多次的故障排查，我总结出一个习惯，就是在每台云主机上都准备一个简单的测试脚本。这个脚本不干别的，就是尝试解析几个常用的域名，然后把结果和耗时记录下来。一旦监控系统发现解析失败或者解析时间异常变长，脚本会自动把当前的配置文件、网络状态、系统时间等信息打包保存下来，方便事后分析。这个小工具帮过我很多次，有时候故障发生得很突然，等你登录上去看的时候，配置可能已经被自动修复脚本给改回来了，你根本看不出当时到底出了什么问题。

最后总结一下，云主机DNS解析失败的修复思路可以归纳为这几个要点。首先要确认网络本身是通的，用IP地址而不是域名去测试连通性。然后检查配置文件，确保DNS服务器的地址正确无误，并且有可用的备用地址。接着手动指定不同的DNS服务器来解析同一个域名，排除DNS服务本身的问题。再看安全组和防火墙规则，确保出方向的DNS端口没有被拦截。排查云主机上安装的安全软件或者网络代理软件，它们可能会干扰正常的解析流程。确认系统时间准确，时间偏差会导致证书验证失败。如果以上都不行，要考虑系统是否被入侵，必要时重装系统。最后一点，养成定期检查和备份配置文件的习惯，这样出问题的时候能快速对比出哪里被改动了。

DNS解析就像是你在网络世界里的导航，导航出了问题，你哪都去不了。但好在排查方法是有章可循的，不用慌，也不用上来就重启或者重置，按照上面说的思路一步步来，绝大部分问题都能在半小时内找到原因并修复。