dig是诊断DNS问题的核心工具，通过拆解解析链路——查本地配置（/etc/resolv.conf、systemd-resolved）、+trace跟踪递归路径、直连权威服务器验证记录、检查MX/TXT/DNSSEC等关键类型，实现可读、可比、可验证的精准排障。
排查复杂 DNS 问题，不能只看“能不能解析”，而要拆解整个解析链路：从本地配置、递归路径、权威响应到缓存状态。dig 的价值就在于把这一整套黑盒过程变成可读、可比、可验证的文本输出。
查清本地 DNS 配置是否生效
系统实际用哪个 DNS 服务器，未必是你以为的那个。/etc/resolv.conf 可能被 NetworkManager 或 systemd-resolved 动态覆盖，导致查询行为和预期不符。
- 运行 cat /etc/resolv.conf 查看当前生效的 nameserver 列表
- 用 dig @127.0.0.53 google.com +short（systemd-resolved 默认地址）和 dig @192.168.1.1 google.com +short（你的网关DNS）对比结果
- 若两者返回不同IP或超时，说明本地解析服务异常，需检查 resolved 状态：systemctl status systemd-resolved
跟踪完整解析路径，定位卡点在哪一级
+trace 选项会模拟递归解析全过程，逐级向根服务器、顶级域、权威服务器发起查询，清晰显示哪一环失败或返回异常。
- 执行 dig example.com +trace
- 观察输出中每一段响应的 status 字段：NOERROR 表示成功，SERVFAIL 是服务器错误，NXDOMAIN 是域名不存在，REFUSED 是被拒绝
- 重点关注最后一段非根/非顶级域的响应——它来自你的目标域名权威服务器，如果这里返回空或错误，就是域名配置本身的问题（如 NS 记录未生效、区域文件语法错误）
绕过缓存，直连权威服务器验证真实配置
本地或中间 DNS 缓存可能污染结果。直接向权威服务器发查询，才能看到最原始的记录状态。
- 先查权威服务器：dig example.com NS +short 获取该域名的 NS 列表（如 ns1.example.com.）
- 再查该 NS 的 IP：dig ns1.example.com. A +short
- 最后直连查询：dig @192.0.2.1 example.com A（用上一步得到的真实IP替换）
- 若直连能返回正确A记录，但普通 dig 不行，基本可判定是缓存延迟、递归服务器故障或中间策略拦截
检查关键记录类型与安全机制是否合规
现代 DNS 问题常涉及 MX、TXT（SPF/DKIM）、CAA 或 DNSSEC，单一 A 记录正常不代表服务可用。
- 查邮件配置：dig example.com MX +noall +answer
- 查 SPF 策略：dig example.com TXT +noall +answer，确认返回值含 v=spf1 开头且语法无误
- 查 DNSSEC 签名状态：dig example.com DNSKEY +noall +answer 和 dig example.com RRSIG A +noall +answer
- 若某条记录缺失或格式错误（比如 TXT 记录末尾多空格、CAA 记录值不合法），会导致邮件拒收、HTTPS 证书申请失败等连锁问题
