当网站无法进行访问的时候, 或者是邮箱收不到邮件的情况发生之际, 亦或是CDN加速出现了失效这样的问题时。这些现象背后的真正原因, 往往是因为DNS解析出现了异常情况。如果想要快速地找到故障所在的地方, 那么第一步就是去选择好适合自己的DNS解析检测工具。

对于网站的管理人员来说, 开发人员, 还有运维工作人员, 他们都可以直接把下面这些被大家确认过经常使用的工具方法, 以及规范化的排查问题流程拿来直接使用, 这些都是经过验证的可靠内容。

01常用DNS解析检测工具

1. dig(命令行工具)

这个工具是适用于 Linux 系统的, 也是适用于 macOS 系统的, 并且对于 Windows 系统来说是可以适用的, 但是在这里是需要安装才行。dig 就是那个功能最完整的 DNS 查询工具, 这一点是肯定的。

它是支持对 A 记录类型进行查询的, 也是支持对 AAAA 记录类型进行查询的, 还是支持对 MX 记录类型进行查询的, 以及也是支持对 NS 记录类型进行查询的, 同时也是支持对 TXT 记录类型进行查询的。

常用指令:

dig example.com A:查询A记录(IPv4地址)

dig example.com MX:查询邮件交换记录

执行dig example.com NS这条指令, 其作用就是用来查询该域名对应的服务器有哪些。

用这个命令, dig @8.8.8.8 example.com, 来指定DNS服务器去查询。

dig这个东西, 它的长处, 就是能够对查询的参数, 进行非常精确的控制, 然后返回来的结果, 是那种完整的响应信息, 所以说它, 更适合用来做深度的排查工作。

2. nslookup(跨平台命令行工具)

在 Windows 系统中, 该功能是属于自带的状态的, 是不需要去进行安装的操作的。只要你输入nslookup example.com这个内容, 就马上可以返回来解析出来的结果。这种方式是非常适合用来对某个域名是不是解析到了那个正确的 IP 地址的情况去进行快速的验证的。

3. 在线DNS检测平台

如果在实际工作中遇到那些不方便来操作命令行的场景的话DNS解析检测工具DNS解析检测工具,那么用户是完全可以使用在线工具来解决问题的。具体来说, 当用户在gname.xin这个平台上面输入想要查询的目标域名的时候, 就可以直接一键获取到该域名所对应的A记录, 以及CNAME记录, 还有MX记录和NS记录等等所有这些解析信息。

除此之外, 该系统还全面支持全球范围内的多节点探测功能, 这样能够比较直观地展示出世界各地在网络解析方面是否存在一致的情况。同时, 该平台还会一并提供一些诸如TTL值或者记录变更历史之类的辅助信息内容, 因此这种工作方式是非常适合拿来用于日常巡检工作的。

4. DNSPing / DNSChaff

DNS解析检测工具推荐:常用工具对比与排查步骤(图1)

DNSPing这个功能, 它是可以同时地向多个不同的DNS服务器去发起查询操作的, 为的是去验证最终的解析结果是不是保持一致的。至于说DNSChaff, 它的主要用途是用来测试DNS劫持还有中间人是怎样进行篡改行为的, 这种做法通常是适用于安全审计这个场景里面的。

02标准化排查步骤

当发现网站无法访问时灵音心图,按以下顺序逐层排查:

1. 本地缓存排查: 你可以执行 ipconfig /flushdns 这个命令, 这通常是在Windows系统里用的。

或者在macOS系统里, 你可以使用 sudo dscacheutil -flushcache。这样做的目的是为了把本地的DNS缓存给清掉。等缓存清除完毕以后, 你再试着重新操作一遍。

2. 本地解析验证, 使用 nslookup 或者 dig 在出现故障的终端设备上查询目标域名, 确认返回的结果是否正确, 也就是确认是否返回了正确的 IP 地址, 如果在本地的情况下无法进行解析操作, 就需要去检查 /etc/resolv.conf 这个配置文件, 如果使用的是 Linux 系统, 或者去检查系统的 DNS 设置内容。

3. 使用dig example.com NS这个命令来确认一下, 当前域名所指向的权威DNS服务器是否正确, 这是已经由权威的NS给出的确认信息, 要是这个NS记录的配置是错误的, 那么所有的解析操作都会出现失败的情况。

4. 在全球节点探测的过程中, 需要在gname.xin这个平台上面去选择那些分布在不同地区的节点。然后由这些节点来发起相关的探测行动。

通过这样的方式, 我们能够判断出当前的情况属于全局性的故障, 还是比较区域性的解析异常现象。要是发现只有少数的部分地区出现了异常情况的话, 那么很多时候都是因为当地的DNS运营商那边的缓存信息还没有完成刷新操作所导致的。

5. TTL与生效时间: 检查记录的TTL值。在修改解析记录以后, 全球生效的时间会变为原来的那个TTL值。这个时间最长可能会达到48小时。如果用户把TTL设为300秒, 也就是5分钟这样的话, 就可以大幅度缩短后续那些变更生效所花费的时间。

6. 记录内容核对: 对每一项内容进行核实。查看A记录的IP地址是否和期望值一致, 查看CNAME的指向是否和期望值一致, 查看MX优先级的数值是否和期望值一致, 以此方式排除掉录入错误的情况。

03关键注意事项

在修改了DNS记录之后呢, 请务必要确认这个TTL已经生效, 然后再去进行验证, 否则的话, 很有可能是因为缓存的过期时间还没有到, 从而产生误判, 认为没有生效。

当邮件收不到的时候, 你应该先去看看MX记录是不是有了, 再看看那个优先级对不对, 还有SPF和DKIM记录有没有配齐。

可以在使用 dig 工具的时候, 给它加上一个 +trace 这样的参数。这么做的目的呢, 就是为了去追踪从根服务器一直到权威服务器这个整个过程里的解析链路。通过这种方式, 就可以把中间环节出现故障的具体位置给定位出来。

在生产环境里面, 建议把关键域名的TTL时间维持在天级别以下, 这样做是为了给紧急切换预留出响应的窗口。

当你掌握上面所说的这些工具和操作流程之后, 你就能够覆盖掉超过百分之九十五以上的DNS解析异常场景了。针对日常的巡检工作, 给出的建议是每周至少要去执行一次全球节点的探测。这么做的好处在于, 可以确保解析的状态能够一直保持在正常的程度。