引言：那个「永远是 DNS 的问题」的梗#

运维圈有一句流传已久的自嘲：It’s always DNS（永远是 DNS 的锅）。服务挂了、部署上线后访问不通、CDN 切换后一半用户报错——排查一圈下来，罪魁祸首往往是这个我们平时几乎不会注意的系统。

DNS 之所以频繁「背锅」，是因为它是整个互联网访问链路的第一环，却又是缓存层级最多、状态最难观测的一环。这篇文章从解析链路讲起，把 DNS 的工作机制拆开，再落到具体的排查手法上。

一、DNS 到底是什么#

DNS（Domain Name System）本质上是一个全球分布式的键值数据库，把人类可读的域名映射成机器可路由的 IP 地址。它的设计有两个关键点：

1. 树状层级结构

域名从右往左读，是一棵倒置的树：

1
                    . (根域)
2
                 /     |     \
3
             com      org     cn
4
            /   \             |
5
       google  example      com
6
                  |           |
7
                www         baidu

www.example.com. 末尾那个点代表根域，平时被浏览器省略了。每一层由不同的机构管理：根域由 13 组根服务器（a.root-servers.net 到 m.root-servers.net）负责，.com 由 Verisign 管理，example.com 则由你自己的域名服务商托管。

2. 授权与委派

上一级并不存储下一级的全部记录，只存储「谁负责下一级」的指针（NS 记录）。这种委派机制让 DNS 能承载数十亿域名而不需要任何单点保存全量数据。

二、一次完整解析的链路#

假设你在浏览器输入 www.example.com，背后发生的事情按顺序是：

1
浏览器缓存 → 操作系统缓存(hosts + stub resolver)
2
    → 递归解析器(通常是运营商 DNS 或 8.8.8.8)
3
        → 根服务器：「.com 归这些 NS 管」
4
        → .com TLD 服务器：「example.com 归这些 NS 管」
5
        → example.com 权威服务器：「www 的 A 记录是 93.184.216.34」
6
    ← 逐层返回并缓存

这里有个容易混淆的概念：递归查询 vs 迭代查询。

• 你的设备向递归解析器发的是递归查询：「你负责给我最终答案，别让我自己找」。
• 递归解析器向各级权威服务器发的是迭代查询：「你知道就给答案，不知道就告诉我该问谁」。

真正干活跑遍全球的是递归解析器，你的设备只发了一个包。

三、常见记录类型速查#

四、TTL 与缓存：故障的高发区#

每条 DNS 记录都带一个 TTL（Time To Live），单位是秒，告诉下游「这个答案你可以缓存多久」。TTL 是 DNS 里最反直觉的部分——你改了记录，不代表用户立刻能看到。

一次 DNS 变更真正全网生效，需要等待链路上所有缓存层过期：

1
权威服务器(立即生效)
2
  → 递归解析器缓存(等 TTL)
3
    → 操作系统缓存(等 TTL)
4
      → 浏览器缓存(Chrome 默认约 60s，且不总是尊重 TTL)

所以正确的切换姿势是：提前 24~48 小时把 TTL 降到 60 秒，切换完成、观察稳定后再调回 3600。很多人在切换当天才想起改 TTL，那时旧的高 TTL 已经被缓存出去了，为时已晚。

还有一个坑是 negative caching（负缓存）：当解析失败返回 NXDOMAIN 时，这个「不存在」的结论同样会被缓存，时长由 SOA 记录的最后一个字段决定。这就是为什么「记录明明加上了，还是解析不到」——你在添加记录之前的那次失败查询，把 NXDOMAIN 缓存住了。

五、实战排查：dig 才是正确工具#

ping 只能告诉你通不通，nslookup 输出信息太少。排查 DNS 请直接用 dig。

基础查询：

1
# 查 A 记录
2
dig example.com A +short
3
# 93.184.216.34
4

5
# 完整输出，看 TTL 和响应来源
6
dig example.com A

关注输出中的三个关键点：

1
;; ANSWER SECTION:
2
example.com.    3600    IN    A    93.184.216.34
3
                 ↑ 剩余 TTL，每次查询递减说明命中了缓存
4

5
;; SERVER: 8.8.8.8#53      ← 实际应答的解析器
6
;; flags: qr rd ra;        ← ra 表示该服务器支持递归

绕过缓存，直接问权威服务器：

这是判断「是记录没配好，还是缓存没过期」的决定性手段：

1
# 1. 先找出权威服务器
2
dig example.com NS +short
3
# ns1.example.com.
4

5
# 2. 直接向它查询，绕开所有递归缓存
6
dig @ns1.example.com example.com A

如果权威服务器返回了正确结果，而 8.8.8.8 没有，那就是纯粹的缓存问题，等 TTL 即可。

逐级追踪完整委派链：

1
dig example.com +trace

这条命令会从根服务器开始，把每一级委派完整打印出来。当你怀疑 NS 记录配错、或者域名在注册商和 DNS 服务商之间「脱节」时，+trace 能立刻定位断在哪一层。

对比不同解析器（排查 DNS 污染 / 分区解析）：

1
for s in 8.8.8.8 1.1.1.1 223.5.5.5 114.114.114.114; do
2
  echo -n "$s => "
3
  dig @$s example.com A +short | head -1
4
done

六、四类经典故障对照表#

另外一个高频陷阱：根域（apex domain）不能配 CNAME。RFC 1034 规定 CNAME 记录不能与其他记录共存，而根域必须有 SOA 和 NS 记录，因此 example.com 本身无法配 CNAME，只有 www.example.com 可以。想让根域指向 CDN，需要用云厂商提供的 ALIAS / ANAME / CNAME flattening 这类非标准扩展。

七、写一个诊断脚本#

Node.js 的 dns 模块内置了两套 API：dns.lookup() 走操作系统解析（会读 hosts 文件），dns.resolve*() 直接发 DNS 查询。排查时必须用后者，否则你测的是系统缓存而不是 DNS。

1
import { Resolver } from 'node:dns/promises';
2

3
const RESOLVERS = {
4
  Google: '8.8.8.8',
5
  Cloudflare: '1.1.1.1',
6
  AliDNS: '223.5.5.5',
7
};
8

9
async function diagnose(domain) {
10
  console.log(`\n=== 诊断 ${domain} ===\n`);
11

12
  // 1. 查权威服务器
13
  const base = new Resolver();
14
  base.setServers(['8.8.8.8']);
15
  let authNS = [];
16
  try {
17
    authNS = await base.resolveNs(domain);
18
    console.log(`权威服务器: ${authNS.join(', ')}`);
19
  } catch (err) {
20
    console.log(`NS 查询失败: ${err.code}`);
21
  }
22

23
  // 2. 多解析器交叉对比，检测结果是否一致
24
  const results = new Map();
25
  for (const [name, ip] of Object.entries(RESOLVERS)) {
26
    const r = new Resolver({ timeout: 3000, tries: 2 });
27
    r.setServers([ip]);
28
    try {
29
      const addrs = await r.resolve4(domain, { ttl: true });
30
      const line = addrs.map((a) => `${a.address}(ttl=${a.ttl}s)`).join(' ');
31
      results.set(name, addrs.map((a) => a.address).sort().join(','));
32
      console.log(`${name.padEnd(11)} ✓ ${line}`);
33
    } catch (err) {
34
      // ENOTFOUND=NXDOMAIN, ESERVFAIL=服务端故障, ETIMEOUT=不可达
35
      console.log(`${name.padEnd(11)} ✗ ${err.code}`);
36
    }
37
  }
38

39
  // 3. 判断是否存在解析不一致
40
  const unique = new Set(results.values());
41
  if (unique.size > 1) {
42
    console.log('\n⚠️  各解析器返回结果不一致，可能是缓存未同步或分区解析');
43
  } else if (unique.size === 1) {
44
    console.log('\n✓ 各解析器结果一致');
45
  }
46
}
47

48
await diagnose(process.argv[2] ?? 'example.com');

运行 node dns-check.mjs example.com，就能一次性看到 TTL 剩余量和跨解析器的一致性——这两个信息覆盖了日常八成的 DNS 故障判断。

八、加密 DNS：DoH 与 DoT#

传统 DNS 查询走 UDP 53 端口，完全明文。这意味着链路上任何一跳都能看到你访问了哪些域名，甚至伪造响应（这正是 DNS 劫持与污染的技术基础）。

两种主流加密方案：

• DoT（DNS over TLS，RFC 7858）：走 853 端口，在 TLS 隧道里跑标准 DNS 协议。端口独立，便于网络管理员统一管控。
• DoH（DNS over HTTPS，RFC 8484）：把查询封装成 HTTPS 请求走 443 端口，与普通网页流量混在一起，难以被识别和阻断。

DoH 可以直接用 curl 验证：

1
curl -s -H 'accept: application/dns-json' \
2
  'https://cloudflare-dns.com/dns-query?name=example.com&type=A' | jq

需要注意的是，加密 DNS 解决的是传输链路的隐私与完整性，不解决解析器本身是否可信——你的查询记录依然完整暴露给了那家 DoH 服务商。这是一个信任转移，而不是信任消除。

结语#

DNS 的复杂性不在协议本身——它的报文格式几十年没大改过——而在于那条横跨浏览器、操作系统、递归解析器、权威服务器的多级缓存链路。排查时记住一条主线就够了：

从权威服务器往回查。 先用 dig @权威NS 确认源头数据对不对，再逐层往下判断是哪一级缓存拖住了。

搞清楚这一点，「It’s always DNS」就从玄学变成了三条命令能定位的日常问题。

参考来源#

• RFC 1034 - Domain Names: Concepts and Facilities
• RFC 1035 - Domain Names: Implementation and Specification
• RFC 2308 - Negative Caching of DNS Queries
• RFC 8484 - DNS Queries over HTTPS (DoH)
• Cloudflare Learning - What is DNS?
• Node.js DNS 模块官方文档