DNS Stub Resolver、递归解析器、转发器和权威服务器有什么区别？

直接答案

Stub Resolver是设备或应用中的轻量DNS客户端，通常把查询交给上游；递归解析器代表客户端追踪DNS委派链，最终返回答案或错误，并通常缓存结果；转发器不自行完成全部迭代解析，而把查询交给另一个上游解析器；权威服务器保存某个DNS区域的权威数据，针对所管理区域回答记录或委派信息。

四种角色可能由不同机器承担，也可能组合在同一软件或设备中。“DNS服务器”这个笼统名称不能说明它提供递归还是权威服务。排障时先识别查询停在哪个角色，再判断是本机配置、缓存、转发链、委派还是区域数据问题。

一、角色对比

表格描述逻辑角色，不等于软件产品分类。同一BIND、Unbound、dnsmasq或网关实例的实际行为取决于配置。

二、Stub Resolver是什么

RFC 8499将Stub Resolver定义为不能自行完成全部解析、通常依赖递归解析器的Resolver。操作系统的名称解析库常扮演这一角色：应用请求解析域名，本机组件根据DNS配置把问题发送给上游服务器。

Stub通常不从根服务器开始逐级查询，也不维护完整共享缓存。浏览器或应用还可能拥有独立DNS实现、DoH配置和自身缓存，所以“系统DNS已修改”不保证所有应用都改走相同上游。

三、递归解析器是什么

递归解析器收到客户端查询后，要么从缓存回答，要么向其他DNS服务器查询，直到取得最终答案或错误。对客户端而言，递归模式返回答案或错误，而不是让客户端自己继续跟随Referral。

当缓存未命中时，解析器通常从根提示引导，依次查询根、顶级域和相关权威服务器。它还需要处理CNAME、超时、重试、服务器选择、DNSSEC验证和缓存策略，实际流程可能比简化示意复杂。

四、转发器是什么

转发器接收下游查询后，把解析责任交给另一个递归解析器，而不是自行从根和权威服务器完成迭代解析。家庭路由器、企业网关和本地缓存服务经常采用这种模式。

转发器可以缓存，也可以只做转送；它还可能按域名把内部区域发送到企业DNS，把其他查询发送到公共上游。因而查询链可能是“应用—系统Stub—路由器转发器—运营商递归解析器—权威服务器”。

五、权威服务器是什么

权威服务器从本地配置的DNS Zone获得数据，能够针对其负责区域回答记录。RFC 8499指出，权威回答通常设置AA标志；服务器也可能为被委派的子区域返回Referral。

权威服务器的职责是发布区域内容，不是为任意互联网域名提供开放递归。一个域名常有多个权威服务器，以降低单点故障风险；Primary和Secondary描述区域数据来源关系，不表示其中一个“只备用、不响应”。

六、递归查询和迭代查询有什么区别

递归查询要求接收方代表客户端取得最终答案。DNS报文中的RD位表示希望递归，服务器响应中的RA位表示其提供递归能力。RD和RA的具体组合要结合响应内容与服务器策略判断。

迭代解析中，查询方收到Referral后，自己继续向更接近目标的服务器查询。典型递归解析器在面向权威链路时执行这种工作，而普通Stub通常把它交给递归服务器。

七、完整查询链如何运行

以首次查询 www.example.com A 为例：

1. 应用把名称交给系统或应用内Stub。

2. Stub向配置的递归解析器或本地转发器发送查询。

3. 转发器若没有本地答案，将查询交给上游递归解析器。

4. 递归解析器缓存未命中时，查询根服务器获得顶级域Referral。

5. 再查询顶级域权威服务器，获得目标区域的权威服务器信息。

6. 查询目标权威服务器，取得A记录、CNAME、NODATA或NXDOMAIN等结果。

7. 解析器按TTL缓存适用数据并把结果逐层返回Stub与应用。

缓存命中时，中间多步不会发生，所以抓包未看到权威查询并不表示解析链错误。

八、缓存存在于哪些位置

应用、操作系统Stub、本地代理、路由器转发器和递归解析器都可能缓存结果。浏览器缓存清除不一定清除系统或上游缓存，重启路由器也不一定改变递归解析器中的记录。

正向答案按TTL逐步过期。RFC 2308还规定负缓存：不存在的名称或记录类型也可能被缓存，以减少重复无效查询和上游流量。因此，刚修复记录后仍返回NXDOMAIN，可能是负缓存尚未到期。

九、NXDOMAIN和NODATA有什么区别

NXDOMAIN表示查询名称不存在；NODATA表示名称存在，但没有所查询类型的记录。例如域名存在AAAA却没有A，可得到无该类型数据的答案，而不是名称不存在。

这一区别影响负缓存和排障方向。不要看到空答案就创建重复记录；先检查响应码、Answer与Authority部分、SOA及实际查询类型。

十、为什么换DNS有时立刻恢复

切换递归解析器会绕过原解析器的缓存、转发策略、DNSSEC验证结果或网络路径，所以可能恢复。但这只说明两个解析路径结果不同，不能直接证明原DNS“被污染”。

应同时查询原上游、新上游和目标权威服务器，比较响应码、记录、TTL、权威信息和时间。若权威数据本身错误，换递归服务器只能暂时命中不同缓存，最终仍会扩散。

十一、为什么直接查权威正常，客户端仍失败

客户端查询要经过Stub、转发器和递归缓存。权威修复后，旧的正向或负缓存可能继续有效；企业Split DNS也可能让内部与公网使用不同区域视图。

此外，客户端查询类型可能不同，例如应用优先请求AAAA，而手工只查A。验证时必须使用相同名称、类型和网络环境，不能用不同问题的正常答案替代。

十二、如何识别当前查询的角色

先查看系统实际配置的DNS服务器地址。若是家庭网关地址，它很可能是转发或缓存层；若是企业内网地址，可能同时承载内部权威区与递归；公共DNS地址通常提供递归服务。

使用DNS查询工具时记录Server、flags、status、Answer、Authority、Additional和TTL。带AA的回答可支持权威判断，但经转发或特殊实现后仍应结合查询目标和服务器配置，不要只看单一标志。

十三、常见故障对应哪一层

单个设备失败，其他设备正常

优先检查该设备的Stub配置、hosts文件、应用内DoH、本地缓存和安全软件。

整个局域网失败，移动网络正常

检查路由器转发器、上游DNS地址和局域网到DNS端口的路径，不要先修改域名权威记录。

多地递归DNS均返回相同错误

检查权威区域、委派、DNSSEC链和记录内容，尤其是最近变更后的Serial与权威节点一致性。

只有企业内部域名失败

检查Split DNS和条件转发规则，以及客户端是否误用公共DoH绕过企业解析路径。

十四、安全与隐私边界

开放递归服务器可能被滥用，应限制可使用递归服务的客户端范围。权威服务器与递归服务最好按风险模型隔离，避免一项配置错误扩大攻击面。

加密DNS保护客户端到指定解析器之间的传输，不自动证明权威答案正确，也不隐藏递归解析器向权威链发出的全部查询。DNSSEC提供数据来源验证能力，但仍需正确的信任链和验证解析器。

十五、最小排障流程

1. 记录域名、记录类型、时间、网络和完整错误。

2. 确认应用使用系统Stub还是应用内DoH。

3. 查询当前配置的上游，保存flags、响应码、TTL和Authority。

4. 对照另一个合法递归解析器，保持名称和类型相同。

5. 从父区委派找到实际权威服务器，不凭控制台名称猜测。

6. 直接查询多个权威节点，比较Serial和答案。

7. 区分正向缓存、NXDOMAIN负缓存和NODATA。

8. 修复后等待适用TTL，并恢复临时DNS设置再次验证。

分享结果前删除内部域名、客户端IP、查询日志中的用户标识及企业服务器地址。

十六、常见误区

• 把所有DNS服务器都称为“权威DNS”。
• 认为Stub会自己查询根服务器。
• 把转发器等同于完整递归解析器。
• 权威查询正常就忽略中间缓存。
• 将NODATA与NXDOMAIN混为一谈。
• 只查A记录，却排查AAAA失败的应用。
• 换公共DNS恢复后立刻断言是污染。
• 公开递归服务给整个互联网。
• 把DoH等同于DNSSEC验证。

十七、FAQ

家庭路由器是递归解析器还是转发器？

取决于实现和配置。许多路由器主要缓存并转发到上游，也有软件能自行递归。应查看实际配置或查询行为，不能仅凭网关地址判断。

权威服务器会缓存其他域名吗？

权威only服务器只按本地区域数据和委派回答。某个软件实例也可能同时启用递归功能，但那是另一逻辑角色，不是“权威”本身的要求。

RD和RA都存在就证明答案来自权威吗？

不能。RD表示客户端请求递归，RA表示服务器可递归；权威回答主要结合AA标志、区域与查询上下文判断。

刷新本机DNS缓存能清除运营商缓存吗？

不能。本机只控制自身缓存。上游转发器或递归解析器仍会按TTL保留数据，除非运营方提供专门清理机制。

修改DNS记录后多久生效？

取决于旧记录或负答案在各层缓存中的剩余TTL、权威节点同步和委派变化。不能用一个固定分钟数覆盖所有情况。

十八、结论

Stub Resolver负责把本机问题交给上游，递归解析器追踪委派并缓存答案，转发器把解析责任交给另一上游，权威服务器发布区域数据。沿这四个角色逐层核对相同名称和记录类型，可以区分本地配置、缓存、转发与权威数据故障，避免用“换DNS”代替根因定位。

核验来源

• RFC Editor：RFC 8499，DNS Terminology，https://www.rfc-editor.org/info/rfc8499/（核验日期：2026-08-26）
• RFC Editor：RFC 1034，Domain Names — Concepts and Facilities，https://www.rfc-editor.org/info/rfc1034/（核验日期：2026-08-26）
• RFC Editor：RFC 1035，Domain Names — Implementation and Specification，https://www.rfc-editor.org/info/rfc1035/（核验日期：2026-08-26）
• RFC Editor：RFC 2308，Negative Caching of DNS Queries，https://www.rfc-editor.org/info/rfc2308/（核验日期：2026-08-26）