什么是 DNS 查找以及网络为何使用它

DNS 查找是解析器查找与人类可读域名关联的信息（最常见的是 IP 地址）的过程。经典的查找流程会检查本地信息、寻找最佳服务器、向其查询答案，然后返回并缓存结果。

您可能正在酒店、学校或医院的 WiFi 网络上阅读本文，并刚点击了一个熟悉的网站。您的设备已建立连接，但在页面加载之前，网络需要找到该网站所在的位置。请将 DNS 视为一个帮助您的设备定位服务的分布式目录，而不仅仅是一个网站电话簿。

这种区别在共享 WiFi 环境中至关重要。处理查询的解析器会影响网页加载的速度、特定域名是否被封锁，以及场所网络能否查看或管理该查询。加密性、真实性、策略实施和匿名性是彼此独立的属性，混淆这些概念可能会导致错误的安全决策。

目录

• DNS 查询的实际工作原理
  • 是目录查询，而非页面请求
• DNS 查询内部的各个阶段
  • 缓存命中或缓存未命中
  • TTL 保持缓存解析结果最新
• 让查询具备扩展能力的层级结构
  • 根系统如何演进发展
• 为什么 DNS 查询是一个执行点
  • DNS 策略能够与不能覆盖的内容
• 加密 DNS 真正改变了什么
  • 共享 WiFi 网络上的权衡取舍
• 当共享 WiFi 上的 DNS 查询失败时
  • 在更改设置之前先区分具体症状
• 接下来如何选择保护性 DNS
  • 比较策略与运营契合度

DNS 查询的实际工作原理

宾客在酒店 WiFi 网络上点击了一个链接。浏览器知道域名，但网络设备使用 IP 地址路由流量。DNS 查询就是解析器寻找与该易读名称相关联的信息（通常是 IP 地址）的过程，以便设备可以开始访问该服务。

使用电话簿是一个很好的初步比喻，但 DNS 更像是一个分布式实时目录。不同类型的记录支持邮件投递、别名、服务发现、反向查询以及其他网络功能。DNS 不仅仅是将网站域名映射到地址，它还能帮助应用程序查找一系列网络服务。

基础 DNS 规范出现在 1987 年 11 月，当时互联网工程任务组发布了 RFC 1034。该文档描述了一个四阶段算法：检查本地信息、查找最佳服务器、向其发送查询直到收到响应，并在适当情况下返回并缓存结果 (RFC 1034)。缓存非常重要，因为解析器可能已经拥有来自先前请求的可用答案。

是目录查询，而不是页面请求

当您的设备请求一个域名时，它并不是要求 DNS 传输网页，而是请求有助于应用程序连接相关服务的信息。随后浏览器会将该答案作为其连接过程的一部分。

在访客 WiFi 上，这使得查询成为一个极具价值的共享决策点。解析器在返回 IP 地址前会先获取所请求的域名，因此网络运营商可以利用这一时机来实施相关策略。有关 DNS 问题如何影响网络可用性的实际概述，请参阅此指南，了解如何 防止因 DNS 故障导致的网络中断。

了解这一过程有助于跟踪查找的去向，明白为什么缓存答案速度更快，并认识到 DNS 在共享 WiFi 上可以和不可以控制什么。速度、策略、加密和查找失败互相关联，但它们并非同一个问题。

DNS 查询内部的各个阶段

酒店住客在浏览器中输入 example.com 并按回车键。页面尚未加载。在此之前，域名需要通过一系列固定的查找步骤，而在共享 WiFi 上，每一步都会给场所网络提供一个新的机会来观察或引导该请求。

设备的存根解析器（stub resolver）通过将递归查询传递给缓存解析器来启动该流程。场所、互联网提供商或独立 DNS 服务都可以运营该解析器，而这一选择至关重要，因为它决定了谁最先看到该查询。

缓存命中或缓存未命中

缓存解析器首先检查其内存。仍然有效的记录会直接返回，这种 缓存命中 会跳过所有上游交互。缺失或过期的记录则属于 缓存未命中，随后解析器会通过 DNS 层级进行查询：根服务器将其指向正确的顶级域名，TLD 服务器将其指向该域名的权威名称服务器，最终由该名称服务器返回记录。

对于网站而言，答案通常是包含 IPv4 地址的 A 记录，或者是包含 IPv6 地址的 AAAA 记录。其他记录类型则涵盖邮件路由和别名等工作。

各个阶段涉及完全不同的问题。加密决定了谁可以在传输过程中读取查询。真实性决定了答复是否来自域名的运营方。策略决定了解析器是否会返回该答复。而匿名性则决定了哪些参与方最先得知了该名称。

TTL 保持缓存答案的最新状态

每个记录集都带有生存时间 (TTL)，即解析器可以保留它的最长时间。解析器必须在到期时丢弃该记录，从而使更新后的地址和策略重新进入流通。

一位住客的缓存未命中会预热后续访客的缓存。较短的 TTL 可以让变更更快生效；较长的 TTL 则能减少重复的上游查找。区域运营商在该权衡中做出选择，共享网络上的每个人都会继承这一结果。

某些网络会在该流程中插入一个转发步骤，将查询发送至另一个解析器，而不是直接逐级查询层级结构。这篇关于 DNS 转发如何改变路径 的指南解释了该迂回步骤发生的位置。

使查找具备可扩展性的层级结构

DNS 层级结构划分了管理职责。最顶层是根服务器身份，负责指引解析器找到正确的顶级域名。TLD 服务器处理诸如 .com 和 .org 等域名，而每个域名的权威服务器则提供该域名内具体名称的记录。

关于 13 台根服务器 的常见形象可能会让人产生误解。历史上一共定义了 13 个标识，分别标注为 A 到 M，由 12 个独立组织 负责运营。它们并不只是 13 台物理计算机。Anycast 选路技术允许从 全球 900 多个分布式实例 为相同的标识提供服务，有助于查询请求就近接入并增强网络韧性（参阅 ICANN 的根服务器概览）。

根系统是如何发展的

根系统随着网络需求的变化而发展。第一台根服务器于 1984 年 在南加州大学信息科学研究所建立。该系统在 1985 年 拥有 4 台服务器，1987 年 达到 7 台，1993 年 达到 9 台，到 1997 年 扩展至 13 台。如今，根系统同时支持 IPv4 和 IPv6。一份技术概览指出了 26 个主要地址端点（每种协议 13 个）以及分布式的 Anycast 实例。

这些数字阐述了架构的不同组成部分。13 个身份是指可识别的根服务器名称；地址端点同时支持 IPv4 和 IPv6；分布式实例则有助于从全球各个地点提供服务。失去对某一个实例的访问权限，并不等于在所有地方都失去了对根身份的访问。

正是这种设计使得查找即使依赖于全局多级系统，体验上也像是在本地进行。解析器可以访问附近的实例，而层级结构继续将责任分发给根、TLD 和权威运算符。

为什么 DNS 查找是一个执行点

酒店 WiFi 上的笔记本电脑在访问任何内容之前，都需要向网络的解析器查询域名。该请求会通过场所控制的设备，这使得域名查找成为设备独立建立连接之前的最后一个共享决策点。防护性 DNS 服务可以正常应答、拒绝查询，或者返回一个指向空处的响应。如果没有返回可用的地址，连接通常根本不会开始。

正是这种地位赋予了 DNS 策略在访客网络上的覆盖能力。访客的手机和笔记本电脑很少安装管理软件，因此场所无法在设备本身上安装控制措施。解析器是每个设备都会经过的唯一检查点。在此处应用的策略可以阻止与网络钓鱼、恶意软件或命令与控制流量相关的域名，强制执行成人内容或赌博等类别限制，并应用安全搜索设置。

时间节点进一步增强了这一优势。策略实施发生在请求阶段，即应用程序通过该解析器获取地址之前。如需了解网络其他层级的防护措施，请参阅这份 保护 Microsoft 365 商业网络 指南。

DNS 策略可以和不能涵盖的内容

DNS 强制执行仅管理名称解析，而连接可以绕过它。应用程序可能会重用缓存地址、直接联系 IP、访问从未用过 DNS 名称的服务，或者通过场所未分配的加密解析器发送查询。

因此，运营商在进行过滤时，需要综合考量加密 DNS 行为、应用缓存以及直连 IP 流量。DNS 过滤只是更广泛控制体系中的一个层级。有关 DNS 过滤以及策略如何应用于查询 的指南对过滤机制的作用进行了详细说明。

策略也只是信任的一个维度。域名是否被允许、响应是否真实，以及是否有人可以在传输过程中读取查询，这些都是独立的问题，由不同的机制解答。

否定回答同样值得关注。解析器可以缓存 NXDOMAIN 响应（即表明所请求的域名不存在），而不是再次向上游服务器询问相同的缺失名称。RFC 8020 描述了 NXDOMAIN 截断，其中经验证的否定回答同样确认了缺失域名之下的名称不存在（参阅 RFC 8020）。最新的 IETF 指南还要求对解析失败进行缓存，从而减少无谓的重复查询。

加密 DNS 究竟改变了什么

当访客连接酒店的 WiFi 并访问网站时，DNS 查询是建立连接前的最后一个共享决策点：设备向解析器询问要使用的地址，而解析器可能会应用场所的相关规则。对该请求进行加密改变了传输过程中能够读取请求内容的主体。但这本身并不会改变解析器可以查看的内容，也不会使访客实现匿名化。

设备将查询发送至递归解析器，由其查找答案并予以返回。DNS over HTTPS (DoH) 会对设备与该解析器之间的连接进行加密。监视 WiFi 的人员可能难以读取或篡改查询内容，但解析器仍然会接收到请求的域名。

DNSSEC 解决的是另一个独立问题：它允许验证解析器检查已签名 DNS 数据的真实性和完整性。它不会对查询进行加密。加密、真实性、策略执行和匿名性是不同的属性。

共享 WiFi 上的权衡

使用 DoH 的浏览器可能会将查询发送至由浏览器或用户选择的解析器，而非由酒店、学校、医疗机构或公共 WiFi 运营商分配的解析器。这可能会限制场所网络所能查看的内容及其可应用 DNS 规则的范围。如果场所网络依赖于自身的解析器，这还会增加排查故障的难度。

实际效果的区别很明显：DoH 仅保护查询在传输到解析器途径中的安全，它并不能向该解析器隐藏查询内容。DNSSEC 则有助于验证经签署的答复。只有当相关查询通过场所自身控制或集成的解析器时，该场所才能实施 DNS 策略，且这两种技术都无法实现用户匿名。

当 DNS 查找在共享 WiFi 上失败时

两位客人连接到同一个酒店 WiFi。一位能打开熟悉的网站；另一位则看到错误提示，即使两台设备都显示已连接。差异可能在于查找路径、设备的缓存，或者每台客户端所使用的解析器。

解析器可能无法访问、返回不完整的答案，或者无法解析仅存在于组织内部网络中的名称。网络也可能会阻止 UDP 或 TCP 端口 53 上的传统 DNS 流量，或者因策略阻止所请求的域名而故意返回失败信息。

在更改设置之前先区分症状

以学校的内部门户网站为例，该网站可以通过学校指定的解析器正常工作，但无法通过外部公共解析器访问。学校可能使用了分离视图 DNS (split-horizon DNS)，即内部域名仅可通过该网络的解析器进行解析。更改设备的 DNS 设置可能会使公共网站顺利加载，但同时也可能导致无法访问内部门户网站。

加密 DNS 可能会增加另一个故障点。一项 2025 年的研究指出，HTTPS DNS 查询 约占所观测 DNS 流量的 8%，而不完整的响应增加了查询量（参阅 加密 DNS 流量研究）。另一项关于解析器的研究发现，三分之一公布的加密解析器未能回复。因此，即使场所分配的解析器可用，客户端仍可能在使用未按预期响应的加密解析器。

故障排除规则：在要求住客更改 DNS 设置之前，请先确认客户端实际使用的是哪种解析器。

对于运营商而言，请排查可能的原因，而不是对每个查询错误都采取相同的处理方式：

• Captive Portal：设备尚未完成 WiFi 登录或条款页面确认。
• 过期缓存：客户端或解析器保存了过时的解析结果。
• 上游中断：配置的解析器无法完成请求。
• 端口 53 被封锁：传统 DNS 流量被封锁或无法到达解析器。
• 不支持的 DoH 或 DoT：客户端的加密 DNS 行为不受网络支持或管理。
• 策略拦截：解析器故意拒绝提供解析结果。

DNS 错误也可能预示着 WiFi 安全问题，而非解析器问题。有关识别欺诈性接入点的指南，请参阅 RDE Technologies 的恶魔双胞胎防范指南。

下一步如何选择保护性 DNS

连接到您 WiFi 的每台访客设备在建立连接之前，仍必须获取定向信息。网络运营商面临的真正抉择在于由谁来响应这一请求：设备随附的解析器、过时的防火墙规则集，还是由您控制的安全 DNS 服务。在这一最终的共享决策点上，每种选择都会影响您能够实施的策略力度以及能够保留的证据存量。

方案	未管理设备	决策点	运算符证据
客户端选择的解析器	通常在场所的 DNS 策略之外	由设备或浏览器选择解析器	有限的全网可见性
仅靠老旧防火墙	覆盖范围取决于防火墙规则和流量路径	该网络可用的防火墙控制措施	防火墙日志和警报
云端保护性 DNS 解析器	可覆盖使用网络分配解析器的设备	在返回地址之前进行域名查询	来自解析器的查询和拦截报告

正如前面所指出的，对于酒店、教育、医疗、公共部门以及多场所网络，Purple Shield 是一种防护型 DNS 选项。它在连接发起前评估查询请求，应用成人和赌博等内容过滤类别，在 Google、Bing 和 YouTube 上强制启用安全搜索，并拦截命令与控制、钓鱼和恶意软件域名。该供应商还介绍了 AI 辅助信号，旨在比标准黑名单更早地识别新兴威胁，并在 DNS 层提供广告和追踪器拦截功能，从而减轻页面加载重量并减少流量消耗。

比较策略和运维契合度

该服务支持按 SSID、VLAN、场所和时间表制定策略，并提供仪表板、定制品牌拦截页面和故障闭锁（fail-closed）运行模式。其服务说明指出，它不需要客户端代理或防火墙更改，列出了已发布的运行时间 SLA，并与 Friendly WiFi 和 Internet Watch Foundation 标准保持一致。请将这些视为供应商的声明，并根据您自身的报告和韧性要求进行衡量。

DNS 过滤也仅解决了安全问题的一部分。加密向路径上的观察者隐藏了查询，真实性检查确认了答案来自正确的解析器，策略决定是否给予应答，而匿名性则取决于谁在运营该解析器。安全 Web 网关 可能会覆盖该技术栈的更多层面，因此在做出选择之前，请先对比这两个角色的差异。

首先选择一个访客 SSID。记录其设备当前使用的解析器，然后在该网络上测试 Purple Shield，最后再将策略扩展到所有场所。