DNS 术语、组件和概念概述

DNS (Domain Name System) 是驱动互联网的关键组件之一。对 DNS 工作原理的正确理解有助于诊断网站配置问题，并拓宽您对幕后发生的事情的理解。

在本指南中，我们将讨论 DNS 的一些基本概念，以便在您进行 DNS 配置时为您奠定坚实的基础。本指南还将帮助您设置自己的域名或 DNS 服务器。

让我们开始吧！

域名术语

首先，我们需要对我们将要使用的术语建立一个认识。您可能已经从其他背景中熟悉了其中的一些术语。然而，在谈论域名和 DNS 时，有许多特定术语在计算机的其他领域中并不经常讨论。

• 域名系统

域名系统（简称 DNS）是一种现有的网络系统，它将便于人类记忆的域名转换为唯一的 IP 地址。

• 域名

域名是指用于与互联网资源相关联的、便于人类记忆的名称。例如，“cloudsigma.com” 就是一个域名。有些人可能会认为只有 “cloudsigma” 部分才是域名，但通常它指的是整体。

URL “cloudsigma.com” 与 CloudSigma 拥有的服务器相关联。在浏览器中输入该 URL 时，它会与 DNS 进行通信，以连接到目标服务器的 IP 地址。

• IP 地址

IP 地址充当连接到网络的设备的网络地址。每个 IP 地址在网络中必须是唯一的。在网站的语境下，网络在大多数情况下是指整个互联网。

有两种类型的 IP 地址：

• • IPv4: 这是最常见的 IP 地址形式。它被写为一组四个数字，每组最多有 3 位数字。每组之间用点分隔。IPv4 的范围是从 0.0.0.0 到 255.255.255.255.

  • IPv6: 这是一个更现代的标准，旨在解决IPv4 地址枯竭问题。IPv4 支持多达 232 个唯一地址，而 IPv6 支持多达 2128 个地址。任何 IPv6 地址都用十六进制数字编写。它可以包含多达 32 位数字，分为 8 个部分（每个部分 4 位数字）。每个部分用冒号 (:) 分隔。

顶级域名

顶级域名（简称 TLD）是域名中最通用的部分。它指的是最右侧的部分（用点分隔）。一些常见的顶级域名包括：

• “com”

• “net”

• “org”

• “edu”

• “io”

• “gov”

就域名而言，这些域名处于层级结构的顶端。ICANN（互联网名称与数字地址分配机构）可以向某些方颁发控制顶级域名的许可。获得许可后，这些方可以分发该 TLD 下的域名（通常通过域名注册商）。

• 主机

在域名中，所有者可以指定单个主机，指代通过域名可访问的独立机器/服务。例如，通常的做法是让 Web 服务器可以通过裸域名（ example.com）以及 “主机” 定义 “www  （ www.example.com).

在通用域名下也可以有其他主机，例如，通过 “api” 主机进行 API 访问（ api.example.com），通过 “ftp” 或 “files” 主机进行 FTP 访问（ ftp.example.com 或 files.example.com).

请注意，只要域名在域内是唯一的，就可以是任意的。

• 子域名

子域名是与主机相关的概念。DNS 按层级结构运行。一个 TLD 下可以有许多域名。例如，“ example.com”, “ cloudsigma.com”等都属于“com” TLD。在这方面，子域名是指作为目标域名一部分的任何域名。因此，我们可以说“example.com”是“com”的子域名。通常，“example”部分被称为SLD（二级域名）。

同样，一个域名可以控制位于其下的所有“子域名”。这通常是“子域名”一词所指的意思。例如，“ history.example.com”是子域名，其父域名为“ example.com”.

主机名和子域名之间的关键区别在于，主机定义了计算机/资源，而子域名扩展了父域名。每当谈论子域名或主机时，您可以通过查看域名最左侧的部分来确定，因为它是最具体的。这就是 DNS 的工作原理：从最具体（最左侧）到最不具体（最右侧）。

• 完全限定域名

完全限定域名（简称 FQDN）是指绝对域名。在 DNS 系统中，域名可以相对彼此给出。这可能会导致一些歧义。然而，FQDN 是一个绝对名称，指向域名系统的绝对根。

这意味着 FQDN 指定了包括 TLD 在内的每个父域名。一个合适的例子是“ mail.google.com”。在特定情况下，FQDN 可能不以点结尾，但它必须有一个尾随的点（ICANN 标准要求）。

• 域名服务器

域名服务器是用于将域名翻译为 IP 地址的专用计算机。域名服务器承担了 DNS 系统中的大部分负载。由于域名解析请求的总数太高，单台服务器无法处理，因此请求经常被重定向到其他域名服务器以分担压力。

域名服务器可以是“权威的”，这意味着它只回答对其控制下的域名的查询。此类服务器可以将请求转发给其他域名服务器，或者提供其他域名服务器数据的缓存副本。

• 区域文件

区域文件是一个文本文件，包含域名和 IP 地址之间的映射。它充当 DNS 系统的数据库。这是 DNS 在完成用户对特定域名的请求时，用于查找要联系哪个 IP 地址的目录。

通常，域名服务器托管区域文件并定义单个域名下可用的资源。它还可以包含有关去哪里获取该信息的信息。

• 记录

一个区域文件包含许多记录。在这里，记录被定义为资源和名称之间的单一映射。记录可以是映射到 IP 地址的域名、特定域名下可用的资源，或者是获取该信息的去处的引用。

DNS 实际运行

到目前为止，我们已经熟悉了与 DNS 相关的一些常见术语。然而，该系统实际上是如何工作的？从高层次来看，该系统可能显得非常简单。尽管如此，深入了解细节将揭示其真正的复杂性。总的来说，DNS 系统对于互联网的广泛普及至关重要。

• 根服务器

DNS 的核心是按层级结构运行的。在系统的顶端是“根服务器”。这些服务器由各种组织控制。这些服务器的权限由 ICANN（互联网名称与数字地址分配机构）授予。

截至目前，大约有 13 台根服务器在运行。然而，由于负载原因，这些服务器中的每一台都有镜像。需要注意的是，所有镜像服务器都与根服务器共享相同的 IP 地址。每当向根服务器发出任何请求时，该请求都会被重定向到该服务器最近的镜像。

根服务器的工作是什么？它们提供有关顶级域名的信息。每当低级别域名服务器无法解析请求时，请求就会被重定向到该域名的根服务器。

然而，根服务器实际上并不知道该域名的位置。它只是重定向将处理具体请求的顶级域的请求。例如，如果请求的是“ blog.cloudsigma.com”，根服务器的记录中不会有该域名。它会搜索其区域文件，但其中不会有任何相关记录。相反，它会识别出“com”顶级域（TLD），并将请求实体重定向到处理“com”地址的名称服务器。

• TLD 服务器

继续我们之前的例子，请求实体现在会将请求发送到该 IP 地址（由根服务器提供）。在“ blog.cloudsigma.com”的情况下，“com”名称服务器将在其区域文件中搜索其记录。

其中不会有与该请求相对应的记录。然而，它会找到一条记录，列出负责“ cloudsigma.com”.

• 域名级名称服务器

现在，请求实体已经获取了实际托管有关“ blog.cloudsigma.com”信息的名称服务器的 IP 地址。现在它将向该服务器发送一个新请求，要求解析“www.cloudsigma.com”。

与之前一样，名称服务器将检查其区域文件，并找到与“ cloudsigma.com”相关联的文件。在此文件内部将包含一条针对“www”主机的条目。该记录描述了该主机的位置。最终答案将被转发给请求实体。

• 解析名称服务器

在示例中，我们提到了一个请求实体。它是什么？在大多数情况下，请求者将是一个“解析名称服务器”。它是一个被配置为向其他服务器提问的服务器。它充当用户的中间服务器。它会缓存结果以提高速度。

任何用户通常都会在其系统上配置几个解析名称服务器。通常，解析名称服务器由 ISP 或其他组织提供。例如，Google 提供了可供查询的公共解析 DNS 服务器。您可以手动将其配置到您的系统中。

在浏览器中输入 URL 时，它会寻找资源的位置。首先，在本地进行搜索。这包括“hosts”文件（以及其他一些位置）。如果未找到，则将请求发送到解析名称服务器。收到请求后，解析名称服务器会在其缓存中搜索答案。如果未找到，则它会执行前面提到的步骤。

解析名称服务器简化了终端用户的请求过程。客户端只需向解析名称服务器询问资源的位置。名称服务器将进行调查并返回最终答案。

• 区域文件

我们已经讨论过“区域文件”和“记录”的概念。那么，它们是如何运作的呢？

区域文件充当名称服务器的数据库，存储它们所知道的域名的信息。名称服务器知道的所有域名都将存储在其区域文件中。然而，发送到名称服务器的大多数请求并不能通过区域文件直接解析。如果服务器配置为处理递归查询（例如解析名称服务器），那么它将返回答案。否则，它将把请求方重定向到另一个地方继续寻找。

名称服务器托管的区域文件越多，其回答就越具权威性。区域文件描述了一个 DNS“区域”（整个 DNS 命名系统的一个子集）。通常，一个区域文件仅包含单个域名的配置数据。它可以包含许多记录，用于定义相关域名资源的位置。

一个区域的 $ORIGIN 参数等于该区域的最高权威级别。例如，“ cloudsigma.com” 的区域文件，其 $ORIGIN 将为 “ cloudsigma.com”。该参数的值可以存储在区域文件的开头或 DNS 服务器的配置中。无论哪种方式，该参数都描述了该文件对哪个区域具有权威性。

该 $TTL 参数设置其提供结果的“生存时间”信息。它可以被描述为一个计时器，缓存服务器可以使用它来跟踪缓存回答的有效性。如果 TTL 值耗尽，该回答将不再有效并被丢弃。

• 记录类型

区域文件由许多记录组成。现在，有不同类型的记录。接下来，我们将介绍一些最常见（且强制性）的记录类型：

SOA 记录

起始授权机构（简称 SOA）记录在所有区域文件中都是强制性的。它必须是文件中的第一条真实记录。然而，像 $ORIGIN 或 $TTL 这样的条目允许提前出现。

SOA 记录是较复杂的记录类型之一。它的结构看起来像这样：

让我们来拆解一下：

• • example.com：此部分定义了区域的根。在此示例中，区域文件针对的是域名“ example.com”。有时，该值可能会被替换为 @（一个用于替换 值的占位符$ORIGIN).

  • IN SOA：“IN”一词表示“互联网”（internet）。您会在许多记录中找到它。“SOA”一词表示这是一条 SOA 记录。

  • ns1.example.com：此值保存域名“ 的主域名服务器example.com”。域名服务器可以是主域名服务器，也可以是辅助域名服务器。如果配置了动态 DNS，则需要有一个“主”服务器。如果没有配置动态 DNS，那么它将是主域名服务器之一。

  • admin.example.com：此处填写区域管理员的电子邮件地址。请注意，这里的 @ 被替换为 .。如果原始电子邮件地址中包含点，则会替换为 \。例如，“ my.domain@example.com”将变成“ my\domain.example.com”.

  • 12083：这是区域文件的序列号。每次编辑区域文件时，都必须更新该数字，以便文件能够正确传播。辅助服务器使用此序列号来跟踪其自身的区域文件是否是最新的。

  • 3h：它表示区域的刷新间隔。辅助服务器在检查区域文件更新之前将等待这段时间。

  • 30m：此值表示区域的重试间隔。如果辅助服务器在刷新期满后无法连接到主服务器，它将等待这段时间，然后再次轮询主服务器。

  • 3w：此值表示过期时间。如果辅助服务器在此时间内无法连接到主服务器，它将停止返回“权威”响应。

  • 1h：此值表示如果在其区域文件中未找到名称错误，域名服务器将缓存该错误的时间。

A 和 AAAA 记录

这些记录建立了主机与 IP 地址之间的映射。在这里，“A”记录表示到主机的 IPv4 映射，而 AAAA 表示 IPv6 映射。

这是 A 和 AAAA 记录的基本结构：

在 SOA 记录示例中，我们将域名服务器称为“ ns1.exampel.com”。域名服务器属于域名“ example.com”。以下是它的 A 记录的样子：

请注意，我们不必提供完整名称。只需主机名（不含 FQDN），DNS 服务器就可以使用来自 的值来填充其余部分$ORIGIN。但是，我们仍然可以使用 FQDN：

以下是将 Web 服务器定义为“www”的方法：

我们还应该包括到基础域的映射。该条目看起来像这样：

或者，我们可以使用 @ 符号来表示基础域（而不是其完整名称）：

包含一个通配符条目是一个好习惯，这样可以解析该域名下所有未明确定义的任何内容：

相同的结构也适用于 AAAA 记录。唯一的区别是 IPv6 地址。

CNAME 记录

CNAME 记录用作服务器规范名称（由 A 或 AAAA 记录定义）的别名。请看以下示例：

在这里，我们使用“server1”作为定义“www”名称的别名。请注意，此类快捷方式会带来性能开销，因为服务器必须运行额外的查询才能获得最终答案。根据别名层数的不同，这很容易导致巨大的性能开销。然而，有一种特定情况可以从 CNAME 别名中受益，例如，提供当前区域之外的资源。

MX 记录

MX 记录定义了域名的邮件交换服务器。它有助于电子邮件正确到达服务器。与其他记录不同，MX 记录不将主机映射到某些内容，因为它们适用于整个区域。这就是为什么 MX 记录看起来像这样的原因：

请注意，条目的开头没有主机名。您还会注意到该行中有一个额外的值。它是优先级编号，有助于决定将邮件发送到哪台服务器（如果定义了多个邮件服务器）。数字越小，优先级越高。

MX 记录应该指向由 A 或 AAAA 记录（而不是 CNAME）定义的主机。记住这一点，如果配置了两个邮件服务器，那么记录将如下所示：

在这个例子中，从优先级编号来看，“mail1”是比“mail2”更优选的服务器。我们可以通过省略完整域名来进一步缩短代码：

NS 记录

这些记录定义了特定区域的名称服务器。现在，显而易见的问题是，如果区域文件驻留在名称服务器中，为什么它需要对自身的引用？该问题的一个答案是 DNS 系统的多重缓存机制。区域文件实际上可能是其他服务器上的缓存副本。

与 MX 记录类似，NS 记录适用于整个区域。因此，默认情况下它们没有任何特定的主机。NS 记录条目看起来像这样：

建议定义两个名称服务器，以防其中一个服务器无法正常运行。此外，如果区域文件仅包含单个名称服务器，大多数 DNS 服务器将拒绝该文件。

您还应该包括使用 A 或 AAAA 记录的主机映射：

PTR 记录

PTR 记录是经典 A 或 AAAA 记录的反向记录。这些记录用于定义与 IP 地址关联的名称。这些记录具有独特的属性，因为它们开始于 .arpa 根并代表 IP 地址的所有者。是由 RIR（区域互联网注册机构）向组织和服务提供商分配 IP 地址。这些 RIR 包括 APNIC、AFRINIC、LACNIC、RIPE NCC 和 ARIN。

例如， 111.222.333.444 的 PTR 记录看起来会像这样：

在下一个 PTR 记录示例中，看看 Google’s 的 IPv6 DNS 服务器 2001:4860:4860::8888:

我们可以使用带有 -x 标志的 dig 工具来查找 IP 地址的反向 DNS 名称。例如，查看 的反向 DNS IP 地址8.8.4.4:

互联网服务器使用 PTR 记录来跟踪日志条目中的域名、做出明智的垃圾邮件处理决策，并显示关于其他设备易于阅读的信息。

常用的邮件服务器会查找发送邮件的 IP 地址的 PTR 记录。如果 PTR 记录为空，那么该邮件很有可能是垃圾邮件（因此会被拒绝）。请注意，FQDN 与 PTR 记录的域名是否匹配并不是关键。重要因素是是否存在一个有效的 PTR 记录与匹配且对应的正向 A 记录相关联。

通常，互联网上的网络路由器都有与其物理位置相对应的 PTR 记录。例如，“NYC” 或 “CHI” 是位于纽约和芝加哥的路由器的有效参考。在执行 traceroute 或 MTR 并查看数据包所经路径时，这种技术非常有用。

CAA 记录

这些记录指定了可以为您的域名颁发 SSL/TLS 证书的 CA（证书颁发机构）。自 2017 年 9 月 8 日起，所有 CA 在颁发证书之前都必须检查 CAA 记录。如果不存在 CA 记录，则任何 CA 都可以颁发证书。否则，只有特定的 CA 才能颁发证书。CAA 记录既可以应用于单个主机，也可以应用于整个域名。

以下是 CAA 记录的一个示例：

该条目中特定于 CAA 的部分是 0 issue "letsencrypt.org"。这部分包含三个部分：

• 标志：这是一个整数值，指示 CA 应该如何处理它不理解的标签。如果标志值设置为 0，那么该记录将被忽略。如果值为 1，那么 CA 必须拒绝颁发证书。
• 标签：这些是表示 CAA 记录用途的字符串。截至目前，有效值包括 issue（授权 CA 为特定域名颁发证书）， issuewild（授权通配符证书），以及 iodef （定义一个 URL，CA 在该 URL 报告违反策略的行为）。
• 值：这些是与记录标签相关联的字符串。如果标签是 issue 或 issuewild，该值通常会是您授予权限的 CA 的域名。如果标签是 iodef，它将是一个联系表单的 URL 或一个 mailto: 链接，用于电子邮件反馈。

我们可以使用 dig 工具来获取 CAA 记录：

有关 CAA 记录的更多深入信息，请查看 RFC 6844.

结语

本指南介绍了各种与 DNS 相关的术语。它还介绍了所有组件是如何协同工作的。有了这个全面的概述，您应该对 DNS 系统的功能有一个很好的了解。虽然总体概念简单易懂，但其中的细节很快就会变得非常复杂。对于缺乏经验的管理员来说，应用这些概念和策略可能会很困难。

您是 CloudSigma 的客户吗？那么请查看 管理和更新您的 CloudSigma 基础设施的反向 DNS/PTR 记录.

祝您计算愉快！