DNS术语、组件与概念综述

提供：ZStack云计算

系列教程

本教程为7篇系列中的第1篇：DNS管理简介

内容介绍

DNS，全称为域名系统，通常属于网站及服务器配置工作中较难学习的部分。理解DNS的工作机制能够帮助大家对网站访问流程中的问题加以诊断，同时允许我们更为深入地理解业务体系背后的运作原理。

在今天的教程中，我们将探讨部分基础性DNS概念，旨在帮助大家透彻理解关于DNS配置的一切。在遵循本教程时，大家应该首先参阅利用DigitalOcean设置域名或者设置我们自己的DNS服务器。

在着手设置服务器以解析域名或者在控制面板中设置域名之前，首先一起来看与之相关的部分基础概念。

域名术语

我们应当首先明确几个概念定义。其中多数与域名及DNS相关，而不太涉及到计算范畴。

首先看看比较简单的概念：

域名系统

域名系统，通常被简称为“DNS”，作为一套网络系统允许将人类友好型域名解析为惟一地址。

域名

域名是一条人类友好型名称，用于对某一互联网资源进行分配。举例来说，“google.com”就属于一条域名。有些人认为其中“google”部分才是真正的域名，但我们一般会将整个结合体统称为域名。

作为一条URL，“google.com”与由谷歌公司持有的服务器相关联。该域名系统允许大家在浏览器中输入“google.com”时接入谷歌服务器。

IP地址

一条IP地址代表的是一个网络可建起位置。每条IP地址必须在其自有网络之内具备惟一性。当我们谈起某个网站时，其立足的网络也就是整体互联网。

作为最常见的地址类型，IPv4由四组数字构成，其中每一组最高可容纳3位数，各组之间用“.”分隔。举例来说，“111.222.111.222”就是一条有效的IPv4地址。利用DNS，我们可以将一条域名映射至该地址，这样我们就无需硬记这些难以理解的数字了。

顶级域名

所谓顶级域名，或者简称TLD，属于域名当中最为普遍的部分。顶级域名也就是“.”之后的结尾部分，常见的顶级域名包括com、net、org、gov、edu以及io。

顶级域名处于域名结构中的顶端位置。某些机构会利用ICANN（即国际互联网名称与编号分配）机制对顶级域名加以管控。这些机构随后可立足于顶级域名分配域名，通常通过域名注册商实现。

主机

在一条域名当中，域所有者能够定义各单独主机，其用于通过域名指向特定计算机或者服务。举例来说，大多数域名持有者允许其服务器通过裸域名进行访问（example.com），同时亦可通过“主机”定义“www”（www.example.com）。

大家也可以在一般域名之下添加其它主机定义。例如通过“api”主机实现API访问（api.example.com），或者将一台主机定义为“ftp”或者“files”以实现ftp访问（ftp.example.com或者files.example.com）。其中主机名可随意定义——只要在当前域名下惟一即可。

子域名

与主机相关的对象即为子域名。

DNS以分层方式运作。顶级域名可以包含多个域。举例来说，“com”顶级域名可同时容纳“google.com”与“ubuntu.com”。而一个“子域”则对应作为大型域中的特定部分。例如，“ubuntu.com”即可被称为“com”中的一个子域。我们一般直接将其称为域名，或者将“ubuntu”部分称为SLD，即二级域名。

同样的，每个域名都能够控制定位至其之下的“子域名”。举例来说，大家可以在学校网站中建立一个校史子域，域名为“www.history.school.edu”。其中的“history”部分则为子域名。

主机名称与子域名之间的区别在于，主机负责定义一台计算机或者相关资源，而子域名则属于主域名的扩展。其属于域名本身的一种细分手段。

无论是讨论子域名还是主机，其左侧起始部分都最为具体。而这也正是DNS的工作方式：从左到右，从最具体到最不具体。

完全合格域名

完全合格域名，通常被简称为FQDN，也就是我们所说的绝对域名。DNS系统中的域名可以彼此赋予，因此有时候其指向可能比较模糊。而FQDN则属于绝对名称，且位置关系指向域名系统的绝对root。

这意味着其会指定每个主域名，包括顶级域名。一条正确的FQDN应以“.”结尾，同时指示DNS结构中的root，例如“mail.google.com”。有时候软件在调用时不要求FQDN以“.”结尾，但加上“.”更符合ICANN标准。

命名服务器

所谓命名服务器，就是一台负责将域名翻译成IP地址的计算机。这些服务器也是DNS系统中最为重要的组成部分。由于域名翻译总量太大，任何单一服务器都难以应对，因此其中一台服务器可能将请求重新定向至其它服务器或者委托给子域名中的一个子集。

命名服务器是可以“授权的”，意味着其会应答其控制之下各域名接收到的查询请求。如果收到其它域名的请求，其要么将其指向其它服务器，要么提供其它命名服务器数据的缓冲副本。

区域文件

区域文件就是一个简单的文本文件，其中囊括了域名与IP地址间的映射关系。利用它，DNS系统才能最终找出哪个IP地址能够与用户所请求的特定域名相关联。

域名文件驻留于命名服务器当中，而且通常用于定义特定域名下的可用资源，或者提供可获取资源的其它位置信息。

记录

在区域文件当中保存有多条记录。在最简单的格式之下，一条记录基本上代表的是一项资源与某一名称之间的单一映射。其可以是将一条域名与一条IP地址相映射，为域名定义命名服务器以及为域名定义邮件服务器等等。

DNS工作原理

现在大家已经熟悉了DNS中的部分术语，那么这套系统是如何运作的？

从高级层面来看，该系统非常简单——但其具体细节却相当复杂。总体来讲，这是一套非常可靠的基础设施，并成为如今我们所熟知的互联网的实现基石。

Root服务器

如上所述，从核心角度讲，DNS就是一套分层系统。系统顶端为我们常说的“root服务器”。这些服务器受多家机构控制，并获取了ICANN的授权。

目前正在运作的root服务器共有13台。然而随着每分钟需要解析的域名数量不断增长，每台服务器也都开始以镜像形式进行规模扩展。有趣的是，其设置要求同一root服务器的每套镜像共享同一IP地址。当请求指向特定root服务器时，该请求将被路由至距离最近的该服务器镜像。

那么这些root服务器负责哪些工作？Root服务器处理与顶级域名相关的信息请求。因此如果底层命名服务器无法解析某一请求，其就会生成一条指向该域名对应root服务器的查询。

这些root服务器实际上并不清楚所查询域名被托管于何处。然而，它们能够将请求定向至能够处理相关顶级域名的命名服务器。

因此，如果一台root服务器接收到指向“www.wikipedia.org”的请求，并发现其记录中无相关结果，那么它将检查自身区域文件以找到符合“www.wikipedia.org”的条目。

如果仍然找不到结果，它会查找“org”顶级域名列表并将请求转发至负责处理“org”地址的命名服务器。

顶级域名服务器

请求者随后发送一条指向新IP地址的请求（此新IP地址由root服务器提供），从而访问负责解析请求内顶级域名的命名服务器。

继续来看我们的示例，其会发送一条请求并指向负责解析“org”域名的命名服务器，旨在查看其中是否包含“www.wikipedia.org”的位置。

这里，请求方再次搜索区域文件，但其中仍不存在任何记录。

不过在这里，其会找到一条负责处理“wikipedia.org”域名的命名服务器IP地址。可以看到，我们距离答案已经很近了。

域级别名服务器

现在，请求方已经拥有了了解目标资源实际IP地址的命名服务器IP，其会向该命名服务器发送新请求以解析“www.wikipedia.org”。

此命名服务器会检查自身区域文件并发现其中一个文件关联至“wikipedia.org”。此文件内包含“www”主机的记录，而该记录则能够告知主机的IP地址。此命名服务器向请求方返回最终结果。

域名解析服务器是什么？

在以上场景中，我们提到了“请求方”概念。那么，示例中的“请求方”到底是什么？

在多数情况下，我们将请求方称为“域名解析服务器”。一台域名解析服务器就是一台经过配置且专门负责向其它服务器提问的设备。其基本上负责将此前的查询结果保留在缓存当中，从而提高速度并帮助root服务器“解析”其尚不清楚的请求。

基本上，一位用户在自己的计算机系统上通常拥有多项域名解析服务。这些域名解析服务往往由互联网服务供应商或者其它机构提供。举例来说，谷歌提供DNS解析服务器供大家使用。大家可以在自己的计算机上自动或者手动加以配置。

在浏览器中输入一条URL时，我们的计算机会首先查找该资源是否位于本地。它会检查计算机上的“hosts”文件及其它几个位置。在此之后，它将请求发送至域名解析服务并等待返回的资源IP地址。

域名解析服务随后会检查缓存以搜索答案。如果找不到答案，它就会采取前面提到的一系列步骤。

域名解析服务压缩了最终用户的请求流程。该客户端只需向域名解析服务器询问特定资源的位置，并在完成检查后返回最终答案。

区域文件

我们之前已经讨论过了“区域文件”与“记录”的概念。

区域文件由命名服务器用于存储其已知域名的相关信息。命名服务器的每个已知域名都会被存储在一个区域文件当中。大多数指向命名服务器的普通请求都不需要使用区域文件。

如果被配置为处理递归查询，例如域名解析服务，那么其会找出答案并进行返回。否则，其会告知请求方继续查询其它域名解析服务器。

一台命名服务器中的区域文件越多，其拥有应答授权的请求也就越多。

区域文件将DNS描述为一个“区域”，其基本上属于完整DNS命名系统中的一个子集。它通常被用于配置单一域名，同时也可容纳负责定义该域名多种相关资源的多条记录。

区域中的$ORIGIN参数等同于该区域内的最高默认授权等级。

因此如果某个区域文件被用于配置“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      ; exiry period
                                        1h      ; negative TTL
)

下面进行逐一解释：

• domain.com.: 此处为区域的root所在，负责指定该区域文件指向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 IP地址。

这两类记录的一般格式如下：

host     IN      A       IPv4_addresshost     IN      AAAA    IPv6_address

由于我们的SOA记录要求“ns1.domain.com”为第一主服务器，因此作为“ns1.domain.com”中的“domain.com”区域，我们需要按照配置将其映射至一个IP地址。

具体记录如下：

ns1     IN  A       111.222.111.222

请注意，我们不需要为其提供完整名称。我们可以只提供主机，并利用$ORIGIN值实例FQDN与DNS服务器。当然，也可以直接使用完整的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命名记录定义“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记录

此记录类型用于定义该区域所使用的命名服务器。

大家可能会好奇，“如果区域文件就驻留在命名服务器当中，它为什么还要引用自身？”DNS之所以如此成功，就是因为它包含多层缓存结构。在区域文件当中定义命名服务器的理由之一在于，该区域文件可能恰恰由另一台命名服务器中的缓存副本负责支持。当然还有其它一些更为复杂的情况，这里我们暂时不讨论。

与MX记录类似，NS记录包含三条全区域参数，因此其同样不需要填写主机。一般来讲，其内容应如下所示：

    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或者AAA记录的倒数。PTR记录是惟一的，因为它们以.arpa root开头且被委托线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 DNS服务器201：4860：4860：8888的半字节反向PTR记录格式：

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

其输出结果将为该PTR记录中指向对应IP地址的域名：

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

互联网上的服务器使用PTR记录在日志条目当中放置域名、做出正确的垃圾邮件处理决定并显示易于阅读的其它设备细节信息。

大多数常用的邮件服务器都会查看接收到电子邮件的IP地址PTR记录。如果其源IP地址不存在与之关联的PTR记录，则该邮件则会被判断为垃圾邮件并拒收。在PTR当中，FQDN是否与发送邮件的域名相匹配并不重要。真正重要的是一条有效的PTR记录必须要有与之对应且匹配的正向A记录。

一般来讲，互联网上的网络路由器会被分配PTR记录以对应其物理位置。举例来说，大家可能会在纽约或者芝加哥的路由器中看到“NYC”或者“CHI”字样。这能够帮助大家运行traceroute或者MTR并审查正在接收的互联网流量路径。

大多数提供专用服务器或者VPS服务的供应商都允许客户为其IP地址设置一条PTR记录。DigitalOcean也会在创建时自动为任何以域名命名的Droplet分配此PTR记录。Droplet名称是在创建时进行分配的，用户亦可以在实际使用中通过控制面板进行重新设置。

注意：必须保证PTR记录中的FQDN与正向A记录对应及匹配。例如：111.222.333.444拥有一条server.example.com PTR记录，其中server.example.com就是一条指向111.222.333.444的A记录。

总结

现在大家应该已经非常熟悉DNS的工作原理了。尽管概念性的知识易于把握，但缺乏经验的管理员仍然很难将其用于解决实际问题。因此，请大家多多加油！

大家还可以参阅如何利用DigitalOcean控制面板设置 域名一文。

本文来源自DigitalOcean Community。英文原文：An Introduction to DNS Terminology, Components, and Concepts By Justin Ellingwood

翻译：diradw