DNS 递归和迭代：一次解析到底问了谁

一条 dig 只有几行输出，抓包却是多条往返。分不清谁在问谁，通常是把"递归"和"迭代"当成同义词了。分界不在命令，在 RD 标志位。

一次 dig 背后发生了什么

客户端发出一条查询，解析器替它走完一整圈，最后返回一条结果。你看到的是最后一条，中间的往返发生在服务端之间，在客户端抓包抓不到。

先把结论放前面：一次解析里，客户端只发一次请求，解析器发多次。 看清这一点，后面六跳才有意义。

客户端到递归解析器：要的是完整结果，RD=1。

解析器到权威：要的是下一跳，RD=0。

两条关系方向相反，目的也不同。前者是"你替我查完"，后者是"你告诉我该问谁"。

RD 是请求方的意图，RA 是服务端的承诺——应答里 RA=1 表示这台服务器支持递归。分界看 RD，不看是谁发起的包。同一个解析器，回给客户端的应答原样带回 RD=1，发给权威的查询置 RD=0，两个方向都对。

跳次	发起方 → 接收方	RD	拿到什么
1	客户端 → 递归解析器	1	提交查询。缓存未命中才继续往下
2	递归解析器 → 根	0	TLD 的 NS 记录
3	递归解析器 → TLD	0	该域的权威 NS
4	递归解析器 → 权威	0	记录本身，应答带 `AA=1`
5	递归解析器 → 客户端	1（原样回显）	结果，应答带 `RA=1`
6	客户端 → 递归解析器（下一次查询）	1	命中缓存，0 次上游查询

前五跳里只有第 1 跳和第 5 跳与客户端有关，第 2 到第 4 跳全在解析器与权威之间。第 6 行不是同一次解析的第六跳，是"下一次查询"的对照：如果第 1 跳就命中缓存，第 2 到第 4 跳都不发生，解析器直接回包，不会出现两次客户端查询。

缓存能顶多久由 TTL 决定。这也是为什么"改了记录没生效"多半不是解析出错，是解析器本地缓存还没过期。

读包顺序固定：先看 RD 判断这一跳是要结果还是要下一跳，再看 RA 判断对方能不能替你做，最后看 AA 判断这条答案是不是权威给的。

+trace 不是"看解析器怎么迭代"，是 dig 自己在从根开始一级一级问。这些查询全部 RD=0，由 dig 在本机手动发起迭代——相当于你替解析器把这条路走了一遍。

所以它看到的是"如果由我自己走一遍会怎样"，不是线上解析器实际走的路径——后者可能命中缓存，可能走转发，可能被策略改写。把 +trace 的输出当成"解析器做了迭代"的证据，是把工具的行为记到了别人头上。

名字与行为不是一回事，判据要落到具体动作。这和站内《危险函数检索为什么在真实项目里失效》讲的是同一件事：名字叫检索，实际做的是按形态找。站内文章：危险函数检索为什么在真实项目里失效

+norecurse 是另一回事：它把 RD 置 0：对递归解析器，只回缓存里有没有，不替你去问；对权威服务器，就是直接问权威。要直连权威，命令里得指定权威服务器；不指定，默认问的还是本机配置的解析器。观察缓存命中与权威直连，用这条。

BASH

# 看最终结果与解析器是否支持递归
dig example.com

# 只问本级缓存，不发递归请求
dig +norecurse example.com

# 本机自己从根开始逐级迭代
dig +trace example.com

三条命令的用途不同，输出也不能互相替代。命令与排查清单见工具库 · 底层速查，名词解释见 DNS 与端口。

递归解析器同时是放大与投毒的现场。它对公网开放递归，就等于替陌生人做迭代：攻击者发一条小查询，解析器替他向权威发多条。在正常递归解析里，权威侧看到的 RD=0 查询来自解析器，不是终端用户；+trace 那种客户端直连是另一回事。

一个可判断的信号：入站 RD=1 的来源大量不属于自己的客户网段，且查询目标分散。 正常的递归解析器，入站请求来自自己的用户，出站查询由缓存未命中驱动；来源和目标都对不上，才说明它在替陌生人干活。

DNS 放大与缓存投毒的具体构造不在这里展开，本文只给关系与判据。

递归与迭代不是两种命令，是两种关系：一个要结果，一个要下一跳。 判断一次解析里谁在做什么，看 RD。

本文仅用于安全学习与授权环境下的测试。文中所有示例均为本地或授权靶场环境，不构成对任何真实系统的测试指引。

仅限授权测试，严禁非法滥用。