DNS 术语、组件和概念简介

介绍

DNS（即域名系统）通常是学习如何配置网站和服务器的一个非常困难的部分。了解 DNS 的工作原理将帮助您诊断配置网站访问的问题，并让您更深入地了解幕后发生的事情。

在本指南中，我们将讨论一些基本的 DNS 概念，这些概念将帮助您开始使用 DNS 配置。完成本指南后，您应该准备好使用 DigitalOcean 设置您的域名 or 设置您自己的 DNS 服务器.

在我们开始设置您自己的服务器来解析您的域或在控制面板中设置我们的域之前，让我们先回顾一下有关所有这些实际工作原理的一些基本概念。

领域术语

我们应该从定义我们的术语开始。虽然其中一些主题在其他环境中很常见，但在谈论域名和 DNS 时使用的许多术语在其他计算领域中并不经常使用。

让我们从简单的开始：

域名系统

域名系统（通常称为“DNS”）是一种现有的网络系统，它允许我们将人类友好的名称解析为唯一的 IP 地址。

域名

域名是我们习惯于与互联网资源关联的人类友好名称。例如， ”google.com” 是一个域名。有人会说“google”部分就是域名，但我们一般可以将组合形式称为域名。

网址“google.com” 与 Google Inc. 拥有的服务器相关联。当我们键入“时，域名系统允许我们访问 Google 服务器google.com”进入我们的浏览器。

IP地址

IP 地址就是我们所说的网络可寻址位置。每个 IP 地址在其网络中必须是唯一的。当我们谈论网站时，这个网络就是整个互联网。

IPv4 是最常见的地址形式，被写为四组数字，每组最多三位数字，每组之间用点分隔。例如， ”111.222.111.222” 可以是有效的 IPv4 IP 地址。通过 DNS，我们将名称映射到该地址，这样您就不必为您希望在网络上访问的每个位置记住一组复杂的数字。

顶级域名

顶级域 (TLD) 是域中最通用的部分。顶级域是右侧最远的部分（用点分隔）。常见的顶级域名有“com”、“net”、“org”、“gov”、“edu”和“io”。

就域名而言，顶级域位于层次结构的顶部。 ICANN（互联网名称与数字地址分配机构）授予某些方对顶级域名的管理控制权。然后，这些各方通常可以通过域名注册商在 TLD 下分配域名。

Hosts

在域内，域所有者可以定义各个主机，这些主机是指通过域访问的单独计算机或服务。例如，大多数域名所有者都通过裸域访问他们的 Web 服务器（example.com）并且还通过“主机”定义“www”（www.example.com).

您可以在通用域下有其他主机定义。您可以通过“api”主机访问 API（api.example.com）或者您可以通过定义名为“ftp”或“files”的主机来进行 ftp 访问（ftp.example.com or files.example.com）。主机名可以是任意的，只要它们对于域是唯一的即可。

子域

与主机相关的主题是子域。

DNS 以层次结构运行。 TLD 下可以有许多域名。例如，“com”TLD 具有“google.com” and “ubuntu.com”在它下面。 “子域”是指属于较大域的任何域。在这种情况下， ”ubuntu.com”可以说是“com”的子域名。这通常被称为域，或者“ubuntu”部分被称为 SLD，这意味着二级域。

同样，每个域都可以控制位于其下的“子域”。这通常就是我们所说的子域。例如，您可以为您学校的历史系设置一个子域，地址为“www.history.school.edu”。 “历史”部分是一个子域。

主机名和子域之间的区别在于，主机定义计算机或资源，而子域扩展父域。它是一种细分域本身的方法。

无论是谈论子域还是主机，您都可以开始看到域的最左侧部分是最具体的。这就是 DNS 的工作原理：从左到右阅读时，从最具体到最不具体。

完全合格的域名

完全限定域名，通常称为 FQDN，就是我们所说的绝对域名。 DNS 系统中的域可以相互关联，因此可能有些模糊。 FQDN 是一个绝对名称，指定其相对于域名系统绝对根的位置。

这意味着它指定了包括 TLD 在内的每个父域。正确的 FQDN 以点结尾，表示 DNS 层次结构的根。 FQDN 的示例是“mail.google.com.”。有时，要求 FQDN 的软件不需要结尾点，但尾随点需要符合 ICANN 标准。

名称服务器

名称服务器是指定将域名转换为 IP 地址的计算机。这些服务器完成 DNS 系统中的大部分工作。由于域转换的总数对于任何一台服务器来说都太多，因此每台服务器可能会将请求重定向到其他名称服务器或委派其负责的子域子集的责任。

名称服务器可以是“权威的”，这意味着它们可以回答有关其控制下的域的查询。否则，它们可能指向其他服务器，或提供其他名称服务器数据的缓存副本。

区域文件

区域文件是一个简单的文本文件，其中包含域名和 IP 地址之间的映射。这就是当用户请求某个域名时，DNS 系统最终找到应该联系哪个 IP 地址的方式。

区域文件驻留在名称服务器中，通常定义特定域下的可用资源，或者可以获取该信息的位置。

Records

在区域文件内，保存记录。在最简单的形式中，记录基本上是资源和名称之间的单一映射。它们可以将域名映射到 IP 地址、定义域的名称服务器、定义域的邮件服务器等。

DNS 的工作原理

现在您已经熟悉了 DNS 涉及的一些术语，那么该系统实际上是如何工作的呢？

从高层次上看，该系统非常简单，但从细节上看却非常复杂。但总的来说，它是一个非常可靠的基础设施，对于我们今天所知的互联网的采用至关重要。

根服务器

正如我们上面所说，DNS 的核心是一个分层系统。该系统的顶部是所谓的“根服务器”。这些服务器由各个组织控制，并由 ICANN（互联网名称与数字地址分配机构）授予权力。

目前有13台根服务器在运行。然而，由于每分钟有大量的名称需要解析，因此每个服务器实际上都是镜像的。此设置的有趣之处在于单个根服务器的每个镜像共享相同的 IP 地址。当对某个根服务器发出请求时，请求将被路由到该根服务器最近的镜像。

这些根服务器的作用是什么？根服务器处理有关顶级域信息的请求。因此，如果请求的内容是较低级别的名称服务器无法解析的，则会向该域的根服务器进行查询。

根服务器实际上并不知道域托管在哪里。但是，他们将能够将请求者定向到处理特定请求的顶级域的名称服务器。

因此，如果请求“www.wikipedia.org如果向根服务器发出“”，根服务器将不会在其记录中找到结果。它将检查其区域文件中是否有与“www.wikipedia.org”。它不会找到一个。

相反，它将查找“org”TLD 的记录，并向请求实体提供负责“org”地址的名称服务器的地址。

顶级域名服务器

然后，请求者将新请求发送到负责该请求的顶级域的 IP 地址（由根服务器为其提供）。

因此，继续我们的示例，它将向负责了解“org”域的名称服务器发送请求，看看它是否知道“www.wikipedia.org“ 位于。

请求者将再次寻找“www.wikipedia.org”在其区域文件中。它不会在其文件中找到该记录。

然而，它会找到一条记录，列出负责“的名称服务器的IP地址”wikipedia.org”。这已经越来越接近我们想要的答案了。

域级名称服务器

此时，请求者就拥有了负责了解资源实际IP地址的名称服务器的IP地址。它向名称服务器发送一个新请求，再次询问是否可以解析“www.wikipedia.org”.

名称服务器检查其区域文件，发现它有一个与“wikipedia.org”。该文件内部有“www”主机的记录。这条记录告诉了该主机所在的IP地址。名称服务器将最终答案返回给请求者。

什么是解析名称服务器？

在上面的场景中，我们提到了“请求者”。在这种情况下，请求者是什么？

在几乎所有情况下，请求者都是我们所说的“解析名称服务器”。解析名称服务器是配置为向其他服务器询问问题的服务器。它基本上是用户的中介，它缓存以前的查询结果以提高速度，并知道根服务器的地址，以便能够“解析”对其不知道的事物发出的请求。

基本上，用户通常会在其计算机系统上配置一些解析名称服务器。解析名称服务器通常由 ISP 或其他组织提供。例如Google 提供解析 DNS 服务器您可以查询。这些可以在您的计算机中自动或手动配置。

当您在浏览器的地址栏中键入 URL 时，您的计算机首先查看是否可以在本地找到资源所在的位置。它检查计算机和其他一些位置上的“hosts”文件。然后，它将请求发送到解析名称服务器，并等待接收资源的 IP 地址。

然后，解析名称服务器检查其缓存中的答案。如果没有找到，它将执行上述步骤。

解析名称服务器基本上压缩了最终用户的请求过程。客户端只需知道询问解析名称服务器资源所在的位置，并确信他们会调查并返回最终答案。

区域文件

我们在上面的过程中提到了“区域文件”和“记录”的概念。

区域文件是名称服务器存储有关其所了解的域的信息的方式。名称服务器知道的每个域都存储在区域文件中。大多数到达普通名称服务器的请求都不是服务器为其提供区域文件的内容。

如果将其配置为处理递归查询（例如解析名称服务器），它将找出答案并返回。否则，它将告诉请求方下一步该去哪里。

名称服务器拥有的区域文件越多，它能够权威地回答的请求就越多。

区域文件描述了一个 DNS“区域”，它基本上是整个 DNS 命名系统的子集。它通常用于仅配置单个域。它可以包含许多记录，这些记录定义了相关域的资源所在位置。

该区的$ORIGIN是默认等于区域最高权限的参数。

因此，如果使用区域文件来配置“example.com.” 域，$ORIGIN将被设置为example.com..

这可以在区域文件的顶部配置，也可以在引用区域文件的 DNS 服务器的配置文件中定义。不管怎样，这个参数描述了该区域的权威性。

同样，$TTL配置其提供的信息的“生存时间”。它基本上是一个计时器。缓存名称服务器可以使用以前查询的结果来回答问题，直到 TTL 值用完。

记录类型

在区域文件中，我们可以有许多不同的记录类型。我们将在这里讨论一些更常见（或强制类型）的类型。

SOA记录

授权开始（SOA）记录是所有区域文件中的强制记录。它必须是文件中的第一个真实记录（尽管$ORIGIN or $TTL规格可能会出现在上面）。它也是最难理解的之一。

权限记录的开头看起来像这样：

domain.com.  IN SOA   ns1.domain.com. admin.domain.com. (
                          12083           ; serial number
                          3h              ; refresh interval
                          30m             ; retry interval
                          3w              ; expiry period
                          1h              ; negative TTL
                          )

让我们解释一下每个部分的用途：

• domain.com.：这是区域的根。这指定区域文件用于domain.com.领域。通常，您会看到它被替换为@，这只是一个占位符，用于替换内容$ORIGIN我们在上面了解到的变量。

• IN SOA：“IN”部分表示互联网（并且将出现在许多记录中）。 SOA 指示这是授权起始记录。

• ns1.domain.com.：这定义了该域的主名称服务器。名称服务器可以是主服务器，也可以是辅助服务器，如果配置了动态 DNS，则一台服务器需要成为“主服务器”，即此处。如果您尚未配置动态 DNS，那么这只是您的主要名称服务器之一。

• admin.domain.com.：这是该区域管理员的电子邮件地址。电子邮件地址中的“@”被替换为点。如果电子邮件地址的姓名部分通常有一个点，则在此部分中将其替换为“”（your.name@domain.com变成your\name.domain.com).

• 12083：这是区域文件的序列号。每次编辑区域文件时，都必须增加此数字，区域文件才能正确传播。辅助服务器将检查主服务器的区域序列号是否大于其系统上的序列号。如果是，则请求新的区域文件，如果不是，则继续提供原始文件。

• 3h：这是区域的刷新间隔。这是辅助服务器在轮询主服务器以查找区域文件更改之前等待的时间。

• 30m：这是该区域的重试间隔。如果在刷新周期结束时辅助节点无法连接到主节点，它将等待一段时间并重试轮询主节点。

• 3w: 这是有效期。如果辅助名称服务器在这段时间内无法联系主名称服务器，它将不再作为该区域的权威源返回响应。

• 1h：如果在此文件中找不到请求的名称，名称服务器将缓存名称错误的时间量。

A 和 AAAA 记录

这两条记录都将主机映射到 IP 地址。 “A”记录用于将主机映射到 IPv4 IP 地址，而“AAAA”记录用于将主机映射到 IPv6 地址。

这些记录的一般格式是这样的：

host     IN      A       IPv4_address
host     IN      AAAA    IPv6_address

因此，由于我们的 SOA 记录调用了主服务器“ns1.domain.com”，我们必须将其映射到 IP 地址的地址，因为“ns1.domain.com” 位于“domain.com” 该文件正在定义的区域。

该记录可能如下所示：

ns1     IN  A       111.222.111.222

请注意，我们不必提供全名。我们可以只提供主机，不需要 FQDN，DNS 服务器将用 FQDN 填充其余部分$ORIGIN价值。然而，如果我们想要语义化，我们也可以轻松地使用整个 FQDN：

ns1.domain.com.     IN  A       111.222.111.222

在大多数情况下，您可以在此处将 Web 服务器定义为“www”：

www     IN  A       222.222.222.222

我们还应该告诉基域解析到哪里。我们可以这样做：

domain.com.     IN  A       222.222.222.222

我们本可以使用“@” 来代替引用基域：

@       IN  A       222.222.222.222

我们还可以选择解析此域下未明确定义到此服务器的任何内容。我们可以用“*” 通配符：

*       IN  A       222.222.222.222

所有这些都与 IPv6 地址的 AAAA 记录一样有效。

别名记录

CNAME 记录定义服务器规范名称的别名（由 A 或 AAAA 记录定义）。

例如，我们可以有一个定义“server1”主机的 A 名称记录，然后使用“www”作为该主机的别名：

server1     IN  A       111.111.111.111
www         IN  CNAME   server1

请注意，这些别名会带来一些性能损失，因为它们需要对服务器进行额外的查询。大多数时候，通过使用额外的 A 或 AAAA 记录可以获得相同的结果。

建议使用 CNAME 的一种情况是为当前区域之外的资源提供别名。

MX 记录

MX 记录用于定义用于域的邮件交换。这有助于电子邮件正确到达您的邮件服务器。

与许多其他记录类型不同，邮件记录通常不会将主机映射到某些内容，因为它们适用于整个区域。因此，它们通常看起来像这样：

        IN  MX  10   mail.domain.com.

注意开头没有主机名。

另请注意，其中有一个额外的数字。如果定义了多个邮件服务器，这是帮助计算机决定将邮件发送到哪个服务器的首选项编号。数字越小，优先级越高。

MX 记录通常应指向由 A 或 AAAA 记录定义的主机，而不是由 CNAME 定义的主机。

所以，假设我们有两个邮件服务器。必须有类似这样的记录：

        IN  MX  10  mail1.domain.com.
        IN  MX  50  mail2.domain.com.
mail1   IN  A       111.111.111.111
mail2   IN  A       222.222.222.222

在此示例中，“mail1”主机是首选电子邮件交换服务器。

我们也可以这样写：

        IN  MX  10  mail1
        IN  MX  50  mail2
mail1   IN  A       111.111.111.111
mail2   IN  A       222.222.222.222

国民服役记录

此记录类型定义用于此区域的名称服务器。

您可能想知道，“如果区域文件驻留在名称服务器上，为什么它需要引用自身？”。 DNS 如此成功的部分原因在于它的多级缓存。在区域文件内定义名称服务器的一个原因是区域文件实际上可能是从另一个名称服务器上的缓存副本提供服务的。需要在名称服务器本身上定义名称服务器还有其他原因，但我们不会在这里讨论。

与 MX 记录一样，这些是区域范围的参数，因此它们也不占用主机。一般来说，它们看起来像这样：

        IN  NS     ns1.domain.com.
        IN  NS     ns2.domain.com.

每个区域文件中应该至少定义两个名称服务器，以便在一台服务器出现问题时能够正常运行。如果只有一个名称服务器，大多数 DNS 服务器软件都会认为区域文件无效。

与往常一样，包括具有 A 或 AAAA 记录的主机的映射：

        IN  NS     ns1.domain.com.
        IN  NS     ns2.domain.com.
ns1     IN  A      111.222.111.111
ns2     IN  A      123.211.111.233

您还可以使用很多其他记录类型，但这些可能是您会遇到的最常见的类型。

PTR记录

PTR 记录用于定义与 IP 地址关联的名称。 PTR 记录是 A 或 AAAA 记录的逆记录。 PTR 记录的独特之处在于它们从.arparoot 并委托给 IP 地址的所有者。区域互联网注册管理机构 (RIR) 管理向组织和服务提供商的 IP 地址授权。区域互联网注册管理机构包括 APNIC、ARIN、RIPE NCC、LACNIC 和 AFRINIC。

以下是 PTR 记录的示例111.222.333.444看起来像：

444.333.222.111.in-addr.arpa.	33692	IN	PTR	host.example.com.

IPv6 地址的 PTR 记录示例显示了nibbleGoogle IPv6 DNS 服务器的反向格式2001:4860:4860::8888.

8.8.8.8.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.6.8.4.0.6.8.4.1.0.0.2.ip6.arpa. 86400IN PTR google-public-dns-a.google.com.

命令行工具dig与-xflag 可用于查找 IP 地址的反向 DNS 名称。

这是 dig 命令的示例。这+short附加以减少反向 DNS 名称的输出。

dig -x 8.8.4.4 +短

上面 dig 命令的输出将是 IP 地址的 PTR 记录中的域名：

google-public-dns-b.google.com.

Internet 上的服务器使用 PTR 记录将域名放入日志条目中，做出明智的垃圾邮件处理决策，并显示​​有关其他设备的易于阅读的详细信息。

最常用的电子邮件服务器将查找从中接收电子邮件的 IP 地址的 PTR 记录。如果源 IP 地址没有关联的 PTR 记录，则发送的电子邮件可能会被视为垃圾邮件并被拒绝。 PTR 中的 FQDN 是否与所发送电子邮件的域名匹配并不重要。重要的是存在有效的 PTR 记录以及相应且匹配的前向 A 记录。

通常，Internet 上的网络路由器都会获得与其物理位置相对应的 PTR 记录。例如，您可能会看到纽约市或芝加哥的路由器引用“NYC”或“CHI”。这在运行时很有帮助追踪路由或地铁并检查互联网流量的路径。

大多数提供专用服务器或 VPS 服务的提供商都会让客户能够为其 IP 地址设置 PTR 记录。当Droplet以域名命名时，DigitalOcean将自动分配任何Droplet的PTR记录。Droplet 名称是在创建过程中指定的，稍后可以使用 Droplet 控制面板的设置页面进行编辑。

中国航空协会记录

CAA 记录用于指定允许哪些证书颁发机构 (CA) 为您的域颁发 SSL/TLS 证书。自 2017 年 9 月 8 日起，所有 CA 在颁发证书之前都必须检查这些记录。如果没有记录，任何 CA 都可以颁发证书。否则，只有指定的 CA 可以颁发证书。 CAA 记录可以应用于单个主机或整个域。

CAA 记录示例如下：

example.com.	IN	CAA	0 issue "letsencrypt.org"

主人，IN，和记录类型（CAA) 是常见的 DNS 字段。上述 CAA 特定信息是0 issue "letsencrypt.org"部分。它由三部分组成：标志（0）、标签（issue）和值（"letsencrypt.org").

• Flags是一个整数，指示 CA 应如何处理它不理解的标签。如果标志是0，该记录将被忽略。如果1，CA必须拒绝颁发证书。
• Tags是表示 CAA 记录用途的字符串。目前他们可以issue授权 CA 为特定主机名创建证书，issuewild授权通配符证书，或iodef定义 CA 可以报告策略违规行为的 URL。
• Values是与记录关联的字符串tag. For issue and issuewild这通常是您授予权限的 CA 的域。为了iodef这可能是联系表单的 URL，或者mailto:电子邮件反馈的链接。

您可以使用dig使用以下选项获取 CAA 记录：

dig example.com type257

有关 CAA 记录的更多详细信息，您可以阅读RFC 6844，或者我们的教程如何使用 DigitalOcean DNS 创建和管理 CAA 记录

结论

您现在应该很好地掌握了 DNS 的工作原理。虽然一旦熟悉了策略，总体思路就相对容易掌握，但对于缺乏经验的管理员来说，付诸实践仍然困难。

如需概览，请查看如何在 DigitalOcean 控制面板中设置域.