域名解析出现故障的时候, 核心排查路径是这么规定的, 也就是从本地缓存开始, 到DNS递归服务器为止, 再到权威DNS服务器这里, 最后检查服务器网络状况, 按照这样的顺序去逐项定位问题, 这样是可以把百分之九十五以上的各类解析异常场景都给覆盖住的, 下文是按照层级层面来给出标准操作流程的。
第一层：本地与客户端排查
1. 清除本地DNS缓存
在Windows系统当中, 你需要去执行ipconfig /flushdns这个具体的操作动作, 通过这个方法来达成相应的结果。
macOS：执行 sudo dscacheutil -flushcache
把东西清除掉之后, 再去重新访问目标域名, 以此确认会不会是本地缓存残留导致的问题出现。
2. 对本地网络的连接情况进行测试和确认。
执行代码段 ping 加目标IP的操作, 来确认网络层是否可达。
执行 tracert（Windows）或 traceroute（Linux/macOS），定位网络中断节点
3. 更换测试DNS
把本地DNS暂时改成分开的逗号, 具体操作就是把本地DNS临时改为 114.114.114.114 , 或者把它临时改为 8.8.8.8。
如果你进行了更换操作之后, 发现解析的功能重新恢复了正常运转的状态, 那么这就说明了原先的那个域名服务器供应商方面存在异常的、不正常的情况。
第二层：DNS递归与权威服务器排查
1. 使用 dig 命令查询完整解析链
基础性的查询操作, 可以使用指令dig example.com A +trace。
如果我们拿gz88.cn这个情况当作一个例子来看的话, 通过去使用 dig gz88.cn A +trace 这种操作方式, 是可以把从最上面的根服务器一直到那个权威的NS所经历的递归路径, 给非常彻底地追踪清楚的。
把重点放在每一层级的名字服务器的响应上面, 去观察它们花费了多长时间才给出回复, 并且仔细检查在这些回复的信息之中, 是不是出现了表示拒绝服务的 REFUSED 或者是表示服务器错误的 SERVFAIL。
2. 对那个权威名称服务器里的配置情况, 去好好地检查一遍。
请登录域名注册商的后台系统, 然后进行确认工作以确保名称服务器记录正确地指向了权威DNS服务器的。
要去确认TTL值这个东西, 是不是会变得异常大, 如果把它设置成了像好几天那么长的时间, 会不会出现一种情况, 就是在你进行完修改之后, 需要等待很长时间才能看到生效的现象。
对A记录、CNAME记录以及MX记录的数值进行逐一核对, 检查这些内容里面的英文字母或者是数字, 是不是都拼写对了。
3. 验证权威服务器状态
对权威DNS IP执行 ping 和 dig 测试
如果响应时间超过设定的时限, 需要对服务器的防火墙规则进行检查, 同时要检查 DNS 服务进程（Bind9/PowerDNS）是否处于正常的运行状态。
第三层：服务器与网络层排查
1. 在服务器的那一侧, 对数据进行验证的操作。
在服务器上面执行一下这个动作, 也就是用代码框里面写的那个, dig后面跟一个域名这个组合的形式, 通过这种方式来把外部网络带来的那些影响给排除掉, 这样就比较稳妥了。
检查 /etc/resolv.conf（Linux）中DNS配置是否正确
去确认一下安全组或者是不是防火墙没有把五百三端口给拦截住了, 这个端口是udp协议加tcp协议的。
2. 证书与协议排查
如果HTTPS站点的解析情况是正常的, 但是还是没有办法进行访问的话, 那么建议先去检查一下SSL证书这个内容是否存在过期的这种可能性。
执行 openssl s_client -connect 域名:443 这个操作, 通过这个方法, 来验证证书链的完整性, 是不是完整的。
高频疑难与对应处理
预防措施
权威DNS至少配置2台不同机房的NS域名解析故障排查域名解析故障排查龙南市就业服务平台，避免单点故障
在生产环境里, 对于TTL值, 大家建议把它设置成300秒以内, 主要是为了兼顾到解析速度, 还有故障恢复的时效性。
我们接入了一种基于dig工具的定时DNS巡检监控措施。这种监控能在故障影响到终端用户之前提前触发告警信号。
将那些关键的域名全部都启用那个 DNSSEC 技术, 以此来防止中间人对手那边的篡改作用, 导致那个解析出来的这个结果发生错误。
大家可以把上述流程看作是涵盖了从客户端一直到权威服务器这个完整解析链路的全过程, 只要能够按照层级顺序去一一执行操作的话, 那么就可以顺利定位绝大多数域名所存在的关联的解析故障问题。
