介绍

什么是DNS，DNS的全称是域名系统（Domain Name System）,DNS是在学习配置一个站点或者服务时比较难的一个部分。理解DNS如何工作的原理对你诊断站点访问配置问题带来帮助，同时也能加深你对它背后的运行机制的理解。

在这篇文章中，我们将会讨论一些关于DNS的基本概念，这些概念会在你配置DNS时更好地帮助到你。当然在学习这篇文章前，如果你手头已经有一个域名那就更好了。

在我们准备开始配置你的站点的域名解析或者在后台控制面板配置域名之前，让我们先学习下关于DNS如何工作的相关概念。

Domain域的概念

我们应该从定义术语开始。在讨论关于域名和DNS时，虽然其中一些主题在其他上下文中很熟悉，但是在讨论域名和DNS时使用的许多术语在其他计算领域中并不常用。让我们开始吧：

Domain Name System 域名系统

域名系统(通常称为“DNS”)是一种网络系统，它允许我们将对人类友好的名称解析为惟一的地址。

Domain Name 域名

一个域名是我们用来关联换一个互联网资源的一个人性化的名字。举个例子，比如google.com就是一个域名。当然有些人觉得其中的google就是域名，但是我们通常把google.com这个组合称为域名。

IP Address IP地址

IP地址就是我们说的网络定位寻址。在网络中的每一个IP地址都必须唯一。当我们讨论网站时，我们说的这个网络指代的就是我们的因特网。

IPv4是最最常见的网络地址形式，他是由4组数字，每组由三个数字构成，组与组之间用点号分割。比如"111.222.111.222"就是一个有效的IPv4的IP地址。使用DNS，我们可以映射一个名字到我们的地址，这样我们在想要在网络上访问的时候，就不需要记忆那串复杂的数字了。

Top-Level Domain 顶级域名

顶级域名又称TLD是域名中最常见的部分。是互联网DNS等级之中的最高级的域，它保存于DNS根域的名字空间中。顶级域名是域名的最后一个部分，即是域名最后一点之后的字母，例如在example.com这个域名中，顶级域是.com（或.COM），大小写视为相同。 wiki

顶级域名是指域名中的最高层级。这个部分是由ICANN（互联网名称与数字地址分配机构）进行管理分配的，通过域名注册商在TLD下分发。

Host 主机

有了域名，你就可以定义独立的host主机，来通过域名访问不同的计算机和服务。举个例子，大多数域名拥有者会让他们的域名既能通过 (example.com)访问也能通过host主机定义的"www"（www.example.com）来访问。

你也可以定义其他host主机名。比如：你可以定义api这个host，通过api.example.com来访问API或者你也可以定义ftp，或者files的host然后通过(ftp.example.com或者files.example.com)来访问。对于一个域名它底下的host名称可以随意只要保证在该域名下唯一就可以。

SubDomain 子域名

和host主机名相关的一个主题就是子域名。

DNS的有层级的。TLD顶级域名底下可以有很多的域名。比如:"com"这个顶级域名下面会有"google.com"和"ubuntu.com"等域名。子域名是指的一个更大域名底下的那些域名。比如这个例子中的"ubuntu.com"就可以被称作com的一个子域名。我们把其中的ubuntu成为是一个 SLD 二级域名（Secode level domain）。

也就是时候，每个域名可以控制位于它底下的所有子域名。也就是我们通常说的通过子域名。比如你可以为你学学校的历史系分配一个子域名 "www.history.school.edu"。其中的history部分就是一个子域名。

host name主机名和subdomin子域名之间的区别是，一个host主机定义了一台计算机或者一个资源。而subdomain是继承自父域名。他是一种细分域名本身的方法。

不管是讨论子域名还是主机host，你都可以发现在一个域名越靠近左侧的部分就越特殊。这就是DNS的工作原理：当你从左往右阅读的时候，就是从特殊到非特殊的过程。

全限定域名

全限定域名，经常被称为 FQDN。就是我们所说的绝对域名。域名在DNS域名系统中可以通过相对位置来关联其他部分。因此也就可能比较模糊。FQDN是一个绝对的名字用来指定他和域名系统的绝对根位置的位置关系。

也就是说指定每个父级域名包括TLD顶级域名。一个正确的FQDN以一个点号结尾，表示DNS层次结构中的根。举个FQDN中的例子"mail.google.com."。有些软件在调用FQDN时并不需要结尾的点，但是尾部的点号对于一个标准的ICANN形式是必须的。

Name Server 名字服务器

名字服务器是一台设计用来转换域名到IP地址的计算机。这些服务器在DNS域名系统中做很多事情。因为这么多数量的域名转换工作如果都让一台服务器来干太多了，因此每台服务器把请求重定向到其他名字服务器或当他们响应时委派响应给他们的子域名。

名字服务器是有"权威性"的，也就是说他们为他们底下控制的域名提供查询域名的答案。否则，他们就指向其他服务器，或者缓存其他名字服务器的数据。

Zone File 区域文件

一个区域文件是一个简单的文本包含了域名名字和IP地址之间的映射。这也是当用户发起一个具体的域名请求时DNS服务器能够最终找到要联系的IP地址的原因。

区域文件存放在域名服务器上，通常定义了指定域名下可以访问的资源或者能否获得信息的地方。

Record 记录

在区域文件上，还会有record记录。它的最简单的形式——一条记录就是一条从资源到名字的单一映射。这样可以映射一个域名到一个IP地址，为域名定义名字服务，为域名定义邮件服务等等。

DNS的工作原理

现在你已经对DNS的相关概念已经有个大致的了解了，那这套系统究竟是如何运转的？

从宏观上看，这套系统非常的简单。但是当你仔细去看的时候却又非常复杂。总之一句话它是当今互联网采用的非常可靠的基础设施。

Root Server 根服务器

正如我们上面所说的，DNS它的核心是一套层级系统。在这套系统的顶层就是我们所称的根服务器（root server）。这些服务器被各种组织所控制，并有ICANN（互联网名称与数字地址分配机构）授权。

全球目前有13台根服务器。然而，因为每分钟有无数的名字要处理，所以事实上有很多这些服务器的镜像。有意思的是这些镜像服务器的IP竟然和单根服务器共享同样的IP地址。当请求要发送到一台根服务器，这个请求会被路由到最近的镜像根服务器上。

那么这些跟服务器都做什么？根服务器处理关于顶级域名信息的请求。因此如果一个请求在低层级的域名服务器上无法解决，就会查询域名的根服务器。

根服务器实际上并不真的知道域名主机在哪。它们会把请求指向处理指定顶级域名的名字服务器来处理。

所以如果产生了一个发送给根服务器的请求比如"www.wikipedia.org"，根服务器如果在它的record记录中没有找到结果。它会检查它的区域文件查看是否有匹配"www.wikipedia.org"。当然它不会找不到。

相反它会找到一条关于TLD"org"的记录，然后把org地址的名字服务器的地址返回。

TLD Server 顶级域名服务器

请求者然后发送一条新的请求到新地址（根服务器提供的），这就是顶级域名对这条请求的响应。

所以，为了继续我们的这个例子，它会发送一条请求到名字服务器来响应这个已知的org域名，来查看是否有"www.wikipedia.org"的下落。

这次，请求者会查找它的区域文件。在它的文件记录里还是找不到。

然而，它会找到一条负责"wikipedia.org"这个名字的服务器的IP地址。现在已经离我们想要的答案又近了一步。

Domain-Level Name Server 域名级名字服务器

此时此刻，请求者已经有了负责处理这个资源的实际IP的名字服务器的IP地址。它发送一条新的氢气到这个名字服务器来询问，看这台服务器是否能解决"www.wikipedia.org"。

名字服务器检查他的区域文件，并找到与这个wikipedia.org相关联的一条区域文件。在这个文件中，这里有一条关于"www"host的记录。这条记录里交待了这个主机的具体IP地址。然后名字服务器把最终的答案返回给了请求者。

什么是名字解析服务器？

在上面的场景里，我们提到的"请求者"。在这个场景中到底什么是Requester？

在几乎所有的例子中，请求者就是我们所谓的"名字解析服务器"。一台名字解析服务器是一台被配置用来询问其他服务器问题的。对于用户来说它就好比一个中介，通过缓存之前的查询结果来提高速度，它也知道哪些能够解决他还不知道的相关请求的根服务器的地址。

基本上，用户通常很少在他们的电脑上配置域名服务器。域名解析服务器通常是由ISP或者其他组织来提供的。比如你可以查询Google提供的DNS服务器。当然这些你可以在你的电脑上自动配置或者手动配置。

当你在浏览器的地址栏里输入一个URL地址时，你的计算机首先查看本地看资源是否已经定位。它通过检查计算机上的hosts文件和一些其他定位文件。然后发起请求到名字解析服务器等待接受资源对应的IP地址。

名字解析服务器器然后检查检查它的缓存看是否能够找到答案。如果没有找到，然后它就会走之前说的那些步骤。

名字解析服务器通常会为最终用户压缩请求处理的进度。客户端只需要询问名字解析服务器资源所在位置，并确信他们会返回最终答案。

Zone File 区域文件

在上面的过程中我们提到了"Zone File"区域文件和"record"记录。

区域文件是用来给名字服务器存储他们所知道的域名信息的的地方。名字服务器知道的每一个域名都存储在一个区域文件中。对于进入到普通名字服务器的大多数请求都不需要服务器通过区域文件来查询。

如果它被配置为递归查询，就像一个名字解析服务器，他会查找到答案并返回。否则，他会告诉请求方下一步应该去哪里查。

一个名字服务器拥有的Zone File 区域文件越多，他需要应答的请求也就越多。

一个区域文件描述一个DNS的区域，这是整个DNS域名系统的子集。它通常被用来配置一个单一的域名。它可以包含多条记录用来定义请求中的域名所对应的资源在哪。

默认情况下Zone中的$ORIGIN是一个参数等价于区域中最高权限级别。

所以如果一个区域文件被用来配置一个"example.com."的域名，这个$ORIGIN就要被设置为 example.com. 。

这配置在区域文件的顶部或者也可以定义在DNS服务器配置文件引用区域文件。无论哪种方式，这个参数都表示了这个Zone文件代表的文件。

同样的，$TTL用来配置"time to live"的信息。他基本上是一个定时器。用来表示一个缓存，名字服务器可以使用它之前的查询结果直到TTL时间用完为止。

Record 记录类型

在一个区域文件中，我们可以使用不同的记录类型。一会我们会讨论一些常见的类型（或者强制类型）。

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. :这是区域的根。这里指定这个zone文件是给 domain.com. 这个域名的。当然，经常你会看到这里会用@，他是一个占位符替代我们上文中的 $ORIGN。
IN SOA:"IN"这个部分的意思是internet（在很多记录中会出现）。SOA是指示符用来用来表示这是一个SOA记录。
ns1.domain.com.:这里定义了这个域名的主名字服务器。名字服务器可以是主服务器或者从服务器。如果动态DNS被配置，那这里就需要一台主服务器。如果你没有配置动态DNS，这里就只是一个你的主名字服务器。
admin.domain.com.:这里是这个zone区域的管理员的email地址。email地址中的@被替代为一个点。如果邮箱地址中有点那么需要使用一个""反斜杠来替代，比如your.name@domain.com（需要写成your\name.domain.com)。
12083:这个是zone文件的序列号。每次你编辑一个zone文件，你必须要要增加一次这个文件的这个数字让它正确传播。从服务器会检查主服务器的zone文件的序列号是否比他们系统里现有的序列号大。如果是，它就会请求一个新的zone文件，否则就继续使用老的文件。
3h:这个是zone文件的刷新间隔周期。从机会等待这个时间周期然后轮询主机，检查zone文件变化。
30m: 这是重试zone文件的间隔时间。如果从机在刷新时间到达后无法连接主机，他会等待一段时间并重新尝试轮询主机。
3w: 过期时间。如果一个名字服务器从机在这个时间段里无法连接服务器，它就不能作为这个区域的权威来发挥响应
1h: 这个时间段是名字服务器缓存一个名字错误的时间量，如果它不能在文件中找到请求的名字。

A和AAAA记录

这些记录都映射一个host到一个IP地址。A记录是被用来应一个host到一个IPv4的IP地址，而AAAAA记录则是用来映射一个host到一个IPv6的地址。

这些记录的常规格式

host IN A    IPv4_address
host IN AAAA IPv6_address

我们的SOA记录调用我们的ns1.domain.com的主服务器。我们需要映射它到一个IP地址，因为ns1.domain.com中的domain.com的zone文件以及定义了。

这个记录看起来像下面这样：

ns1 IN A 111.222.111.222

注意我们不需要指定全名称。我们只需要给定host，不需要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

上面的这些同样适用于AAAA记录来配置IPv6地址

CNAME记录

CNAME记录定义了一个给定的服务（一个通过A记录或者AAAA记录定义的）名字的别名。

例如：我们已经定义了一条A记录叫server1的host，然后使用www来定义一个这个host的一个别名：

server1     IN  A       111.111.111.111
www         IN  CNAME   server1

需要注意的是这些别名会带来一些性能上的损失，应为他们需要对服务器做额外的查询。绝大多数时候，同样的结果可以通过使用A或者AAAA记录来完成。

只有一种情况下推荐使用CNAME，就是为当前区域以外的资源提供别名。

MX记录

MX记录是被用来定义域名邮件交换。这可以帮助邮件消息正确到达邮件服务器。

不像许多其他的记录类型，邮件记录生成不需要映射host到什么事情上，因为他们使用本Zone，因此他们看起来像这样：

   IN  MX  10   mail.domain.com.

注意开头没有host名称

同时还要注意这里的一个额外的数字。这个数字是帮助计算机决定发送到哪台邮件服务器如果定义了多台邮件服务器的话。数字越低拥有越高的优先级。

MX记录通常应该指向一台A或者AAAA记录定义的host，而不是用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的host是首先的邮件交换服务器。

我们也可以写成下面这样

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

NS记录

这个记录类型定义了名字服务器被这个zone使用

你可能回想，如果zone文件放在了名字服务器，为啥还需要引用他自己？DNS之所以如此的成功，是因为使用了几多的缓存。在zone文件中定义名字服务器的一个原因是zone文件可以被从一个缓存拷贝到另一个名字服务器。当然在自己的名字服务器上定义名字服务还有其他的原因，但是我们现在还没有到那一步。

就像MX记录，这里是区域范围参数，所以他们就不用关心host。他们如下

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

为了在其中一个服务器出问题时，能够正确的操作，你可能有两个名字名字服务器，每一个都定义了zone文件。绝大多数DNS服务器软件都会把只有单一的名字服务的zone文件看做是失效的。

通常情况下，都会影杀host到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（Regional Internet Registries）区域互联网注册机构管理IP地址代理给组织和服务提供商。RIR包括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.

命令行工具dig带上-x标志可以用来查询反向DNS服务器的IP地址

这里是一个dig命令的例子。附加的+short是用来减少反向DNS名字输出的。

$ dig -x 8.8.4.4 +short

执行上面的那条命令，你会看到PTR记录对于IP地址所对应的域名

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

互联网上的服务器使用PTR记录来把域名放到日志条目中，做出明智的垃圾邮件处理决策，并显示其他设备的易读的详细信息。

最大多数常用的邮件服务器都会查询PTR记录在接收邮件的时候。如果来源IP地址没有PTR记录的关联信息，发送的邮件会被当成垃圾邮件并被拒接。PTR中的FQDN与正在发送的电子邮件的域名匹配并不重要。重要的是，存在具有相应且匹配的前向A记录的有效PTR记录。

通常互联网上的网络路由提供对应他们物理地址的PTR记录。例如你可以看到在纽约和芝加哥引用NYC或者CHI作为路由。这对于运行traceroute或者MTR或者查看英特网流量所采用的路径时非常有用。

大多数提供商提供专用服务或者VPS服务会给客户设置PTR记录到他们IP地址的能力。

FQDN在PTR记录中有一个通讯并匹配前向A记录。
例如111.222.333.444有一个PTR到server.example.com和server.expamle.com有一个指向111.222.333.444的A记录

CAA记录

CAA记录被用来指定允许CA（证书颁发机构）为你的域名颁发SSL/TLS证书。到2017年9月8日全部的CA都被允许检查这些记录在颁发证书前。如果没有记录，任何CA都可以颁发证书。否则，是有特定的CA可以颁发证书。CAA记录能够被应用到单个host或者整个域名。

下面是一个CAA记录的例子：

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

host,IN和记录类型CAA在DNS字段中很普遍。上面的CAA信息是 0 issue "letsencrypt.org"的一部分。它有三部分组成：flags(0),tags(issue)和values("letsencrypt.org")。

Flags 是一个整数，用来指示CA应该处理它不理解的tags。如果flag为0，记录会忽略。如果值为1，CA必须决绝签发证书。
Tags 是字符串表示CAA记录的目的。目前，他们可能有权授权CA为特定主机名创建证书，isswild授权通配符证书，或者iodef定义CA可以报告策略违规的URL。
Values 是一个字符串关联到一个tag记录。对于issue和issuewild这通常是你授予权限CA的域。对于iodef，这可能是联系人表单的URL或者一个到反馈邮件的mailto:的链接。

你可以用使用dig来发去CAA记录使用下面的选项：

$ dig example.com type257

对于更多的关于CAA记录的信息，你可以阅读 RFC6844

结论

你现在应该已经对DNS是如何工作的有了相当好的掌握。一旦你熟悉了这些策略，这些概念相对比较容易掌握，但对于没有经验的管理员来说，任然难以实现。

原文地址