在假设所有域名服务器均采用迭代查询方式的场景下，DNS解析过程将呈现以下特点及影响：

1、迭代查询的核心机制
客户端与服务器职责分离：客户端（如本地DNS解析器）直接向各级DNS服务器发起查询，每次查询仅获得下一跳的最佳指引（如上级服务器地址或权威服务器地址），而非完整的解析结果。
服务器不代查：被查询的服务器不会代替客户端向其他服务器发起请求，仅返回自己知道的最佳信息（如缓存记录或下级服务器参考）。

2、解析流程示例
假设用户访问 `www.example.com`，且所有缓存为空：
1、根服务器查询
客户端向根服务器询问 `www.example.com`。
根服务器返回 `.com` TLD服务器的地址（如 `a.gtldservers.net`）。

2、TLD服务器查询
客户端向 `.com` TLD服务器发起相同查询。
TLD服务器返回 `example.com` 的权威服务器地址（如 `ns1.example.com`）。

3、权威服务器查询
客户端向 `example.com` 的权威服务器查询 `www` 子域名。
权威服务器返回最终的IP地址（如 `192.0.2.1`）。

3、关键影响与挑战
客户端负担加重
客户端需主动发起多次查询（可能跨不同网络），增加了网络延迟和复杂性。
对终端设备（如手机、IoT设备）的DNS实现要求更高。

效率与延迟问题
每次查询需独立完成往返通信（RTT），总延迟为各步骤RTT之和。
无递归查询的“一站式”优化，可能降低用户体验（尤其在跨地域查询时）。

缓存利用率下降
中间服务器（如ISP的本地DNS）无法通过递归查询积累完整结果的缓存，客户端需自行缓存或重复多级查询。

流量分布变化
根和TLD服务器需直接响应大量终端客户端的查询（而非递归服务器的聚合查询），可能加剧其负载。

4、对比现实中的混合模式
实际部署：互联网通常采用递归+迭代混合模式（如本地DNS递归查询，根/TLD服务器迭代响应）。
优势：递归查询减轻终端负担，迭代查询保护高层服务器资源。

5、潜在优化措施
若强制全迭代：
客户端本地缓存：终端实现缓存以减少重复查询。
预取与并行查询：客户端预测后续查询并提前发起（如同时询问根和TLD）。
Anycast路由：通过地理就近的服务器副本降低RTT。

结论
全迭代查询模型会显著改变DNS的效率和架构，更适合研究场景或特定安全需求（如避免递归查询的潜在篡改），但在实际互联网中因性能和可扩展性问题难以全面部署。