介绍
DNS 或域名系统通常是学习如何配置网站和服务器的一个非常困难的部分。 了解 DNS 的工作原理将帮助您诊断配置对网站的访问的问题，并将让您扩大对幕后发生的事情的理解。
在本指南中，我们将讨论一些基本的 DNS 概念，这些概念将帮助您开始使用 DNS 配置。 完成本指南后，您应该准备好 使用 DigitalOcean 设置您的域名或 设置您自己的 DNS 服务器 。
在我们开始设置您自己的服务器以解析您的域或在控制面板中设置我们的域之前，让我们回顾一下有关所有这些实际工作原理的一些基本概念。
领域术语
我们应该从定义我们的术语开始。 虽然其中一些主题在其他环境中很熟悉，但在谈论域名和 DNS 时使用了许多在其他计算领域不常使用的术语。
让我们从简单的开始：
域名系统
域名系统，通常称为“DNS”，是一种网络系统，它允许我们将人类友好的名称解析为唯一的 IP 地址。
域名
域名是我们习惯于与互联网资源相关联的人性化名称。 例如，“google.com”是一个域名。 有人会说“google”部分就是域名，但我们一般可以将组合形式称为域名。
URL “google.com” 与 Google Inc. 拥有的服务器相关联。 当我们在浏览器中输入“google.com”时，域名系统允许我们访问 Google 服务器。
IP地址
IP 地址就是我们所说的网络可寻址位置。 每个 IP 地址在其网络中必须是唯一的。 当我们谈论网站时，这个网络就是整个互联网。
IPv4 是最常见的地址形式，写成四组数字，每组最多三位数字，每组以点分隔。 例如，“111.222.111.222”可能是有效的 IPv4 IP 地址。 使用 DNS，我们将名称映射到该地址，这样您就不必为网络上要访问的每个地方记住一组复杂的数字。
顶级域
顶级域或 TLD 是域中最通用的部分。 顶级域是最右边的部分（由点分隔）。 常见的顶级域是“com”、“net”、“org”、“gov”、“edu”和“io”。
就域名而言，顶级域位于层次结构的顶部。 ICANN（Internet Corporation for Assigned Names and Numbers）授予某些各方对顶级域的管理控制权。 然后，这些各方可以在 TLD 下分发域名，通常是通过域名注册商。
主机
在域内，域所有者可以定义单独的主机，这些主机指的是可通过域访问的单独计算机或服务。 例如，大多数域所有者通过裸域 (example.com) 以及通过“主机”定义“www” (www.example.com) 来访问他们的 Web 服务器。
您可以在通用域下拥有其他主机定义。 您可以通过“api”主机（api.example.com）获得 API 访问权限，或者通过定义名为“ftp”或“文件”的主机（ftp.example.com 或 [X150X）获得 ftp 访问权限]）。 主机名可以是任意的，只要它们对于域是唯一的。
子域
与主机相关的主题是子域。
DNS 在层次结构中工作。 TLD 下可以有许多域。 例如，“com”TLD 在其下方同时具有“google.com”和“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 地址的方式。
区域文件驻留在名称服务器中，通常定义特定域下可用的资源，或者可以去获取该信息的位置。
记录
在区域文件中，记录被保存。 在最简单的形式中，记录基本上是资源和名称之间的单一映射。 这些可以将域名映射到 IP 地址、定义域的名称服务器、定义域的邮件服务器等。
DNS 的工作原理
既然您已经熟悉了与 DNS 相关的一些术语，那么该系统实际上是如何工作的？
该系统在高级概述中非常简单，但在您查看细节时非常复杂。 总的来说，它是一个非常可靠的基础设施，对于我们今天所知的互联网的采用至关重要。
根服务器
正如我们上面所说，DNS 的核心是一个分层系统。 该系统的顶部是所谓的“根服务器”。 这些服务器由各种组织控制，并由 ICANN（互联网名称与数字地址分配机构）授权。
目前有 13 台根服务器在运行。 但是，由于每分钟要解析的名称数量惊人，因此这些服务器中的每一个实际上都是镜像的。 这种设置的有趣之处在于，单个根服务器的每个镜像共享相同的 IP 地址。 当对某个根服务器发出请求时，请求将被路由到该根服务器最近的镜像。
这些根服务器是做什么的？ 根服务器处理有关顶级域信息的请求。 因此，如果请求进入较低级别的名称服务器无法解析的内容，则会对域的根服务器进行查询。
根服务器实际上并不知道域的托管位置。 但是，他们将能够将请求者定向到处理特定请求的顶级域的名称服务器。
因此，如果向根服务器发出“www.wikipedia.org”请求，根服务器将不会在其记录中找到结果。 它将检查其区域文件以查找匹配“www.wikipedia.org”的列表。 它不会找到一个。
相反，它将查找“org”TLD 的记录，并向请求实体提供负责“org”地址的名称服务器的地址。
顶级域名服务器
然后，请求者向负责请求的顶级域的 IP 地址（由根服务器提供）发送一个新请求。
因此，继续我们的示例，它将向负责了解“org”域的名称服务器发送一个请求，以查看它是否知道“www.wikipedia.org”的位置。
再一次，请求者将在其区域文件中查找“www.wikipedia.org”。 它不会在其文件中找到此记录。
但是，它会找到一条记录，其中列出了负责“wikipedia.org”的名称服务器的 IP 地址。 这离我们想要的答案越来越近了。
域级名称服务器
此时，请求者拥有名称服务器的 IP 地址，该名称服务器负责了解资源的实际 IP 地址。 它向名称服务器发送一个新请求，再次询问它是否可以解析“www.wikipedia.org”。
名称服务器检查它的区域文件，发现它有一个与“wikipedia.org”关联的区域文件。 在这个文件中，有一条“www”主机的记录。 这条记录告诉了这个主机所在的 IP 地址。 名称服务器将最终答案返回给请求者。
什么是解析名称服务器？
在上述场景中，我们提到了“请求者”。 在这种情况下，请求者是什么？
在几乎所有情况下，请求者都是我们所说的“解析名称服务器”。 解析名称服务器是一种配置为询问其他服务器问题的服务器。 它基本上是用户的中介，它缓存以前的查询结果以提高速度，并知道根服务器的地址，以便能够“解析”对它还不知道的事物的请求。
基本上，用户通常会在其计算机系统上配置一些解析名称服务器。 解析名称服务器通常由 ISP 或其他组织提供。 例如 Google 提供解析 DNS 服务器 供您查询。 这些可以在您的计算机中自动或手动配置。
当您在浏览器的地址栏中键入 URL 时，您的计算机首先会查看它是否可以在本地找到资源所在的位置。 它检查计算机和其他一些位置上的“主机”文件。 然后它将请求发送到解析名称服务器并等待接收资源的 IP 地址。
解析名称服务器然后检查其缓存以获取答案。 如果它没有找到它，它会执行上述步骤。
解析名称服务器基本上压缩了最终用户的请求过程。 客户端只需知道向解析名称服务器询问资源所在的位置，并确信他们会调查并返回最终答案。
区域文件
我们在上面的过程中提到了“区域文件”和“记录”的概念。
区域文件是名称服务器存储有关它们所知道的域的信息的方式。 名称服务器知道的每个域都存储在区域文件中。 大多数到达普通名称服务器的请求都不是服务器拥有区域文件的东西。
如果它被配置为处理递归查询，如解析名称服务器，它将找出答案并返回。 否则，它将告诉请求方下一步要查找的位置。
名称服务器拥有的区域文件越多，它能够权威地回答的请求就越多。
区域文件描述了一个 DNS “区域”，它基本上是整个 DNS 命名系统的一个子集。 它通常用于仅配置单个域。 它可以包含许多记录，这些记录定义了相关域的资源在哪里。
zone的$ORIGIN是默认等于zone最高权限的参数。
因此，如果使用区域文件配置“example.com.”域，则 $ORIGIN 将设置为 example.com.。
这可以在区域文件的顶部进行配置，也可以在引用区域文件的 DNS 服务器的配置文件中定义。 无论哪种方式，此参数都描述了该区域的权威性。
同样，$TTL 配置它提供的信息的“生存时间”。 它基本上是一个计时器。 缓存名称服务器可以使用先前查询的结果来回答问题，直到 TTL 值用完。
记录类型
在区域文件中，我们可以有许多不同的记录类型。 我们将在这里讨论一些更常见的（或强制类型）。
SOA 记录
授权开始或 SOA 记录是所有区域文件中的强制性记录。 它必须是文件中的第一个真实记录（尽管上面可能会出现 $ORIGIN 或 $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”在“[ X162X]” 该文件定义的区域。
记录可能如下所示：
ns1 IN A 111.222.111.222
请注意，我们不必提供全名。 我们可以只给主机，没有 FQDN，DNS 服务器将用 $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 记录
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
NS记录
此记录类型定义用于此区域的名称服务器。
您可能想知道，“如果区域文件驻留在名称服务器上，为什么它需要引用自身？”。 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 记录是独一无二的，因为它们从 .arpa 根开始并委托给 IP 地址的所有者。 地区互联网注册管理机构 (RIR) 管理对组织和服务提供商的 IP 地址委派。 地区互联网注册机构包括 APNIC、ARIN、RIPE NCC、LACNIC 和 AFRINIC。
以下是 111.222.333.444 的 PTR 记录示例：
444.333.222.111.in-addr.arpa. 33692 IN PTR host.example.com.
此 IPv6 地址的 PTR 记录示例显示了与 Google 的 IPv6 DNS 服务器 2001:4860:4860::8888 反向的 nibble 格式。
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.
带有 -x 标志的命令行工具 dig 可用于查找 IP 地址的反向 DNS 名称。
以下是 dig 命令的示例。 附加 +short 以减少反向 DNS 名称的输出。
dig -x 8.8.4.4 +short
上面 dig 命令的输出将是 IP 地址的 PTR 记录中的域名：
google-public-dns-b.google.com.
Internet 上的服务器使用 PTR 记录将域名放置在日志条目中，做出明智的垃圾邮件处理决策，并显示有关其他设备的易于阅读的详细信息。
最常用的电子邮件服务器会查找它接收电子邮件的 IP 地址的 PTR 记录。 如果源 IP 地址没有与之关联的 PTR 记录，则发送的电子邮件可能会被视为垃圾邮件并被拒绝。 PTR 中的 FQDN 是否与正在发送的电子邮件的域名相匹配并不重要。 重要的是有一个有效的 PTR 记录和对应的匹配前向 A 记录。
通常，Internet 上的网络路由器会获得与其物理位置相对应的 PTR 记录。 例如，您可能会在纽约市或芝加哥看到对路由器的“NYC”或“CHI”的引用。 这在运行 traceroute 或 MTR 并查看 Internet 流量所采用的路径时很有帮助。
大多数提供专用服务器或 VPS 服务的提供商都会让客户能够为其 IP 地址设置 PTR 记录。 DigitalOcean 会在任何Droplet 使用域名命名时自动分配PTR 记录。 Droplet 名称是在创建过程中分配的，以后可以使用Droplet 控制面板的设置页面进行编辑。
注意： 重要的是PTR记录中的FQDN有一个对应且匹配的前向A记录。 示例：111.222.333.444 的 PTR 为 server.example.com，server.example.com 是指向 111.222.333.444 的 A 记录。
民航局记录
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来定义一个 URL，CA 可以在其中报告策略违规. - Values 是与记录的 tag 关联的字符串。 对于
issue和issuewild，这通常是您授予权限的 CA 的域。 对于iodef，这可能是联系表单的 URL，或用于电子邮件反馈的mailto:链接。
您可以使用 dig 使用以下选项获取 CAA 记录：
dig example.com type257
有关 CAA 记录的更多详细信息，您可以阅读 RFC 6844，或我们的教程 如何使用 DigitalOcean DNS 创建和管理 CAA 记录
结论
您现在应该很好地掌握了 DNS 的工作原理。 虽然一旦您熟悉了该策略，总体思路相对容易掌握，但对于没有经验的管理员来说，这仍然很难付诸实践。
有关概述，请查看 如何在 DigitalOcean 控制面板 中设置域。
