如何在Ubuntu14.04上将Bind配置为仅授权的DNS服务器

来自菜鸟教程
跳转至:导航、​搜索

介绍


在学习如何配置网站和服务器时,DNS 或域名系统通常是一个难以正确掌握的组件。 虽然大多数人可能会选择使用托管公司或域名注册商提供的 DNS 服务器,但创建自己的 DNS 服务器有一些优势。

在本指南中,我们将讨论如何在 Ubuntu 14.04 机器上安装和配置 Bind9 DNS 服务器作为权威 DNS 服务器。 我们将在主从配置中为我们的域设置这两个绑定服务器。

先决条件和目标

要完成本指南,您首先需要熟悉一些常见的 DNS 术语。 查看 本指南 以了解我们将在本指南中实施的概念。

您还需要至少两台服务器。 一个用于“主” DNS 服务器,我们域的区域文件将来自该服务器,另一个将作为“辅助”服务器,它将通过传输接收区域数据,并在另一台服务器出现故障时可用。 这避免了 DNS 服务器出现单点故障的风险。

缓存或转发 DNS 服务器 或多用途 DNS 服务器不同,仅授权服务器仅响应对其授权区域的迭代查询。 这意味着如果服务器不知道答案,它只会告诉客户端(通常是某种解析 DNS 服务器)它不知道答案,并提供一个可能知道更多信息的服务器的参考。

仅权威 DNS 服务器通常是高性能的良好配置,因为它们没有解析来自客户端的递归查询的开销。 他们只关心他们旨在服务的区域。

出于本指南的目的,我们实际上将引用 服务器。 上面提到的两个名称服务器,以及一个我们想要配置为我们区域内的主机的 Web 服务器。

我们将在本指南中使用虚拟域 example.com。 您应该将其替换为您正在配置的域。 这些是我们将要配置的机器的详细信息:

目的 DNS FQDN IP地址
主名称服务器 ns1.example.com 192.0.2.1
辅助名称服务器 ns2.example.com 192.0.2.2
网络服务器 www.example.com 192.0.2.3

完成本指南后,您应该为您的域区域配置了两个仅限权威的名称服务器。 上表中间列中的名称将能够用于访问您的各种主机。 使用此配置,递归 DNS 服务器将能够将有关域的数据返回给客户端。

在名称服务器上设置主机名

在我们开始配置我们的名称服务器之前,我们必须确保我们的主机名在我们的主 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,我们将使用的 DNS 服务器。

Bind 软件在 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; };
};

完成后,保存并关闭文件。

配置本地文件

我们需要采取的下一步是指定我们希望控制此服务器的区域。 区域是被委派给名称服务器进行管理的域的任何部分,该名称服务器尚未被分委给其他服务器。

我们正在配置 example.com 域,我们不会将域的任何部分的责任分派给其他服务器。 因此该区域将覆盖我们的整个域。

要配置我们的区域,我们需要使用 sudo 权限打开 /etc/bind/named.conf.local 文件:

sudo nano /etc/bind/named.conf.local

除了注释,这个文件最初是空的。 我们的服务器还知道其他用于一般管理的区域,但这些区域在 named.conf.default-zones 文件中指定。

首先,我们需要为我们的 example.com 域配置转发区域。 转发区域是我们大多数人在讨论 DNS 时想到的传统名称到 IP 解析。 我们创建一个配置块来定义我们希望配置的域区域:

zone "example.com" {
};

笔记: 许多 DNS 工具、它们的配置文件和文档使用术语“主”和“从”,而 DigitalOcean 通常更喜欢替代描述符。 为了避免混淆,我们选择使用术语“主要”和“次要”来表示服务器之间的关系,并且仅在配置指令需要时使用“主”或“从”。


在这个块里面,我们添加了关于这个区域的管理信息。 我们指定此 DNS 服务器与区域的关系。 这是下面示例区域中的 type master;,因为我们正在将此机器配置为所有区域的主名称服务器。 我们还将 Bind 指向包含定义区域的实际资源记录的文件。

我们将把我们的主要区域文件保存在 Bind 配置目录中一个名为 zones 的子目录中。 我们将调用我们的文件 db.example.com 以从 Bind 目录中的其他区域文件中借用约定。 我们的块现在看起来像这样:

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 地址,最具体的部分在右侧。
  • 域规范中最具体的部分是子域或主机名。 这是在域的区域文件中定义的。
  • 每个子域又可以定义更多的子域或主机。

所有反向区域映射都在由 Internet 编号分配机构 (IANA) 控制的特殊域 in-addr.arpa 下定义。 在此域下,存在一棵树,它使用子域来映射 IP 地址中的每个八位字节。 为了确保 IP 地址的特殊性与普通域的特殊性相同,实际上将 IP 地址的八位字节颠倒了。

因此,我们的主 DNS 服务器的 IP 地址为 192.0.2.1,将被翻转为 1.2.0.192。 当我们将此主机规范添加为存在于 in-addr.arpa 域下的层次结构时,可以将特定主机引用为 1.2.0.192.in-addr.arpa

由于我们在使用 DNS 时在区域文件本身中定义了单个主机(如此处的前导“1”),因此我们将配置的区域将是 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

现在,我们可以使用 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.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 记录之后,我们要建立的第一件事是我们区域的名称服务器。 我们指定域,然后按名称指定对区域具有权威性的两个名称服务器。 由于这些名称服务器将是域本身内的主机,因此它看起来有点自引用。

对于我们的指南,它看起来像这样。 再次注意结尾点!:

; Name servers
example.com.    IN      NS      ns1.example.com.
example.com.    IN      NS      ns2.example.com.

由于区域文件的目的主要是将主机名和服务映射到特定地址,因此我们还没有完成。 任何读取此区域文件的软件都想知道 ns1ns2 服务器在哪里,以便访问权威区域。

所以接下来,我们需要创建 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.localnamed.conf.options 文件。 由于这两个文件都是骨架 named.conf 文件的来源,它将测试我们修改的文件的语法。

sudo named-checkconf

如果返回时没有任何消息,则表示 named.conf.localnamed.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

请密切注意此日志以确保没有错误。

配置辅助绑定服务器

现在我们已经配置了主服务器,我们可以继续设置辅助服务器。 这将比主服务器容易得多。

配置选项文件

同样,我们将从 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,因为该服务器充当该区域的辅助服务器。 这仅仅意味着它通过传输而不是本地系统上的文件接收其区域文件。 此外,我们只是要指定相对文件名而不是区域文件的绝对路径。

这样做的原因是,对于次要区域,Bind 存储文件 /var/cache/bind。 Bind 已配置为在此目录位置中查找,因此我们无需指定路径。

对于我们的前锋区域,这些细节将如下所示:

zone "example.com" {
    type slave;
    file "db.example.com";
};

最后,我们将通过 IP 地址指定主服务器,而不是 allow-transfer 指令,该服务器将从该服务器接受区域传输。 这是在一个名为 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

如果返回没有任何错误,则意味着您修改的文件没有语法错误。

如果是这种情况,您可以重新启动 Bind 服务:

sudo service bind9 restart

使用以下命令检查主服务器和辅助服务器上的日志:

sudo tail -f /var/log/syslog

您应该会看到一些指示区域文件已正确传输的条目。

将授权委托给您的名称服务器

您的仅权威名称服务器现在应该已完全配置。 但是,您仍然需要将您的域的权限委托给您的名称服务器。

为此,您必须访问您购买域名的网站。 根据您使用的域名注册商,界面和术语可能会有所不同。

在您的域设置中,查找允许您指定要使用的名称服务器的选项。 由于我们的名称服务器是 within 我们的域,这是一种特殊情况。

注册商不是通过使用 NS 记录简单地为区域委派权限,而是需要创建一个 粘合记录 。 粘合记录是一个 A 记录,它在指定将授权给的名称服务器之后指定名称服务器的 IP 地址。

通常,委托只列出将处理域权限的名称服务器,但当名称服务器位于域本身内时,父区域中的名称服务器需要 A 记录。 如果这没有发生,DNS 解析器将陷入循环,因为它永远无法找到域名称服务器的 IP 地址来遵循委托路径。

因此,您需要在域名注册商的控制面板中找到允许您指定名称服务器 的 IP 地址的部分。

作为演示,注册器 Namecheap 有两个不同的名称服务器部分。

有一个名为“Nameserver Registration”的部分允许您指定域内名称服务器的 IP 地址:

在里面,您将能够输入域中存在的名称服务器的 IP 地址:

这将创建作为您在父区域文件中需要的粘合记录的 A 记录。

完成此操作后,您应该能够将活动名称服务器更改为您域的服务器。 在 NameCheap 中,这是使用“域名服务器设置”菜单选项完成的:

在这里,您可以告诉它使用您添加的名称服务器作为您站点的权威服务器:

更改可能需要一段时间才能传播,但您应该会看到大多数注册商在接下来的 24-48 小时内使用来自您的名称服务器的数据。

结论

您现在应该配置了两个仅授权的 DNS 服务器来为您的域提供服务。 这些可用于在您获得更多域时存储其他域的区域信息。

配置和管理您自己的 DNS 服务器可让您最大程度地控制 DNS 记录的处理方式。 您可以进行更改并确保所有相关的 DNS 数据在源头都是最新的。 虽然其他 DNS 解决方案可能会使此过程更容易,但重要的是要知道您有选择并了解更多打包解决方案中发生的情况。