dig不支持全程追踪，+trace仅模拟递归路径而非复现mdnsresponder真实解析；真实链路需tcpdump捕获53端口流量，并结合scutil --dns等命令综合诊断。
dig 本身不支持“全程追踪”——它只查一次 DNS 查询，想看到递归全过程，必须手动模拟或换工具。
为什么 dig +trace 不等于真实递归过程
dig +trace 看似在“追踪”，实际是 dig 自己发起一系列独立查询：先问根服务器，再问顶级域，再问权威服务器……但它不复现本地递归解析器（如 macOS 的 mDNSResponder 或配置的 DNS 服务器）的真实行为。你看到的是 dig 的“探路”，不是系统真实的解析链路。
- macOS 默认用
mDNSResponder做 DNS 缓存和递归，它内部逻辑（比如是否转发、是否用 DoT、是否 fallback）dig +trace完全不体现 -
+trace强制绕过本地缓存和配置，直接走公网 DNS 层级，结果可能和nslookup example.com或浏览器实际访问结果不一致 - 遇到 CDN、Anycast、EDNS 子网划分等场景，
+trace返回的路径往往是“理论最优”，而非你本机真实拿到的 IP
真正想看 macOS 实际怎么解析，得抓本地流量
唯一可靠方式是捕获 mDNSResponder 发出的 DNS 请求。macOS 不允许直接 strace，但可用 tcpdump 过滤 UDP 53 端口，并配合 dig 触发解析：
- 新开终端，运行：
sudo tcpdump -i any -n -s 0 port 53 and udp - 另开终端，执行：
dig example.com A（不要加+trace） - 观察 tcpdump 输出中是否有发往你配置的 DNS（如
192.168.1.1或8.8.8.8）的查询，以及是否收到响应 - 如果没看到请求，说明命中了
mDNSResponder本地缓存——此时可先清缓存：sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
dig 的实用组合技：聚焦某一层验证
与其强求“全程”，不如用 dig 精准验证特定环节。例如排查为什么某个域名解析慢或错，按顺序检查：
- 查本机配置的 DNS 是否生效：
dig @127.0.0.1 example.com（假设你用 dnsmasq 或 stub resolver） - 绕过本机，直连上游 DNS：
dig @8.8.8.8 example.com，对比结果差异 - 查权威服务器是否返回预期记录：
dig @ns1.example.com example.com A（需先用dig NS example.com拿到权威 NS） - 检查 DNSSEC 是否中断：
dig +dnssec example.com，看响应里ad标志位是否置位
容易被忽略的关键点
macOS 的 DNS 解析不是单一线性链路：它可能混合使用 /etc/hosts、mDNS（.local）、DNS over HTTPS（通过网络设置配置）、甚至企业 MDM 推送的 DNS 策略。单纯盯着 dig 输出，很容易误判问题根源。
真正卡住的时候，优先确认三件事：scutil --dns（看当前生效的 DNS 配置）、cat /etc/resolver/*（看是否有自定义域解析规则）、ping -c1 example.com（看是否被 /etc/hosts 或 mDNS 拦截）。dig 只是其中一环，不是全貌。
