你有没有想过，当你在浏览器里输入一个网址，比如 www.example.com，电脑是怎么知道该去哪个服务器上找内容的？这背后靠的就是域名系统（DNS）。而其中一种常见的查询方式，叫作“迭代查询”。
什么是迭代查询？
简单来说，迭代查询就是 DNS 客户端（比如你的电脑）向一个 DNS 服务器问：“你知道这个域名对应的 IP 吗？”如果这台服务器不知道完整答案，它不会继续替你去查，而是告诉你：“我不知道，但你可以去问某某服务器。”然后你自己再去问下一个服务器，直到找到结果。
这就像你在一个陌生城市找一家小店。你先问路人A，他说他不知道，但建议你去问街角的便利店老板。你再去找便利店老板，他说你应该去问对面邮局的工作人员。最后你在邮局问到了地址。整个过程是你自己一步步跑腿，而不是让第一个人帮你跑完全程。
和递归查询有啥区别？
有些人会把迭代查询和递归查询搞混。递归查询更像是“代劳服务”——你把问题丢给 DNS 服务器，它必须给你一个明确答案，不管它是自己查还是帮您层层追问，最终得把结果送上门。
而大多数公共 DNS 服务器（比如运营商提供的），对客户端只做递归查询；但在 DNS 服务器之间互相沟通时，通常用的是迭代查询。也就是说，你的电脑可以要求本地 DNS 服务器帮忙递归查找，但这两个服务器之间交流时，更多是采用迭代的方式协作。
一次典型的迭代过程长什么样？
以查询 www.example.com 的 IP 为例：
- 你的设备问本地 DNS 服务器：www.example.com 的 IP 是多少？
- 本地 DNS 服务器查了缓存没有，就转向根域名服务器发问。
- 根服务器回复：“我不认识，但你可以问问负责 .com 的顶级域名服务器。”
- 本地 DNS 再去问 .com 域名服务器，对方回：“example.com 归某个权威服务器管，它的地址是 ns1.example.com。”
- 接着本地 DNS 找到 example.com 的权威服务器，终于拿到 www.example.com 对应的 IP 地址。
- 最后，这个结果被返回给你的设备。
这一连串动作中，从根服务器到顶级域再到权威服务器之间的每一跳，基本都是通过迭代完成的。
实际配置中的体现
如果你管理过 DNS 服务器，可能会在 BIND 或其他 DNS 软件里看到相关设置。例如，在配置转发或区域传输时，明确区分递归请求和迭代响应的处理逻辑很重要。
options {
recursion yes; // 允许对受信任客户端进行递归查询
allow-query { any; };
};
zone "example.com" {
type master;
file "/etc/bind/zones/db.example.com";
// 这个权威服务器会对其他 DNS 服务器提供迭代应答
};这里的配置并不直接写“启用迭代”，因为迭代是 DNS 协议默认的行为模式之一。服务器在面对非递归请求时，自然就会返回 referrals（指引）而不是最终答案。
为什么迭代查询仍然重要？
虽然我们日常上网感觉不到这个过程，但正是这种分工机制让 DNS 系统既高效又稳定。如果每个查询都靠单台服务器全程跑完所有步骤，压力太大，容易崩溃。而通过迭代方式分散任务，各个层级各司其职，整个系统才能扛住全球数十亿设备的同时访问。
下次你打开网页秒开的时候，不妨想想：可能已经有三四台 DNS 服务器悄悄接力了一圈，才把那个正确的 IP 地址送到你面前。