欢迎，来自IP地址为：216.73.216.112 的朋友
DNS （Domain Name System）域名系统将域名（例如 example.com）转换为 IP 地址（例如 192.0.2.1），以便我们轻松访问网站。在本文中，我们将了解 DNS 解析的启动过程、其分步流程、缓存的工作原理，以及根域名服务器、顶级域名服务器和权威域名服务器的作用。
DNS 解析过程
当我们在浏览器中输入域名（例如 example.com）时，网站几乎会立即加载。那么它是如何做到的呢？
DNS 解析实现了这一点，它就像互联网的 GPS 一样，将域名转换为计算机用来查找服务器的 IP 地址（例如 192.0.2.1）。
DNS 解析的工作原理是向一系列 DNS 服务器发送查询请求，每个服务器都会帮助精确定位地址。此过程始于一个关键步骤：我们的设备需要知道首先要联系哪个 DNS 服务器，是自动设置的服务器，还是根据速度和可靠性自行选择的服务器。
首选 DNS 服务器：默认设置、DHCP 和手动设置
要使 DNS 正常工作，设备必须知道至少一个 DNS 服务器的 IP 地址。这可以通过预配置设置、DHCP 自动配置和手动配置来实现。
路由器、智能手机和计算机等设备通常附带硬编码的 DNS 服务器 IP。常见示例包括 Google 公共 DNS（8.8.8.8、8.8.4.4）和 Cloudflare DNS（1.1.1.1）。这些 IP 地址作为 DNS 查询的默认起始点。
此外，当设备连接到网络（例如家庭 Wi-Fi）时，动态主机配置协议 (DHCP) 服务器（通常位于路由器上）会分配 IP 地址和 DNS 服务器地址。这些地址通常由互联网服务提供商 (ISP) 提供，但可以使用 OpenDNS（208.67.222.222）或 Quad9（9.9.9.9）等其他 DNS 服务商作为替代方案。
高级用户可以手动指定 DNS 服务器。公共 DNS 提供商为了简化操作，会使用易于记忆的 IP 地址，例如 Google 的 8.8.8.8（重复数字）、Cloudflare 的 1.1.1.1（短序列）或 Quad9 的 9.9.9.9（重复数字）。
这种设计通过 DHCP 和默认配置，确保大多数用户能够无缝运行，同时允许高级用户选择速度更快或更注重隐私的 DNS 服务。
DNS 解析如何支持应用程序的网络请求
当应用程序（例如 Web 浏览器或后端服务）需要进行网络调用时（例如，用于加载网页的 HTTP 请求、用于微服务通信的 gRPC 调用或用于检索数据的 API 获取），它会触发一系列检查和查询，将域名转换为 IP 地址。此过程旨在提高效率，利用缓存和分布式服务器网络来处理互联网的海量规模。
1. 有效 IP 检查
该过程首先检查目标地址是否已经是有效的 IP 地址，例如 192.168.1.1。系统会使用正则表达式检查来确认这一点。如果是有效的 IP，则无需进行 DNS 解析，网络调用将直接进行。
需要注意的是，在某些情况下，如果直接使用 IP 地址，DNS 解析将被完全跳过。例如，用户可能会在浏览器中手动输入 IP 地址（例如 192.0.2.1）而不是域名。虽然这样可以直访问目标服务器，但这并不是一个好方案，因为引入域名系统的目的就是为了方便记忆需要访问的目标服务器，理论上来讲，我们记住一个域名比直接记忆它对应的 IP 地址要容易的多。
同样，有些应用程序会直接使用 IP 地址进行网络调用，从而绕过 DNS 的依赖。
2. 应用程序缓存查找
如果目标地址是域名（例如 example.com），应用程序会检查自身的 DNS 缓存（如果有）。
Chrome 和 Firefox 等现代浏览器内置了缓存以加快浏览速度。如果此时可以找到域名到 IP 的映射，则该过程将停止，并使用该 IP 进行网络调用。
3. 操作系统缓存检查
如果应用程序缓存中缺少映射，或者应用程序根本没有缓存机制，则请求将转移到操作系统的 DNS 客户端（也称为本地解析器）。
不同操作系统会有所不同：
- Windows 使用 dnscache
- macOS 使用 mDNSResponder
- Linux 使用 Name Switch Service
DNS 客户端会检查两个地方：操作系统级别的 DNS 缓存（用于存储最近的域名到 IP 的映射）和 hosts 文件（用于手动将域名映射到 IP 的本地文件，例如 127.0.0.1 localhost）。如果在任一地方找到映射，则该过程在此处停止。
4. 转发请求到已配置的 DNS 服务器
如果映射仍未解析，DNS 客户端会将查询发送到已配置的 DNS 服务器，例如 ISP 的服务器或公共服务器，例如 Google DNS (8.8.8.8) 或 Cloudflare DNS (1.1.1.1)。该服务器是一个复杂的系统，拥有自己的缓存和一个递归解析器服务（例如 BIND 或 Unbound），后者负责接管查询。
缓存技术
- 缓存：尤其是在递归解析器中，用于存储查询结果，以最大限度地减少冗余查找并加快用户响应速度
- 递归解析器缓存：在递归解析器中存储来自根域名服务器、顶级域名服务器和权威域名服务器的查询结果，以加快响应速度
- 负向缓存：存储不存在的域名或记录的响应，以避免重复查询
- 转发查询缓存：存储转发到其他解析器或 DNS 服务器的查询响应，以提高性能
这些缓存机制可最大限度地减少外部查找 (RFC 1035)。
5. 跨服务器递归解析
递归解析器是 DNS 服务器的核心组件，负责执行递归解析，将像 example.com 这样的域名转换为 IP 地址。
由于 DNS 记录分布在多台服务器上，解析器会解析域名并执行一系列查询：
- 它会联系根域名服务器，后者会将其定向到顶级域名 (TLD) 服务器（例如 .com）
- TLD 服务器指向特定域名的权威域名服务器
- 权威服务器提供最终的 IP 地址
这种分布式方法确保了可扩展性和可靠性（RFC 1035）。
理解递归解析器的作用
递归解析器是 DNS 解析背后的引擎，负责将像 example.com 这样的域名转换为 IP 地址。它的旅程始于查询根域名服务器，这是在 DNS 层次结构中查找正确地址的第一步。
递归解析器与根域名服务器的交互
为了理解这种交互，我们首先来探讨一下什么是根域名服务器以及它们在 DNS 中的作用。
根域名服务器是构成 DNS 层次结构的基础，负责响应顶级域名 (TLD) 记录的查询并启动解析。它们将递归解析器引导至 TLD 服务器，从而实现对域名 IP 地址的查找。
- 共有 13 个根服务器集群，分别名为 a.root-servers.net 至 m.root-servers.net，由 12 个组织运营（VeriSign 管理两个）。这些集群负责分担全球 DNS 查询负载。截至 2025 年 5 月 10 日，1,936 个任播实例确保了高可用性和可扩展性，每日可处理数十亿次查询（数据来源：根服务器技术运营协会 (Root Server Technical Operations Association)）
- 每个集群都使用任播路由，在多个全球服务器之间共享一个 IP 地址。查询会被路由到最近或负载最低的实例，从而降低延迟、提高可靠性，并在服务器发生故障时提供冗余
- 由 ICANN（IANA）提供的根提示文件列出了根服务器的 IP 地址，并已预加载到解析器中。它支持在无需解析根服务器域的情况下进行初始 DNS 查询，从而避免了循环依赖并确保了系统稳定性
DNS 诞生于 1983 年，当时只有两台根域名服务器。随着互联网的发展，为了满足需求，DNS 增加了更多服务器。到 2002 年，服务器数量达到 13 台，并提出了任播路由，允许多台服务器以单个集群的形式在一个 IP 地址下运行。此后，DNS 通过扩展这 13 个集群来满足全球需求（RFC 882，Netnod）。
递归解析器如何查询根域名服务器
递归解析器通过查询根域名服务器的 TLD 记录来启动解析，并依赖多种机制来确保准确性和效率。
- 它使用根提示文件（ICANN 的根服务器 IP 地址列表，该列表硬编码在解析器（例如 BIND）中）来避免循环依赖
- 启动查询会在解析器启动或缓存到期时获取更新的根服务器 IP，以确保可靠性 (RFC 8109)
- 根区域文件（ICANN 的 TLD 及其域名服务器数据库）供根服务器使用，用于响应 TLD 详细信息 (IANA)
查询时，解析器会选择一个根服务器并请求 TLD 记录（例如：.com 的 TLD 记录）。响应包含 NS 记录（例如：.com 的 TLD 记录为 a.gtld-servers.net）和粘合记录，后者是 IP 地址记录（A 或 AAAA），直接提供 TLD 域名服务器的 IP 地址。
当请求的域名服务器的域名位于被查询的域名内时（例如，example.com 的 TLD 记录为 ns1.example.com），粘合记录至关重要，因为它可以通过提供 IP 地址而不解析域名来避免循环依赖。
对于 TLD 查询，始终包含粘合记录，通过避免对 a.gtld-servers.net 等 TLD 域名服务器域名进行额外查找来加快解析速度，尤其是对于像 .com 这样繁忙的 TLD（RFC 1035）就是显得更为重要。
递归解析器与 TLD 服务器的交互
递归解析器收到根服务器的响应（包含粘合记录）后，会查询 TLD 域名服务器（例如，查询 a.gtld-servers.net 查询 .com）。TLD 域名服务器维护区域文件，列出其 TLD 下的域名（例如，查询 example.com）及其对应的域名服务器。
TLD 服务器会返回一个引用，提供权威域名服务器记录（例如，查询 example.com 的 ns1.example.com）。如果权威服务器的域名位于请求的域名范围内（例如，ns1.example.com），则会包含粘合记录以直接提供 IP 地址，从而避免循环依赖。
解析器会根据响应的 TTL 缓存响应，以加快后续查询速度。如果 TLD 服务器无法访问，则会尝试从根服务器的响应中获取另一个 TLD 服务器（RFC 1035）。
递归解析器与权威域名服务器的交互
- 递归解析器随后会查询权威域名服务器（例如 ns1.example.com），该服务器维护其域名（例如 example.com）的区域文件，其中包含 A、CNAME 或 MX 等 DNS 记录
- 服务器会根据查询返回请求的记录，例如 A 记录（例如 192.0.2.1）、AAAA、CNAME 或 MX
- 如果服务器位于域名内，TLD 响应中的 Glue 记录会提供服务器的 IP 地址，从而避免循环依赖
- 为了提高效率，解析器会根据 TTL 缓存响应。在极少数情况下，服务器可能会委托给另一个权威服务器（例如，对于子域名），从而需要进一步查询。如果无法访问，解析器会尝试其他权威服务器（RFC 1035）
传统上，根域名服务器、顶级域名服务器和权威域名服务器的区域文件都是文本文件，列出了域名及其 DNS 记录，用于指导跨 DNS 层次结构的查询。
现代 DNS 基础设施已将这些文本文件替换为高效的数据库或内存数据库，并使用哈希表或树状结构等优化的数据结构来提高查找速度和可扩展性。这种转变支持所有服务器类型中不断增长的顶级域名数量和高查询量。
同样，为提高速度和可靠性而提出的任播路由提案，也适用于所有域名服务器——根域名服务器、顶级域名服务器和权威域名服务器。
虽然根域名服务器普遍采用任播，以确保低延迟和冗余，但并非所有顶级域名服务器和权威域名服务器都严格遵循该提案。
由于成本或运营限制，一些顶级域名服务器和较小的权威服务器依赖于单播或有限的任播，导致整个 DNS 层次结构的性能存在差异。
域名注册商和新域名的 DNS 设置
什么是域名注册商？
域名注册商最初设立的目的是管理域名注册，允许个人和组织为网站和在线服务获取唯一的域名（例如 example.com）。它们充当域名所有者和域名注册局之间的中介，而域名注册局则维护着 .com 或 .org 等顶级域名 (TLD) 的权威数据库。
注册商负责处理域名注册、续费和更新 DNS 设置等任务，确保与全球 DNS 系统无缝集成。许多注册商还提供其他服务，例如网站托管和 SSL 证书，以支持网站运营。
GoDaddy 和 Hostinger 等众多注册商以其用户友好的平台和全面的服务而闻名。
购买新域名时，DNS 系统会发生什么？
当我们通过 GoDaddy 或 Hostinger 等注册商购买新域名（例如 example.com）时，DNS 系统会执行以下步骤：
- 步骤 1：向注册局注册 – 注册局将我们的域名详细信息发送给顶级域名 (TLD) 的注册局（例如，.com 的注册局由 VeriSign 负责）。注册局将域名添加到其数据库中，记录注册局作为管理实体以及指定的权威域名服务器（例如，ns1.example.com）
- 步骤 2：域名服务器配置 – 我们可以在注册局的控制面板（例如，GoDaddy 的域名组合或 Hostinger 的 hPanel）中配置域名的域名服务器。这些域名服务器通常由注册局或托管服务提供商提供（例如，ns1.hostinger.com），它们指向包含域名 DNS 记录的 DNS 区域文件
- 步骤 3：DNS 区域设置 – DNS 区域文件（在域名服务器指向的位置进行管理）会使用以下 DNS 记录进行更新：
- A 记录：将域名（例如 example.com）映射到托管服务器的 IP 地址（例如 192.0.2.1）
- CNAME 记录：将子域名（例如 www.example.com）别名化为其他域名
- MX 记录：将电子邮件定向到邮件服务器
如果使用注册商的主机，这些记录可能会自动设置。否则，则需要手动配置它们，使其指向我们的主机提供商的 IP。
- 步骤 4：DNS 传播 – 更新域名服务器或 DNS 记录后，更改将传播至全球 DNS 网络，由于缓存和服务器更新，这可能需要 24-48 小时。在此期间，使用新域名的网站可能无法立即访问
- 步骤 5：TLD 注册管理机构更新 – 注册管理机构会更新其记录，以包含域名的域名服务器，这些服务器在 DNS 查找过程中由递归解析器查询。对于域名服务器位于同一域中的域名（例如，ns1.example.com 对应 example.com），会在注册管理机构注册粘合记录（域名服务器的 IP 地址），以防止循环依赖
域名系统 (DNS) 将域名转换为 IP 地址，使互联网更加便捷。它通过分层系统和缓存高效地解析查询，从 1983 年的几台根服务器发展到如今可扩展的、由任播驱动的网络服务。
