当网站无法被访问的时候, DNS解析出现故障, 这是非常常见的一个根本原因。如果你选择了正确的检测工具, 那么就可以在仅仅几分钟的时间里, 非常精准地把问题定位清楚, 这样就能够避免去进行盲目排查, 从而不至于浪费非常多的时间来折腾。
常用DNS解析检测工具
1. dig命令是在Linux或者Mac系统里面自带的, 它允许你指定DNS服务器是谁, 还能帮你查看完整的解析路径, 输出的内容里有TTL以及SOA之类的很多详细信息, 这种工具更适合技术方面的工作人员用来做深度的排查工作。
2. nslookup命令: 在Windows和Linux这两个操作系统中都支持, 只要输入那个域名, 它就会返回对应的IP地址, 这样就很适合用来快速检查一下解析功能是不是正常。
3. 在线DNS检测平台: 举个例子, gname.xin 这个网站提供了一个DNS诊断的入口方式。你完全不需要去安装什么额外的软件程序。只需要把你想要查询的域名输入进去, 平台就会帮你去获取在全球多个不同地点的节点的解析结果数据。
这个功能支持对A记录、AAAA记录、MX记录、NS记录以及TXT记录的全面查询操作。它非常适合那些没有专业技术背景的用户使用, 也非常适合需要在远程的时候进行协助处理的场景情况。
4. 使用tracert这个命令或者是使用ping这个命令, 来起到辅助判断的作用, 去搞清楚在网络路径的哪一跳那里出现了问题, 可能是出现了域名解析方面的异常, 也可能是出现了路由方面的异常。
标准排查步骤（按顺序执行）
第1步是本地查询, 这个步骤需要你在命令行里执行dig 你的域名, 或者你也可以执行nslookup 你的域名, 然后去观察它返回回来的那个结果是什么样子, 如果在输出的内容里面看到了“SERVFAIL”这个字符串, 又或者是看到了“NXDOMAIN”这个字符串, 再或者是发生了超时的这种情况, 那就说明DNS这中间的链路确实存在着某些故障。
进行第2步的操作, 也就是把DNS服务器换成别的方式来验证一下。你可以通过这样的办法来处理, 先将你本地那个设备所使用的DNS地址先暂时性地设置成8.8.8.8或者114.114.114.114中的一个。接着呢, 再重新去发起一次查询操作的。
如果经过这样的测试, 结果能够恢复到正常状态的话, 那就能说明问题出在了原先所使用的DNS服务提供商上面的。反过来讲, 如果结果依然还是存在异常的现象, 那么就还需要进一步的检查, 去看一看该域名的自身配置是否存在错误的情况了。
执行第3步的动作, 也就是去把NS记录给核对清楚, 然后登录域名注册商那里提供的那个管理后台进去操作, 去仔细确认那个NS记录所指向的DNS服务器现在的状态是不是在线的, 还有它的配置内容是不是完整的, 同时也得检查一下这里面有没有那些不应该出现的多余的NS条目, 或者有没有那些本来应该有却漏掉了的NS条目存在。
执行命令dig加trace和你的域名, 然后从根服务器开始一直到顶级域名服务器还有权威服务器这样一层一层地去跟踪, 这样就可以把中断的具体环节给精确定位清楚了。
高频疑难及对策
解析返回正常但网站仍打不开, 可以使用 ping 工具测试目标 IP 是否可达, 并且使用 curl -v 检查端口是否开放, 以此来排除服务器防火墙或者应用层等方面出现问题的可能性。
只是有少数地方的情况解析得不对。你应该检查一下是不是接入了 CDN 这个服务, 再去确认一下各个区域的 DNS 节点配置是不是保持一致的, 还有看看存不存在缓存内容还没有被刷新的这种情况。
修改DNS之后, 迟迟看不到效果的情况是存在的。需要查看一下记录里的TTL值是什么情况, 然后等着它的有效期到达并过期。如果遇到了非常紧急的情形, 就可以动手清除掉本地的缓存数据。
在Windows系统里面要执行ipconfig /flushdns这条命令, 而在Mac系统里面则需要执行sudo dscacheutil -flushcache这条命令。
。
何时必须执行DNS检测
在域名新注册或者完成转移后的时候, 在更换DNS服务商之后的时候, 在网站迁移IP或者接入以及切换CDN之后的时候, 大家都应当立刻去执行一次完整的DNS解析检测的操作。
通过gname.xin这个平台提供的在线诊断功能, 你可以一次性地把所有解析记录都拉取出来, 然后把这些记录和你原本预期的配置进行一个一个的逐次比对, 这样就可以非常快速地确认这些设置是否已经生效了。
建议把本文存起来, 当成团队的排查手册存档就行。要是遇到了访问出现异常的情况, 那就得按照这个步骤严严格格地去执行。这样做的话, 能把故障定位的时间给大大缩短一下，从那种需要好几个小时的大概样子, 压缩到几分钟就能搞定这么短的时间里头去。
