诊断工具

这一课你将能做到

1. 熟练使用 dig 的十余个常用参数（+short、+trace、@server、-t、-x、+norecurse、+multi 等），并完整读懂一份报文
2. 用 nslookup、host 完成等价查询，在 Windows 与 Linux 双环境都不卡手
3. 用 curl --resolve、curl --connect-to 绕过 DNS，把「解析问题」与「站点问题」彻底分开验证

为什么要学

工具是 DNS 排障的手和眼。前 4 课我们反复用 dig，但每次只用一两个参数；真实工单要求你在 5 分钟内回答：「权威记录到底是什么」「是递归缓存问题还是传播问题」「新机器不配域名能不能先验证 HTTPS」「给工单该贴哪段输出」。

同一批信息，dig/nslookup/host 三种工具各有展示习惯：dig 最全、适合贴报告；nslookup Windows 自带、适合应急；host 输出最简洁、适合管道脚本。再配合 curl 的两个绕解析参数，你就能对任意站点做「分层解剖」。本课把这些工具一次性练透。

先建立图像

排障工具箱分层：

  第一层：看「名字→IP」
    dig / nslookup / host
       │
       ├─ +short ........ 只要答案（脚本用）
       ├─ +trace ........ 自己做迭代，看全链路
       ├─ -x ............ 反向解析（PTR）
       ├─ @server ....... 指定问谁
       └─ +norecurse .... 禁止递归，看对方真实持有数据

  第二层：绕过 DNS 看站点
    curl --resolve 主机:端口:IP ...... 强制把名字指到指定 IP
    curl --connect-to 主机:端口:目标.. 连到指定地址但 SNI/Host 不变

  第三层：看本机解析环境
    Windows: ipconfig /all        看 DNS 服务器与后缀
    Linux:   cat /etc/resolv.conf、resolvectl status

工具	平台	输出风格	最适合的场景
dig	Linux/macOS/WSL	完整分区报文	精查、贴工单、自动化
nslookup	全平台自带	分段、可交互	Windows 应急、没权限装软件
host	Linux/macOS	一行一条、简洁	快速确认、shell 管道
curl	全平台	HTTP 层视角	绕过解析验证站点与证书

跟着做

步骤 1：精读一份完整 dig 报文

dig www.coderoadmap.cn A

示例输出（逐段注释）：

; <<>> DiG 9.18.1-1ubuntu1 <<>> www.coderoadmap.cn A
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43210
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
│                 │              │
│                 │              └─ ra: 递归服务器支持递归
│                 └─ rd: 请求里要求递归
└─ status: NOERROR（正常）；NXDOMAIN=不存在；SERVFAIL=权威侧故障

;; QUESTION SECTION:        ← 你问了什么
;www.coderoadmap.cn.        IN A

;; ANSWER SECTION:          ← 答案（核心）
www.coderoadmap.cn. 287 IN A  104.21.5.10
www.coderoadmap.cn. 287 IN A  172.67.133.10

;; Query time: 24 msec      ← 本次耗时
;; SERVER: 127.0.0.53#53(127.0.0.53)   ← 实际应答的递归器
;; WHEN: Wed Oct 07 10:00:00 CST 2026
;; MSG SIZE rcvd: 76

读报四步：先看 status，再看 ANSWER 数量，再看 TTL，最后看 SERVER。这四步覆盖九成判断。

步骤 2：dig 常用参数组合速练

dig +short www.coderoadmap.cn                    # 只要答案
dig www.coderoadmap.cn AAAA +short               # 指定类型简查
dig -x 203.0.113.10 +short                      # 反向查 PTR
dig @8.8.8.8 www.coderoadmap.cn A +short        # 指定递归器
dig @ns1.cloudflare.com www.coderoadmap.cn A +norecurse  # 问权威、不递归
dig +trace www.coderoadmap.cn A                 # 全链路迭代
dig +multi xxx._domainkey.coderoadmap.cn TXT     # 长 TXT 美化换行
dig coderoadmap.cn ANY +noall +answer           # 一次拿多类（多数权威已禁用ANY，RFC8482）
dig +bufsize=4096 www.coderoadmap.cn DNSKEY     # EDNS0 大包、DNSSEC

组合记忆：「问谁（@）+ 问什么（类型/-x）+ 怎么答（+short/+trace/+norecurse）」。

步骤 3：nslookup 两种模式

# 一行模式
nslookup www.coderoadmap.cn
nslookup -type=MX coderoadmap.cn 8.8.8.8

# 交互模式：连续改类型，少敲重复命令
nslookup
> server 8.8.8.8          # 切换默认服务器
> set type=any
> coderoadmap.cn
> set debug               # 打开完整报文（排查时才用，输出很长）
> exit

注意 nslookup 的两个坑：默认会同时做 A/AAAA 查询导致输出重复；非权威答案会标 Non-authoritative answer（正常，说明来自缓存，不是故障）。

步骤 4：host 的简洁输出

host www.coderoadmap.cn
host -t MX coderoadmap.cn
host 203.0.113.10          # 反向直接写 IP
host -a coderoadmap.cn     # 等价 ANY，带 TTL

示例输出：

www.coderoadmap.cn has address 104.21.5.10
www.coderoadmap.cn has address 172.67.133.10
www.coderoadmap.cn has IPv6 address 2606:4700::6810:50a
coderoadmap.cn mail is handled by 10 mail.coderoadmap.cn.

步骤 5：curl --resolve 绕过 DNS 做验证

# 强制把 www.coderoadmap.cn:443 解析到 203.0.113.20（新机器），SNI/证书校验照常
curl -I --resolve www.coderoadmap.cn:443:203.0.113.20 https://www.coderoadmap.cn/

# 迁移时新旧 IP 对比（两个命令都跑，看谁返回 200/正确证书）
curl -I --resolve www.coderoadmap.cn:443:203.0.113.10 https://www.coderoadmap.cn/
curl -I --resolve www.coderoadmap.cn:443:203.0.113.20 https://www.coderoadmap.cn/

成功输出示例：

HTTP/2 200
server: nginx
content-type: text/html; charset=utf-8

若证书不匹配会看到 SSL: no alternative certificate subject name matches——这恰恰证明 TLS 校验没被绕过，验证结果可信。

步骤 6：--connect-to 与本机解析环境核查

# 连接目标改写：连 203.0.113.20，但 SNI/Host 头仍写 www.coderoadmap.cn
curl -I --connect-to www.coderoadmap.cn:443:203.0.113.20:443 https://www.coderoadmap.cn/

# 查看本机 DNS 配置
ipconfig /all | findstr /i "DNS"        # Windows
resolvectl status                        # Linux（systemd）
cat /etc/resolv.conf                     # Linux（传统）
scutil --dns | head -30                  # macOS

把「本机用的递归器」抄下来：排障时先确认你问的是谁，再和公共解析器对比，避免拿单一数据源下结论。

步骤 7：固化一个「DNS 工单信息收集」命令块

{
  echo "=== 时间 ==="; date
  echo "=== 默认解析器 ==="; dig www.coderoadmap.cn A | grep -E "SERVER|status"
  echo "=== 谷歌视图 ==="; dig @8.8.8.8 www.coderoadmap.cn A +short
  echo "=== 阿里视图 ==="; dig @223.5.5.5 www.coderoadmap.cn A +short
  echo "=== 链路 ==="; dig +trace www.coderoadmap.cn A | grep -E "NS\s|IN\s+A\s"
} > dns-report.txt

贴工单时一份 dns-report.txt 胜过十句口头描述，对方一眼能定位层级。

讲清楚要点

1. dig 的 status 是第一判断点：NOERROR 正常；NXDOMAIN 名字不存在；SERVFAIL 权威无响应/配置损坏；REFUSED 权威拒绝回答该名字。
2. +short 丢失上下文：脚本里好用，排障时必须配合完整输出，否则你看不到是缓存命中还是权威应答。
3. 问权威用 +norecurse：你要看权威「自己持有」的记录，而不是让它再递归一圈把缓存答案还给你。
4. ANY 类型正在退役：RFC 8482 允许权威对 ANY 返回最小答案，Cloudflare 等已执行；想看全记录要逐类型查。
5. --resolve 只改解析这一步：TCP/TLS/HTTP 全部照常，证书主机名校验照常——这是它能用来验证新机器的原因。
6. nslookup 是唯二 Windows 原生命令（另一个是 ping），没管理员权限、不让装软件时它是救命工具。
7. 时间戳要留：DNS 问题随缓存时间变化，工单输出不带时间等于没法复盘。

你可能会懵的地方

• dig、nslookup、host 答案会不一样吗？ 问同一台服务器、同一类型时核心答案一致；差异在 TTL（查询时刻不同）和附加信息。若连 IP 都不同，先检查是否默认递归器不同。

• --resolve 和改 hosts 有什么区别？ 功能相似但作用域不同：--resolve 只对这一条 curl 命令生效、不留痕迹、可指定端口；hosts 是系统级覆盖、影响所有程序且容易忘记删。排障优先用 --resolve。

• 为什么 dig 报 WARNING: recursion requested but not available？ 你问的是一台权威服务器（默认请求了递归），而权威关闭了递归服务。加 +norecurse 即可消除，也符合「问权威就该直接要数据」的姿势。

• dig ANY 返回很少，是不是记录丢了？ 不是。RFC 8482 后权威可对 ANY 只返回一条 SOA 或少量记录。按实际需要的类型逐个查。

• Query time 包含 TCP 或 TLS 时间吗？ 不包含，它只是 DNS 报文一问一答的耗时。站点整体耗时要用 curl 的 -w 变量分段看。

错法对照

错法	后果	正确做法
只贴 +short 结果提工单	缺少状态码、TTL、服务器，无法定位	贴完整 dig，或用步骤 7 的收集块
在权威查询时不加 +norecurse	拿到递归缓存答案，误判权威数据	查权威一律 +norecurse
--resolve 验证失败就认为站点坏	可能是新机器防火墙/证书没就绪	先确认 443 可达、证书 SAN 含该域名
用 ping 代替 DNS 查询	ping 不显示 TTL，也不查 MX/TXT	用 dig/host 按类型查
忽略 dig 输出的 SERVER 行	不知道自己问的是内网还是公网递归	先 SERVER，再对比公共解析器

卡点急救

1. dig 超时（no servers could be reached）：先测 UDP 53 连通性（换 @8.8.8.8）；公司网多为 53 端口被限，改用允许的递归器。Linux 上还可检查 /etc/resolv.conf 是否被 NetworkManager 清空。
2. nslookup 正常但应用解析失败：应用可能不走系统 NSS（如 Java 老版本不读 mDNS/搜索域）。检查应用的 DNS 配置与 search 后缀，用 getent hosts 名字（Linux）模拟系统解析全流程。
3. --resolve 拿到旧证书：目标 IP 上的 Nginx 没配该域名的 server 块或证书未更新，不是 DNS 问题。直接登录目标机查 Nginx 配置和证书文件。

面试常问

• 线上说域名有问题，你用什么命令、按什么顺序查？ 先 dig 域名 看 status 和 SERVER；再 dig @8.8.8.8、dig @223.5.5.5 对齐公网视图；需要看链路就 dig +trace；DNS 正常后用 curl -I 看 HTTP、用 curl --resolve 绕过解析直连源站/新机验证。即「先解析、再站点、再绕解析」的分层顺序。

• dig +trace 和直接 dig 的区别？排查什么用哪个？ 普通 dig 只向递归器发一次递归查询，看到的是最终答案与递归器耗时；+trace 让本机自己从根开始做迭代，逐跳展示根、TLD、权威的引荐。怀疑传播/委派/权威配置问题用 +trace，只想确认答案和缓存状态用普通 dig。

• 如何在不修改 DNS 的情况下验证新服务器上的站点？ 用 curl --resolve www.example.com:443:新IP https://www.example.com/，它把本次查询强制指向新 IP，但 SNI、Host、证书主机名校验全部保持真实域名，因此能同时验证站点内容和证书是否就绪。改 hosts 也能做到但影响全局、易残留。

自测三问

1. dig 报文中你应该按什么顺序读哪四个信息？status=SERVFAIL 首先怀疑谁？
2. 要验证「新机器 Nginx 和证书已就绪但还没切流量」，给出完整命令。
3. dig @ns1.cloudflare.com 域名 不加 +norecurse 有什么隐患？

小结一句话

dig 看全报文、nslookup 应急、host 做脚本、curl --resolve 绕过解析验站点——四把刀按「解析→站点→绕解析」的顺序解剖问题。

延伸

• BIND 工具手册：dig（官方 HTML 版）
• RFC 8482：ANY 查询的处理
• curl 官方文档：--resolve 与 --connect-to
• Google 公共 DNS 文档
• 下一课预告：本站域名配置——把工具用到 coderoadmap.cn 的 Nginx、Cloudflare、云 DNS 真实配置上。