解析流程：递归与迭代查询
基于 HTTP 现代标准 · 核于 2026-06
速查
- 一次完整解析有 8 步：浏览器缓存 → OS 缓存（stub resolver）→ 递归解析器 → 根服务器 → TLD 服务器 → 权威服务器 → 把 IP 逐级回传 → 浏览器拿到 IP。任一层命中缓存即可提前短路、跳过后续步骤。
- 递归解析器（DNS recursor）是「跑腿的图书管理员」：客户端只发一次请求，由它代为追问根 → TLD → 权威，直到拿到答案或报错返回。
- 四类 DNS 服务器分工：递归解析器（接客、代查、缓存）/ 根服务器（指向 TLD）/ TLD 服务器（指向权威）/ 权威服务器（终点，持有真实记录）。
- 递归 vs 迭代是「看立场」：客户端 → 递归解析器是递归查询（要么给答案要么报错）；递归解析器 → 各级服务器是迭代查询（每级只回「下一步去问谁」的引荐 referral）。
- 非递归查询（non-recursive）：被查方手里已有答案（自己是权威 / 缓存命中），无需再向上追问，直接返回。
- 根服务器全球仅 13 个「逻辑」编号（a~m），由 ICANN 监管；经 Anycast 部署成 600+ 物理实例就近响应。
- TLD 服务器按后缀分管：
.com/.net（通用 gTLD）与.cn/.uk（国家 ccTLD），由 IANA 管理。 - 权威服务器是「真相终点」：能用自有数据直接应答，无需再问别人；返回 A/AAAA 等记录（记录类型见下一页）。
- 传输层默认 UDP 53：单包查询/响应、无连接、开销小、速度快——绝大多数解析走这条路。
- 改用 TCP 53 的两种场景：① 响应过大（传统 >512 字节、或 EDNS 协商后仍超限、截断位 TC=1 触发重试）；② 区域传送（AXFR/IXFR） 主从同步必须用 TCP 保证可靠有序。
- DNS 报文五段结构：Header（含 ID / QR / 标志 / 各段计数）+ Question（问题）+ Answer（回答）+ Authority（授权 NS）+ Additional（附加，常含胶水记录）。
- 解析延迟直接拖慢首次访问：未命中缓存时多级往返叠加在 TCP/TLS 之前，是首屏的隐形成本——优化手段见前端 DNS 优化。
一、从输入域名到拿到 IP：完整解析全流程
当你在地址栏敲下 example.com，浏览器并不能直接用域名建立连接——它需要先把域名翻译成 IP 地址，这个翻译过程就是 DNS 解析（DNS resolution）。整个过程对用户透明，但底层要在多个缓存层与多级服务器之间穿梭。
按 Cloudflare 的归纳，一次未命中任何缓存的完整解析有 8 步（命中缓存会跳过其中若干步）：
浏览器缓存 ──→ OS 缓存(stub) ──→ 递归解析器 ──┬─→ 根服务器(.) ：去问 .com TLD
②未命中 ③未命中 (代为追问) │ ⑤引荐
├─→ TLD(.com) ：去问权威
⑧IP ◄──────────────────────── ◄───────────┤ ⑦引荐
逐级回传 └─→ 权威服务器 ：返回 A 记录(IP)
example.com 的 NS
─────────────────────────────────────────────────────────────────────────
⑨ 浏览器拿到 IP → 向该 IP 发 HTTP 请求 → ⑩ 服务器返回页面逐步拆解（对应上图编号）：
- 用户在浏览器输入
example.com，请求进入网络，最终交给一个 DNS 递归解析器。 - 解析器向 根服务器（
.） 发问。 - 根服务器回复负责该后缀的 TLD 服务器地址（这里是
.com）。 - 解析器转而向
.comTLD 服务器发问。 - TLD 服务器回复该域名的权威服务器地址。
- 解析器向
example.com的权威服务器发问。 - 权威服务器把
example.com的 IP（A 记录）返回给解析器。 - 解析器把最终 IP 回复给浏览器。
Once the 8 steps of the DNS lookup have returned the IP address for example.com, the browser is able to make the request for the web page. —— Cloudflare, What is DNS?
拿到 IP 后才轮到 HTTP：浏览器向该 IP 发起请求（⑨），服务器返回页面（⑩）。DNS 解析发生在 TCP 连接与 TLS 握手之前——它是整条链路最靠前、却最容易被忽视的一环。
真实世界里很少跑满 8 步
绝大多数请求会在某一层缓存命中而提前短路：浏览器缓存命中则一步到位；OS 缓存命中省去出网；递归解析器若缓存了权威服务器的 NS 记录，可直接问权威、跳过根与 TLD。缓存与 TTL 的细节见DNS 缓存与 TTL。
二、两道本地缓存：浏览器与操作系统
请求离开你的机器之前要先过两道本地缓存，原则都是「离浏览器越近、命中越早、省下的步骤越多」：
- 浏览器缓存（第一道）：现代浏览器默认缓存一段时间的 DNS 记录，发起解析时第一个被检查，命中则整个外部查询全省。Chrome 里可在
chrome://net-internals/#dns查看。 - OS 缓存 / stub resolver（第二道）：浏览器未命中后交给操作系统的解析模块——stub resolver（存根解析器）。它先查自身缓存，仍未命中才带上「递归标志（RD）」把查询发出本地网络，交给 ISP 或公共 DNS 的递归解析器。
The operating system level DNS resolver is the second and last local stop before a DNS query leaves your machine. —— Cloudflare, What is DNS?
这正是「客户端发递归查询」的起点：stub resolver 的潜台词是「我不想自己一级级追问，你帮我把最终答案查回来」。
三、四类服务器各司其职
一次无缓存的解析，靠四类 DNS 服务器协作完成。Cloudflare 用「图书馆」作了精妙类比：
| 服务器类型 | 图书馆类比 | 职责 | 管理方 |
|---|---|---|---|
| 递归解析器 recursor | 帮你找书的图书管理员 | 接收客户端查询，代为逐级追问，缓存结果后回传 | ISP / 公共 DNS（如 1.1.1.1） |
| 根服务器 root | 指向各书架的总索引 | 按后缀把解析器引荐给对应 TLD 服务器 | ICANN（13 个逻辑编号 a~m） |
| TLD 服务器 | 某一排特定书架 | 管同后缀全部域名，把解析器引荐给目标域的权威服务器 | IANA（gTLD / ccTLD） |
| 权威服务器 authoritative | 书架上的词典本身 | 持有该域真实记录，是最终真相来源，直接应答 | 域名所有者 / DNS 托管商 |
递归解析器在头，权威服务器在尾
One way to think about the difference is the recursive resolver is at the beginning of the DNS query and the authoritative nameserver is at the end. —— Cloudflare, What is DNS?
递归解析器主动发起一连串查询；权威服务器被动持有最终记录、能用自有数据直接回答而无需再问别人。两者一头一尾，构成整条解析链。
关于根服务器有个常见误解：全球只有 13 个根服务器。准确说是 13 个逻辑编号（a~m），每个编号经 Anycast 路由复制成全球多个物理实例，加总有 600+ 台——所以根服务器并不会成为性能瓶颈，且就近响应。
四、递归查询 vs 迭代查询：关键在「看谁的立场」
这是本页最核心、也最容易混淆的概念。一次典型的无缓存解析，同时包含递归查询和迭代查询两种：
A typical uncached DNS lookup will involve both recursive and iterative queries. —— Cloudflare, What is DNS?
差别不在于「谁发的请求」，而在于**「被问方有没有义务给出最终答案」**：
| 维度 | 递归查询（Recursive） | 迭代查询（Iterative） |
|---|---|---|
| 发生在哪一段 | 客户端 → 递归解析器 | 递归解析器 → 根 / TLD / 权威 |
| 被问方的义务 | 必须给最终答案或报错 | 只需给「最佳答案」——通常是引荐 |
| 典型回应 | 直接返回 IP（或 NXDOMAIN 错误） | 返回 referral：「我不知道，去问下一级」 |
| 谁来「跑腿」 | 递归解析器替客户端跑完全程 | 解析器自己拿着引荐一级级追问 |
把它画成时序更直观——递归解析器对客户端「是递归的」，对各级服务器「是迭代的」：
客户端 ──递归查询(要最终答案)──► 递归解析器 ──迭代──► 根 ：去问 .com（引荐）
──迭代──► TLD：去问权威（引荐）
──迭代──► 权威：IP=93.184.x.x
客户端 ◄────────递归响应(最终 IP)──────────┘还有第三种——非递归查询（Non-recursive）：当被查方自己就是该记录的权威，或缓存里已有该记录时，无需再向上追问，直接返回答案。命中缓存的解析大多落在这一类，这也是缓存能加速解析的原因。
别把「递归查询」和「递归解析器」当成一回事
It's important to differentiate between a recursive DNS query and a recursive DNS resolver. —— Cloudflare, What is DNS?
递归查询是「请求的类型」（要求对方负责到底）；递归解析器是「处理这种请求的那台机器」。一个是动作，一个是角色，名字像但不是同一层概念。
五、DNS 报文结构：五个段
DNS 查询与响应复用同一种报文格式（RFC 1035 定义），由五个段组成。查询时通常只填 Header + Question，响应时由服务器补齐后三段：
| 段 | 名称 | 内容 |
|---|---|---|
| 1 | Header（头部） | 16 位事务 ID、QR（查询/响应位）、Opcode、各类标志（AA 权威应答 / TC 截断 / RD 期望递归 / RA 递归可用）、以及后四段各自的记录条数 |
| 2 | Question（问题段） | 要查什么：域名（QNAME）+ 查询类型（QTYPE，如 A/AAAA/MX）+ 类（QCLASS，通常 IN） |
| 3 | Answer（回答段） | 直接回答问题的资源记录（如 A 记录里的 IP） |
| 4 | Authority（授权段） | 指向权威服务器的 NS 记录（迭代里的「引荐」就装在这） |
| 5 | Additional（附加段） | 补充信息，常见是胶水记录（glue record）——把权威服务器的 IP 一并捎上，省去再解析一次 |
一条典型响应：Question 段问 example.com A IN，Answer 段回 example.com A 93.184.x.x，Authority 段附 NS ns1.example.com，Additional 段则带上 ns1 的 IP 作胶水记录。
标志位里藏着「递归/迭代」的开关
报文头里的 RD（Recursion Desired） 由客户端置位，表示「我希望你递归地帮我查完」；RA（Recursion Available） 由服务器置位，表示「我支持递归」。stub resolver 发给递归解析器的查询会设 RD=1；而递归解析器发给根/TLD 的迭代查询通常 RD=0——它并不指望根服务器替它跑完全程。TC（Truncated） 位则与下一节的 UDP→TCP 切换直接相关。
六、传输层：默认 UDP 53，何时改走 TCP 53
DNS 在传输层同时使用 UDP 和 TCP，端口都是 53，但分工不同。
默认：UDP 53（快、无连接）
绝大多数 DNS 查询走 UDP 53：一个请求包、一个响应包，无需三次握手，开销小、延迟低。对「问一个 IP、答一个 IP」这种短小交互，UDP 是天然最优解——这也是 DNS 解析能做到毫秒级的重要原因。
切到 TCP 53 的两种场景
| 触发场景 | 为什么必须用 TCP |
|---|---|
| 响应过大 | 传统 UDP 响应上限 512 字节；超限时服务器置 TC=1（截断位），客户端据此改用 TCP 重发查询，以拿到完整响应（DNSSEC、多记录返回时常见）。现代多用 EDNS(0) 协商更大的 UDP 包，但仍超限时照样回退 TCP |
| 区域传送（Zone Transfer） | 主/从权威服务器同步整个区域数据（AXFR 全量 / IXFR 增量），数据量大且要求可靠、有序、完整，必须用面向连接的 TCP |
一句话记住 UDP/TCP 的取舍
「查询走 UDP 图快，搬数据走 TCP 图稳」：日常解析是小数据、要低延迟，用无连接的 UDP；区域传送是大数据、要零丢失，用可靠的 TCP；UDP 装不下时靠 TC 位回退 TCP 兜底。
七、解析延迟：首次访问的隐形成本
DNS 解析排在 TCP 连接、TLS 握手之前，是发起任何 HTTP 请求的前置步骤。一次未命中缓存的解析要经历「本地缓存查询 + 递归解析器多级迭代往返」，在高延迟网络下可能耗费数十至上百毫秒，全部叠加在首屏时间里。对首次访问（缓存全空）尤为明显：页面引用的第三方域越多（脚本、字体、图片），要解析的域名越多，累积延迟越可观。
这正是前端要做 DNS 优化的动机
正因为 DNS 解析处在首屏链路最前端，前端可用 dns-prefetch、preconnect 等手段提前并行解析关键域名，把这段延迟从关键路径上挪走。具体手段见前端 DNS 优化。
小结
一次完整 DNS 解析有 8 步：浏览器缓存 → OS 缓存（stub resolver）→ 递归解析器 → 根 → TLD → 权威 → IP 逐级回传 → 浏览器拿到 IP，任一层缓存命中即可提前短路。四类服务器各司其职：递归解析器接客代查并缓存、根服务器指向 TLD、TLD 指向权威、权威持有真实记录作为终点。本页最关键的概念是递归 vs 迭代取决于立场——客户端到递归解析器是递归查询（必须给最终答案），递归解析器到各级服务器是迭代查询（每级只给引荐），缓存命中时则是非递归查询。DNS 报文复用同一五段结构（Header/Question/Answer/Authority/Additional），标志位 RD/RA/TC 控制着递归意图与 UDP/TCP 切换。传输层默认 UDP 53 图快，响应过大或区域传送时改走 TCP 53 图稳。理解了这套流程，也就理解了为何 DNS 解析延迟是首次访问的隐形成本，以及前端为何要把它从关键路径上提前挪走。
- 上一页：DNS 作用与域名层级体系
- 下一页：常见记录类型