第 19 章 DNS、CDN 与网络排障

前几章讲协议"应该怎么工作"，本章讲它"实际上哪里坏了"。DNS 是唯一能把整条链路拖慢数秒的旁路系统。

学习目标

读完本章，你应当能够：

1. 画出 DNS 递归查询与迭代查询的两条路径，说清每一层的缓存位置、TTL 归属与负缓存作用范围；
2. 判断一组 DNS 记录能否合法共存（CNAME 与 MX、CNAME 与根域名），解释"切换 IP 前为什么要调小 TTL"的量化依据；
3. 用 dig +trace、+short、@server、+tcp、+noedns 定位解析异常，说明 nslookup 在排障中的信息缺失；
4. 对一次"网站访问慢"给出分层命令序列，按 curl -w 的 time_* 差值定位到 DNS、建连、TLS、TTFB、传输中的哪一段；
5. 写出 tcpdump 的主机/端口/标志位过滤表达式，并判断握手是否完成、有无重传、RST、零窗口；
6. 辨析 ping/traceroute/mtr/telnet/nc/ss 各自的能力边界，在 ICMP 被禁时给出替代手段。

前置知识检查

19.1 DNS 的完整查询流程：递归与迭代是两条路径

面试里"讲一下 DNS 解析过程"最常见的错误回答，是把浏览器缓存、根服务器、权威服务器串成一条线性链。真实的 DNS 是两段拼接：客户端到本地 DNS 服务器（local DNS server，也常叫递归解析器 recursive resolver）是递归，本地 DNS 服务器到根/TLD/权威是迭代。两段的责任划分、缓存归属、故障表现都不同。

19.1.1 两段路径的全图

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20

 客户端（浏览器/应用）                   本地 DNS 服务器          根/TLD/权威
 ┌────────────────────────┐            ┌──────────────┐      ┌──────────────┐
 │ ① 浏览器 DNS 缓存       │            │              │      │              │
 │ ② OS 解析器             │            │              │      │              │
 │    nsswitch.conf:      │            │              │      │              │
 │    hosts: files dns    │            │              │      │              │
 │    → /etc/hosts 命中即止│            │              │      │              │
 │ ③ OS DNS 缓存           │            │              │      │              │
 │ ④ 读 /etc/resolv.conf   │  递归查询   │              │      │              │
 │    nameserver 10.0.0.53─┼───────────▶│              │      │              │
 └────────────────────────┘   (RD=1)    │ ⑤ 查自身缓存  │      │              │
                                        │   未命中 ↓    │      │              │
                                        │ ⑥ 问根 ───────┼─────▶│ .  返回 TLD NS│
                                        │ ⑦ 问 TLD ─────┼─────▶│ com. 返回权威 │
                                        │ ⑧ 问权威 ─────┼─────▶│ 返回 A 记录   │
                                        │ ⑨ 按 TTL 缓存 │      │              │
                                        └───────┬───────┘      └──────────────┘
                                                │ 递归应答 (RA=1)
                                                ▼
                                         客户端拿到 A 记录

三个容易答错的点。第一，/etc/hosts 优先于 DNS 不是"永远优先"，而由 nsswitch.conf 里 hosts: 一行的顺序决定：写成 hosts: dns files 就反过来，写成 hosts: files myhostname dns 是多数发行版默认。面试问"改了 hosts 不生效"，第一个要看这一行，第二个是应用自己缓存了（JVM 的 networkaddress.cache.ttl、Go 的 GODEBUG=netdns）。第二，本地 DNS 服务器自己也会缓存，所以第 ⑥～⑧ 步通常根本不发生——这也是"改了权威记录但不生效"的第一大原因，不是你的 TTL 没到，是别人的缓存还没到期。第三，递归与迭代的分界在本地 DNS 服务器：客户端发的是 RD=1（recursion desired）请求，只关心最终答案；本地 DNS 发的是 RD=0 请求，每问一台就要自己接着问下一台。根服务器从不做递归，以避免被放大攻击利用。

19.1.2 TTL 与负缓存：为什么"删除记录"不一定立刻失效

负缓存（negative caching） 是面试的高区分度点：查询不存在的名字时，权威返回 NXDOMAIN 并附上 SOA 记录，本地 DNS 按 SOA 的 minimum 字段（RFC 2308 口径）把这个"不存在"缓存一段时间。后果是：刚上线的新域名若已被解析器查过一次，必须等负缓存过期才能解析成功，表现为"我这边能通、别人那边 NXDOMAIN"。因此上线顺序永远是先建记录再切流量。同理，TTL 设为 0 也不等于"不缓存"：多数解析器有秒级下限（RFC 1035 里 0 只表示"不要复用"），客户端缓存更不受你的 TTL 完全支配。

19.1.3 切换 IP 时必须提前调小 TTL：一个算例

TTL 决定缓存能活多久，所以变更生效的最坏时间 ≈ 当前 TTL。切换 IP 的标准动作是两阶段：提前至少一个旧 TTL 的时长把 TTL 从 86400（1 天）改成 60，等旧的长 TTL 缓存全部过期；然后改记录值（A → 新 IP）并等 60 s 让新值扩散；稳定后再把 TTL 调回 86400，降低解析器压力与放大攻击面。

算例：TTL = 86400 时直接改 IP，最坏情况下一部分客户端 24 小时内仍在访问旧 IP，而你很可能已经下线了旧机器——这就是"灰度切换变成部分用户 404"。把 TTL 降到 60 s 后，最坏生效时间从 86400 s 压到 60 s，代价是解析器查询量上升 1440 倍，所以必须在切换完成后调回去。

19.2 DNS 报文结构与记录类型

19.2.1 报文的五个区段

DNS 报文固定 12 字节头（Header），之后是四个可变长区段。面试常考标志位与"哪些区段会变长”：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            ID (16 bit，把应答与查询配对)                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|QR| Opcode  |AA|TC|RD|RA|   Z    |         RCODE (4 bit)      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     QDCOUNT（问题数，通常 1）  |     ANCOUNT（回答数）          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     NSCOUNT（权威数）          |     ARCOUNT（附加数，EDNS0 在此）|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 区段顺序：Question → Answer → Authority → Additional（后三段可为空）
 域名压缩：重复出现的域名用指针 0xC0xx 指回报文前面，故域名不可任意长

TC 与 EDNS0 的关系是高频追问：传统 DNS 的 UDP 应答上限 512 字节（RFC 1035），超了就置 TC=1；EDNS0（RFC 6891）通过一条**伪记录（OPT RR）**把 UDP 承载能力协商到更大（常见 1232～4096 字节），并同时承载 DNSSEC 的 DO 位。所以”dig 看到没截断"，往往是因为对方支持 EDNS0，而不是记录真的小。

19.2.2 记录类型与"为什么有些记录不能共存"

为什么 CNAME 不能与 MX 共存、不能用在根域名？ 根因是同一条记录集（RRset）里"名字到值"的映射必须唯一。DNS 是一条"问名字、拿值"的查询协议；当某个名字被声明为 CNAME 时，它只剩下别名这一种语义，RFC 1034 要求该名字下不得再存在其他类型的数据，否则解析器拿到 CNAME 后去追新名字，其他记录就成了永远取不到的孤儿。所以 example.com CNAME target.com 与 example.com MX mail.example.com 冲突。根域名（zone apex）不能是 CNAME，因为根域名必须承载 NS 与 SOA（区的委托点与起始授权）——一个名字既然已有 NS/SOA，就不可能"只剩 CNAME 语义"。这就是"裸域不能直接 CNAME 到 CDN"的规范来源，工程上用 A/AAAA 指向 CDN 固定 IP，或用厂商的 ANAME/ALIAS 类记录（服务端合成 A 记录）绕过。同理 MX 指向 CNAME 也违反 RFC 2181 的澄清，它既多一次解析，又给邮件投递路径增加失败面。追踪一条 CNAME 链则意味着解析器逐跳再查，每跳都可能是一次额外迭代：

1
2
3

 www.example.com          CNAME  example.cdn-provider.net   ← 第 1 跳（权威返回）
 example.cdn-provider.net CNAME  edge-42.cdn.net            ← 第 2 跳
 edge-42.cdn.net          A      203.0.113.42               ← 第 3 跳才拿到 IP

每跳都增加延迟（未缓存即为一次 RTT），并放大失败面：任一跳的权威不可达，整个解析就是 SERVFAIL。这是 CDN 接入时建议减少 CNAME 层数的原因。

19.3 DNS 负载均衡与健康检查

分工上，DNS 做的是最外层、最粗粒度的一次分流：决定流量进哪个机房/集群入口。进入机房后，LVS 一类四层负载均衡按连接分流，Nginx/Envoy 再按请求分流与路由（并发模型见第 7 章 7.5 节）。三层职责不可互换：DNS 看不到连接，四层看不到 URL。

工程上的补救是分层兜底：DNS 负责机房级选择（TTL 设小一些，如 60 s），健康检查在 DNS 侧只做服务器级存活探测（失败则摘除该 A 记录），精细负载交给机房内的四层/七层，再由应用层做熔断降级（见第 35 章）。能把"DNS 只能做粗粒度、且摘除受 TTL 约束"说清楚，就已超过只背"轮询/加权/就近"的答法。

19.4 dig 的实战用法与 nslookup 的差距

dig（domain information groper）的价值在于它把报文的每个区段都打出来，包括 flags、QUERY/ANSWER/AUTHORITY 段与耗时。写排障命令时，注释要写"为什么这么查"：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20

# 只看答案：脚本里取 IP 用，避免再去解析 "ANSWER SECTION" 这类人类可读文本
dig +short www.example.com

# 走完整迭代链路：跳过本地解析器缓存，复现"根→TLD→权威"每一步，
# 用来区分"权威配置错了"与"本地解析器缓存了旧值"
dig +trace www.example.com

# 换服务器对比：定位本地 DNS 被污染、缓存旧值或配置了内网 view 的问题
dig @8.8.8.8 www.example.com
dig @ns1.example.com www.example.com +norecurse   # 直问权威，绕开所有缓存

# 验证 TC 截断与 EDNS0 协商：人为压到 512 字节逼出 TC=1，再看 TCP 重查是否成功
dig +bufsize=512 www.example.com
dig +tcp www.example.com
dig +noedns www.example.com      # 关闭 EDNS0，回退到 512 字节口径

# 反查与其他类型：PTR 缺失是邮件被拒收的高频原因
dig -x 203.0.113.42 +short
dig MX example.com +short
dig NS example.com +short        # 委托链要逐级向上问才能确认完整

dig 与 nslookup 的差距在于信息量：nslookup 是历史工具，输出经过"友好格式化"，默认不显示 flags、TTL、AUTHORITY 段，也不区分答案来自缓存还是权威，只能告诉你"解析出来了/没解析出来"。而排障需要的是为什么：

19.5 CDN：回源、命中率与调度

设 命中率 = 边缘直接响应的请求数 / 总请求数，其补数是回源率。回源请求要额外走一次"边缘 → 源站"的 RTT 并占用源站容量，所以回源率高的 CDN 等于给源站加了一层绕路。

1
2
3
4
5
6
7
8
9

                    ┌──────────── 边缘节点 ────────────┐
 用户 ─▶ DNS 调度 ─▶│ 缓存查询 → 命中 → 直接返回        │
        (或 Anycast)│        └ 未命中 ──┐               │
                    └───────────────────┼───────────────┘
                                        │ 回源（长连接 + 协议优化）
                                        ▼
                                   ┌─────────┐
                                   │  源站   │
                                   └─────────┘

命中率低的常见原因（面试高频，按出现频率排序）：一是 Cache-Control: no-cache/no-store/private 写错，边缘只能遵守源站指令；二是 URL 带随机参数（?t=时间戳、?rand=），每次都是新 key，等于关掉缓存；三是 Vary 维度过多（Vary: User-Agent 会把每个 UA 变成独立 key）或按 Cookie 全量区分；四是缓存键设计过细，把完整 query string 都算进 key 而业务只需要其中一两个参数；五是 TTL 过短，或源站 max-age 与边缘默认 TTL 冲突时取了小值；六是内容本来就动态（个性化接口），此时应走动态加速而不是硬缓存；七是发布后大规模刷新使缓存未回温，或请求合并没有开启导致同一文件被并发回源多次。

调度有两条路线。DNS 调度按解析器位置/运营商返回不同边缘 IP，粒度是客户端级且受 TTL 约束，切换与摘除都慢。Anycast 让同一 IP 在全球多节点公告，由 BGP 选最近入口，逐包生效、切换快，但路由抖动会影响长连接，且故障节点若未撤公告会持续收流量。两者常叠加：Anycast 做入口就近，DNS 做机房级容量调度。预热（preheat）与刷新（purge） 方向相反，面试常混：预热是主动把内容推到边缘（上线前拉一遍热门文件，避免上线瞬间全量回源打垮源站）；刷新是主动让边缘副本失效（发布新版本后强制回源）。刷新本质上牺牲命中率换一致性，因此发布后短时间内回源率会尖峰上升。至于动态加速，对不可缓存的请求，CDN 的价值从"缓存"转为"路径优化"：边缘与源站之间保持长连接复用（省掉每次 TCP + TLS 握手，见第 20 章 20.5 节）、使用更优的传输协议（如基于 UDP 的 QUIC，见第 15 章）、选更优的回源路径。这时该看回源时延与回源成功率，而不是命中率。

19.6 一次"网站访问慢"的分层排查法（主线案例）

排障第一原则是只改变一个变量。先用一条命令把一次 HTTP 请求切成若干时间段，再决定往哪一层深挖：

1
2
3
4
5
6
7

# 用 curl -w 把一次请求切成若干时间段；关掉连接复用，否则"第二次很快"
# 可能只是连接被复用了，反而掩盖了真正的握手问题
curl -w '\n time_namelookup:%{time_namelookup} time_connect:%{time_connect}\n
 time_appconnect:%{time_appconnect} time_pretransfer:%{time_pretransfer}\n
 time_starttransfer:%{time_starttransfer} time_redirect:%{time_redirect}\n
 time_total:%{time_total} http_code:%{http_code} remote_ip:%{remote_ip}\n
 num_connects:%{num_connects}\n' -o /dev/null -s https://www.example.com/

按图索骥的命令序列，不要一上来就抓包：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19

# 1 DNS 耗时与来源：换解析器对比，若公共解析器快则问题在内网解析器
dig +stats www.example.com | sed -n '/Query time/p;/SERVER/p'
dig @8.8.8.8 +short www.example.com

# 2 建连：nc -vz 只判断端口，telnet 能再看应用是否有应答；-w 防止排障命令自己挂住
nc -vz -w 3 www.example.com 443

# 3 多次采样看抖动：单次数字会被偶发抖动骗，P99 才是用户感知
for i in $(seq 1 10); do
  curl -o /dev/null -s -w '%{time_connect} %{time_appconnect} %{time_starttransfer} %{time_total}\n' \
       https://www.example.com/
done

# 4 对比不同源：换 IP 明显变快说明问题在特定入口而不在应用
curl -o /dev/null -s -w '%{time_starttransfer}\n' --resolve www.example.com:443:203.0.113.42 \
     https://www.example.com/

# 5 TTFB 异常时用 Host 头直连源站：直连快而走 CDN 慢，问题在 CDN 调度或回源路径
curl -o /dev/null -s -w '%{time_starttransfer}\n' -H 'Host: www.example.com' https://203.0.113.9/

19.6.1 curl -w 全部时间指标表

两个易踩的坑：这些 time_* 是相对命令起点的累计量而非分段量，必须做减法；time_appconnect 在非 TLS 请求（如 http://）下为 0，此时 time_pretransfer − time_connect 也接近 0，不要错误解读为"TLS 没耗时"。

19.7 抓包与协议分析：tcpdump 看什么

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

# 抓到文件而不是刷屏：抓包本身很贵，先落盘再离线分析（-w 不解析，减少排障动作的干扰）
tcpdump -i eth0 -s 0 -w /tmp/cap.pcap 'host 203.0.113.42 and tcp port 443'

# 只抓握手三包；只抓 SYN 且非 ACK 是判断"谁发起连接"的标准写法
tcpdump -i any -nn 'tcp port 443 and tcp[tcpflags] & (tcp-syn|tcp-ack) != 0'
tcpdump -i any -nn 'tcp[tcpflags] & tcp-syn != 0 and tcp[tcpflags] & tcp-ack == 0'

# 只看 RST/FIN：定位"谁先断的"；RST 往往比超时更能说明问题
tcpdump -i any -nn 'tcp[tcpflags] & (tcp-fin|tcp-rst) != 0'

# 按网段与方向过滤，避免把整个网卡的流量都拉进来
tcpdump -i any -nn 'net 10.0.0.0/8 and src host 10.0.1.5'

# 抓 ICMP：验证"ping 不通"到底是没回包还是被策略丢弃
tcpdump -i any -nn 'icmp'

tcp[tcpflags] 的位含义固定：tcp-fin=0x01、tcp-syn=0x02、tcp-rst=0x04、tcp-push=0x08、tcp-ack=0x10、tcp-urg=0x20。

Wireshark 里两个必用功能：Follow → TCP Stream 把一条连接的双向载荷按序拼成可读流，用来确认应用层到底发了什么（响应体是否被压缩、是否少了某个头部），注意它按连接过滤，多连接时要先在包列表里选中一条会话；Statistics → TCP Stream Graphs 的 Throughput 图给出实际速率随时间的变化，Time-Sequence (Stevens) 图给出序列号随时间上升的斜率——斜率变平就是停等或阻塞，锯齿状回落通常是丢包/重传导致窗口收缩。这两张图是把"抓包"变成"证据"的关键。

19.8 连通性工具的能力边界

面试高频辨析题几乎都围绕"某个工具说通/不通，能不能证明服务可用"。核心原则：每个工具只探测它自己那一层的语义，跨层推断就是错的。

ICMP 被禁时的替代手段（把"ping 不通"继续往下推）：一是 TCP 建连探测，nc -vz -w 3 host port，或 traceroute -T -p 443 host 用 TCP SYN 探路；二是应用层探测，curl -v --max-time 5 看是否拿到状态码，openssl s_client -connect host:443 -servername host 验证证书链；三是抓包确认责任方，tcpdump -nn 'icmp or tcp port 443' 区分"没发包"、“发了没回”、“回了被丢”；四是绕开本机网络栈干扰，mtr --tcp --port 443 host、多网卡用 -a/-I 指定源地址对比。

本章小结

自测题

Q1（推导）某域名的 A 记录 TTL 为 86400，你计划在明天 10:00 把服务从旧机房切到新机房。请给出完整的切换步骤与每一步的等待时长依据，并说明不做这一步会发生什么。

Q2（辨析）同事说："example.com 的裸域我直接加一条 CNAME 指向 CDN 就行了。“请指出这条方案的问题，并给出两种可落地的替代。

Q3（计算）一次 curl -w 输出为 time_namelookup=0.004、time_connect=0.052、time_appconnect=0.158、time_pretransfer=0.159、time_starttransfer=1.310、time_total=1.340（秒，--resolve 直连某机房，http_code=200，响应体 12 KB）。请把总耗时拆成五段，指出问题在哪一层，并给出下一步两个验证动作。

1
2
3
4
5
6

 DNS：      0.004 s                     → 4 ms，正常
 TCP 建连： 0.052 − 0.004 = 0.048 s     → 48 ms，偏高（同城 RTT 应为 0.1~0.5 ms 量级）
 TLS 握手： 0.158 − 0.052 = 0.106 s     → 106 ms，偏高
 应用等待： 0.159 − 0.158 ≈ 0.001 s     → 可忽略
 TTFB：     1.310 − 0.159 = 1.151 s     → 1.15 s，异常，占总耗时 86%
 内容传输： 1.340 − 1.310 = 0.030 s     → 12 KB / 30 ms ≈ 400 KB/s，偏低但不主导

Q4（判断）“我用 ping www.example.com 能通，说明 443 端口是开的、网站是好的。“请判断并说明，同时给出这个结论会漏掉的三类故障。

Q5（设计）线上告警"某地域用户访问慢”，该地域用户走 CDN。请设计一套从 DNS 到 CDN 到源站的排查顺序，写明每一步的命令、要看的指标，以及"看到什么就跳到下一步"的判据。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

 步骤 1  DNS 调度是否正确（先确认用户被调度到哪个机房）
         dig +short www.example.com          # 从该地域解析器视角取结果
         dig @<该地域解析器> www.example.com  # 对比是否被调度到远端节点
         判据：返回 IP 不属于就近节点 → 调度问题（查 geo 库 / EDNS Client Subnet）；否则进步骤 2
 步骤 2  CDN 边缘时延与命中率（区分"边缘慢"还是"回源慢"）
         curl -w '<time_* 模板>' -o /dev/null -s https://www.example.com/
         控制台看该节点命中率与回源率
         判据：命中率高而 TTFB 高 → 边缘或最后一公里；命中率骤降 → 进步骤 3
 步骤 3  回源路径（边缘到源站）
         边缘侧看回源时延与成功率；curl -H 'Host: ...' 直连源站对比
         判据：直连源站快而走 CDN 慢 → 回源路径差或长连接复用失效（每次回源重建 TCP+TLS）
 步骤 4  源站与应用（TTFB 归因）
         服务端看应用耗时、下游依赖、慢查询、线程池队列
         判据：源站自身 TTFB 正常 → 回到链路；源站 TTFB 高 → 应用问题，与网络无关
 步骤 5  路径质量与丢包（仅当步骤 1~4 都正常）
         mtr --tcp --port 443 -c 100 <边缘IP>     # 只看最后一跳的丢包与抖动
         tcpdump -i any -nn -w cap.pcap 'host <边缘IP> and tcp port 443'
         判据：末跳丢包/抖动持续 → 链路质量问题；否则两端抓包比对时间戳

面试高频问题与陷阱

延伸阅读

• RFC 1034《Domain names - concepts and facilities》：递归/迭代、委托与 zone 概念的第一手定义，19.1 节的路径划分以它为准。
• RFC 1035《Domain names - implementation and specification》：报文格式、512 字节 UDP 上限与各记录类型的字段定义。
• RFC 2181《Clarifications to the DNS Specification》：CNAME 与 MX/NS 目标关系的澄清，19.2.2 节的规范依据。
• RFC 2308《Negative Caching of DNS Queries》：负缓存机制与 SOA minimum 的口径。
• RFC 6891《Extension Mechanisms for DNS (EDNS(0))》：EDNS0 伪记录、UDP 承载能力协商与 DO 位。
• RFC 8499《DNS Terminology》：术语标准化，写文档与答辩时统一用词。
• man 1 dig、man 8 tcpdump、man 5 nsswitch.conf、man 5 resolv.conf：本章命令行为与配置文件优先级的权威口径。
• Wireshark 官方文档中 Statistics → TCP Stream Graphs 一节：吞吐图与 Stevens 时间序列图的读法。