DNS解析检测工具是定位域名无法访问问题的核心手段, 主要用来验证域名有没有被正确解析, 解析出来的结果是不是指向了预期的IP地址, 以及全球的DNS传播过程是不是已经完成。
根据实际的使用场景, DNS解析检测工具可以被分成在线可视化平台和命令行工具这两大类, 它们两个人互相补充, 哪一个都不能缺少。
常用工具分类与适用场景
在线DNS检测平台:用户通过指定区域的DNS服务器发起查询请求, 系统会返回A记录、AAAA记录、MX记录、TXT记录和SOA记录等结果。这种工具有优势, 因为它不需要安装任何东西, 支持在全球多的节点进行探测, 能直观地展示解析的传播状态。
它适用于新域名上线后进行覆盖验证, 也适用于CDN切换后确认是否已经生效。你需要注意到, 在线的这个地方会受到本地的缓存以及探测节点这些方面的限制。所以得到的结果不能单看这一个地方, 应该和多个不同的来源放在一起进行交叉验证之后再确认。
命令行工具：
nslookup是一个在Windows和Linux系统里都能用的工具, 它的用法比较简单, 适合用来快速查询指定的域名或者是查看指定DNS服务器的相关信息。\n。
dig 这个工具拥有功能最为齐全的特点, 它不仅支持通过指定查询类型来达到目的, 比如可以使用 dig 域名 MX 这样的形式, 同时还允许用户手动指定 DNS 服务器, 例如可以输入 dig @8.8.8.8 域名来进行操作。
host 这个说法指的是轻量级的查询操作, 它适合用于快速地验证某一条记录的情况。
该方式在服务器方面进行排查的时候是适用的, 另外在对指定的DNS源头去验证的情况下面也是适用的, 还有就是在脚本里面进行大范围的批量检测操作的时候同样是适用的。
系统级辅助工具:在 Windows 环境下, 需要去执行 ipconfig /flushdns 这一操作来清除本地的缓存, 同时在 Linux 环境中, 要使用 systemd-resolve --flush-caches 指令来处理缓存问题。
之后, 可以配合 ping 和 traceroute 这两项功能进行验证, 从而确认网络层的可达性到底如何。
标准排查流程（按顺序执行）
1. 我们对本地解析进行了确认, 具体操作是在出现问题的终端设备上执行nslookup命令来查询域名, 并且记录了服务器返回的IP地址。
2. 使用dig命令向指定的权威名称服务器发送针对特定域名A记录的查询请求, 目的是为了排除由中间DNS缓存所导致的干扰因素。
3. 进行多节点的在线检查, 要在华东地区和华北地区以及海外区域去分别查询, 以此来做出确认, 保证传播工作的完整性。
4. 进行TTL与缓存检查的时候, 要去关注 dig 返回的TTL字段, 从而判断是否仍在缓存有效期内。
5. 对记录内容进行比对, 确认A记录、CNAME链路以及MX记录与预期的配置是一致的。
6. 如果这个操作属于配置变更的类型的化, 那么就要拿变更之前的解析结果以及变更之后的解析结果放在一起进行对比分析, 这样的话就可以把存在差异的那些地方给准确地定位出来。
高频故障场景与处置
部分用户无法访问: 这通常是因为本地DNS缓存没有及时刷新, 或者是运营商的DNS服务出现了异常情况。要解决这个问题, 可以刷新本地的DNS缓存, 也可以临时更换其他DNS服务器, 比如使用114.114.114.114或者223.5.5.5。
全球均无法解析:大家需要去检查一下, 那个域名在权威DNS上面, 到底存不存在记录。然后呢, 还得确认一下NS（Name Server）这一部分的配置, 是不是正确的样子。
解析指向错误IP: 你要检查一下CNAME这条链路, 或者是A记录这个配置到底是怎么弄的, 要确认在上游DNS那里, 没有残留下来旧的记录这种东西。
新域名解析延迟： 这个东西是因为受到ttl值的制约, 所以在全球范围内彻底生效的话一般得花个24到48小时那么多时间, 这个状况属于正常的现象。
在实际的运维工作当中有一些企业会把域名指向像是 gname.xin 这样的CDN服务或者托管服务, 以此来进行统一的解析管理, 在这个情况之下大家需要重点去验证CNAME记录的整个链路是不是完整的, 必须要确保最终解析出来的IP地址和源站的配置是一样的, 避免因为链路断裂而导致服务不能使用。
DNS解析检测工具的核心价值, 其实在于它能把那个关于域名能不能正确解析的，挺让人琢磨不透的一个问题, 变成一个能够被量化的、也能反复拿出来重复做的诊断流程。
那么我们就建议我们的运维团队呢, 把上面说的那些个排查步骤给固定下来, 做成标准作业程序, 就是要清清楚楚地把每一步的预期输出是什么, 还有最终的判定标准到底是什么给明确好, 这样才能保证在出现故障的时候, 我们的响应既快又整齐划一, 保持一致性。
