DNS 及其运行机制

2021-03-09 约 6199 字预计阅读 13 分钟

什么是 DNS？

域名系统 (DNS - Domain Name System) 是 Internet 电话簿。人们通过例如 baidu.com 或 qq.com 等域名在线访问信息。Web 浏览器通过 Internet 协议 (IP) 地址进行交互。DNS 将域名转换为 IP 地址，以便浏览器能够加载 Internet 资源。

连接到 Internet 的每个设备都有一个唯一 IP 地址，其他计算机可使用该 IP 地址查找此设备。DNS 服务器使人们无需存储例如 192.168.1.1（IPv4 中）等 IP 地址或更复杂的较新字母数字 IP 地址，例如 2400:cb00:2048:1::c629:d7a2（IPv6 中）。

DNS 如何工作？

DNS 解析过程涉及将主机名（例如 www.example.com）转换为计算机友好的 IP 地址（例如 192.168.1.1）。Internet 上的每个设备都被分配了一个 IP 地址，必须有该地址才能找到相应的 Internet 设备 - 就像使用街道地址来查找特定住所一样。当用户想要加载网页时，用户在 Web 浏览器中键入的内容（example.com）与查找 example.com 网页所需的机器友好地址之间必须进行转换。

为理解 DNS 解析过程，务必了解 DNS 查询必须经过的不同硬件组件。对于 Web 浏览器，DNS 查找在「幕后」进行，除了初始请求外，不需要从用户的计算机进行任何交互。

DNS 服务器类别

所有 DNS 服务器都属于以下四个类别之一：递归解析器、根域名服务器、TLD 域名服务器和权威性域名服务器。在典型 DNS 查找中（当没有正在进行的高速缓存时），这四个 DNS 服务器协同工作来完成将指定域的 IP 地址提供给客户端的任务（客户端通常是一个存根解析器 - 内置于操作系统的简单解析器）。

DNS 解析器（DNS recursor） - 该解析器可被视为被要求去图书馆的某个地方查找特定图书的图书馆员。DNS 解析器是一种服务器，旨在通过 Web 浏览器等应用程序接收客户端计算机的查询。然后，解析器一般负责发出其他请求，以便满足客户端的 DNS 查询。
根域名服务器（Root nameserver） - 根域名服务器是将人类可读的主机名转换（解析）为 IP 地址的第一步。可将其视为指向不同书架的图书馆中的索引 - 一般其作为对其他更具体位置的引用。
TLD 域名服务器（TLD nameserver） - 顶级域服务器（TLD）可被视为图书馆中的特定书架。此域名服务器是搜索特定 IP 地址的下一步，其托管主机名的最后一部分（在 example.com 中，TLD 服务器为「com」）。
权威性域名服务器（Authoritative nameserver ） - 可将这个最终域名服务器视为书架上的字典，其中特定名称可被转换成其定义。权威性域名服务器是域名服务器查询中的最后一站。如果权威性域名服务器能够访问请求的记录，则其会将已请求主机名的 IP 地址返回到发出初始请求的 DNS 解析器（图书管理员）。

DNS 查找 IP 地址步骤

注意

通常，DNS 查找信息将本地缓存在查询计算机内，或者远程缓存在 DNS 基础设施内。DNS 查找通常有 8 个步骤。缓存 DNS 信息时，将从 DNS 查找过程中跳过一些步骤，从而使该过程更快。以下示例概述了不缓存任何内容时的所有 8 个步骤。

DNS服务器根据域名的层级，进行分级查询。
需要明确的是，每一级域名都有自己的NS（Name Server的缩写）记录，NS记录指向该级域名的域名服务器。

用户在 Web 浏览器中键入 example.com，查询传输到 Internet 中，并被 DNS 递归解析器接收。
接着，解析器向 DNS 根域名服务器（.）发起查询请求。
然后，根服务器返回其域信息的顶级域（TLD）DNS 服务器（例如 .com 或 .net）的 NS 记录和 A 记录给该解析器。例如：在访问 example.com 时，我们的请求指向 .com TLD 服务器。
然后，解析器向 .com TLD 服务器发出请求。
TLD 服务器随后返回域名 example.com 的权威性域名服务器 NS 记录和 A 记录。
最后，递归解析器将查询发送到域的域名服务器。
example.com 的 IP 地址从权威性域名服务器返回到解析器。
然后 DNS 解析器使用最初请求的域的 IP 地址响应 Web 浏览器。

DNS 查找经过这 8 个步骤返回 example.com 的 IP 地址后，浏览器便能发出对该网页的请求。

浏览器向该 IP 地址发出 HTTP 请求。
位于该 IP 的服务器返回将在浏览器中呈现的网页（第 10 步）。

//gcore.jsdelivr.net/gh/G2/i@data/static_files/images/2021/dns-lookup-diagram.png — dns-lookup-diagram

什么是 DNS 递归解析器？

//gcore.jsdelivr.net/gh/G2/i@data/static_files/images/2021/recursive-resolver.png — recursive-resolver

递归解析器（也称为 DNS 解析器）是 DNS 查询中的第一站。递归解析器作为客户端与 DNS 域名服务器的中间人。从 Web 客户端收到 DNS 查询后，递归解析器将使用缓存的数据进行响应，或者将向根域名服务器发送请求，接着向 TLD 域名服务器发送另一个请求，然后向权威性域名服务器发送最后一个请求。收到来自包含已请求 IP 地址的权威性域名服务器的响应后，递归解析器将向客户端发送响应。

在此过程中，递归解析器将缓存从权威性域名服务器收到的信息。当一个客户端请求的域名 IP 地址是另一个客户端最近请求的 IP 地址时，解析器可绕过与域名服务器进行通信的过程，并仅从第二个客户端的缓存中为第一个客户端提供所请求的记录。

大多数 Internet 用户使用他们 ISP 提供的递归解析器，但还有其他可用选择；例如 Cloudflare 的 1.1.1.1、阿里的 223.5.5.5/223.6.6.6、百度的 180.76.76.76。

什么是 DNS 根域名服务器？

//gcore.jsdelivr.net/gh/G2/i@data/static_files/images/2021/root-nameserver.png — root-nameserver

每个递归解析器都知道 13 个 DNS 根域名服务器，它们是递归解析器搜寻 DNS 记录的第一站。根服务器接受包含域名的递归解析器的查询，根域名服务器根据该域的扩展名（.com、.net、.org 等），通过将递归解析器定向到 TLD 域名服务器进行响应。根域名服务器由一家名为 Internet 名称与数字地址分配机构（ICANN）的非营利组织进行监督。

注意

尽管有 13 个根域名服务器，但这并不意味着根域名服务器系统中只有 13 台计算机。根域名服务器有 13 种类型，但在世界各地每个类型都有多个副本，它们使用 Anycast 路由来提供快速响应。如果您将根域名服务器的所有实例加在一起，您将有 1376 台不同的服务器（截至 2021 年 3 月）。

DNS 根服务器的结构

域名系统 (DNS) 的管理通过使用不同的受管理分区或区域的层次结构构造，其根区域位于该层次结构的最顶部。根服务器是在根区域中运行的 DNS 域名服务器。这些服务器可以直接回答针对根区域内存储或缓存的记录的查询，还可以将其他请求引向相应的顶级域 (TLD) 服务器。TLD 服务器是 DNS 层次结构中比根服务器低一级的 DNS 服务器组，它们是解析 DNS 查询的必要部分。

技巧

其实每个域名后面都有一个根域名，因为对于所有域名都是一样的所以平时是省略的。如：www.baidu.com真正的域名是www.baidu.com.root，简写为www.baidu.com.。因为，根域名.root对于所有域名都是一样的，所以平时是省略的。

//gcore.jsdelivr.net/gh/G2/i@data/static_files/images/2021/dns-root-server.png — dns-root-server

在未缓存的 DNS 查询期间，每当用户在浏览器中输入网址，该操作都会触发 DNS 查找，并且所有 DNS 查找都从根区域开始。查找到达根区域后，将沿 DNS 系统的层次结构向下移动，首先到达 TLD 服务器，然后到达特定域（可能还有子域）的服务器，直到最终到达权威性名服务器，以查到正确的域名，其中包含要搜索的网站的数字 IP 地址。然后，该 IP 地址被返回给客户端。有趣的是，尽管需要许多步骤，但此过程仍可以非常快速地进行。

根服务器是 Internet 基础设施的重要组成部分；没有它们，Web 浏览器和许多其他 Internet 工具将无法工作。有 13 个不同的 IP 地址为 DNS 根区域提供服务，并且全球有数百个冗余根服务器来处理对根区域的请求。

为什么只有 13 个 DNS 根服务器地址？

一个普遍的误解是，世界上只有 13 台根服务器。实际上根服务器有许多，但只有 13 个 IP 地址用于查询不同的根服务器网络。DNS 原始架构的限制要求根区域中最多只能有 13 个服务器地址。在 Internet 面世之初，这 13 个 IP 地址的每一个都只有一台服务器，其中大多数位于美国。

如今，这 13 个 IP 地址中的每一个都有多个服务器，这些服务器使用 Anycast 路由基于负荷和距离分发请求。目前，地球上每座有人生活的大陆上都分布着 1300 多台 DNS 根服务器。

谁对 DNS 根服务器拥有权限？

根区域的最终权限属于国家电信和信息管理局 (NTIA)，后者是美国商务部的一部分。NTIA 将根区域的管理委托给 Internet 名称与数字地址分配机构 (ICANN)。

ICANN 为根区域中 13 个 IP 地址之一操作服务器，并将其他 12 个 IP 地址的操作委托给包括 NASA、马里兰大学和 Verisign（唯一运营两个根 IP 地址的组织）在内的多个组织。

解析器如何找到 DNS 根服务器？

由于 DNS 根区域位于 DNS 层次结构的顶部，因此递归解析器无法在 DNS 查找中被引导到这些位置。因此，每个 DNS 解析器都在其软件中内置了 13 个 IP 根服务器地址的列表。每次发起 DNS 查找时，递归器的第一个通信就是与这 13 个 IP 地址之一进行的。

如果 DNS 根服务器不可用怎么办？

由于使用了 Anycast 路由并具备高冗余性，根服务器非常可靠。但是在极少数情况下，根服务器将必须更新其 IP 地址。在这种情况下，递归解析器可以继续使用根区域中的其他 12 个 IP 地址执行 DNS 查找，直到它们的软件更新为所有 13 台服务器的正确地址为止。由于所有根服务器都能够将 DNS 请求转发到 TLD 服务器，因此当一台根服务器关闭时，不会影响 Internet 正常运行。

什么是 TLD 域名服务器？

//gcore.jsdelivr.net/gh/G2/i@data/static_files/images/2021/tld-nameserver.png — tld-nameserver

TLD 域名服务器维护共享通用域扩展名的所有域名的信息，例如 .com、.net 或 url 中最后一个点之后的任何内容。例如，.com TLD 域名服务器包含以「.com」结尾的每个网站的信息。如果用户正在搜索 google.com，则在收到来自根域名服务器的响应后，递归解析器将向 .com TLD 域名服务器发送查询，后者将通过针对该域的权威性域名服务器进行响应。

TLD 域名服务器的管理由 Internet 编号分配机构（IANA）加以处理，其为 ICANN 的一个分支机构。IANA 将 TLD 服务器分为两个主要组：

通用顶级域：这些是非特定国家/地区的域，一些最知名的通用 TLD 包括 .com、.org、.net、.edu 和 .gov。
国家/地区代码顶级域：这些包括特定于某个国家/地区或州的任何域。例如，uk、.us、.ru 和 .jp 等。

对于基础设施域实际上存在第三个类别，但该类别几乎从不使用。此类别是为 .arpa 域创建的，该域是在创建新式 DNS 时使用的过渡域；其当今主要是具有历史意义。

什么是权威性域名服务器？

//gcore.jsdelivr.net/gh/G2/i@data/static_files/images/2021/authoritative-nameserver.png — authoritative-nameserver

当递归解析器收到来自 TLD 域名服务器的响应时，该响应会将解析器定向到权威性域名服务器。权威性域名服务器通常是解析器查找 IP 地址过程中的最后一步。权威名称服务器包含特定于其服务域名的信息（例如，google.com）权威性域名服务器包含特定于其所服务的域名的信息（例如 google.com），并且它可为递归解析器提供在 DNS A 记录中找到的服务器的 IP 地址，或者如果该域具有 CNAME 记录（别名），它将为递归解析器提供一个别名域，这时递归解析器将必须执行全新 DNS 查找，以便从权威性域名服务器获取记录（通常为包含 IP 地址的 A 记录）。例如在查询对象为子域 foo.example.com 或 blog.cloudflare.com 的情况下，将向权威性域名服务器之后的序列添加一个附加域名服务器，其负责存储该子域的 CNAME 记录。

//gcore.jsdelivr.net/gh/G2/i@data/static_files/images/2021/dns-record-request-sequence-3.png — dns-record-request-sequence

DNS 查询的类型

典型 DNS 查找中会出现三种类型的查询。通过组合使用这些查询，优化的 DNS 解析过程可缩短传输距离。在理想情况下，可以使用缓存的记录数据，从而使 DNS 域名服务器能够返回非递归查询。

递归查询 - 在递归查询中，DNS 客户端要求 DNS 服务器（一般为 DNS 递归解析器）将使用所请求的资源记录响应客户端，或者如果解析器无法找到该记录，则返回错误消息。
迭代查询 - 在这种情况下，DNS 客户端将允许 DNS 服务器返回其能够给出的最佳应答。如果所查询的 DNS 服务器与查询名称不匹配，则其将返回对较低级别域名空间具有权威性的 DNS 服务器的引用。然后，DNS 客户端将对引用地址进行查询。此过程继续使用查询链中的其他 DNS 服务器，直至发生错误或超时为止。
非递归查询 - 当 DNS 解析器客户端查询 DNS 服务器以获取其有权访问的记录时通常会进行此查询，因为其对该记录具有权威性，或者该记录存在于其缓存内。DNS 服务器通常会缓存 DNS 记录，以防止更多带宽消耗和上游服务器上的负载。

DNS 缓存方式

DNS 高速缓存

缓存的目的是将数据临时存储在某个位置，从而提高数据请求的性能和可靠性。DNS 高速缓存涉及将数据存储在更靠近请求客户端的位置，以便能够更早地解析 DNS 查询，并且能够避免在 DNS 查找链中进一步向下的额外查询，从而缩短加载时间并减少带宽 CPU 消耗。DNS 数据可缓存到各种不同的位置上，每个位置均将存储 DNS 记录并保存由生存时间（TTL）决定的一段时间。

浏览器 DNS 缓存

现代 Web 浏览器设计为默认将 DNS 记录缓存一段时间。目的很明显；越靠近 Web 浏览器进行 DNS 缓存，为检查缓存并向 IP 地址发出正确请求而必须采取的处理步骤就越少。发出对 DNS 记录的请求时，浏览器缓存是针对所请求的记录而检查的第一个位置。

在 Chrome 浏览器中，您可以转到 chrome://net-internals/#dns 查看 DNS 缓存的状态。

操作系统（OS）级 DNS 缓存

操作系统级 DNS 解析器是 DNS 查询离开您计算机前的第二站，也是本地最后一站。操作系统内旨在处理此查询的过程通常称为「存根解析器」或「DNS 客户端」。当存根解析器获取来自某个应用程序的请求时，其首先检查自己的缓存，以便查看是否有此记录。如果没有，则将本地网络外部的 DNS 查询（设置了递归标记）发送到 Internet 服务提供商（ISP）内部的 DNS 递归解析器。

与先前所有步骤一样，当 ISP 内的递归解析器收到 DNS 查询时，其还将查看所请求的主机到 IP 地址转换是否已经存储在其本地持久性层中。

根据其缓存中具有的记录类型，递归解析器还具有其他功能：

如果解析器没有 A 记录，但确实有针对权威性域名服务器的 NS 记录，则其将直接查询这些域名服务器，从而绕过 DNS 查询中的几个步骤。此快捷方式可防止从根和 .com 域名服务器（在我们对 example.com 的搜索中）进行查找，并且有助于更快地解析 DNS 查询。
如果解析器没有 NS 记录，它会向 TLD 服务器（本例中为 .com）发送查询，从而跳过根服务器。
万一解析器没有指向 TLD 服务器的记录，其将查询根服务器。这种情况通常在清除了 DNS 高速缓存后发生。

DNS 分级查询调试例子

技巧

此次操作在 Linux 上使用 dig 工具执行，类似的 DNS 工具还有host、nslookup、whois

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
> dig +trace blog.zzz.run

; <<>> DiG 9.11.4-P2-RedHat-9.11.4-16.P2.el7_8.6 <<>> +trace blog.zzz.run
;; global options: +cmd
.			11890	IN	NS	m.root-servers.net.
.			11890	IN	NS	a.root-servers.net.
.			11890	IN	NS	b.root-servers.net.
.			11890	IN	NS	c.root-servers.net.
.			11890	IN	NS	d.root-servers.net.
.			11890	IN	NS	e.root-servers.net.
.			11890	IN	NS	f.root-servers.net.
.			11890	IN	NS	g.root-servers.net.
.			11890	IN	NS	h.root-servers.net.
.			11890	IN	NS	i.root-servers.net.
.			11890	IN	NS	j.root-servers.net.
.			11890	IN	NS	k.root-servers.net.
.			11890	IN	NS	l.root-servers.net.
;; Received 239 bytes from 10.236.158.114#53(10.236.158.114) in 1 ms

run.			172800	IN	NS	demand.beta.aridns.net.au.
run.			172800	IN	NS	demand.alpha.aridns.net.au.
run.			172800	IN	NS	demand.delta.aridns.net.au.
run.			172800	IN	NS	demand.gamma.aridns.net.au.
run.			86400	IN	DS	26716 8 1 6741B9D1A2296CA777AB9C2C359241CD23AF3C63
run.			86400	IN	DS	26716 8 2 F9DC679779C8D1FD3B924221CBD9BBBD468B44048026CA1A267E5D66 10C37BAE
run.			86400	IN	RRSIG	DS 8 1 86400 20210322050000 20210309040000 42351 . XuWs3u7UeaFt0ZruWuHahAeZjYeWieVxB8CgOQzL8HeTfbofO1BoLiNg lBUvgKN6TT0p3FFLnhYaZIuxcM0iyvhEcPcE4kQdOcqvdl5aGnf+8bse Whd9BUKjM8ybW1xqyLm2mD/ImAG7HRIskY0E+AW6nlfQ1cFEoZDZMNat WUVeGHYushLy8PVmR3vzjVWpN6U6t57JLW4KQWIBuYSYeUcZ9brHmouV zavhQ6X6PUMWnoIg8Lst+XFIrjSTYN67gQbhbQm26cMP97nCWPXSV/4y LqqhwCeWmJFrjUS1EuKRYx0yS0g39C2os0smZV6vmvbBAoc1nMD/yTlG FIRj/w==
;; Received 708 bytes from 198.97.190.53#53(h.root-servers.net) in 202 ms

zzz.run.		86400	IN	NS	mcgrory.ns.cloudflare.com.
zzz.run.		86400	IN	NS	ximena.ns.cloudflare.com.
k9o68q9fs4otbs0klvsiv6evni8qeq0p.run. 86400 IN NSEC3 1 1 1 EEBCE3E6 KABG58AJUK48M5EF2LR7G32LL44PBLPV NS SOA RRSIG DNSKEY NSEC3PARAM
k9o68q9fs4otbs0klvsiv6evni8qeq0p.run. 86400 IN RRSIG NSEC3 8 2 86400 20210401132957 20210302132940 34593 run. atCHYOxTrEBhr4SYA/O2d8SBjN7jdQ3f4HTpOL2v5N4QNHDZkl4zsNhs 01TH0mtmPPnU6efPURKoGuIJ/FIvIRqkH0q279YtWWj59j4atSu9R02X sKmmvR1Hs8L1XhqCSygS9pwmjfVYYhWA/rq8kdV3n+NbjfYcpJ05aL6A LrNUss4snRwWInhl/+7JzZKELkZDhAMXvv483KzUHa/A+w==
hmh1t78l7lgmcr36rms03kk46dstrva0.run. 86400 IN NSEC3 1 1 1 EEBCE3E6 HNF1HTT3RBMQSNCVQ3MM7DSR27PGFJMJ NS DS RRSIG
hmh1t78l7lgmcr36rms03kk46dstrva0.run. 86400 IN RRSIG NSEC3 8 2 86400 20210402010024 20210303005533 34593 run. Qc73UuPlV/7o4UD1pal5uhu/Vfu80RFY6N9QVA7CHXIUKqSBzJVzj484 FWGkcNmfkjCilCjy6t9TayChU1le+garM+n4JHY8FX1yQSRq6ZgLpKMn woZHxUHiSRK4vKSm+hIQiOKxxL2cO5l5ixZFnnrxvdIybVrNPgGgsez8 n2JEGhWuO88O+gWxrwtY4BAndpWqeE8s8uoUEU0mL2vIhw==
;; Received 661 bytes from 37.209.194.7#53(demand.beta.aridns.net.au) in 4 ms

blog.zzz.run.		300	IN	A	104.21.42.163
blog.zzz.run.		300	IN	A	172.67.163.138
;; Received 73 bytes from 162.159.38.10#53(ximena.ns.cloudflare.com) in 182 ms

从命令dig +trace blog.zzz.run的运行结果来看总共分为四段。

解析器获取根域名.的 13 条 NS 记录，即所有根域名服务器。

根据内置的根域名服务器 IP 地址，DNS 解析器向所有这些 IP 地址发出查询请求，询问blog.zzz.run的顶级域名服务器run.的 NS 记录。最先回复的根域名服务器将被缓存，以后只向这台服务器发请求。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
.			38533	IN	NS	j.root-servers.net.
.			38533	IN	NS	l.root-servers.net.
.			38533	IN	NS	i.root-servers.net.
.			38533	IN	NS	e.root-servers.net.
.			38533	IN	NS	m.root-servers.net.
.			38533	IN	NS	k.root-servers.net.
.			38533	IN	NS	d.root-servers.net.
.			38533	IN	NS	a.root-servers.net.
.			38533	IN	NS	f.root-servers.net.
.			38533	IN	NS	b.root-servers.net.
.			38533	IN	NS	h.root-servers.net.
.			38533	IN	NS	c.root-servers.net.
.			38533	IN	NS	g.root-servers.net.

通过请求根服务器（Root Server）找到.run后缀域名的 4 条 NS 记录

1
2
3
4
run.			172800	IN	NS	demand.alpha.aridns.net.au.
run.			172800	IN	NS	demand.delta.aridns.net.au.
run.			172800	IN	NS	demand.gamma.aridns.net.au.
run.			172800	IN	NS	demand.beta.aridns.net.au.

DNS 服务器向这些顶级域名服务器（TLD Server）发出查询请求，寻找blog.zzz.run中次级域名zzz.run 的 NS 记录

1
2
zzz.run.		86400	IN	NS	mcgrory.ns.cloudflare.com.
zzz.run.		86400	IN	NS	ximena.ns.cloudflare.com.

通过这两台 NS 服务器（权威性域名服务器）查询到有两条 A 记录。并且还显示最先找到这条记录的 NS 服务器是mcgrory.ns.cloudflare.com，通过这两个 IP 地址都可以访问到网站。

1
2
3
blog.zzz.run.		300	IN	A	104.21.42.163
blog.zzz.run.		300	IN	A	172.67.163.138
;; Received 73 bytes from 172.64.35.170#53(mcgrory.ns.cloudflare.com) in 150 ms

目录