## 概念是什么
dig 是 DNS 排查的主力工具，一次完整的域名解析涉及两类角色：递归服务器负责替你从根开始逐级问到结果，普通用户配置的就是它；权威服务器持有某个域的真实记录，是答案的最终来源。看懂这两个角色分工，解析问题就变成了在链路上定位哪一环出错。
## 背后原理
加 trace 参数后，dig 会模拟一次完整的递归过程：先问根服务器要该域的顶级域服务器，再问顶级域要该域的权威服务器，最后问权威拿最终记录。每一步的应答都会打印出来，链路上任何一个环节的记录指向错误，都会在输出里现形。
dig +trace example.com dig @223.5.5.5 example.com dig example.com NS +short
## 最小实操
排查从分角色查询开始：先指定本地递归服务器查一次，看它给的结果；再绕过缓存直接查权威，对比两者是否一致。递归给的旧、权威给的新，是缓存未过期；递归返回的地址与权威不同，可能是被劫持或中间盒篡改。查 NS 记录可以确认权威到底是谁， registrar 变更后经常需要核对这一步。
## 常见错误
只在本机查一次就下结论，没有区分缓存与权威，容易被旧记录误导。顺云云服务器上 systemd-resolved 之类的本地缓存层会再叠一层缓存，dig 指定服务器查询时务必带上 @ 前缀绕开它。另外域名的 TTL 意味着变更天然存在传播窗口，刚改完记录查到旧值是正常现象，等 TTL 过了再判定异常。
取证场景下 dig 还有进阶用法：同时查域名的 NS、SOA 与解析记录，把权威是谁、序列号多少、解析值是什么放在一张输出里对比。变更后的验收按这张清单走：权威上的记录正确、各递归陆续过期刷新、TTL 在变更前已调短，三个条件都满足，切换才可控。反向记录的验证也别忘，邮件与部分服务依赖反查，用 dig 的 x 参数按地址查名字。把常用查询做成别名脚本，排查时一键输出全套记录，省时也不漏项。