本文由 AI 辅助撰写，内容经人工复核。文中案例来自一次真实排查，域名与验证 token 已做脱敏处理。
日常工作中经常需要验证一条 DNS 记录是否生效：SPF 是否配好、google-site-verification 是否还在、CNAME 有没有指对。Linux 上一条 dig 就能搞定，换到 Windows、再遇上网络环境干扰，事情就会变得有趣起来。本文整理各平台的等效命令，并用一次真实排查案例演示如何交叉验证 DNS 结果。
一、Linux / macOS：dig 是标准答案
dig 是最常用的 DNS 查询工具，macOS 自带，主流 Linux 发行版可通过 bind-utils / dnsutils 包安装。
# 查询 TXT 记录，+short 只输出记录值
dig +short TXT example.com# 过滤出目标记录
dig +short TXT example.com | grep 'google-site-verification='# 指定 DNS 服务器查询（@ 后跟服务器）
dig +short TXT example.com @8.8.8.8# 直接查权威 NS（先查 NS，再向权威发问）
dig +short NS example.com
dig +short TXT example.com @ns1.example-dns.com# 强制走 TCP（排除 UDP 截断问题）
dig +tcp TXT example.com @8.8.8.8# 查看完整应答（含 TTL、flags、应答来源）
dig TXT example.com
nslookup 和 host 也可用，语法更简单，输出信息较少：
nslookup -type=TXT example.com
host -t TXT example.com
二、Windows：Resolve-DnsName 是 dig 的等效物
Windows 没有自带 dig，Git-Bash 里同样没有捆绑。PowerShell 的 Resolve-DnsName 覆盖了 dig 的绝大部分能力。
# 等效于 dig TXT example.com
Resolve-DnsName example.com -Type TXT# 等效于 dig +short（只要记录值）
(Resolve-DnsName example.com -Type TXT).Strings# 等效于 dig +short ... | grep 'xxx'
(Resolve-DnsName example.com -Type TXT).Strings | Select-String 'google-site-verification='# 指定服务器 + 强制 TCP（等效于 dig @8.8.8.8 +tcp）
Resolve-DnsName example.com -Type TXT -Server 8.8.8.8 -TcpOnly# 精确匹配可以用 Where-Object
(Resolve-DnsName example.com -Type TXT).Strings |Where-Object { $_ -like '*google-site-verification=*' }
不方便用 PowerShell 时，nslookup 在 cmd / PowerShell / Git-Bash 里通用：
nslookup -type=TXT example.com
nslookup -type=TXT example.com 8.8.8.8:: cmd 下用 findstr 过滤
nslookup -type=TXT example.com | findstr "google-site-verification="
确实想在 Windows 上用原生 dig，可以安装 BIND 工具包：
winget install ISC.Bind9
dig 与 PowerShell 对照速查表
| dig 写法 | PowerShell 等效写法 |
|---|---|
dig TXT example.com |
Resolve-DnsName example.com -Type TXT |
dig +short TXT example.com |
(Resolve-DnsName example.com -Type TXT).Strings |
dig ... | grep 'xxx' |
... | Select-String 'xxx' |
dig @8.8.8.8 ... |
... -Server 8.8.8.8 |
dig +tcp ... |
... -TcpOnly |
dig MX / NS / CNAME ... |
... -Type MX / NS / CNAME |
三、在线工具与 DNS-over-HTTPS：第三个视角
本地命令查到的结果受本机网络路径影响。需要一个独立视角时，有两类工具。
1. Google Admin Toolbox Dig（网页版）
地址：https://toolbox.googleapps.com/apps/dig/，URL 支持直达参数，例如 #TXT/example.com。
浏览器只负责展示页面，实际 DNS 查询由 Google 的服务器在它们的机房发出，查询流量完全脱离本机网络。适合人工临时查证。
2. DNS-over-HTTPS JSON API（可脚本化）
Google 与 Cloudflare 都提供 DoH 的 JSON 接口，查询从本机发出，走加密的 443 端口，中间设备无法篡改应答：
# Google Public DNS
curl -s 'https://dns.google/resolve?name=example.com&type=TXT'# Cloudflare（需要 accept 头）
curl -s -H 'accept: application/dns-json' \'https://cloudflare-dns.com/dns-query?name=example.com&type=TXT'
PowerShell 版本：
$r = Invoke-RestMethod 'https://dns.google/resolve?name=example.com&type=TXT'
$r.Answer.data | Select-String 'google-site-verification'
两者视角上的细微差别：DoH 查询由本机发起，Google 解析器可能通过 EDNS Client Subnet 把发起方的大致网段告知权威服务器，因此对做了地理分流的域名，DoH 结果更贴近本地区应看到的答案；网页版 Toolbox 的查询源是 Google 机房，反映的是数据中心视角。绝大多数场景下两者结果一致。
四、实战案例：一条"时有时无"的 TXT 记录
以下排查过程发生在 2026-08-06，域名已脱敏为 example.com。
现象：验证某域名的 google-site-verification TXT 记录。第一次查询返回 17 条 TXT 记录，目标记录在列；几分钟后重查，只剩 5 条，目标记录消失。
排查步骤：
- 换服务器：指定
8.8.8.8查询，仍是 5 条。 - 强制 TCP：
-TcpOnly排除 UDP 截断（大 TXT 记录集超过 UDP 包限制时会置 TC 位要求 TCP 重试），仍是 5 条。 - 直查权威 NS：先查 NS 记录定位权威服务器，再分别向两台权威直查，UDP 与 TCP 都只有 5 条。到这一步，表面证据已经指向"记录被管理员删除"。
- 换视角复核：用 Google Admin Toolbox 网页版查询——返回完整 17 条，目标记录赫然在列。
- DoH 交叉验证：
dns.google与cloudflare-dns.com的 DoH 接口同样返回 17 条。 - 回归复测：再次从本机走 53 端口查询各服务器，全部恢复 17 条。
结论：权威数据从头到尾完整无缺。那几分钟里，本机出口网络对境外 53 端口的 DNS 流量存在中间设备代答，返回了不完整的记录集——连 TCP 直查权威都拿到同样的残缺应答，这只有代答设备可以解释，普通的 UDP 截断做不到。目标记录 TTL 仅 5 分钟，异常消退后坏缓存很快被刷掉。
教训：
- 本地查询结果与预期不符时，先怀疑查询路径，再怀疑记录本身。
- "指定了 8.8.8.8"并等于"应答真的来自 8.8.8.8"，明文 53 端口的流量可以被中间设备拦截代答，TCP 同样可以。
- DoH 是本机可用的最可靠交叉验证手段：查询加密、应答加密，中间设备无从下手。
- 权威 NS 直查排除的是递归解析器缓存问题；要排除网络路径问题，必须换传输通道（DoH）或换查询源（网页工具）。
五、总结：一套可复用的验证流程
验证一条 DNS 记录是否真实存在，按成本从低到高：
- 本机常规查询（
dig/Resolve-DnsName）。 - 指定公共 DNS（8.8.8.8 / 1.1.1.1）加
+tcp/-TcpOnly复查。 - 直查权威 NS，排除递归缓存。
- DoH JSON 接口交叉验证，排除本机网络路径干扰。
- 网页版工具（Google Admin Toolbox Dig）换查询源做最终确认。
前三步结果一致即可信；出现矛盾时，第 4、5 步给出的才是权威事实。