用 dig 而不是 nslookup：五个真正有用的 DNS 查询

2026-10-29 · DNS / 排障

nslookup 是 Windows 自带的，所以大部分人排障时第一个用它。问题是它的输出不区分「答案来自缓存」还是「答案来自权威」，也不显示 TTL，更不会告诉你是谁在回答。这三件事恰好是 DNS 排障最需要的信息。

dig 会把这些都打出来。Windows 上没有预装，装 BIND 工具或者用 WSL / Git Bash 里的版本都行；实在不想装，可以用 Resolve-DnsName，输出结构也够用。

一、先看谁在回答

dig tynqueevue.com A

输出里最该看的是这两行：

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3421
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
...
;; SERVER: 192.168.1.1#53(192.168.1.1)

status 是结果码，SERVER 是回答你的那台机器。如果 SERVER 是你家路由器，那这个答案可能来自缓存，不代表现在的真实状态。

要问权威服务器，加 @：

dig @1.1.1.1 tynqueevue.com A
dig @8.8.8.8 tynqueevue.com A

两个公共解析器给出同样的答案，才说明记录真的生效了。只有一个对，说明还在传播。

二、看委派链，而不是猜

dig +trace tynqueevue.com

这一条会从根服务器开始，一级一级问下来：根 → .com → 你的权威 NS → 最终答案。中间每一步都打出来。

它解决的是「我到底该找谁」这个问题。比如 NS 改了但站点不生效，+trace 能直接告诉你是注册商还没把新 NS 写进 .com 区，还是 .com 已经更新但权威服务器上没这条记录。这两种情况的修法完全不同。

注意 +trace 会绕过本地缓存直接问，所以它慢，但它是唯一能看到完整链路的方法。

三、只想要答案

dig +short tynqueevue.com A
dig +short tynqueevue.com MX
dig +short tynqueevue.com TXT

适合写进脚本。比如检查 MX 是不是 Cloudflare 的：

dig +short tynqueevue.com MX | sort

预期是三条 route1/2/3.mx.cloudflare.net，带 10/20/30 的优先级。少一条就说明 Email Routing 没配全。

四、CNAME 链要看全

dig tynqueevue.com CNAME +noall +answer

CNAME 可以套好几层：www → xxx.pages.dev → yyy.cloudflare.net。任何一层断了，最终解析就失败，但报错只会在最后一跳出现。

+noall +answer 只保留答案段，看起来干净很多。

五、确认「没有」是真的没有

dig tynqueevue.com AAAA
dig _dmarc.tynqueevue.com TXT

如果返回 status: NXDOMAIN，说明这个名字不存在；如果返回 NOERROR 但 ANSWER: 0，说明名字存在但没有这种记录。这两个状态在排障时含义完全不同：前者可能是名字拼错，后者只是没配。

还有一点容易踩：否定应答也会被缓存。你刚加了一条记录，但本地解析器之前缓存了 NXDOMAIN，那么在 TTL 到期前你看到的仍然是「不存在」。这时候换 @1.1.1.1 问一下，就能区分是「没配好」还是「缓存还没过期」。

一条命令做完体检

for t in A AAAA NS MX TXT CAA; do
  echo "== $t =="
  dig +short tynqueevue.com $t @1.1.1.1
done

PowerShell 版本：

'A','AAAA','NS','MX','TXT','CAA' | ForEach-Object {
  "== $_ =="
  dig +short tynqueevue.com $_ @1.1.1.1
}

六条记录一次看完，比一条条敲快，也不容易漏。

一个反直觉的点

ANY 查询已经被 RFC 8482 事实上废弃了。很多解析器对 ANY 直接返回 HINFO 或者截断结果，所以别用 dig ANY 来「一次看全部记录」——你会得到一个看起来像答案、其实不完整的结果。要哪条就查哪条。

相关：NS 改了但站点不生效 · 只改 NS 的域名迁移