提供：ZStack云计算
系列教程
本教程为DNS管理介绍系列七篇中的第五篇。
内容介绍
DNS，或者称为域名系统，往往成为学习网站与服务器配置中的一大难点。尽管很多人都会使用由托管厂商或者域名注册商提供的DNS服务器，但建立自己的DNS服务器亦能带来诸多不容忽视的助益。
在本篇教程中，我们将探讨如何在Ubuntu 14.04当中安装Bind9 DNS服务器并将其配置为仅权威DNS服务器。作为示例，我们将立足于一套主-从配置为域名进行Bind服务器设置。
先决条件与目标
要完成今天的教程，大家首先应当熟知与DNS相关的各类术语。请参阅本篇教程以掌握下面将要使用的各项概念。
我们还需要拥有至少两台服务器。其一将作为“主”DNS服务器，这里将驻留有域名的区域文件; 其二为“从”服务器，其负责通过传输接收区域数据并能够在其它服务器发生故障时接替而上。这就使得我们的DNS服务器避免发生单点故障。
与缓存或正向DNS服务器或者多用途DNS服务器不同，仅权威服务器只对指向其自身作为权威的区域的查询做出响应。这意味着如果该服务器并不知晓响应答案，那么其将告知客户端（通常为某种解析DNS服务器）其不具备答案，并为对方提供可能知晓答案的服务器参考。
仅权威DNS服务器通常适用于高性能配置场景，这是因为它们不会因为对客户端的递归查询做出回应而造成资源负担。具体来讲，它们只针对其负责的区域。
在本示例中我们将实际使用三台服务器，除了之前提到的两台命名服务器，另外还有一台作为区域主机进行配置的Web服务器。
我们仍将使用example.com作为示例。大家可以将其替换为自己实际使用的域名。下面来看我们所须配置的各设备细节：
PurposeDNS FQDNIP Address
Master name server ns1.example.com. 192.0.2.1
Slave name server ns2.example.com. 192.0.2.2
Web Server www.example.com. 192.0.2.3
在完成本教程之后，大家应该拥有两台面向域名区域配置完成的仅权威命名服务器。上表中的名称可用于访问各位的主机。在这套配置中，将有一台递归DNS服务器负责将域名相关数据返回至客户端。
在命名服务器上设定主机名称
在对命名服务器进行配置之前，我们必须要确保自己的主机名称在主、从两台DNS服务器上皆得到妥善配置。
首先对/etc/hosts文件进行编辑。以sudo权限将其在文本编辑器中打开：
sudo nano /etc/hosts
经过配置，此文件将正确包含每台服务器的主机名称与FQDN。对于主命名服务器，此文件的初始内容应如下所示：
127.0.0.1 localhost
127.0.1.1 ns1 ns1
. . .
我们应当修改其中第二行以引用自己的实际主机与域名，并将其指向我们的公共静态IP地址。在此之后，我们可以在结尾处添加不合格名称作为别名。在本示例的主服务器当中，大家可以将其第二行修改为：
127.0.0.1 localhost
192.0.2.1 ns1.example.com ns1
. . .
完成后保存并退出。
我们亦需要对/etc/hostname文件进行修改以包含不合格主机名称：
sudo nano /etc/hostname
ns1
利用以下命令使得当前所运行系统读取该值：
sudo hostname -F /etc/hostname
我们需要在自己的从服务器上完成同样的流程。
首先打开/etc/hosts文件：
sudo nano /etc/hosts
127.0.0.1 localhost
192.0.2.2 ns2.example.com ns2
完成后保存并退出。
接下来，修改/etc/hostname文件。请记住，只在该文件中使用实际主机名称（在本示例中为ns2）：
sudo nano /etc/hostname
ns2
再次读取该文件以修改当前系统：
sudo hostname -F /etc/hostname
现在我们的服务器应该已经拥有正确的主机定义了。
在两台命名服务器上安装Bind
下面在两台命名服务器上安装之后要使用的Bind。
Ubuntu默认软件库中即提供Bind软件，因此我们只需要对本地软件包索引进行更新并利用apt命令加以安装即可。我们还需要安装说明文档及其它一些常用工具：
sudo apt-get update
sudo apt-get install bind9 bind9utils bind9-doc
在主、从DNS服务器上运行以上安装命令以获取对应文件。
配置主Bind服务器
现在我们已经完成了软件安装，接下来可以在主服务器上配置DNS服务器了。
配置options文件
第一步从配置named.conf.options文件开始。
Bind DNS服务器亦被称为named。此主配置文件位于/etc/bind/named.conf处。该文件负责调用我们下面将要具体配置的其它文件。
打开此options文件：
sudo nano /etc/bind/named.conf.options
以下所示已经去掉了大部分注释内容，但安装后的文件主体仍然得到完整保留：
options {
directory "/var/cache/bind";
dnssec-validation auto;
auth-nxdomain no; # conform to RFC1035
listen-on-v6 { any; };
};
对此文件进行配置的主要目的就是实现递归。由于我们需要设置一套仅权威服务器，因此我们当然不希望在此服务器上启用递归机制。我们可以在options block当中将其关闭。
我们也可以利用默认方式禁用传输。我们之后会利用特定区域指定对其进行覆盖：
options {
directory "/var/cache/bind";
recursion no;allow-transfer { none; };
dnssec-validation auto;
auth-nxdomain no; # conform to RFC1035
listen-on-v6 { any; };
};
完成后保存并退出。
配置local文件
接下来，我们需要指定用于控制此服务器的区域。所谓区域，是指域中的特定部分，其被委托管理某套尚未被子委托至其它服务器的命名服务器。
现在我们要配置的是example.com域，而且我们不需要将该域中的任何部分委托给其它服务器，因此此区域将涵盖我们的整个域。
要对我们的区域进行配置，需要以sudo权限打开/etc/bind/named.conf.local文件：
sudo nano /etc/bind/named.conf.local
此文件除了注释之外没有任何实际内容。出于常规管理的目的，我们的服务器还知晓其它一些区域，但这里要谈的是在named.conf.default-zones文件内进行指定的区域。
我们首先需要配置example.com域的正向区域。正向区域即传统的名称到IP地址解析机制，也就是大多数人所说的DNS。我们创建一个配置block，负责定义我们需要配置的域名区域：
zone "example.com" {
};
在此block当中，我们添加与此区域相关的管理信息。我们需要为此DNS服务器与区域指定关系。在本示例中为“master”，这是因为我们正在配置的这台设备为此区域中的主命名服务器。我们还需要将Bind指向至此文件，因为后者中包含有用于定义此区域的实际资源记录。
接下来我们将父区域文件保存在Bind配置目录中的zones子目录当中。我们将此文件命名为db.example.com，以便于Bind目录内的其它区域文件调用。我们的block将如下所示：
zone "example.com" {
type master;
file "/etc/bind/zones/db.example.com";
};
我们希望允许此区域被传输至从服务器，因此需要在其中添加这样一行：
zone "example.com" {
type master;
file "/etc/bind/zones/db.example.com";
allow-transfer { 192.0.2.2; };
};
下面，我们开始为自己的域名定义反向区域。
反向区域概述
如果为我们提供IP地址的服务商并没有提供网络范围，并将范围指定工作交由我们自己负责，那么我们的反向区域文件将无法被引用，而是由服务商自行处理。
如果大家选择了托管供应商，那么反向映射通常由对应公司负责。举例来说，在DigitalOcean中，客户服务器的反向映射将会在用户将设备FQDN设定为控制面板内服务器名称的同时自动生成。本示例中的反向映射则可通过以下方式命名服务器来创建：
在本示例中，由于我们还没有为管理员分配地址块，因此需要首先完成对应的策略设置。以下所示策略已经补充完整，如果大家经过委托能够控制范围较大的连续地址，则可直接使用该策略。
反向区域用于将一条IP地址回连至一项域名。不过，域名系统本身的初始设计目的在于正向映射，因此我们需要想办法适应这种反向映射。
要理解反向映射，大家首先需要牢记以下几点：
- 在域名当中，最具体的地址位于左侧位置。而对于IP地址，最具体的部分位于右侧位置。
- 域名当中最具体的部分要么是子域名、要么是主机名称，其被定义于该域名的区域文件当中。
- 反过来，每个子域名亦能够定义更多子域名或者主机。
全部反向区域映射都被定义于特定域名in-addr.arpa之下，其则由互联网编号分配机构（简称IANA）负责控制。在此域名下存在一套树状结构，其利用子域名映射单一IP地址中的每个八位字节。为了确保该IP地址准确映射正常域名，IP地址中的各八位字节实际上都是反向的。
因此在IP地址为192.0.2.1时，我们的主DNS服务器将被翻转读为1.2.0.192。而在我们将此主机指定添加至in-addr.arpa域下的现有结构中时，此特定主机即被引用为1.2.0.192.in-addr.arpa。
由于我们在使用DNS时会在区域文件之内进行个别主机定义（例如之前提到的‘1’主机），因此我们需要配置的区域即为2.0.192.in-addr.arpa。如果大家的网络供应商为各位提供一条/24地址块，例如102.0.2.0/24，则意味着其将此in-addr.arpa部分委托给了我们。
现在大家已经了解如何指定反向区域名称了，其具体定义与正向区域完全一致。在example.com区域定义当中，请大家为自己的网络创建一个反向区域。再次强调，如果大家被委托控制一套地址块，那么上述操作将是非常必要的：
zone "2.0.192.in-addr.arpa" {
type master;
file "/etc/bind/zones/db.192.0.2";
};
我们已经将文件名称设定为db.192.0.2，其直接指向加以配置的区域且较反向方式更具可读性。
完成后保存并退出。
创建正向区域文件
我们已经告知Bind我们的正向与反向区域了，但还没有创建负责定义这些区域的文件。
大家应该还记得，我们之前曾将文件位置指定在名为zones的子目录当中。下面创建该目录：
sudo mkdir /etc/bind/zones
现在我们可以使用Bind目录中的部分模板区域文件作为创建基础了。对于正向区域而言，db.local文件比较符合我们的需求。将该文件复制至zones子目录当中，文件名则改为named.conf.local。
sudo cp /etc/bind/db.local /etc/bind/zones/db.example.com
与此同时，我们可以为反向区域复制另一个模板文件。这里使用db.127文件：
sudo cp /etc/bind/db.127 /etc/bind/zones/db.192.0.2
现在，利用sudo权限在编辑器中打开该正向区域文件：
sudo nano /etc/bind/zones/db.example.com
文件内容如下：
$TTL 604800
@ IN SOA localhost. root.localhost. (
2 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS localhost.
@ IN A 127.0.0.1
@ IN AAAA ::1
我们首先需要修改其SOA（即起始授权）记录，即以“@”开头一直到右括号部分的内容。
我们需要将其中的localhost.替换为本设备的FQDN名称。这部分记录用于定义任何将以权威方式作出响应的命名服务器，也就是我们目前正在配置的设备，ns1.example.com。（请注意，结尾处的‘.’。这一点对于顺利完成注册非常重要。）
我们还希望变更下一部分，即利用“.”替换“@”以构成特殊的邮件地址格式。我们希望将邮件发送至此域中的管理员处，因此这里选择较为传统的命名方式——admin@example.com。经过翻译，其新格式将为admin.exapmle.com.：
@ IN SOA ns1.example.com. admin.example.com. (
下面是编辑其序列号。序列号的值用于告知Bind是否需要向从服务器发送更新后的信息。
注意：用户常常由于忘记对该序列号进行增量而导致区域更新出现错误。每次进行编辑之后，大家都必须增加该序列号。
一种较为常见的作法是利用约定对该序列号进行增量。例如利用YYYYMMDD（日期格式）作为序列号，从而保证后添加的修改永远具备大于此前版本的序列号。初次修订发生在2014年6月5号，则其序列号为2014060501，而当天晚些时候的修订则被编号为2014060502，这一数字最长可达十位。
需要使用约定能够实现良好的易用性，但为了保证本示例易于理解，我们直接将序列号设定为5：
@ IN SOA ns1.example.com. admin.example.com. (
5 ; Serial
接下来，我们可以直接删除文件中的最后三行（即最下方以‘@’开头的部分），添加自己需要的内容。
首先在SOA记录之后添加用于此区域的命名服务器。我们指定该域名，而后是两台作为区域权威的命名服务器。由于这些命名服务器将在域内作为主机存在，因此会有点自我引用的意思。
在本示例中，修改后的内容如下所示。再次强调，在结尾处添加“.”：
; Name servers
example.com. IN NS ns1.example.com.
example.com. IN NS ns2.example.com.
由于区域文件的作用主要是将主机名称与服务映射至特定地址，因此到这里我们的工作还没有完成。任何读取此区域文件的软件都需要了解ns1与ns2服务器的具体位置，从而访问这两个权威区域。
所以，我们需要创建一条A记录，旨在将这些命名服务器名称与命名服务器的实际IP地址关联起来：
; A records for name servers
ns1 IN A 192.0.2.1
ns2 IN A 192.0.2.2
现在我们已经拥有一条A记录，其能够将我们的命名服务器解析至正确的IP地址。当然，我们也可以添加其它一些记录。请记住，我们的主机中还有一台Web服务器，专门用于支撑实际站点。因此我们需要将访问通用域名（在此次示例中为example.com）的请求外加指向www主机的请求指向该主机。具体如下：
; Other A records
@ IN A 192.0.2.3
www IN A 192.0.2.3
大家也可以创建更多A记录以添加其它必要的主机定义。请参阅DNS基础指南一文以了解如何创建其它记录。
完成后，文件内容如下所示：
$TTL 604800
@ IN SOA ns1.example.com. admin.example.com. (
5 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
; Name servers
example.com. IN NS ns1.example.com.
example.com. IN NS ns2.example.com.
; A records for name servers
ns1 IN A 192.0.2.1
ns2 IN A 192.0.2.2
; Other A records
@ IN A 192.0.2.3
www IN A 192.0.2.3
完成后保存并退出。
创建反向区域文件
现在，我们已经配置了正向区域，但还需要设置反向区域文件。在上一章开头，我们已经创建了该文件。
以sudo权限打开该文件：
sudo nano db.192.0.2
文件内容如下所示：
$TTL 604800
@ IN SOA localhost. root.localhost. (
1 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS localhost.
1.0.0 IN PTR localhost.
我们将通过与正向区域基本相同的方式进行设置。首先调整域名、管理员邮箱以及序列号，保证其与上一文件中的内容相匹配（序列号可以有所区别，但必须进行增量）：
@ IN SOA example.com. admin.example.com. (
5 ; Serial
同样，删除右括号之前的SOA记录。我们将取每条IP地址的最后八位字节并利用PTR记录将其映射回主机的FQDN。每条IP地址都只应包含一条PTR记录，从而避免给某些软件造成运行问题——因此，大家必须选定反向映射所指向的目标主机名称。
举例来说，如果大家设置一台邮件服务器，则可能希望通过设置将其反向映射至邮件名称，因为大多数系统都会使用反向映射来验证发件地址。
首先，我们需要再次设定命名服务器：
; Name servers
IN NS ns1.example.com.
IN NS ns2.example.com.
接下来，大家将引用IP地址的最后八个字节并将春指向希望返回的合格域名。在本示例中，我们将使用：
; PTR Records
1 IN PTR ns1.example.com.
2 IN PTR ns2.example.com.
3 IN PTR www.example.com.
完成后，文件内容应如下所示：
$TTL 604800
@ IN SOA example.com. admin.example.com. (
5 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
; Name servers
IN NS ns1.example.com.
IN NS ns2.example.com.
; PTR records
1 IN PTR ns1.example.com.
2 IN PTR ns2.example.com.
3 IN PTR www.example.com.
完成后保存并退出。
测试文件并重启服务
主服务器的配置工作现在已经完成，但我们还需要进行其它一些变更。
在重启服务之前，我们应当测试全部配置文件以确保其配置正确。另外，还有多款工具能够帮助我们对其文件中的语法加以检查。
首先，我们使用named-checkconf命令对named.conf.local与named.conf.options文件进行检查。由于这两个文件皆源自named.conf模板文件，因此我们的检查重点应为修改内容的语法。
sudo named-checkconf
如果没有返回任何信息，则意味着named.conf.local与named.conf.options文件不存在语法错误。
接下来使用named-checkzone命令检查区域处理与区域文件位置。在本示例中，具体命令如下：
sudo named-checkzone example.com /etc/bind/zones/db.example.com
如果文件中不存在问题，则输出结果应显示正确的序列号及“OK”信息：
zone example.com/IN: loaded serial 5
OK
如果显示的是其它信息，则意味着大家的区域文件出了问题。一般来讲，这部分信息通常会描述那些无效部分。
大家可以传递in-addr.arpa地址与文件名称以检查反向区域是否正常。在本示例中，具体命令如下：
sudo named-checkzone 2.0.192.in-addr.arpa /etc/bind/zones/db.192.0.2
同样，输出结果应返回正确的序列号：
zone 2.0.192.in-addr.arpa/IN: loaded serial 5
OK
全部文件检查完毕后，接下来重启Bind服务：
sudo service bind9 restart
通过以下命令检查日志：
sudo tail -f /var/log/syslog
认真阅读日志以确保一切运作正常。
配置从Bind服务器
现在主服务器已经配置完成，接下来是设置从服务器。具体操作难度要远低于主服务器。
配置options文件
首先还是从named.conf.options文件开始。以sudo权限将其打开：
sudo nano /etc/bind/named.conf.options
文件内容修改与主服务器完全一致。
options {
directory "/var/cache/bind";
recursion no;allow-transfer { none; };
dnssec-validation auto;
auth-nxdomain no; # conform to RFC1035
listen-on-v6 { any; };
};
完成后保存并退出。
配置local配置文件
下面在从服务器上配置named.conf.local文件。以sudo权限将其打开：
sudo nano /etc/bind/named.conf.local
在这里，我们将创建与主服务器一样的各区域指定。不过，具体取值与某些参数则有所区别。
首先处理正向区域。与主服务器文件一样:
zone "example.com" {
};
这一次我们将type设置为“slave”，因为此服务器为区域中的从服务器。这意味着其通过传输获取区域文件，而非直接从本地系统获取。另外，我们只需要指定相对文件名，而非指向区域文件的绝对路径。
之所以这样做，是因为对于从区域而言，Bind会将文件存储至/var/cache/bind。Bind已经完成了查看此目录位置的配置，因此我们不再需要指定该路径。
从服务器上的正向区域细节内容如下：
zone "example.com" {
type slave;
file "db.example.com";
};
最后，我们不再使用allow-transfer指令，而是为此从服务器指定获取传输结果的来源主服务器IP地址。我们可以使用master命令实现：
zone "example.com" {
type slave;
file "db.example.com";
masters { 192.0.2.1; };
};
到这里，正向区域指定就配置完成了。我们可以使用同样的格式处理反向区域指定：
zone "2.0.192.in-addr.arpa" {
type slave;
file "db.192.0.2";
masters { 192.0.2.1; };
};
完成后保存并退出。
测试文件并重启服务
我们在从服务器上并不需要真正创建任何区域文件，因为正如之前所言，该服务器将从主服务器处接收区域文件。因此下面直接进行测试。
同样对配置文件语法进行检查。由于我们不需要检查区域文件，因此只使用named-checkconf工具即可：
sudo named-checkconf
如果返回结果没有错误，则意味着对文件内容的修改中不存在语法错误。
在这种情况下，大家可以重启Bind服务：
sudo service bind9 restart
使用以下命令检查主、从服务器日志：
sudo tail -f /var/log/syslog
显示条目应该表明各区域文件都能够正常传输。
为命名服务器委派权威
我们的仅权威命名服务器现在已经配置完成。不过，大家仍然需要为域名进行命名服务器权威委派。
要完成这项工作，大家需要前往购买域名的网站。界面与终端的具体形式可能取决于实际域名注册商。
在域名设置中，找到对应选项以指定想要使用的命名服务器。由于我们的命名服务器存在于我们的域当中，因此这可以算是一种特例。
注册商并不会直接使用NS记录对区域进行权威委派，相反其会创建一条glue记录。所谓glue记录其实是一种特殊的A记录，专门用于将IP地址指定至被委派权威的命名服务器。
一般来讲，委派只会列出命名服务器需要处理的域名权威。但当命名服务器处于域当中时，位于父区域中的命名服务器还需要一条A记录。如若不然，DNS解析会陷入循环——因为其永远无法根据委派路径找到域名命名服务器的IP地址。
因此大家需要找到域名注册商控制面板中的对应部分，并在这里指定命名服务器以及它们的IP地址。
作为示范，注册商 Namecheap提供两种不同的命名服务器实现方式。
其一被称为“命名服务器注册”，允许大家对域内的命名服务器指定IP地址：
在这里，大家可以输入该命名服务器的IP地址：
系统会创建一条A记录，并作为父区域文件内所需要的glue记录。
完成之后，大家应该可以将实际命名服务器变更为自己的域服务器。在NameCheap当中，其提供“域名服务器设置”菜单选项：
在这里，大家可以填写自己要求站点作为权威服务器使用的命名服务器：
变更可能需要一段时间方可生效，一般来说大多数注册商会在未来24到48小时中完成更新。
总结
现在大家已经拥有两台配置完成的仅权威DNS服务器了。它们亦可存储大家购买的更多其它域名的区域信息。
自行配置并管理DNS服务器能够保证大家对DNS记录的处理方式拥有绝对掌控权。大家可以做出变更，同时确保全部相关DNS数据片段都与来源保持同步更新。虽然其它DNS解决方案也许能够进一步简化上述工作，但本教程的核心在于帮助大家了解整套体系的运作方式——这一点显然是那些打包方案所无法实现的。
本文来源自DigitalOcean Community。英文原文：How To Configure Bind as an Authoritative-Only DNS Server on Ubuntu 14.04 By Justin Ellingwood
翻译：diradw
417
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
