当人们发现网站打不开, 或者域名配置完后完全不生效, 那么百分之八十以上的根本原因都是出在DNS解析这一整个过程里。DNS解析检测工具的主要作用是什么?
它的核心作用就是在不修改代码、不重新启动服务这样的情况下面, 去非常精确地找到在解析这条链路上具体是哪一环节出了问题, 从而把原本需要好几个小时才能完成的排查时间, 一下子压缩到只需要几分钟即可完成。
01检测前必须确认的3项信息
在开始检测之前, 需要先核对下面的这些内容, 不然的话结果就不可能进行正确判断。
你需要确认, 你要进行核查工作的对象是属于A记录类型呢, 还是说属于IPv6地址所对应的AAAA记录类型, 再不然, 就是CNAME这样的规范名称记录类型, 或者是用于处理邮件交换事务的MX记录类型中的一种。
权威DNS服务器地址是在域名注册商的后台管理界面, 或者通过 whois 信息可以查到的名称服务器, 比如 ns1.gname.xin 以及 ns2.gname.xin。
它是进行检测工作的基准锚点。如果跳过这一步操作, 那么最后的检测结果可能只会反映出本地的缓存情况, 而无法表现出真实的解析状态究竟如何。
期望返回的IP或目标值需要提前做好记录, 把正确的解析结果存下来, 等到进行检测的时候, 一项一项地去进行核对和比对。
025步检测流程
第1步：本地Hosts排除
你需要去检查操作系统的hosts文件, 如果你是用Windows系统的话, 路径是C:\Windows\System32\drivers\etc\hosts, 如果你用的是Linux或者Mac系统的话, 路径是/etc/hosts, 然后你要确认目标域名没有遭到本地强制指向。
要是发现存在这样的强制指向, 你先把它给注释掉, 然后再重新进行检测。
第2步：递归解析追踪
你可以通过dig +trace 域名这种命令, 或者使用在线的DNS解析检测工具来进行操作。你需要从根服务器开始一层一层地往下进行追踪观察。在这样的过程中, 要看看每一跳所返回的那个Nameserver, 是不是按照大家预期的那样在执行传递任务。
这里大家要特别去关注TTL这个数值的状况。如果TTL值变得异常大, 具体是说它超过了7200秒, 并且你这边刚刚对记录做了一些改动, 出现这样的情况就说明旧的缓存还没有过期呢, 这属于正常的延时情况。
第3步：对比多节点结果
请前往至少包括114.114.114.114, 223.5.5.5和1.1.1.1在内的, 三个不同地域的公共DNS服务节点上, 分别去执行dig @114.114.114.114 域名 A这个操作动作, 然后把从各个节点那里所返回来的IP地址拿出来进行互相比对, 以此来确认它们是否能够保持完全一致。
如果有一个节点返回了NXDOMAIN这个结果, 或者是返回了SERVFAIL这个结果，那么就说明这一条线路出现了递归方面的故障问题, 也可能是运营商方面进行了劫持行为。
第4步：权威服务器直查
你可以直接用 dig @ns1.gname.xin 域名 A 这个命令进行测试, 这里需要把域名替换成你自己域名的权威NS服务器地址, 这个方法是最接近拿到真实答案的一步操作, 要是权威服务器那边返回了正确的记录内容, 但是递归查询那边得到的结果却不一致, 那么问题就会出在中间的递归链路上面。
第5步：CNAME/MX链路完整性校验
如果记录的类型是CNAME, 那么需要一步一步地展开, 一直看到A记录或者AAAA记录, 要是记录的类型是MX, 就要去确认目标邮件服务器这边的解析情况也是没有问题的, 使用dig +follow这个命令就可以把这一整条链都自动展开了。
03结果判读速查
04高频疑难快速处理
改完记录10分钟仍不生效: 你可以去查看旧记录的TTL, 然后你需要等待的最大时间是那个TTL的秒数。如果你遇到了紧急情况, 你可以临时把TTL调为60秒, 然后再进行修改操作。
仅某省/某运营商用户打不开: 这很有可能是本地的运营商DNS缓存出现了问题, 或者是发生了递归故障, 需要在检测工具里面指定该运营商的DNS节点来重复出现这个问题, 然后再向运营商那边进行报障。
使用dig工具进行查询, 其返回的结果显示为NOERROR无误, 然而你的浏览器仍然会提示出错的状况, 因此你需要去清除掉浏览器端保存的DNS缓存数据, 具体操作方法是在Chrome浏览器的地址栏里输入并访问chrome://net/#dns这个网址, 以此来把因为浏览器那边缓存所带来的干扰给彻底排除掉。
完成上文的这5步操作, 就可以把DNS解析故障中占比达到95以上百分比的排查场景全部覆盖到, 完全就没有必要再去进行一层接一层的猜测分析了。
