介绍
DNS或域名系统，在学习如何配置网站和服务器时通常是一个很难的组件。 虽然大多数人可能会选择使用由其托管公司或其域名注册商提供的DNS服务器，但创建自己的DNS服务器有一些优势。
在本指南中，我们将讨论如何在Ubuntu 14.04计算机上安装和配置Bind9 DNS服务器作为仅权威的DNS服务器。 我们将在主从配置中为我们的域设置两个绑定服务器。
先决条件和目标
要完成本指南，您首先需要熟悉一些常见的DNS术语。 查看本指南 ，了解我们将在本指南中实施的概念。
您还需要至少两个服务器。 一个将用于“主”DNS服务器，其中我们域的区域文件将起源，一个将是“从属”服务器，它将通过传输接收区域数据，并在其他服务器关闭的情况下可用。 这避免了您的DNS服务器的单点故障的危险。
不像缓存或转发DNS服务器或多用途的DNS服务器，仅权威服务器只响应了他们的权威区域迭代查询。 这意味着如果服务器不知道答案，它只会告诉客户端（通常是某种解析DNS服务器）它不知道答案，并且可能知道更多的服务器的引用。
只有权威的DNS服务器通常是高性能的良好配置，因为它们没有解析来自客户端的递归查询的开销。 他们只关心他们设计服务的区域。
对于本指南的目的，我们实际上将引用三台服务器。 上面提到的两个Nameservers，以及我们要配置为我们区域中的主机的Web服务器。
我们将使用虚拟域example.com本指南。 您应该将其替换为您正在配置的域。 这些是我们将要配置的机器的详细信息：
| 目的 | DNS FQDN | IP地址 |
|---|---|---|
| 主Nameservers | ns1.example.com。 | 192.0.2.1 |
| 从属Nameservers | ns2.example.com。 | 192.0.2.2 |
| 网络服务器 | www.example.com 。 | 192.0.2.3 |
完成本指南后，您应该为您的域区域配置两个仅授权的Nameservers。 上表中的中心列中的名称将能够用于访问您的各种主机。 使用此配置，递归DNS服务器将能够将关于域的数据返回给客户端。
在Nameservers上设置主机名
在我们开始配置我们的Nameservers之前，我们必须确保在主DNS服务器和从DNS服务器上正确配置主机名。
通过调查开始/etc/hosts的文件。 在文本编辑器中使用sudo权限打开文件：
sudo nano /etc/hosts
我们需要对其进行配置，以便正确识别每个服务器的主机名和FQDN。 对于主Nameservers，文件将最初如下所示：
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
您的服务器现在应正确设置其主机定义。
在两个Nameservers上安装绑定
在每个Nameservers上，您现在可以安装Bind，我们将使用的DNS服务器。
绑定软件是Ubuntu的默认存储库中可用，所以我们只需要更新我们的本地包指数，并使用安装软件apt 。 我们还将包括文档和一些常见的实用程序：
sudo apt-get update
sudo apt-get install bind9 bind9utils bind9-doc
在主DNS服务器和从属DNS服务器上运行此安装命令以获取相应的文件。
配置主绑定服务器
现在我们已经安装了软件，我们可以开始在主服务器上配置我们的DNS服务器。
配置选项文件
我们将配置上手的第一件事是named.conf.options文件。
绑定的DNS服务器也被称为named 。 主配置文件位于/etc/bind/named.conf 。 这个文件调用我们将实际配置的其他文件。
在编辑器中使用sudo权限打开选项文件：
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块。
我们也将默认不允许转移。 我们将在后面的单个区域规范中覆盖此：
options {
directory "/var/cache/bind";
recursion no;
allow-transfer { none; };
dnssec-validation auto;
auth-nxdomain no; # conform to RFC1035
listen-on-v6 { any; };
};
完成后，保存并关闭文件。
配置本地文件
我们需要采取的下一步是指定我们希望控制此服务器的区域。 区域是域的任何部分，其被委派用于管理到尚未被子委派给其他服务器的Nameservers。
我们所配置的example.com域，我们不会成为域中其他服务器的任何部分子委托责任。 因此，该区域将覆盖我们的整个域。
来配置我们的区域，我们需要打开/etc/bind/named.conf.local使用sudo权限的文件：
sudo nano /etc/bind/named.conf.local
除了注释，此文件最初将为空。 有迹象表明，我们的服务器知道的一般管理其他区域，但这些都是在指定的named.conf.default-zones文件。
要开始，我们需要配置正向区域为我们example.com域。 前向区域是我们大多数人在讨论DNS时常见的名称到IP解析。 我们创建一个配置块，定义我们希望配置的域区域：
zone "example.com" {
};
在此块的内部，我们添加有关此区域的管理信息。 我们指定此DNS服务器与区域的关系。 在这种情况下，这是“主”，因为我们将此机器配置为所有区域的主Nameservers。 我们还将绑定指向包含定义区域的实际资源记录的文件。
我们将保持我们的主区域文件的子目录叫做zones绑定配置目录中。 我们会打电话给我们的文件db.example.com到从绑定的目录其他区域文件借贷约定。 我们的块现在看起来像这样：
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地址的八位字节实际上是相反的。
因此，我们的主DNS服务器，拥有一个IP地址192.0.2.1 ，将翻转改为1.2.0.192 。 当我们添加这个主机规格为在现有层次in-addr.arpa域，特定的主机可以作为引用1.2.0.192.in-addr.arpa 。
既然我们定义单个主机（如领先的“1”，在这里）区域文件本身内使用DNS时，该区域我们将配置会2.0.192.in-addr.arpa 。 如果我们的网络供应商给了我们一个地址/ 24块，说192.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
现在，我们可以使用绑定目录中的一些预先存在的区域文件作为我们要创建的区域文件的模板。 对于前向区， 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的名称。 记录的这一部分用于定义将对正在定义的区域进行授权响应的任何Nameservers。 这将是我们现在所配置的机器， ns1.example.com.在我们的例子（注意尾随点。我们进入正确注册这一点很重要！）。
我们也想改变下一段，这实际上是在一个特殊格式的电子邮件地址@一个点所取代。 我们希望我们的邮件转到域的管辖，所以传统的电子邮件是admin@ example.com 。 所以看起来我们将翻译这个admin. example.com .
@ IN SOA ns1.example.com. admin.example.com. (
下一个我们需要编辑的是序列号。 序列号的值是Bind如何指示是否需要将更新的信息发送到从服务器。
注 ：未按递增序列号的，导致问题与区域更新中最常见的错误之一。 每次进行编辑时，都必须碰到的序列号。
一种常见的做法是使用增加数字的约定。 一种方法是使用YYYYMMDD格式的日期以及添加到结尾的日期的修订号。 因此，2014年6月5日的第一次修订可能具有2014060501的序列号，并且该日晚些时候的更新可以具有2014060502的序列号。该值可以是10位数字。
这是值得采用的易用性的公约，但让事情变得简单了我们的演示，我们将只设置我们以5现在：
@ IN SOA ns1.example.com. admin.example.com. (
5 ; Serial
接下来，我们可以摆脱该文件中的最后三行（底部与开始的那些的@ ，我们将作出我们自己的）。
我们想要在SOA记录之后建立的第一件事是我们区域的Nameservers。 我们通过名称指定域，然后指定对区域具有权威性的两个Nameservers。 因为这些Nameservers将是域内的主机，所以它看起来有点自我参照。
对于我们的指南，它将看起来像这样。 再次，注意结束点!:
; Name servers
example.com. IN NS ns1.example.com.
example.com. IN NS ns2.example.com.
由于区域文件的目的主要是将主机名和服务映射到特定地址，因此我们还没有完成。 任何软件阅读本区域文件会想知道那里的ns1和ns2服务器才能访问的授权区域。
所以接下来，我们需要创建A记录，这将这些Nameservers的名称我们的Nameservers的实际IP地址关联：
; A records for name servers
ns1 IN A 192.0.2.1
ns2 IN A 192.0.2.2
现在我们有了A记录来成功地将我们的Nameservers解析为正确的IP地址，我们可以添加任何其他记录。 记住，我们在我们的一个主机上有一个网络服务器，我们想用它来服务我们的网站。 我们将点（一般域的请求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地址的最后八位在我们的网络范围和使用映射回该主机的FQDN PTR记录。 每个IP地址只能有一个PTR记录，以避免在一些软件的问题，所以你必须选择你想扭转映射到主机名。
例如，如果您设置了邮件服务器，则可能需要设置与邮件名称的反向映射，因为许多系统使用反向映射来验证地址。
首先，我们需要再次设置我们的Nameservers：
; 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.conf.local和named.conf.options使用文件named-checkconf命令。 由于这两个文件是由源骨架named.conf文件，它将测试我们修改了文件的语法。
sudo named-checkconf
如果返回没有任何消息，这意味着named.conf.local和named.conf.options文件是语法上有效。
接下来，你可以通过该处理区域和区域文件位置的检查各个区域文件named-checkzone命令。 因此，对于我们的指南，您可以键入以下内容检查前向区域文件：
sudo named-checkzone example.com /etc/bind/zones/db.example.com
如果你的文件没有问题，它应该告诉你，它加载正确的序列号，并给出“确定”消息;
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
如果所有文件都已检出，您可以重新启动绑定服务：
sudo service bind9 restart
您应该通过键入以下内容来检查日志：
sudo tail -f /var/log/syslog
注意这个日志，以确保没有错误。
配置从属绑定服务器
现在我们已经配置了主服务器，我们可以继续设置从服务器。 这将比主服务器容易得多。
配置选项文件
再次，我们将与启动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; };
};
保存并在完成后关闭文件。
配置本地配置文件
接下来，我们将配置named.conf.local从服务器上的文件。 在文本编辑器中使用sudo权限打开它：
sudo nano /etc/bind/named.conf.local
在这里，我们将创建我们的区域规范，就像我们在主服务器上做的那样。 但是，值和一些参数将不同。
首先，我们将在前进区工作。 以与在主文件中所做的相同的方式启动它：
zone "example.com" {
};
这一次，我们要设置type为slave ，因为该服务器充当该区域的Minion。 这只是意味着它通过传输接收其区域文件，而不是本地系统上的文件。 此外，我们只需要指定相对文件名而不是区域文件的绝对路径。
这样做的原因是，对于从属区域，绑定存储的文件/var/cache/bind 。 绑定已配置为查看此目录位置，因此我们不需要指定路径。
对于我们的前进区域，这些详细信息将如下所示：
zone "example.com" {
type slave;
file "db.example.com";
};
最后，而不是allow-transfer指令，我们将指定主服务器，通过IP地址，该服务器将接受区域传输距离。 这是在一个名为指令做masters ：
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
如果返回没有任何错误，这意味着您修改的文件没有语法错误。
如果是这种情况，您可以重新启动绑定服务：
sudo service bind9 restart
使用以下命令检查主服务器和从服务器上的日志：
sudo tail -f /var/log/syslog
您应该看到一些表明区域文件已正确传输的条目。
向您的Nameservers委派权限
您的仅授权的Nameservers现在应该完全配置。 但是，您仍然需要将您的域的权限委派给您的Nameservers。
为此，您必须访问您购买域名的网站。 接口和可能的术语将根据您使用的域名注册商而有所不同。
在您的域设置中，查找一个允许您指定要使用的Nameservers的选项。 由于我们的域名服务器是我们的域中 ，这是一个特例。
取而代之的是简单的注册商通过使用NS记录用于委派区域权威，就需要建立一个粘附记录 。 胶水记录是指定Nameservers的IP地址的A记录，该Nameservers在指定其委派权限的Nameservers之后。
通常，委派仅列出将处理域的权限的Nameservers，但是当Nameservers在域本身内时，父区域中的Nameservers需要A记录。 如果这没有发生，DNS解析器将陷入循环，因为它永远不能找到域的Nameservers的IP地址跟随委托路径。
所以，你需要找到你的域名注册商的控制面板的部分，允许您指定Nameservers和 IP地址。
作为示范，注册商Namecheap有两个不同的域名服务器的部分。
有一个名为“Nameserver注册”的部分，允许您指定域中的Nameservers的IP地址：
在内部，您将能够输入域中存在的Nameservers的IP地址：
这将创建作为您在父区域文件中需要的粘合记录的A记录。
完成后，您应该可以将活动Nameservers更改为域的服务器。 在NameCheap中，使用“域名服务器设置”菜单选项完成此操作：
在这里，您可以让它使用您添加为您的网站的权威服务器的Nameservers：
更改可能需要一段时间才能传播，但您应该可以看到来自您的Nameservers的数据在大多数注册商的24-48小时内使用。
结论
您现在应该有两个仅权威的DNS服务器配置为服务您的域。 这些可以用于存储其他域的区域信息，当您获得更多。
配置和管理自己的DNS服务器使您能够最好地控制如何处理DNS记录。 您可以进行更改，并确保所有相关的DNS数据都是源位置的最新数据。 虽然其他DNS解决方案可以使此过程更容易，重要的是要知道，你有选项，并了解更多的打包解决方案正在发生什么。
