要查看域名DNS递归解析完整路径，需用dig +trace模拟真实递归过程，从根服务器逐级查询；+noall +answer可精简输出仅最终答案，+short则仅返回最终IP但丢失中间状态，排查中断点时必须禁用+short。
要查看域名DNS递归解析的完整路径，必须让dig模拟真实递归客户端行为，从根服务器开始逐级向下查询，而不是直接向本地DNS发一次请求就返回结果。
用+trace选项跟踪完整递归链
执行dig +trace example.com。该命令会从根域（.）出发，依次向根服务器、顶级域服务器（如.com）、权威服务器发起查询，每一步都打印出响应详情。
输出中每一段以分号开头的“;; Received”行表示当前层级的响应来源，注意看SERVER字段是否按预期切换：先是13台根服务器之一，再是.com的NS，最后才是example.com自己的权威NS。
如果某一级返回SERVFAIL或超时，说明该层级DNS服务异常；若卡在某步长时间无响应，可能是防火墙拦截了UDP 53端口或上游策略限制了递归深度。
配合+noall +answer精简关键答案行
方法一：加+noall +answer只保留最终答案
执行dig +trace +noall +answer example.com。它仍走完整递归路径，但只在最后输出ANSWER SECTION内容，避免中间步骤干扰判断。
方法二：用+short进一步压缩
执行dig +trace +short example.com。这会把整个CNAME链展开后仅输出最终IP，适合脚本调用，但丢失了中间各层的status和SERVER信息，无法定位卡在哪一级。
【+short在+trace下不显示中间过程，仅输出最终结果】——若需排查中断点，必须去掉+short。
验证递归是否真正启用
第一步：确认本地DNS支持递归
执行dig @127.0.0.53 example.com +norecurse（假设systemd-resolved监听此地址）。若返回REFUSED或NOTIMP，说明该服务器拒绝非递归查询，即它默认就是递归模式。
第二步：强制走系统默认递归链
直接运行dig example.com（不加@、不加+trace），观察SERVER字段是否指向/etc/resolv.conf里的地址。若是，则证明当前环境已启用递归；若指向意外IP，说明被DNS劫持或配置被覆盖。
第三步：对比+trace与普通查询的响应时间
普通查询通常毫秒级返回，+trace可能耗时2～5秒。若两者耗时几乎一致，说明+trace被本地缓存短路——此时应加@8.8.8.8重试，绕过本地resolver。
