DNS 的工作原理
了解 DNS 如何将域名转换为 IP 地址，以便客户端能够找到并连接到服务。
DNS 为什么存在
人类用域名思考，但计算机使用 IP 地址进行通信——DNS 连接了这两者之间的差距。
- 人类更喜欢像 google.com 这样的可读名称，而不是数字形式的 IP 地址。
- 网络使用诸如 142.250.x.x 这样的 IP 地址来路由流量。
- DNS 将域名转换为 IP 地址，这样通信才能开始。
详情
当你在浏览器中输入一个域名时，你的计算机不能直接使用这个名称在互联网上发送数据。路由器不理解文字——它们根据数字形式的 IP 地址转发数据包。
例如，输入 google.com 最终必须解析为类似 142.250.190.14 的地址。这个 IP 地址标识了全球网络中的目标服务器。
如果没有这种翻译系统，每个用户都需要记住他们使用的每一项服务对应的 IP 地址。这在互联网规模下显然是不现实的。
域名系统（DNS）充当互联网的分布式电话簿。它将人类可读的名称映射为机器可读的 IP 地址，从而让通信真正开始。
DNS 在请求生命周期中的位置
DNS 解析发生在任何 TCP 连接或 HTTP 请求之前。
- DNS 必须先将域名解析为 IP 地址。
- 没有目标 IP，TCP 无法建立连接。
- HTTP 完全依赖于 DNS 之后创建的连接。
详情
当你在浏览器中输入一个 URL 时，系统不能立即发送 HTTP 请求。它首先需要知道要把这个请求发送到哪里。
DNS 解析是最先进行的网络步骤。浏览器会询问：“这个域名对应哪个 IP 地址？”只有在收到 IP 地址之后，系统才能与目标服务器发起 TCP 握手。
这个顺序是严格的：
DNS → TCP 连接 → HTTP 请求 → 服务器响应
如果 DNS 失败，整个过程会立即停止。不会有连接尝试、不会有加密协商，也不会有应用层通信。DNS 是请求生命周期中让其他一切得以开始的入口。
递归 DNS 解析：完整流程
如果 IP 地址没有缓存在本地，DNS 解析就会变成一次跨越全球 DNS 层级的多步骤递归查询。
- 系统会在查询外部 DNS 服务器之前检查多个缓存。
- 递归解析器会代表客户端执行分层查询。
- 解析流程从 Root → TLD → Authoritative server → 再返回客户端。
详情
当你请求一个域名时，浏览器不会立即联系全球 DNS 基础设施。它会先检查本地来源：
- 浏览器缓存
- 操作系统缓存
- 路由器缓存
如果没有缓存结果，请求会被发送到一个递归 DNS 解析器，通常由你的 ISP 或像 8.8.8.8 这样的公共服务提供商运营。
然后解析器会执行分层查询：
- 它会询问一个 Root server：“我在哪里可以找到
.com？” - Root 会返回对应的 TLD (Top-Level Domain) server 的地址。
- 解析器再询问 TLD server：“
example.com在哪里？” - TLD 会返回该域名的 Authoritative name server。
- 解析器再向 authoritative server 请求实际的 IP 地址。
一旦 authoritative server 返回 IP，解析器就会把它发送回客户端，并将其缓存起来供以后使用。
整个过程通常只需几毫秒，但从结构上看，它涉及多个全球分布的服务器协同工作，才能解析出一个域名。
缓存与 TTL
如果每个查询都要到达根服务器，DNS 会太慢并且负载过高，所以缓存会临时存储结果，以减少重复查找。
- DNS 响应会在多个层级被缓存，以避免重复的全局查找。
- TTL（Time To Live）定义了 DNS 记录可以被存储多长时间。
- 缓存可以显著降低延迟和基础设施负载。
详情
如果每次域名查询都需要联系根服务器、TLD 服务器和权威服务器，DNS 很快就会成为全球瓶颈。
为防止这种情况，DNS 响应会在多个位置被缓存：浏览器、操作系统、路由器以及递归解析器。域名一旦被解析，结果就会被临时保存，这样后续请求就可以跳过完整的递归过程。
每条 DNS 记录都包含一个 TTL（Time To Live） 值，以秒为单位。TTL 告诉解析器在必须从权威来源刷新之前，可以保留该记录多长时间。
较短的 TTL 值允许域名所有者更快地更改 IP 地址，而较长的 TTL 值可以提升性能并减少 DNS 流量。TTL 是灵活性和效率之间的平衡。
缓存就是 DNS 解析通常感觉像是瞬间完成的原因，尽管其底层系统是全球分布式的。
重要的记录类型
不同的 DNS 记录类型定义了域名如何映射到 IP 地址或其他服务。
- A 和 AAAA 记录将域名直接映射到 IPv4 或 IPv6 地址。
- CNAME 创建一个别名，将一个域名指向另一个域名。
- MX 记录定义哪个邮件服务器负责处理某个域名的电子邮件。
详情
DNS 不仅仅是把名称转换为单个 IP。它还存储结构化记录，用来定义不同服务应该如何运行。
A 记录将域名映射到 IPv4 地址（例如，example.com → 93.184.216.34）。
AAAA 记录也执行相同的作用，但用于 IPv6 地址。
CNAME（Canonical Name）记录会创建一个别名。它不是直接指向 IP 地址，而是将一个域名指向另一个域名。这通常用于服务托管在外部平台上的场景。
MX（Mail Exchange）记录指定哪些邮件服务器负责处理某个域名的电子邮件。它包含优先级值，以支持备用邮件服务器。
理解这些核心记录类型，可以解释网站如何解析、别名如何工作，以及电子邮件路由如何通过 DNS 进行控制。
DNS 和负载均衡
DNS 可以通过为同一个域名返回不同的 IP 地址来分配流量。
- 一个域名可以映射到多个 IP 地址。
- 解析器可能使用轮询行为轮换响应。
- DNS 可以根据地理位置路由用户。
详情
单个网站很少只托管在一台服务器上。高流量服务会在不同地区运行多台服务器，以提升性能和可靠性。
DNS 通过将一个域名关联到多个 A 或 AAAA 记录，实现基本的负载分配。当解析器查询该域名时，它可能会以交替顺序返回不同的 IP 地址。这称为 轮询 DNS。
更高级的配置会使用 基于地理位置的 DNS，解析器会根据用户的大致位置返回一个 IP 地址。例如，欧洲的用户可能会被导向欧洲的数据中心，而不是北美的数据中心。
虽然与应用层负载均衡器相比，基于 DNS 的负载均衡相对简单，但它具有全球可扩展性，并且发生在连接建立之前。
因此，DNS 不仅仅是名称转换——它还可以在互联网规模上影响性能、可用性和流量分配。
如果 DNS 失败会发生什么？
如果 DNS 无法解析域名，整个请求生命周期会在建立任何连接之前停止。
DNS 查询
TCP 握手
TLS
HTTP 请求
- 如果域名无法解析，就无法开始任何 TCP 或 HTTP 通信。
- 故障可能发生在解析器、权威服务器，或者由于记录已过期。
- DNS 问题通常会表现为“server not found”或“cannot resolve host”错误。
详情
DNS 是互联网请求生命周期的入口。如果它失败，后续的一切都会自动失败。
常见的失败场景包括：
- 递归解析器不可用或配置错误。
- 权威名称服务器宕机。
- DNS 记录最近已更改，但尚未完全传播。
- TTL 已过期，而新的查询无法获取有效响应。
- 域名本身配置错误，或者已经不存在。
从用户角度看，DNS 失败通常会显示为类似 “DNS_PROBE_FINISHED_NXDOMAIN” 或 “Server not found” 的消息。这些错误发生在任何 TCP 握手或 TLS 协商开始之前。
由于 DNS 在建立连接之前就会运行，它的失败会阻止所有应用层通信。系统无法连接到它无法定位的目标。
问题部分
1 / 5