“网站打不开了”，这句话里有三种可能：服务挂了、网络断了、域名解析出问题。先花 10 秒排除第三种，再去重启服务——很多人顺序是反的。dig 就是干这 10 秒活的工具：它直接向 DNS 服务器发查询并把原始应答摆出来，比 ping 域名靠谱得多，因为 ping 失败可能是防火墙拦了 ICMP，但解析问题藏不住。
Ubuntu 24.04 默认没装 dig（装的是精简的 nslookup），一行补上：
sudo apt install dnsutils
dig -v # 输出 DiG 9.18.x 即可，下文命令均在 9.18 验证dig 属于 BIND 套件的一部分，但你不需要自建 DNS 服务器才能用它——它就是个客户端查询工具。本文的排查链从近到远：本机配置 → 递归解析器 → 权威服务器，每一步都有对应的 dig 用法。
先读一条最基础的查询输出
dig example.com输出分四段，排障时各看一处：
; <<>> DiG 9.18.28-0ubuntu0.24.04.1-Ubuntu <<>> example.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12345
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; QUESTION SECTION:
;example.com. IN A
;; ANSWER SECTION:
example.com. 86400 IN A 23.192.228.80
;; Query time: 12 msec
;; SERVER: 8.8.8.8#53(8.8.8.8) (UDP)
;; WHEN: Tue Oct 21 10:00:00 CST 2026
;; MSG SIZE rcvd: 55四个关键位置：
| 位置 | 看什么 | 说明 |
|---|---|---|
status: | 应答状态 | NOERROR 正常；NXDOMAIN 域名不存在；SERVFAIL 服务器解析失败 |
ANSWER SECTION | 解析结果 | 左侧第二列是 TTL（秒），记录还能缓存多久 |
SERVER: | 实际应答的服务器 | 不加 @ 时就是 /etc/resolv.conf 里的那台 |
Query time | 解析耗时 | 几毫秒正常；上千毫秒说明解析器响应慢 |
注意 SERVER 这行：dig 默认问的是系统配置的递归解析器，不是域名的权威服务器。你拿到的答案是缓存出来的还是权威给的，从这个字段判断——这是后面所有排查的起点。
排查第一步：确认本机用了哪个 DNS
域名解析异常时，先确认”这台机器在问谁”。/etc/resolv.conf 在 systemd-resolved 接管后是个存根文件，真实配置要看 resolved 自己：
resolvectl status | grep -A2 "DNS Server"输出里 Global 下的 DNS 服务器是全局配置，每个网卡链接下的才是实际生效的。Ubuntu 24.04 装机后这里往往是云厂商的内网 DNS 或 DHCP 下发的地址。
排除本机配置干扰的更快办法：绕过系统配置，直接指定公共解析器对比查询。
dig @1.1.1.1 example.com +short
dig @8.8.8.8 example.com +short+short 只输出结果值，去掉所有注释和统计行，对比查询时干净得多。两个公共解析器都返回正常 IP、系统默认解析器返回异常 → 问题锁定在系统配置或上游链路，改 /etc/systemd/resolved.conf 的 DNS= 或检查 DHCP 下发。两边都异常 → 问题在域名本身，往下走。
排查第二步：分别查各类记录
“解析不对”很多时候是记录类型查错了。一个域名挂在 DNS 上的记录不止一种，网站打不开时至少查这四类：
| 记录类型 | 查询命令 | 内容 | 排查点 |
|---|---|---|---|
| A | dig example.com A | IPv4 地址 | 网站走 IPv4 的主记录 |
| AAAA | dig example.com AAAA | IPv6 地址 | IPv6 配错了浏览器可能先试它再超时 |
| MX | dig example.com MX | 邮件服务器 | 收不到邮件查这个 |
| CNAME | dig www.example.com CNAME | 别名指向 | CDN/对象存储托管常见 |
+short 模式下 CNAME 链会完整展示出来，别名指到哪一目了然：
$ dig www.example.com CNAME +short
www.example.com. example.com. 0 IN CNAME example.com.
example.com. 86400 IN A 23.192.228.80反向解析（IP 反查域名）用 -x，dig 自动把地址转成 in-addr.arpa 格式：
dig -x 8.8.8.8 +short邮件服务器 IP 没配 PTR 记录会被对方拒信，这个命令是配完 PTR 后的验证步骤。
排查第三步：绕过缓存，问权威服务器
递归解析器给的答案带缓存，TTL 没走完之前改了记录也看不到新值。“我刚改了记录怎么没生效”八成是缓存，不是没改上。要验证改动真的写进了权威服务器，先找出权威 NS：
$ dig example.com NS +short
a.iana-servers.net.
b.iana-servers.net.然后直接指定其中一台查询：
dig @a.iana-servers.net example.com A +short这条查询跳过所有中间缓存，权威服务器说什么就是什么。它有新值而本地没有 → 纯粹等 TTL 过期，不用再动配置；权威服务器也没有新值 → 改动没提交成功，回注册商后台检查。
看 TTL 的剩余值也能判断缓存新旧：同一台递归解析器上连续查两次，TTL 递减说明读的是缓存，TTL 回到初始值说明记录刚刷新。
排查第四步：+trace 看完整解析链路
前几步排不出问题、怀疑某一级委派出错时，+trace 从根服务器开始把整条递归链路走一遍：
dig example.com +trace输出按层级展示：先拿到根服务器列表，再问 .com 顶级域，再拿到 example.com 的 NS 委派，最后拿到 A 记录。链路断在哪一级，输出就停在哪一级——.com 那层之后没有下文，就是顶级域委派出了问题；NS 返回了但没拿到 A，就是权威服务器配置的问题。
对自建 DNS 服务器（BIND 等），+trace 配合 @ 可以区分”权威侧答错了”和”递归侧没问到”：trace 是 dig 自己模拟递归查询，指定 @ 只影响最初的根查询。日常排查不用每次都 trace，前四步命令能覆盖的场景轮不到它。
两种失败状态：NXDOMAIN 和 SERVFAIL 指向不同问题
| status | 含义 | 常见原因 | 下一步 |
|---|---|---|---|
| NXDOMAIN | 域名不存在 | 域名过期、记录被删、NS 配置错误 | 先查 NS 是否正确指向 |
| SERVFAIL | 解析失败 | 权威服务器不响应、DNSSEC 校验失败、委派断裂 | 用 +dnssec 和 +trace 定位 |
两个都查不出记录，但指向的问题不同。快速区分：
dig example.com A +dnssec # 带 DNSSEC 数据查询
dig @a.iana-servers.net example.com A +short # 直接问权威权威有答案而递归 SERVFAIL，十有八九是 DNSSEC 校验失败——签名过期、DS 记录不匹配都会触发。注册商后台重新签名或修正 DS 记录后，递归侧恢复。
四步各答一问：排查链条全貌
| 步骤 | 命令 | 回答的问题 |
|---|---|---|
| 1. 本机配置 | resolvectl status | 这台机器在问哪个 DNS |
| 2. 换解析器对比 | dig @1.1.1.1 域名 +short | 问题在本机还是域名本身 |
| 3. 问权威服务器 | dig @权威NS 域名 +short | 改动是否已落库、缓存何时过期 |
| 4. 追解析链路 | dig 域名 +trace | 委派链断在哪一级 |
四步的顺序是成本排序：前两步 10 秒内出结论，后两步只在问题指向域名本身时才需要。绝大多数”网站打不开”的工单，走完第二步就能定责——本机配置、解析器链路、域名记录三者必居其一。
常见问题
Q：dig 和 nslookup 有什么区别？
nslookup 是交互式简化工具，dig 输出结构更完整（各 section 分明、TTL 可见、+trace 等查询选项丰富）。脚本里两者都能用，排障首选 dig；host 命令是另一个轻量替代，输出最简。
Q：+short 能指定输出格式吗？
+short 只输出记录值本身。要看 TTL 用默认完整输出，或 dig +noall +answer 只保留 ANSWER 段。写脚本处理时还可以 -x 反查或 +yaml 拿结构化输出。
Q：为什么我查到的 IP 和同事的不一样？
正常的。解析结果受解析器位置、GEO 调度、CDN 边缘节点影响。两边先各自 dig @8.8.8.8 域名 +short 指定同一个解析器再比，差异仍存在才说明记录有问题。
Q：公司内网域名能查吗？
能，前提是这台机器的解析器（resolvectl status 里看到的）能解析它。内网域名直接 dig 内网域名 走系统配置的解析器即可，不要用 @8.8.8.8——公共解析器没有你的内网区域数据。
Q：改了 DNS 记录多久生效？
改的是权威侧，保存即生效（用 @权威NS 立刻可验证）。全网可见要等各递归解析器的缓存按 TTL 自然过期，TTL 86400 就是最长一天。迁移记录前先把 TTL 调小到 300，是标准做法。
收束
DNS 排查的完整链条就四步：resolvectl status 确认本机问谁 → dig @公共解析器 +short 排除本机配置 → dig @权威NS 验证改动是否落库 → +trace 兜住剩余的委派链问题。四步走完，“域名不解析”这类问题没有活口。
下次网站打不开，先 dig 再重启。顺序对了，一半的”服务器故障”在 10 秒内就被排除了。
