+trace 是唯一可靠方式查看 dns 完整递归链，从根服务器开始逐级查询，但默认不显示每步耗时，需结合 +stats 看总耗时，且必须置于命令末尾。
dig +trace 会走完整递归链，但默认不显示每步耗时
想看 DNS 是怎么一层层查到结果的，+trace 是唯一可靠方式。它从根服务器（.）开始，依次问根 → 顶级域（如 .com）→ 权威 NS → 最终答案，每步都发真实查询。
常见误区是以为 +trace 自带计时，其实它只打印步骤和返回状态，不显示单步响应时间。要加 +stats 才能看到总耗时，但依然不拆解每跳延迟。
-
+trace必须放在命令末尾，比如dig google.com +trace，放中间会被忽略 - 如果某步返回
REFUSED或TIMEOUT，说明那台服务器拒绝响应或不可达，不是你本地网络问题 - 输出里看到多个
SERVER:行，每个对应一跳实际通信的 DNS 服务器，不是你配置的 resolver - 某些防火墙或运营商会拦截对根/顶级域服务器的直连请求，导致
+trace卡在前两步——这时换用dig @8.8.8.8 google.com +trace可绕过限制
查不到答案时，+trace 输出里 status 不是 always NOERROR
+trace 过程中，中间任意一步 status 为 SERVFAIL 或 REFUSED，后续就停了；只有最后一步 status 是 NOERROR 才代表成功解析。
特别注意：中间步骤出现 NXDOMAIN 是正常的——比如问 .com 域名服务器“example.nonexistent”，它明确说“这个二级域不存在”，这本身就是有效响应，不是错误。
PyCharm 2026.2.0.1 Linux版提供 JetBrains 官方 2026.2.0.1 版本安装包，适合需要指定 PyCharm 版本进行 Python 项目开发、运行和调试的用户。
- 看到
;; Question Section:但没ANSWER SECTION，先看紧邻的status:字段，别急着认为失败 - 如果最后一跳是
NOERROR但ANSWER SECTION为空，说明权威服务器确实没配这条记录（比如查了不存在的子域名） -
+trace不走本地缓存，所以结果比普通dig更接近真实配置，适合验证刚改完的 DNS 记录是否生效
想对比不同 DNS 服务器的解析路径，得手动指定 @server
+trace 默认从你系统配置的 DNS（/etc/resolv.conf）开始，但你想知道 8.8.8.8 和 1.1.1.1 查同一域名路径是否一致，就得分别跑：
dig google.com @8.8.8.8 +trace<br>dig google.com @1.1.1.1 +trace
两个结果可能在第二跳（.com 域名服务器列表）就不同——因为不同递归服务器缓存的根提示（root hints）版本不一样，选的顶级域服务器也不同。
- 别写成
dig @8.8.8.8 google.com +trace和dig google.com @8.8.8.8 +trace，顺序错会导致@8.8.8.8被忽略 - 有些公共 DNS（如 OpenDNS）会修改 trace 路径，把部分步骤合并或重定向，导致看起来跳数变少，这不是 bug，是它们的策略
- 企业内网若部署了 split DNS，
+trace可能根本走不出去——此时只能用dig @内部DNS google.com +trace查内部路径
脚本里解析 +trace 输出，别靠 grep ANSWER
+trace 的输出结构是分段的，每跳一个独立响应块，ANSWER SECTION 只出现在最后一块。用 grep ANSWER 会匹配到中间步骤的空 SECTION，误判为有答案。
真正稳的办法是找最后一段的 status: NOERROR 后面紧跟着的 ANSWER SECTION，或者直接取最后一块的 IN A / IN AAAA 行。
- 简单提取最终 IP：
dig google.com +trace | awk '/^$/ {p=0} /^;;.*ANSWER.*$/ {p=1; next} p && /IN[[:space:]]+(A|AAAA)[[:space:]]+/ {print $5; exit}' - 更安全的做法是用
dig google.com +trace +noall +answer，但它只输出最终答案，不显示路径——折中方案 - 如果目标是自动化判断某记录是否存在，优先用
dig example.com A +noall +answer配合grep -q，而不是解析 trace 输出
