介绍
DNS或域名系统通常是学习如何配置网站和服务器的一个非常困难的部分。 了解DNS的工作原理将有助于您诊断配置访问您的网站的问题，并将帮助您拓宽对幕后情况的理解。
在本指南中，我们将讨论一些基本的DNS概念，这些概念将帮助您使用DNS配置运行。 解决这一指南后，您应该准备好或建立你自己的DNS服务器 。
在我们开始设置您自己的服务器以解决您的域或在控制面板中设置我们的域之前，让我们先来看一些关于如何实现所有这些的基本概念。
域名术语
我们应该从定义我们的条款开始。 虽然其中一些主题从其他上下文是熟悉的，但是有许多术语在谈论在其他计算领域中不常使用的域名和DNS时使用。
让我们开始容易：
域名系统
域名系统（通常被称为“DNS”）是网络系统，允许我们将人类友好的名称解析为唯一的地址。
域名
域名是我们习惯于与互联网资源关联的人性化名称。 例如，“google.com”是一个域名。 有些人会说“google”部分是域，但我们通常可以将组合形式称为域名。
网址“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（互联网名称和号码分配公司）对顶级域进行管理控制。 然后，这些参与方可以根据TLD分发域名，通常通过域名注册商。
主机
在域中，域所有者可以定义单独的主机，这些主机是指通过域可访问的单独的计算机或服务。 例如，大多数站点所有者使他们的网络服务器通过裸域访问（example.com）并通过了“主机”的定义“WWW”（ www.example.com ）。
您可以在一般域下拥有其他主机定义。 您可以通过“api”主机（api.example.com）访问API，也可以通过定义名为“ftp”或“files”（ftp.example.com或files.example.com）的主机来访问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标准。
Nameservers
Nameservers是指定将域名转换为IP地址的计算机。 这些服务器在DNS系统中完成大部分工作。 由于域翻译的总数对于任何一个服务器来说过多，因此每个服务器可以将请求重定向到其他Nameservers或委派他们负责的子域的子集的责任。
Nameservers可以是“权威的”，意味着他们给出关于他们控制下的域的查询的答案。 否则，它们可能指向其他服务器，或者提供其他Nameservers数据的缓存副本。
区域文件
区域文件是一个简单的文本文件，包含域名和IP地址之间的映射。 这是DNS系统最终找出当用户请求某个域名时应联系哪个IP地址的方式。
区域文件驻留在Nameservers中，通常定义特定域下可用的资源，或者可以去获取该信息的位置。
记录
在区域文件中，保留记录。 在最简单的形式中，记录基本上是资源和名称之间的单个映射。 这些可以将域名映射到IP地址，定义域的Nameservers，定义域的邮件服务器等。
DNS的工作原理
现在您已经熟悉DNS所涉及的一些术语，系统如何实际工作？
系统在高级概述中非常简单，但是当您查看详细信息时，它非常复杂。 总的来说，它是一个非常可靠的基础设施，对于通过互联网，今天我们知道是至关重要的。
根服务器
如上所述，DNS的核心是一个分层系统。 在这个系统的顶部是所谓的“根服务器”。 这些服务器由各种组织控制，并由ICANN（互联网名称和数字地址分配公司）授权。
目前有13个根服务器正在运行。 但是，由于每分钟都要解析的名称数量令人难以置信，因此每个服务器实际上都已镜像。 有关此设置的有趣的事情是，单个根服务器的每个镜像共享相同的IP地址。 当对某个根服务器发出请求时，请求将路由到该根服务器的最近的镜像。
这些根服务器做什么？ 根服务器处理有关顶级域的信息的请求。 因此，如果请求来自低级别Nameservers无法解析的内容，则会向该域的根服务器进行查询。
根服务器实际上不知道托管域的位置。 然而，他们将能够将请求者引导到处理特定请求的顶级域的Nameservers。
所以，如果“请求www.wikipedia.org ”是对根服务器进行，根服务器会告诉找不到结果在其记录。 它会检查其区域文件相匹配“的列表www.wikipedia.org ”。 它不会找到一个。
它将改为找到“org”TLD的记录，并给请求实体负责负责“org”地址的Nameservers的地址。
TLD服务器
请求者然后向负责该请求的顶级域的IP地址（由根服务器给予它）发送新请求。
所以，继续我们的例子中，它将发送至负责知道关于“组织”的域以确定它是否知道“，其中的Nameservers的请求www.wikipedia.org ”所在。
再次，请求者将寻找“ www.wikipdia.org在其区域文件”。 它不会在其文件中找到此记录。
但是，它会找到一个记录，列出负责“wikipedia.org”的Nameservers的IP地址。 这越来越接近我们想要的答案。
域级别Nameservers
此时，请求者具有负责知道资源的实际IP地址的Nameservers的IP地址。 它再次发送到域名服务器问，一个新的请求，如果它可以解决“ www.wikipedia.org ”。
Nameservers检查其区域文件，并发现它有一个与“wikipedia.org”相关联的区域文件。 在此文件内部，有一个“www”主机的记录。 此记录说明此主机所在的IP地址。 Nameservers向请求者返回最终答案。
什么是解析Nameservers？
在上面的场景中，我们引用了“请求者”。 在这种情况下请求者是什么？
在几乎所有情况下，请求者将是我们所谓的“解析Nameservers”解析Nameservers是配置为询问其他服务器的问题。 它基本上是一个用户的中介，它缓存先前的查询结果以提高速度，并且知道根服务器的地址，以便能够“解析”它不知道的事情的请求。
基本上，用户通常会在其计算机系统上配置几个解析Nameservers。 解析Nameservers通常由ISP或其他组织提供。 例如谷歌提供解析的DNS服务器 ，你可以查询。 这些可以在计算机中自动或手动配置。
当您在浏览器的地址栏中键入网址时，您的计算机将首先查看是否可以在本地找到资源所在的位置。 它检查计算机上的“主机”文件以及其他几个位置。 然后它将请求发送到解析Nameservers，并等待接收资源的IP地址。
解析Nameservers然后检查其缓存的答案。 如果没有找到它，它将通过上述步骤。
解析Nameservers基本上压缩了最终用户的请求过程。 客户端只需要知道请求资源所在的解析Nameservers，并且确信他们将调查并返回最终答案。
区域文件
我们在上面的过程中提到了“区域文件”和“记录”的想法。
区域文件是Nameservers存储他们所知道的域的信息的方式。 Nameservers知道的每个域都存储在区域文件中。 大多数请求来到平均Nameservers不是服务器将具有区域文件的。
如果它被配置为处理递归查询，如解析Nameservers，它将找到答案并返回它。 否则，它将告诉请求方下一步看哪里。
Nameservers具有的区域文件越多，它将能够权威回答的请求越多。
区域文件描述DNS“区域”，其基本上是整个DNS命名系统的子集。 它通常用于配置只有一个域。 它可以包含多个记录，这些记录定义了所讨论的域的资源位置。
该区域的$ORIGIN等于默认情况下，区域的权威最高水平的参数。
所以如果一个区域文件用于配置“example.com”。 域中， $ORIGIN将被设置为example.com.
这可以在区域文件的顶部进行配置，也可以在引用区域文件的DNS服务器的配置文件中定义。 无论哪种方式，此参数描述区域将是什么权威。
同样， $TTL配置“生存时间”它提供的信息。 它基本上是一个计时器。 缓存Nameservers可以使用先前查询的结果来回答问题，直到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 ; exiry period
1h ; negative TTL
)
让我们解释每个部分是什么：
domain.com：这是该区域的根。 这指定区域文件是为
domain.com.域。 通常情况下，你会看到这个换成@，这只是代替了内容的占位符$ORIGIN我们上面左右学到变量。在SOA中 ：在“IN”部分是指互联网（以及将存在于多条记录）。 SOA是指示这是权限开始记录的指示符。
ns1.domain.com：这定义了该领域主要的主Nameservers。 Nameservers可以是主服务器或从服务器，如果配置动态DNS，则一个服务器需要是“主服务器”，这是在这里。 如果您尚未配置动态DNS，那么这只是您的主Nameservers之一。
admin.domain.com：这是管理员该区域的电子邮件地址。 “@”替换为电子邮件地址中的点。 如果电子邮件地址的名称部分通常有一个句点，这是在这部分“\”替换（ your.name@domain.com成为你\ name.domain.com）。
12083：这是区域文件的序列号。 每次编辑区域文件时，必须增加此编号以使区域文件正确传播。 从服务器将检查主服务器的区域序列号是否大于它们在系统上的序列号。 如果是，它请求新的区域文件，如果不是，它继续服务原始文件。
3小时 ：这是该区域的刷新间隔。 这是从站在轮询主站以更改区域文件之前等待的时间量。
30米 ：这是此区域的重试间隔。 如果从机在刷新周期结束时无法连接到主机，则它将等待此时间并重试轮询主机。
3瓦特 ：这是到期期限。 如果从属Nameservers在此时间内无法与主服务器联系，则它不再返回作为此区域的权威来源的响应。
1H：这是时间的Nameservers缓存的名称错误，如果它不能找到这个文件请求的名称数量。
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服务器将填充其余的$ ORIGIN值。 但是，如果我们感觉像是语义的话，我们可以轻松地使用整个FQDN：
ns1.domain.com. IN A 111.222.111.222
在大多数情况下，您需要将网络服务器定义为“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记录定义的名称）定义规范名称的别名。
例如，我们可以有一个A名称记录定义“server1”主机，然后使用“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记录
此记录类型定义用于此区域的Nameservers。
你可能想知道，“如果区域文件驻留在Nameservers上，为什么它需要引用自身？ 使DNS如此成功的部分原因是它的多级缓存。 在区域文件中定义Nameservers的一个原因是区域文件可能实际上是从另一个Nameservers上的缓存副本提供的。 还有其他原因需要在Nameservers本身定义的Nameservers，但我们不会在这里。
与MX记录一样，这些是区域范围的参数，因此它们也不占用主机。 一般来说，它们看起来像这样：
IN NS ns1.domain.com.
IN NS ns2.domain.com.
您应该在每个区域文件中至少定义两个Nameservers，以便在一个服务器出现问题时正确运行。 如果只有一个Nameservers，大多数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.
PTR记录为IPv6地址的这个例子显示了谷歌的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与-x标志可用于查找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与要发送的电子邮件的域名相匹配并不重要。 重要的是存在具有对应的和匹配的前向A记录的有效PTR记录。
通常，互联网上的网络路由器被给予与其物理位置相对应的PTR记录。 例如，您可能会在纽约市或芝加哥看到对“NYC”或“CHI”的引用。 在运行时，这是有帮助的traceroute的或地铁和审查的路径互联网流量正在采取。
大多数供应商提供的专用的服务器或VPS服务将给客户设置一个PTR记录他们的IP地址的能力。 当Droplet被命名为与域名DigitalOcean会自动分配任何Droplet的PTR记录。Droplet名字创建过程中分配并可以稍后使用Droplet控制面板的设置页面进行编辑。
注意：这是非常重要的FQDN在PTR记录都有相应的匹配和向前的记录。 示例：111.222.333.444具有server.example.com的PTR，server.example.com是指向111.222.333.444的A记录。
结论
你现在应该很好地掌握DNS的工作原理。 虽然一般的想法是相对容易掌握一旦你熟悉的策略，这仍然是一个对于没有经验的管理员很难实施。
有关概述检查出 。
