DNS 看起来只是「名字变 IP」，实际是一条多层协作流水线。研讨排障时，我习惯把它拆成三个角色：

  • Stub Resolver：操作系统/浏览器侧的轻量查询端；
  • Recursive Resolver：替客户端跑完查询过程并缓存结果；
  • Authoritative Server：对某区域数据有最终发言权的服务器。

一次典型解析

访问 www.example.com 时，若缓存未命中，递归服务器大致会：问根 → 获知 .com 的 TLD → 再问 TLD 获知 example.com 权威 → 最后问权威拿到 A/AAAA。中间任意一跳延迟或错误，都会表现为「网站打不开」，但根因完全不同。

常见故障分层

  1. 本地 Stub：错误的 DNS 服务器配置、公司代理劫持、Hosts 残留。
  2. 递归层：缓存了旧答案（TTL 未到期）、UDP 被防火墙限制、DoH/DoT 策略不一致。
  3. 权威层：记录漏改、NS 不一致、DNSSEC 验证失败导致 SERVFAIL。

实用排查顺序

# 看系统解析到什么
dig www.example.com +short

# 指定公共递归，排除本机
dig @1.1.1.1 www.example.com

# 追问权威与链路
dig www.example.com +trace

若公共递归正常而本机异常，问题多半在 Stub 或本地中间盒；若权威 trace 中某级异常，就沿着 NS 委托往下修。

研记要点：DNS 问题优先「分层定位」，不要一上来改业务代码或重装客户端。