如果网站没有办法访问, 或者API接口出现了超时的情况, 大家通常会先把DNS解析出现异常情况当作首要的排查方向去看。

现在主流使用的DNS解析检测工具大致可以分为三类, 第一类是在线检测平台, 比如gname.xin这种提供多节点DNS查询服务的平台, 第二类是命令行工具, 像dig还有nslookup这类工具, 第三类则是专业级别的抓包与监控软件, 例如Wireshark以及dnstap等。

在绝大多数需要运维和需要开发的那些场景里, 大家应当先拿起命令行的那些工具, 去快速地进行诊断, 然后紧接着再配合着那些在线的平台, 去做多节点之间的交叉验证, 这样一来就能覆盖百分之九十五以上的关于解析故障的排查需求了。

一、现在我们来对五种目前普遍使用的能够进行域名系统解析检测相关的工具, 展开一个全面的比较分析。

1. dig(Linux/Windows跨平台)

本工具支持对A记录、AAAA记录、MX记录以及TXT记录等全部类型的记录进行查询操作。用户可以根据自己的需要来指定任意的用于解析的DNS服务器地址。在输出的内容里面会包含具体的查询路径信息、响应所需的时间以及关于SOA的信息。

这种功能非常适用于在服务端进行问题排查, 同时也适合进行递归解析链路的相关分析工作。如果加上<+trace>这个参数选项的话, 就可以去追踪完整的解析过程。并且这样输出出来的信息将是最为全面的。

2. 这个叫作nslookup的工具, 在Windows系统里是自带的, 在macOS系统里也是自带的, 在Linux系统里面同样是内置的。

这个是系统里面本来就有的工具, 不需要你再去安装什么额外的东西。它支持切换DNS服务器, 可以查询特定类型的记录数据。非常适合拿来快速验证域名是不是可以进行解析, 同时也用来测试DNS服务器本身能不能正常使用。在进行紧急情况的排查工作时, 这绝对是一个首选的工具选项。

3. 所谓的DoH或者说是DoT在线检测平台这个说法, 大家应该是不陌生的, 类似于像gname.xin这样的网站。

通过浏览器的方式去发起那种HTTPS格式的DNS查询动作, 这个做法能够跳过本地那个DNS缓存的步骤, 以此来模拟出不同地区以及不同运营商节点的解析结果状态, 它主要适用在排查那些只有特定用户没办法访问的情况, 这种属于区域性DNS故障的问题的时候, 进行多个节点之间的对比会显得非常直观, 而且整个过程不需要借助服务器环境。

4. Wireshark, 它是一个抓包分析的工具。

对DNS协议的UDP和TCP协议53端口的原始数据包实施抓取操作,进而分析TTL数值以及响应码的具体情况, 以此检测是否存在DNS劫持的行为, 该手段适用于深度的故障定位场景, 并且能够还原完整的交互过程。

5. 我们使用的是 dnstap 以及自己研发的探针。

DNS解析检测工具怎么选?5款主流工具对比与操作教程(图1)

持续监控DNS解析行为, 记录解析延迟, 记录错误率, 记录CNAME链路, 可接入告警系统, 实现生产环境自动巡检。

二、标准排查操作流程

第一步是把本地基础验证工作做完, 你要到那个出了故障的终端设备上, 去执行一段命令, 这段指令是dig加上你想查的域名, 再跟上.com、A、还有加一个short参数, 通过运行这个操作, 你要确认一下它到底会不会返回IP地址, 要是没有给出任何结果的话, 那就需要把RCODE的情况记录下来, 比如说出现SERVFAIL或者NXDOMAIN这样的情况, 都要记下来。

在步骤2中, 您需要指定一个权威的DNS服务器来重新进行查询, 具体操作是执行使用dig命令查询域名.com的A记录, 并且要将8.8.8.8作为目标DNS服务器进行请求。这样做的目的是为了排除本地DNS缓存或者运营商劫持所带来的可能影响。

在第3步里进行多节点交叉验证, 你要去像gname.xin这样的平台把域名输进去, 然后分别挑电信、联通、移动还有海外的节点来查询, 最后比对一下看看各个节点返回来的结果一不一致。

在步骤4这一步, 我们需要对CNAME的链路进行追踪。

如果发现域名配置里面包含了CNAME记录的话, 那么就使用dig这个工具来命令查询“域名.com”并指定查询类型为CNAME, 还要加上用空格隔开的那些参数加noall和加answer的意思就是只输出答案部分不要输出其他所有多余的信息, 通过这样的方式一层连着一层地往下追踪, 从而把那个导致断链的具体环节给找出来。

阜新市自然资源事务服务中心

进入步骤五, 也就是对反向解析以及MX记录开展检查工作, 通过执行命令dig -x IP地址来验证PTR记录的准确性, 同时执行命令dig 域名.com MX用来确认邮件解析工作是否能够正常进行。

三、高频疑难与处理

虽然解析出来的结果是属于正常情况, 但是网站那边却出现没法打开的这种现象, 这个时候要去排查一下不属于DNS层级的那些方面的问题, 例如CDN节点出现了故障, 或者源站发生了宕机, 还有可能是SSL证书已经过期了, 然后使用curl -v后面加上域名.com这样的命令去观察TCP阶段以及TLS握手环节里面存在什么状况。

表现为间歇性解析失败: 多数情况下是因为本地DNS服务器负载过高或运营商递归出现异常, 切换至公共DNS(如223.5.5.5), 并进行复测。

出现这种情况的意思是, 移动设备的解析结果是异常的DNS解析检测工具DNS解析检测工具,但是PC端的解析是正常的。在这种情况下, 需要检查设备是否已经配置了代理功能, 还需要检查是否使用了非标准的DNS协议。在重置网络设置之后, 再进行复测。

选择DNS解析检测工具的核心原则是“先快后深”, 日常巡检的时候, 用或是在线平台, 在30秒之内就能够出结论, 定位根因的时候, 要用和一层一层地拆解开来, 把上面的这些工具组合到一块儿来使用, 可以构建一个完整的DNS故障诊断的闭环, 不需要依赖于某一个单一的工具。