排查域名解析故障的核心路径就是从客户端到服务端一层一层地去定位问题所在, 这里需要依次去验证DNS服务器的配置有没有问题, DNS记录的内容是不是准确的, 缓存的影响能不能排除, 服务器的网络连通性到底怎么情况, 域名的注册状态是否正常, 以及DNS服务商的线路是否可以到达。
完成了以下这6个步骤之后, 是可以覆盖到95以上的域名解析故障场景的。
步骤一：确认DNS服务器配置是否正确
请使用 nslookup 或者是 dig 这条命令, 去查询当前域名实际生效的DNS服务器到底是谁。然后执行 dig NS example.com 这个操作。确认通过返回的结果显示的权威DNS, 与在注册商那边配置的DNS是一致的。
如果发现NS记录指向了一个已经停用的旧DNS服务器, 那么所有的解析请求都会出现超时的情况。
以 gname.xin 作为例子, 要是它的 NS 还是指向之前的服务商的话, 那就得去登录一下域名管理的那个后台, 然后把 NS 给更新成现在用的 DNS 服务器所在的地址, 这个全球范围的传播过程呀, 通常呢是需要花费 24 到 48 个小时才能完成的。
步骤二：逐条核验DNS解析记录
请登录到DNS管理面板, 然后一步一步地把A记录、AAAA记录、CNAME、MX、TXT这些都仔细检查一遍。需要特别重点确认的地方是: IP地址的字符有没有写错, 记录的类型是不是设置对了, 比如说, 不要让CNAME错误地被设成了A, 还有优先级字段是否处于合理的数值范围。
请使用代码片段 dig +short example.com A 来验证这些记录究竟有没有在当前生效。如果发现记录本身是正确的, 但是还没有生效, 请你继续进行下一步的操作。
步骤三：排除TTL与本地缓存影响
TTL这个值是用来决定缓存刷新的周期的, 所以在修改记录之后, 全球生效需要的时间是由原来的TTL值决定的, 常见的数值是<3600>秒或者<86400>秒, 所以一般建议你在修改之前先把TTL临时降低到<300>秒, 这样可以把等待恢复的时间给缩短。
与此同时, 需要把客户端本地的DNS缓存给清除掉, 具体的做法是: 在Windows系统下面执行ipconfig /flushdns这个命令, 在Linux系统下面执行sudo systemd-resolve --flush-caches这个命令, 完成这一步操作以后, 再进行重新测试。
步骤四：验证服务器端网络连通性
解析工作成功完成以后, 仍然需要确认目标服务器本身是能够访问到的。你可以利用代码标签中的ping命令去检测一下基础的连通性怎么样, 然后使用带有v参数和http协议的curl命令, 把目标IP地址作为网址输入进去, 这样做是为了验证指定的端口服务是不是处于正常运行的状态。
如果发现解析结果是正确的, 但是服务却无法贯通，那么故障的位置是在服务器的防火墙环节、云安全组阶段或者是应用服务层上面, 这就肯定不是DNS系统自身出现的问题了。
步骤五：检查域名注册状态
你可以去利用一下那个名叫是WHOIS的查询工具, 来看看你那个域名的状态到底是啥样, 要是上面出现了像是clientHold或者serverHold这些东西所代表的那种被锁起来的状况, 那这个域名就不能够被正常的解析了, 导致出现这种常见情况的原因一般是因为你没有交钱续费, 或者是没有去通过实名认证, 又或者是存在什么仲裁争议之类的麻烦事, 你需要去找联系一下那个注册商把锁定给解除了之后, 才能恢复正常使用。
步骤六：排查DNS服务商与线路故障
以上所有情况都属于正常的范畴, 这个时候的故障有可能出在DNS服务商那一侧, 也有可能是特定线路的问题。我们建议大家通过多地区、多互联网服务提供商（ISP）来进行对比测试, 测试的时候可以使用像8.8.8.8、114.114.114.114、223.5.5.5这些不同的公共DNS地址。
如果通过这样的方式发现只是某一个区域出现了异常的现象, 那么就需要去联系DNS服务商了, 让他们确认一下是否存在局部线路发生故障或者是节点宕机这样的情况。
补充
排查的全过程里, 大家建议要把每一个步骤的命令输出内容都保留下来, 这就当作是日志。如果这六步走完了依然没有办法把问题所在的环节找到, 那需要把DNS报文全部抓下来（tcpdump -i any -s 0 port 53）, 然后把这些东西提交给服务商, 让他们去做更深层次的诊断工作。
