CodeRoad Map 程序员的学习成长路线图。内容免费开放，登录后可同步路线图与课时进度。
由 程序员柏风 独立维护 · 关于作者
学习 更多
诊断工具 dig、nslookup、在线 DNS 检查。
诊断工具
这一课你将能做到
熟练使用 dig 的十余个常用参数（+short、+trace、@server、-t、-x、+norecurse、+multi 等），并完整读懂一份报文
用 nslookup、host 完成等价查询，在 Windows 与 Linux 双环境都不卡手
用 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 胜过十句口头描述，对方一眼能定位层级。
讲清楚要点
dig 的 status 是第一判断点 ：NOERROR 正常；NXDOMAIN 名字不存在；SERVFAIL 权威无响应/配置损坏；REFUSED 权威拒绝回答该名字。+short 丢失上下文 ：脚本里好用，排障时必须配合完整输出，否则你看不到是缓存命中还是权威应答。问权威用 +norecurse ：你要看权威「自己持有」的记录，而不是让它再递归一圈把缓存答案还给你。ANY 类型正在退役 ：RFC 8482 允许权威对 ANY 返回最小答案，Cloudflare 等已执行；想看全记录要逐类型查。--resolve 只改解析这一步 ：TCP/TLS/HTTP 全部照常，证书主机名校验照常——这是它能用来验证新机器的原因。nslookup 是唯二 Windows 原生命令 （另一个是 ping），没管理员权限、不让装软件时它是救命工具。时间戳要留 ：DNS 问题随缓存时间变化，工单输出不带时间等于没法复盘。
你可能会懵的地方
dig、nslookup、host 答案会不一样吗？
问同一台服务器、同一类型时核心答案一致；差异在 TTL（查询时刻不同）和附加信息。若连 IP 都不同，先检查是否默认递归器不同。
--resolve 和改 hosts 有什么区别？
功能相似但作用域不同：--resolve 只对这一条 curl 命令生效、不留痕迹、可指定端口；hosts 是系统级覆盖、影响所有程序且容易忘记删。排障优先用 --resolve。
为什么 dig 报 WARNING: recursion requested but not available？
你问的是一台权威服务器（默认请求了递归），而权威关闭了递归服务。加 +norecurse 即可消除，也符合「问权威就该直接要数据」的姿势。
dig ANY 返回很少，是不是记录丢了？
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，再对比公共解析器
卡点急救
dig 超时（no servers could be reached） ：先测 UDP 53 连通性（换 @8.8.8.8）；公司网多为 53 端口被限，改用允许的递归器。Linux 上还可检查 /etc/resolv.conf 是否被 NetworkManager 清空。nslookup 正常但应用解析失败 ：应用可能不走系统 NSS（如 Java 老版本不读 mDNS/搜索域）。检查应用的 DNS 配置与 search 后缀，用 getent hosts 名字（Linux）模拟系统解析全流程。--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 也能做到但影响全局、易残留。
自测三问
dig 报文中你应该按什么顺序读哪四个信息？status=SERVFAIL 首先怀疑谁？
要验证「新机器 Nginx 和证书已就绪但还没切流量」，给出完整命令。
dig @ns1.cloudflare.com 域名 不加 +norecurse 有什么隐患？
小结一句话 dig 看全报文、nslookup 应急、host 做脚本、curl --resolve 绕过解析验站点——四把刀按「解析→站点→绕解析」的顺序解剖问题。
延伸