DNS递归查询与迭代查询的区别与工作流程详解
一、知识点描述
DNS（域名系统）查询是互联网将人类可读的域名转换为机器可用的IP地址的核心过程。这个过程主要分为两种工作模式：递归查询和迭代查询。简单来说，这描述了DNS解析器（通常由你的互联网服务提供商或公共DNS服务如8.8.8.8提供）在获取最终答案的过程中，与其他DNS服务器之间的互动方式。理解这两种模式的差异，是理解DNS如何高效、分布式地工作的基础。
二、核心概念区分
在深入流程之前，我们先明确几个关键角色：
- DNS解析器：也称为“递归解析器”。它接收来自客户端（如你的浏览器）的查询请求，并负责“跑腿”，最终将答案返回给客户端。我们常用的
8.8.8.8、114.114.114.114就是一个递归解析器。 - 根域名服务器：全球有13组（逻辑组，实际服务器更多），它们知道所有顶级域（如
.com，.cn，.net）的权威服务器的地址。 - TLD顶级域名服务器：负责管理特定顶级域（如
.com）下所有二级域名的权威服务器信息。 - 权威域名服务器：最终掌握特定域名（如
www.example.com）的IP地址记录的服务器。域名所有者（或托管商）负责维护它。
递归查询和迭代查询描述的不是客户端和本地解析器之间，而是递归解析器与其他DNS服务器之间的交互模式。
三、递归查询流程详解
在递归查询中，客户端向递归解析器提出一个要求：“你必须给我最终答案，找不到也要告诉我错误，不能让我去问别人。”
递归解析器会承担全部工作，它会代表客户端，与各级DNS服务器进行迭代查询，直到拿到最终答案，然后一次性返回给客户端。
一个完整的递归查询实例（解析 www.example.com）：
假设你的电脑DNS设置的是8.8.8.8。
步骤1：客户端发起递归查询请求
- 你的浏览器要访问
www.example.com。 - 操作系统生成一个DNS查询报文，设置
RD位为1（表示要求递归查询）。 - 这个请求发送给你配置的递归解析器
8.8.8.8。 - 客户端对解析器说：“
8.8.8.8， 请告诉我www.example.com的IP地址，我等你最终结果。”
步骤2：解析器检查本地缓存
8.8.8.8收到请求后，首先检查自己的缓存中是否有www.example.com的有效记录。如果有，直接返回给客户端，流程结束。（这是最快的路径）- 如果没有，
8.8.8.8必须开始“解析之旅”。
步骤3：解析器发起迭代查询（问根服务器）
- 解析器不知道
www.example.com在哪，但它知道根服务器的地址（这些地址通常内置在解析器软件中）。 - 解析器向一个根服务器发起一个迭代查询：“请告诉我
.com顶级域服务器的地址。” - 注意：此时解析器是作为一个客户端向根服务器提问，但根服务器通常不提供递归服务，它只会返回一个“提示”。
- 根服务器回应：“我不知道
www.example.com的具体IP，但我可以告诉你负责.com域的TLD服务器的IP列表（比如a.gtld-servers.net的IP是192.5.6.30）。”
步骤4：解析器继续迭代查询（问TLD服务器）
- 解析器拿到
.comTLD服务器的地址后，向这个TLD服务器发起迭代查询：“请告诉我负责example.com域的权威服务器的地址。” - TLD服务器回应：“我不知道
www.example.com的具体IP，但我可以告诉你example.com的权威服务器的NS记录和对应的A记录（比如ns1.example.com的IP是192.0.2.1）。”
步骤5：解析器进行最后一次迭代查询（问权威服务器）
- 解析器现在有了
example.com权威服务器的地址。 - 解析器向这个权威服务器发起迭代查询：“请告诉我
www.example.com的IP地址。” - 权威服务器查询自己的区域文件，发现
www.example.com的A记录是93.184.216.34。 - 权威服务器回应：“
www.example.com的IP地址是93.184.216.34。”
步骤6：解析器完成工作，返回最终答案给客户端
- 解析器终于拿到了最终答案
93.184.216.34。 - 它将这个结果返回给你的电脑，并在自己的缓存中保存一份（根据记录的TTL值决定保存多久）。
- 你的电脑拿到IP，浏览器开始与
93.184.216.34建立TCP连接。
小结递归查询特点：
- 客户端体验简单：只需问一次，等一个最终回复。
- 解析器压力大：它要完成所有“跑腿”工作，并与多个服务器交互。
- 利用缓存提升效率：解析器的缓存可以为后续大量相同查询加速。
四、迭代查询流程详解
在纯迭代查询中，客户端（或一个解析器）需要自己承担“跑腿”工作，服务器只返回它知道的最佳结果，通常是下一级服务器的地址，然后客户端需要自己去问下一个。
一个理论上的纯迭代查询实例（假设你的电脑自己就是全功能解析器）：
步骤1：问根服务器
- 你的电脑直接向一个根服务器（如
198.41.0.4）发送请求：“www.example.com的IP是什么？” - 根服务器回应：“我不知道，你去问
.com的服务器吧，这是它们的地址列表（a.gtld-servers.net等）。”
步骤2：问TLD服务器
- 你的电脑从回应的地址列表中选一个，向
.comTLD服务器发送请求：“www.example.com的IP是什么？” - TLD服务器回应：“我不知道，你去问
example.com的权威服务器吧，这是它们的地址（ns1.example.com的IP是192.0.2.1）。”
步骤3：问权威服务器
- 你的电脑向
192.0.2.1发送请求：“www.example.com的IP是什么？” - 权威服务器回应：“
www.example.com的IP是93.184.216.34。”
步骤4：获得答案
- 你的电脑拿到了最终IP。
小结迭代查询特点：
- 服务器压力小：每个服务器只回答自己职权范围内知道的部分，不知道就叫你去问别人。
- 客户端（或初始查询者）工作复杂：需要处理多次查询往返。
- 在实际中，通常只有DNS解析器向根、TLD、权威服务器查询时才使用迭代查询模式。普通客户端不直接进行迭代查询。
五、核心区别与对比表格
| 特性 | 递归查询 | 迭代查询 |
|---|---|---|
| 查询主体 | 客户端向递归解析器发出的查询。 | 递归解析器向根/TLD/权威服务器发出的查询。 |
| 责任 | 解析器必须返回最终答案（IP或错误）。 | 被问服务器可以返回最佳已知结果（通常是下级引用）。 |
| 工作负载 | 主要由递归解析器承担。 | 分散在各个层级的DNS服务器上。 |
| 查询次数 | 对客户端是1次请求，1次回复。 | 解析器可能需要发起多次请求（根->TLD->权威）。 |
| 结果 | 最终答案（IP地址）。 | 可能是最终答案，也可能只是下一级服务器的引用。 |
| 典型场景 | 你的电脑/手机向8.8.8.8查询。 |
8.8.8.8向根服务器、.com服务器查询。 |
六、总结与比喻
- 递归查询 就像你去图书馆总服务台，对管理员说：“请帮我找《百年孤独》这本书。”然后你就坐着等，管理员会去各个书架、甚至其他分馆帮你找，最后把书交到你手里，或者告诉你没有。
- 迭代查询 就像管理员告诉你：“小说在A区。”你到A区问管理员，A区管理员说：“拉丁美洲文学在3排。”你到3排自己找到了《百年孤独》。
在互联网的实际DNS解析中，这两种模式是协同工作的：客户端向递归解析器发出“递归查询”，而递归解析器为了完成这个任务，代表客户端向DNS层级系统中的其他服务器发起一系列的“迭代查询”。这种设计完美结合了用户体验（客户端简单）和系统的可扩展性、分布式特性（各级服务器压力可控）。