什么是递归 DNS：工作原理及其重要性
什么是递归 DNS？通过清晰的示例，了解解析器如何响应查找、使用缓存以及在何处实施安全检查。
Published 2026年11月2日
递归 DNS 解析器是一种服务器，它接收来自您设备的名称查询，并通过查询其他 DNS 服务器代为找到匹配的 IP 地址，然后存储该答案以供重复使用。
假设您更改了访客 WiFi 上的某项设置，但访客仍然可以访问您打算拦截的网站。在再次更改防火墙之前，请检查其设备使用的是哪个解析器，以及您的策略是否适用于已缓存的答案。这些细节通常可以解释更改规则与看到规则生效之间的差距。
目录
- 递归 DNS 解析器为您的设备提供哪些服务
- 递归 DNS 服务器与权威 DNS 服务器比较
- 递归查找如何遍历 DNS 层级结构
- 缓存、TTL 与变更所需的时间
- 解析器端的过滤与安全
- 服务中断、陈旧回复与常见误区
- 更改之前确认您的网络正在使用哪个解析器
递归 DNS 解析器能为您的设备做什么
递归 DNS 解析器为设备查找 DNS 答案，非常类似于酒店的前台礼宾员，他们会联系多个部门，而不是让客人逐个前台询问。客人提出问题并希望得到答案，而不是继续自行寻找的指引。
假设一家酒店的客人打开笔记本电脑并输入一个网站名称。如果该笔记本电脑本地尚无食用的可用答案，它会向其配置的 DNS 服务发送查找请求。该服务可以由酒店网络、互联网提供商或单独配置的解析器提供。
查找背后的角色
- 客户端：请求 DNS 答案的设备或应用程序。
- 递归解析器：负责查找并返回该答案的服务。
- 权威服务器：发布所请求域名官方 DNS 记录的服务器。
礼宾人员的比喻使这些职责更容易区分。
对于成功的地址查找，设备会收到一个 IP 地址和一个生存时间（通常缩写为 TTL）。该值告诉缓存系统可以重用该答案多长时间。随后，浏览器可以使用该地址开始联系目标。
递归并不意味着无休止的重复。 它描述了解析器承担的责任：为客户端找到最终答案，如果无法找到，则返回适当的错误信息。
酒店客人通常对发生的这一切一无所知。他们不需要选择根服务器，也不需要了解谁在托管该网站的 DNS。
一个有用的理解检验方式很简单：您的设备请求地址，解析器找到它，然后您的浏览器使用该地址发起连接。
递归 DNS 服务器与权威 DNS 服务器对比
递归解析器与权威服务器比较
| 标准 | 递归解析器 | 权威服务器 |
|---|---|---|
| 主要工作 | 通过查询其他服务器来为客户端寻找答案 | 为其负责的域名发布官方记录 |
| 答案来源 | 其缓存或上游 DNS 服务器 | 其自身的 Zone 记录 |
| 典型运营商 | 互联网提供商、公共解析器服务、网络所有者 | 域名所有者或托管提供商 |
| 是否由设备直接联系 | 是 | 通常不是；由解析器联系它 |
| 是否缓存其他域名的答案 | 是，受 TTL 和本地缓存规则约束 | 否，这不属于其权威角色的一部分 |
核心区别在于检索与权威性。递归解析器代他人检索信息。权威服务器则为其管辖的域名发布信息。
在排除故障时，这种区别至关重要。如果所有人收到的都是您组织网站的错误地址，请检查权威记录。如果只有特定网络上的访问者遇到问题，请排查该网络的解析器、其缓存以及其策略。
运营商可以在不合并角色前提下实现重叠
互联网服务提供商可能会为订阅用户运行递归 DNS，而托管服务提供商则为客户发布权威 DNS。网络所有者也可以为员工设备运行内部解析器。
同一个组织，有时甚至是同一个服务器软件，都可以承担这两种工作。服务器可以为内部域名提供权威应答，同时为员工解析无关的互联网名称。角色取决于正在处理的请求，而不仅仅取决于服务上的公司名称。
转发增加了另一层区分。本地 DNS 服务器可能会将请求传递给上游解析器，而不是自己联系层级结构。了解 DNS 转发 有助于您确认是哪项服务执行了外部查询。
权威服务器通常不是访问者的内容过滤检查点。它发布的是域名的记录，而不是应用访问者的网络规则。
诊断问题： 该服务器是在根据其负责的记录进行回答，还是代客户端查找记录？
提出这个问题，比盲目假设每个标记为 DNS 的服务器都执行相同的工作更有价值。
递归查询如何遍历 DNS 层级结构
假设要查询 www.example.com，但设备及其解析器都没有回答所需的信息。
设备发送递归查询，向其解析器索取最终结果。解析器通常向上游发起迭代查询：根和顶级域名服务器提供转接引荐，而权威服务器则提供所请求的记录。
此图表展示了进行单独交互之前的整体流程。
关注请求与回答
设备联系其配置的解析器。 它发送网站名称，因为在联系目的地之前它需要获得一个地址。
解析器检查其缓存。 可用的缓存答案会立即结束搜索。没有理由向上游服务器查询解析器仍可重复使用的信息。
未命中缓存时，它会询问根服务器。 根服务器会将请求引导至负责相关顶级域名（在此例中为 .com）的服务器。
它询问 .com 服务器。 该服务器会识别 example.com 的权威名称服务器，从而将搜索范围缩小至该域名的指定权威服务器。
它查询权威服务器。 权威服务器返回请求的地址记录及其以秒为单位表示的 TTL。
它存储并返回答案。 解析器保留一份可重复使用的副本，并将结果发送至设备。
后续请求可以使用该缓存副本。 只要答案保持有效可用，解析器就无需为相同的名称和记录类型重复上游查询过程。
这种层级结构分担了责任。根服务器识别顶级域名权威，这些权威识别域名服务器，而域名管理员维护目标记录。
缓存的回复仍然属于合法的回复
解析器的回复通常是非权威的。这意味着它在转播信息，而不是作为域名的权威服务器进行回答，但这并不意味着答案不可信。
某些部署会将请求转发给上游递归服务，由其代为执行此工作。此外，带有缓存引荐的解析器可以跳过图中所示的部分流程。
本地缓存规则同样重要。APNIC 来自 RIPE 91 的笔记 指出，经常观察到的解析器最大缓存定时器为 6 小时、12 小时、24 小时和 7 天，这表明管理员不应假设每个解析器都遵循相同的缓存限制。
如需从另一个角度了解查询过程，此视频展示了完整的 DNS 解析流程。
缓存、TTL 与变更生效所需的时间
某个域名在 9:00 被阻断，而同一网络上的笔记本电脑在 9:40 仍能打开它。这种时差源于重用。TTL 的工作原理就像停车票上的到期时间：它告诉解析器在必须返回上游重新询问之前，可以继续分发已存储答案的时长。
对于普通的缓存记录，关键的指标是剩余生存时间。解析器的最大缓存定时器可以缩短该生存时间，而在本地强行实施的最小值则可以延长该生存时间。根据 APNIC 从 RIPE 91 记录的要点，观察到的解析器最大值包括 6 小时、12 小时、24 小时和 7 天。这些设置决定了记录的新鲜度。只有当过滤设计依赖于刷新 DNS 应答而非检查当前策略时，它们才会决定拦截生效所需的时间。
缓存设置及其对新封锁规则的意义
| 缓存设置 | 典型值 | 对新拦截或变更的影响 |
|---|---|---|
| TTL 为 0 秒 | 无复用生存时间 | 在常规 TTL 处理机制下，下一次请求将触发上游查找 |
| 短 TTL | 数秒至数分钟 | 记录变更在每次刷新后很快便会生效 |
| 解析器最大缓存定时器 | 6 小时 | 限制 TTL 更长的记录的保留时间 |
| 解析器最大缓存定时器 | 12 小时 | 在半天时间点截断更长的记录 TTL |
| 解析器最大缓存定时器 | 24 小时 | 允许回复隔夜保留，最长可达一整天 |
| 解析器最大缓存定时器 | 7 天 | 仅在记录 TTL 亦允许的情况下，才许可长达一周的保留时间 |
将记录变更与策略变更区分开来
假设在解析器缓存旧应答一分钟后，网站的权威地址发生了变更。该解析器可以继续返回旧地址，直到有效生存时间结束 - 即记录 TTL 与解析器自身最大值中的较小者（并根据强行实施的最小值进行调整）。在 24 小时的记录 TTL 和 6 小时的上限下，用户将在 6 小时内访问到新地址。在 7 天的记录 TTL 和 7 天的上限下，用户可能需要等待整整一周。
现在地址保持不变，但安全团队将该域名标记为恶意。在提供缓存答案前重新检查当前策略的解析器会在下一次查询时拦截该域名。如果设计为仅在答案刷新时才重新评估，则该路径在剩余的有效寿命内都处于开放状态，如果上限为 24 小时，这可能意味着一整天的风险暴露。
实用准则：询问解析器何时刷新其 DNS 应答以及何时重新评估其过滤决策。变更将在两者中较晚的时间点生效于用户。
对于紧急变更，请测试先前查询过的域名以及未缓存的域名。请将缓存命中率、上游查询量和策略更新分发情况作为独立指标进行监控。快速的新查询并不代表用户仍持有缓存的答案。
解析器端的过滤与安全
解析器可以在设备发起连接之前对接收到的查询应用规则。但单靠递归无法提供这些规则。内容分类、威胁情报和 DNS 真实性检查属于独立的功能。
内容过滤设定访问规则
基于类别的 DNS 过滤 允许网络所有者决定用户可以访问哪些目的地。例如，家庭游乐场地可以限制访客 WiFi 上的成人内容，同时对管理网络保持不同的规则。
在设备打开网站或应用之前，它会询问 DNS 在何处找到该站点或应用，而我们会根据设备所在网络的策略予以应答。这使得网络的身份识别变得极为重要，而不单单是所请求的域名。
即使由同一个服务提供，其主要功能也是截然不同的。
威胁防御评估目的地
威胁控制功能可以拒绝针对已知钓鱼网站和恶意软件域名的查询。我们的威胁防御还会从查询阶段阻断受感染设备的命令与控制 (C2) 回呼，从而防止尝试通过该解析路径建立连接。
这是十分有用的遏制措施，但它并不能从设备中清除恶意软件。端点防护和防火墙控制仍然各有其责。
DNSSEC 验证真实性而非安全性
DNSSEC 验证使用配置的信任锚和密码学签名链来验证已签名的 DNS 数据。RFC 4033 描述了安全验证，并指出支持安全的解析器在选择缓存生存时间时应考虑签名的有效性，同时考虑到时钟误差。
因此，管理员需要精准的系统时间和保留验证状态的缓存处理。解析器必须将合法的未签名数据与验证失败的已签名数据区分开来。
- 早期控制：过滤可以在连接开始前阻止不必要的查找，但仅限于使用该解析器的请求。
- 一致的规则：使用相同网络策略的设备将获得一致的处理，但替代解析路径需要单独的控制。
- 真实性检查：DNSSEC 有助于检测伪造的已签名应答，但不会加密查询或判断域名是否为恶意域名。
即使经过正确签名，网络钓鱼域名仍然是网络钓鱼域名。过滤机制决定是否应允许访问；而 DNSSEC 则用于确认已签名的 DNS 信息是否真实。
服务中断、陈旧的解析结果与常见误区
访客在其权威 DNS 服务器无法访问时打开某个网站，但页面仍能成功加载。解析器可能拥有未过期的缓存答案，因此本次请求无需联系该权威服务器。
当上游服务器不可用时，某些解析器还可以在普通到期后提供陈旧应答。这是一种可用性策略，而非 DNS 记录无限期保持最新的证据。Cloudflare 的 DNS 说明文档 提供了检索信息的解析器与提供信息的权威服务器之间的根本区别。
已缓存的答案解释了为什么权威服务器中断并不总是会导致即时网页浏览中断。
可用性和保护需要明确的选择
解析器也可以缓存失败的结果。负缓存保留诸如名称不存在之类的信息，从而避免对同一个不存在的名称进行重复搜索。在管理员创建该名称后，某些客户端可能会继续收到已缓存的负面结果，直到其过期。
故障处理引发了一个单独的策略问题。故障打开 (fail-open) 过滤设计在正常策略检查不可用时允许进行解析。故障关闭 (fail-closed) 设计则会拒绝其无法批准的请求，从而保持限制，但可能会中断合法的访问。
DNSSEC 验证失败是另一种特殊情况。管理员不应仅仅为了保持页面加载而将无效的签名数据视为已验证。
导致操作失误的主观假设
- 递归自动意味着拦截：递归负责检索应答；管理员通过策略层添加拦截。
- DNS 过滤器能控制每个连接：硬编码的目标地址和某些 VPN 路径完全可以绕过受保护的查找。
- 更改网络 DNS 可立即迁移每个客户端：现有设置、DHCP 租约和浏览器级别的解析器选择可能会使设备保留在其他路径上。
在排查故障时，请区分不可达的权威服务器、过期的记录、否定应答、验证失败和策略拒绝。它们在访客看来可能相似，但需要不同的修复方案。
递归负责传递解析结果。而策略和韧性则决定网络在不断变化的环境下将提供哪些解析结果。
在更改网络使用的解析器之前，请先进行确认
如果您询问什么是递归 DNS是因为即将对生产网络进行变更，请首先绘制当前路径图。请记录可正常工作的配置，以便在测试暴露内部名称或应用程序依赖项时能够予以恢复。
在上线前检查路径
- 查找设备配置的 DNS 服务。 使用其网络设置或 DNS 查询工具。路由器地址可能代表转发服务，因此也需要追踪其上游目的地。
- 检查 DHCP 和控制器设置。 确认网络广播的是哪个解析器，以及手动配置的客户端是否遵循该设置。
- 拟定所需的策略。 明确内容类别、恶意软件控制、查找日志记录，以及员工与访客访问权限之间的差异。
- 选择可接受的更新行为。 指定可承受的记录刷新和策略更新延迟，以及针对服务故障的预定响应方式。
- 在局限网络中试点。 在扩大更改范围之前，先测试允许的网站、拦截的目的地、内部资源以及故障恢复。
部署是在控制器上进行的针对每个网络的 DNS 设置或 DHCP 变更，客户端设备上无需安装任何内容。这适用于遵循网络 DNS 配置的设备，但并不能保证每个应用程序都使用该配置。
请测试 VPN 和 DNS over HTTPS，它们可能会创建替代解析路径。我们的团队将在试用前展示网络如何处理 VPN 和加密 DNS。
当网络需要在建立连接前进行过滤，且所有者接受其缓存和故障行为时，带有策略的递归解析器是正确的选择。
Purple Shield 为访客和公共 WiFi 提供防护性 DNS、内容过滤、威胁防御以及 DNS 层级的广告拦截，无需在设备上安装代理。请访问 Purple Shield，共同讨论您网络的解析器路径、您所需的策略，以及如何在推广 DNS 变更前测试实施效果。