什么是 DNS 转发？其工作原理与重要性解析
什么是 DNS 转发？了解转发器与递归解析器的区别、缓存和故障转移的工作原理，以及转发在现代网络中的应用位置。
Published 2026年10月23日
DNS 转发是指 DNS 解析器将客户端的查询发送给另一个 DNS 服务器（转发器），而不是直接通过 DNS 层级结构解析该名称的过程。本地解析器仍然可以从其缓存中进行响应并应用本地策略，而上游解析器则在需要时执行完整的查询。但是，如果该上游服务器出现故障，究竟是 DNS 的哪一部分损坏了？
在配置网络或尝试解释为什么某个网站无法加载时，这种区别至关重要。转发解析器不仅会传输数据包：它还能在本地响应熟悉的请求，将选定的查询定向到不同的服务器，并控制由哪个解析器来处理用户的 DNS 流量。
目录
- DNS 转发的具体含义
- 追踪从客户端到解析结果的完整查询路径
- 转发与递归及权威解析服务的区别
- 条件转发、Split Horizon 与环路预防
- 缓存和 TTL 如何影响转发性能
- 在转发、根提示递归和加密 DNS 之间进行选择
- 在您的网络中应用 DNS 转发
DNS 转发的真正含义
可以将本地解析器想象成收发室的前台。客户端按名称请求一个网站，解析器会检查自己是否已知答案。如果其缓存中有有效的答案，就会直接返回。如果没有，它会将查询发送给上游 DNS 服务器（即转发器），由其处理查找并返回响应。
这种安排将两项工作分离开来。本地解析器面向网络的客户端，可以应用本地规则。上游解析器则承担解析本地服务器无法从其缓存或本地数据中回答的名称的工作。因此，转发是一种架构功能，并不自动等同于安全产品。
DNS 诞生于 1983 年 11 月，当时 RFC 882 和 RFC 883 引入了分层命名系统，以取代日益难以管理的 HOSTS.TXT 模型。在 DNS 出现之前，管理员依赖于手动维护的名称到地址映射。1987 年 11 月，RFC 1034 和 RFC 1035 取代了最初的规范，正如 DNS 历史时间线 所记载的那样，它们成为了现代 DNS 架构的基础标准。
您将在何处遇到转发
家用路由器、企业网络、公共 WiFi、学校和云环境都可以使用转发。企业或组织可以使用它将常规的互联网查询发送到托管的递归服务，同时保留对缓存、日志记录、内部域名或拦截规则的本地控制。
这种有用的思维模型很简单：本地解析器是受控的前台；上游解析器则是负责执行完整查找的专家。这种模型也更容易定位问题。即使上游解析器不可用或返回错误，客户端也可能成功连接到前台。
追踪从客户端到答案的查询过程
典型的查询始于设备向其本地解析器请求域名。解析器会首先检查其缓存。如果存储的答案仍然有效，则无需联系上游服务器即可直接返回。如果没有可用的缓存答案，解析器会将查询转发给上游递归解析器。
在 DNS 术语中，转发涉及解析器发送包含 期望递归（RD）位 设置的查询。该标志位表明正在请求接收方解析器解析查询，而不仅仅是在没有该请求的情况下中继数据包。RFC 7719 的词汇表定义 将转发与盲数据包中继区分开来。
如果缓存未命中，上游递归解析器将执行查找工作。它可能会使用自己的缓存，或者通过 DNS 层级结构查询答案。随后，响应会通过转发解析器返回给客户端。
两条可能的路径
- 缓存命中：本地解析器返回有效的缓存答案。上游服务器不参与该查询。
- 缓存未命中：本地解析器将查询发送给上游，接收响应，并将其返回给客户端。
这种交接还明确了职责划分。本地解析器可以应用特定于网络的控制措施、保留日志、使用 split-DNS 规则或实施 DNSSEC 验证策略。当本地解析器无法从其缓存或本地数据中提供答案时，上游解析器将执行递归查询。
故障排除提示：如果本地解析器可以响应客户端，但当其缓存中不包含答案时查询失败，请在判定权威 DNS 服务出现故障之前，先检查转发路径和上游响应。
转发与递归及权威服务的区别
DNS 转发、递归、代理和权威服务描述的是不同的角色。单个系统可以承担多个角色，但这些术语不能互换。在典型的转发设置中，本地服务器为客户端提供服务并维护缓存或策略；上游递归解析器则为缓存未命中执行解析。
| 角色 | 发起方 | 执行完整查询 | 保存权威数据 | 典型故障现象 |
|---|---|---|---|---|
| 转发器 (Forwarder) | 本地解析器向其发送查询 | 通常在充当上游递归解析器时执行 | 不一定 | 上游服务超时或报错 |
| 递归解析器 (Recursive resolver) | 客户端或其他解析器请求解析 | 是，通过使用缓存或在 DNS 层级结构中进行查询 | 不一定 | 解析错误、超时或查询失败 |
| 代理 (Proxy) | 客户端或服务向其发送流量 | 本质上不执行；代理仅根据其设计转发请求 | 否 | 代理请求失败或无法到达目的地 |
| 权威服务器 (Authoritative server) | 解析器针对其托管的域名进行查询 | 否，它为其 Zone 提供数据 | 是，针对其托管的 Zone | 这些 Zone 的记录缺失、不正确或不可用
该表格的关键区别在于由谁执行完整的查找。转发解析器将未回答的查询转发出去；递归解析器则负责处理解析，可能会查询权威服务器。权威服务器为其管理的域名提供记录，而不是代表客户端搜索整个层级结构。
为什么这种区别会改变故障排除方式
即使权威 DNS 基础架构运行正常，转发解析器也可能返回上游超时、SERVFAIL 或不再适用的缓存答案。在这种情况下，如果仅对权威服务器进行排错，可能会让您走入误区。请检查是哪个解析器收到了请求、它是否包含缓存答案，以及下一跳发生了什么。
此外还存在信任依赖关系。RFC 7719 讨论了解析器术语，包括转发器与递归解析器之间的区别。针对缓存污染攻击的研究对这些角色进行了区分，因为转发器依赖于其使用的上游解析器的完整性。如果设计中包含内容控制，网络还可以使用 DNS 过滤，在设备连接到目标之前对查询应用策略。
条件转发、Split Horizon 与环路预防
转发并不一定要将每个未回答的查询发送到同一个上游服务器。通过条件转发，解析器可以将选定域名的查询发送到指定的服务器。例如，网络可以将对内部名称的请求引导至内部 DNS 服务，并将其他请求发送至托管的递归解析器。
一个相关的概念是Split-Horizon DNS（双向 DNS）。它允许网络根据请求来源的不同，对同一个名称返回不同的答案。组织内部的人员可能会收到内部答案，而外部请求者则会收到不同的答案。本地解析器因此成为了将内部名称保持在适当路径上的决策点。
配置必须明确哪个解析器拥有每个查询路径。将内部名称发送到错误上游服务器的规则可能会产生外部答案、解析失败，或者导致网络不同区域之间的结果不一致。
防止解析器环路
当一个解析器将查询发送到第二个解析器，而后者最终又将其发回时，就会发生转发环路。查询会在服务器之间循环，导致重复请求、超时和资源耗尽。解决方法是梳理转发路径，并确保没有解析器链指向较早的服务器。
某些名称也需要明确的边界。RFC 9539 指出了诸如 home.arpa 等命名空间，切勿将其转发到其预期的本地范围之外。原本正常工作但在添加第二个转发器后出现问题的解析器，可能产生了环路；而开始公开解析的本地名称，可能需要更具体的转发规则或本地区域规则。
下面的视频对 DNS 转发概念进行了直观的介绍。
缓存和 TTL 如何塑造转发性能
转发器的缓存工作原理类似于一个有用中介的记忆：一旦它从上游获取了答案，就可以自行回答下一个相同的提问。这单一行为解释了转发对性能造成的大部分影响。每一次缓存命中都会减少一次前往上游解析器的往返。而每一次未命中，在实际查询开始之前都会增加一次往返。
每个记录的生存时间 (TTL) 设定了该缓存的期限。权威服务器发布 TTL，路径上的任何解析器仅在其有效期间可以复用缓存答案。较短的 TTL 能保持答案的新鲜度，但会向上游发送更多查询。较长的 TTL 可以减少上游流量，但在基础架构发生变更后，可能会导致客户端保留过期的地址。
缓存也会在路径上层层叠加。查询可以由客户端的缓存、转发器的缓存或上游解析器的缓存来提供服务，并且每一层都会运行自己的 TTL 倒计时。当用户报告答案过时时，修复方法取决于哪一层保存了该答案，因此在排错过程中应将每个缓存视为独立的排查对象，而不是直接刷新距离最近的缓存。
测量的指标不应仅限于平均延迟
平均查询时间可能会掩盖仅影响部分用户或部分查询的问题。应持续追踪缓存命中率、中位数和长尾查询延迟、上游超时率以及负缓存行为。这些指标有助于区分究竟是上游服务较慢，还是转发器不断错过缓存机会或对失败查询处理不当。
DNSSEC 增加了另一个复杂性。验证解析器除了获取答案本身之外，还需要获取签名和密钥，因此已签名域名的缓存未命中成本要高于未签名域名。缓存的验证答案可以省去这些重复工作，这使得命中率在验证路径上变得更加重要。
没有单一的数字可以预测特定网络上的查询时间。结果取决于每一层的缓存状态、上游响应能力、验证工作、传输设置以及转发器无响应后的重试机制。运行良好的转发器还会原封不动地传递响应代码、截断行为、DNSSEC 记录和标志，从而使客户端看到权威端发送的原始答案。
在转发、根提示递归和加密 DNS 之间进行选择
转发和根提示递归（root-hints recursion）各有不同的权衡。采用转发时，组织会选择上游解析器来处理未回答的查询。这可以简化本地运维并集中管理策略，但会使网络依赖于所选的上游服务。采用根提示递归时，解析器会自行执行迭代查询，从而减少对单一上游递归服务的依赖，但也会让该解析器承担更多的解析责任。
| 架构选择 | 解析发生位置 | 主要运维权衡 |
|---|---|---|
| 转发 | 在选定的上游递归解析器处 | 集中式管理，但存在上游依赖关系 |
| 根提示递归 | 在本地递归解析器处，通过层级结构进行查询 | 更高的本地控制权，但承担更多直接解析的责任 |
| 客户端指定的加密 DNS | 在客户端通过加密连接联系的解析器处 | 本地网络可能无法查看或控制域名查询 |
加密 DNS 使选择变得更加复杂。基于 TLS 的 DNS 和基于 QUIC 的 DNS 可以在传输过程中保护 DNS 流量，但关键问题在于加密在何处终止。如果客户端将查询直接加密传输至外部解析器，本地转发器可能无法看到可用的域名查询。如果加密终止于经批准的企业解析器，则该解析器仍可应用网络策略并将查询转发至上游。
公共 WiFi 需要明确的策略
公共 WiFi 运营商还必须考虑 Captive Portal。在用户登录之前，设备可能需要进行认证前的名称解析和连接性检查。加密 DNS 可能会使 Portal 检测变得复杂或造成延迟，因此运营商需要决定批准哪些解析器、回退机制应如何工作，以及是否有必要设置任何例外。
防护型 DNS 服务可以部署在选定的解析路径中，并在连接开始前对查询进行评估。Purple Shield 专为场馆和访客 WiFi 网络设计，具备基于类别的过滤内容功能、DNS 层的威胁拦截以及可按网络管理的策略。它可以作为独立服务部署，也可以与 Purple Access 网络集成。对于权衡 DNS 控制与更广泛的 Web 流量控制的团队，安全 Web 网关概述 介绍了不同层级的执行机制。
在您的网络中投入使用转发功能
转发会将部分 DNS 工作负载集中在组织选择的上游服务中。使用 DNS-OARC 的 Day in the Life 数据集进行的测量发现，大约 99% 的递归解析器产生了中等查询量，而约 1% 的表现较为激进。该较小的群体占据了 2018 年观察到的 DNS 流量的 98% 和 2019 年的 93%；研究人员估计该群体在 2018 年包含约 8,300 个解析器，在 2019 年超过 14,000 个（激进解析器行为研究）。本地解析器可以将请求发送到上游递归服务，这些服务会缓存并重复使用答案，但这会增加对其可用性和行为的依赖。
在部署或更改转发之前，请检查：
- 上游相互独立：在设计允许的情况下，配置至少两个转发器。
- 故障有明确的响应机制：设置超时和重试行为，并明确当上游未响应时客户端会收到什么。
- 监控覆盖异常症状：密切关注 SERVFAIL 响应、超时和响应延迟。
- 隐私预期清晰明确：确定哪个上游解析器可以查看转发的查询。
如果 DNS 过滤是您访客网络策略的一部分，请将其与您更广泛的 WiFi 内容过滤方案 进行比较。然后审查您的网络转发到哪个解析器，并确认其策略、可用性和隐私状况符合您的预期。
Purple Shield 在设备连接之前检查 DNS 查询，并为场馆和宾客 WiFi 网络提供内容过滤与威胁拦截功能。如果您正在评估转发机制如何支持这些控制措施，请访问 Purple Shield 以了解其部署选项。