浏览器里敲一下回车，页面出来得很快，绝大多数人不会去想背后发生了什么。但凡自己搭过站、绑过域名，早晚会撞上一个问题：域名解析协议到底是怎么走完这一趟的，递归查询和迭代查询又是什么关系，为什么有的解析几毫秒就回来了，有的要卡上好几秒才出结果。
先把一个常见的误会拆开。很多资料一上来就说”DNS查询有两种方式”，听上去像是让你二选一。真实情况不是这样。你电脑上那个解析程序，跟本地DNS服务器之间，走的是递归查询；本地DNS服务器找不到答案时，再去问上级服务器，走的是迭代查询。这两段路是串起来的，不是对立的两条路。
递归查询的特点是把活甩出去。客户端只说一句”我要这个域名对应的IP，你给我最终答案”，剩下的路怎么走、问了几家、中间转了几手，全都不用管。本地DNS服务器必须给出一个确定的结果——要么是IP，要么是明确的”不存在”。它不能回一句”你去问别人”了事。
迭代查询就懒一些。本地DNS服务器问根服务器，根说”这个域名归某某顶级域管，你去问它”；再问顶级域，又指到某台权威服务器。每问一次拿回一个线索，自己接着往下跑。责任没转移，只是拿到了下一步的地址。
想一下电脑和手机的网络环境。客户端可能在公司WiFi、可能在手机流量、也可能连着一个信号很差的热点，让它自己去追一圈根服务器、顶级域、权威服务器的链路，既不现实也不安全。让本地DNS服务器替它跑完全程，客户端只需要守着一条连接等答案，超时了重发就行。
顺便提一句端口。域名解析协议默认走UDP的53端口，答案小的时候一个包来回就完事。答案大或者要做DNSSEC校验的时候会切到TCP，也有服务器支持DoT、DoH这类加密方式。这些细节不影响你理解递归和迭代的区别，但排查问题时会用到。
如果根服务器也做递归，全世界所有解析请求全压到那几台上，后果不用想。递归查询把压力集中到本地DNS服务器，而本地DNS服务器数量多、可以缓存，重复的请求第二次就能直接从缓存里捞出来。迭代查询则让上游只负责”指路”，不替你跑腿，这样一台权威服务器可以同时应对海量询问。
这里有个容易被忽略的点：缓存。第一次解析某域名，本地DNS服务器老老实实走一遍迭代，拿到记录后按TTL存起来。TTL没到期之前再来问，它直接回缓存，连上级都不问。所以同一个域名在同一个网络里，第一次慢、后面快，是很正常的现象。反过来，你刚改了解析记录却发现访问还是老地址，多半是TTL还没走完。
排查解析故障最怕上来就瞎改。先分清是客户端到本地DNS这一段断了，还是本地DNS往上迭代那一段拿不到答案。有几个粗略的判断方向：换一个网络环境试试，手机流量和宽带各测一次；用nslookup或者dig直接指定某个DNS服务器查询，看回的是正常记录、还是超时、还是SERVFAIL；再对比不同DNS服务器的结果，如果不一致，基本就是缓存或者同步延迟的问题。
还有一种情况，本地DNS服务器能正常递归，但迭代到权威服务器时被拒绝。这往往跟域名状态有关，比如域名欠费、被hold、或者解析记录根本没生效。这类问题客户端怎么折腾都没用，得回到域名管理后台看。具体状态含义以服务商控制台和官方文档的说明为准，不同平台的提示文案不太一样。
别信”换个DNS就变快”这种说法。换公共DNS有时确实能绕开某个本地服务器抽风，但如果是权威服务器响应慢、或者记录TTL设得离谱，换谁都得等。判断依据是看解析耗时落在哪一段，而不是凭感觉。
有人图控制权，自己在内网搭一台递归解析服务给团队用。这么做有好处：缓存命中率高、能统一做黑白名单、日志都握在自己手里。代价是要防着被外面利用做放大攻击，递归服务不能对外网敞开，这点在搭建的时候就得配好，不能等出事再补。
反过来，如果你的业务是给其他系统提供权威解析，那重点就完全不同了：多节点、低延迟、记录变更后能快速同步。递归那套缓存思路在这里帮不上忙，反而要想清楚TTL该给多长——短了变更快但请求多，长了稳但改起来磨人。
说到底，递归和迭代不是两个可以随便挑的选项，而是域名解析协议里分工明确的两段流程：客户端这头交给递归，服务器之间用迭代。理解了这个分工，再遇到解析慢、解析失败、改了记录不生效这类问题，至少知道该从哪一段开始看，不至于把时间浪费在反复重装浏览器上。
【版权声明】：本站内容若无意侵犯到您的权利，请及时与我们联系将尽快删除相关内容!
