如何配置绑定作为高速缓存或转发DNS服务器上的Ubuntu 14.04

介绍

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

在本指南中，我们将讨论如何在Ubuntu 14.04计算机上安装和配置Bind9 DNS服务器作为缓存或转发DNS服务器。 这两种配置在服务网络的机器时都有优势。

先决条件和目标

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

我们将演示两个单独的配置，实现类似的目标：缓存和转发DNS服务器。

要继续，您需要访问两台计算机（至少其中一台应该是Ubuntu 14.04服务器）。 一个将作为客户端，另一个将被配置为DNS服务器。 我们的示例配置的详细信息：

我们将向您展示如何配置客户端机器以使用DNS服务器进行查询。 我们将告诉您如何配置DNS服务器在两个不同的配置，根据您的需要。

缓存DNS服务器

第一结构将是一个缓冲 DNS服务器。 这种类型的服务器也称为解析器，因为它处理递归查询，通常可以处理从其他服务器跟踪DNS数据的咕噜工作。

当缓存DNS服务器跟踪客户端查询的答案时，它会向客户端返回答案。 但它也将答案存储在其缓存中的记录的TTL值允许的时间段。 然后，高速缓存可以用作后续请求的源，以便加快总往返时间。

您的网络配置中可能具有的几乎所有DNS服务器都将缓存DNS服务器。 这些弥补了在大多数客户端机器上实现的缺乏足够的DNS解析器库。 缓存DNS服务器是很多情况下的不错选择。 如果你不想依赖你的ISP的DNS或其他公共可用的DNS服务器，自己的缓存服务器是一个不错的选择。 如果它处于与客户端机器紧密物理接近的地方，它也很可能提高DNS查询时间。

转发DNS服务器

我们将展示第二结构是一个转发 DNS服务器。 从客户端的角度来看，转发DNS服务器看起来几乎与缓存服务器相同，但是机制和工作负载是完全不同的。

转发DNS服务器提供了维护缓存以提高客户端的DNS解析时间的同样优势。 然而，它实际上不执行递归查询本身。 相反，它将所有请求转发到外部解析服务器，然后缓存结果以用于以后的查询。

这使得转发服务器从其缓存响应，而不需要它执行递归查询的所有工作。 这允许服务器只做出单个请求（转发的客户端请求），而不必经过整个递归例程。 这在外部带宽传输成本高昂，缓存服务器可能需要经常更改，或者您希望将本地查询转发到一个服务器和外部查询到另一个服务器的环境中，这可能是一个优势。

在DNS服务器上安装绑定

无论您希望使用哪种配置选项，实现绑定DNS服务器的第一步是安装实际的软件。

绑定软件是Ubuntu的默认存储库中可用，所以我们只需要更新我们的本地包指数，并使用安装软件apt 。 我们还将包括文档和一些常见的实用程序：

sudo apt-get update
sudo apt-get install bind9 bind9utils bind9-doc

现在，Bind组件已安装，我们可以开始配置服务器。 转发服务器将使用缓存服务器配置作为跳过点，因此无论您的最终目标是什么，请先将服务器配置为缓存服务器。

配置为缓存DNS服务器

首先，我们将介绍如何配置绑定作为缓存DNS服务器。 此配置将强制服务器在客户端发出查询时递归地寻找来自其他DNS服务器的答案。 这意味着它正在依次查询每个相关的DNS服务器，直到它找到整个响应。

BIND配置文件默认情况下，在一个目录存放/etc/bind 。 现在移动到该目录：

cd /etc/bind

我们不会关心这个目录中的大多数文件。 主要的配置文件名为named.conf （ named和bind是相同的应用两个名字）。 该文件只源的named.conf.options文件，该named.conf.local文件和named.conf.default-zones的文件。

对于一个缓存DNS服务器，我们将只修改named.conf.options文件。 在您的文本编辑器中使用sudo权限打开：

sudo nano named.conf.options

随着注释被删除为了可读性，文件看起来像这样：

options {
        directory "/var/cache/bind";

        dnssec-validation auto;

        auth-nxdomain no;    # conform to RFC1035
        listen-on-v6 { any; };
};

要配置缓存，第一步是设置访问控制列表或ACL。

作为将用于解决递归查询的DNS服务器，我们不希望DNS服务器被恶意用户滥用。 攻击称为DNS放大攻击是特别麻烦，因为它可能会导致你的服务器参与的分布式拒绝服务攻击。

DNS放大攻击是恶意用户尝试删除互联网上的服务器或网站的一种方式。 为此，他们尝试查找将解析递归查询的公共DNS服务器。 他们欺骗受害者的IP地址，并发送一个查询，返回对DNS服务器的大响应。 在这样做时，DNS服务器响应于具有针对受害者服务器的大有效载荷的小请求，有效地放大攻击者的可用带宽。

托管公共，递归DNS服务器需要大量的特殊配置和管理。 为了避免您的服务器被用于恶意目的，我们将配置一个我们信任的IP地址或网络范围的列表。

上面的options块，我们将创建一个名为新块acl 。 为要配置的ACL组创建一个标签。 在本指南中，我们将调用组goodclients 。

acl goodclients {
};

options {
    . . .

在此块中，列出应允许使用此DNS服务器的IP地址或网络。 由于我们的服务器和客户端都在相同的/ 24子网内运行，我们将示例限制到此网络。 我们也将增加localhost和localnets将尝试自动执行此操作：

acl goodclients {
    192.0.2.0/24;
    localhost;
    localnets;
};

options {
    . . .

现在，我们有我们想要解析的请求的客户端的访问控制列表，我们可以配置在这些功能options阻止。 在此块中，添加以下行：

options {
    directory "/var/cache/bind";

    recursion yes;
    allow-query { goodclients; };
    . . .

我们明确启用递归，然后配置allow-query使用我们的ACL规格参数。 我们可以使用不同的参数，如allow-recursion引用我们的ACL组。 如果存在和递归是， allow-recursion将决定可使用递归服务客户的名单。

但是，如果allow-recursion没有设置，然后绑定回落上allow-query-cache列表，那么allow-query列表，终于默认localnets和localhost只。 既然我们在配置缓存唯一服务器（它有自己的没有权威的区域，不转发请求），则allow-query列表将永远只适用于递归。 我们使用它，因为它是指定ACL的最通用的方法。

完成这些更改后，保存并关闭文件。

这实际上是缓存DNS服务器所需要的。 如果您决定这是您要使用的服务器类型，请随时跳过以了解如何检查配置文件，重新启动服务和实施客户端配置。

否则，请继续阅读以了解如何设置转发DNS服务器。

配置为转发DNS服务器

如果转发DNS服务器更适合您的基础设施，我们可以轻松地设置它。

我们将从在缓存服务器配置中停止的配置开始。 该named.conf.options文件应该是这样的：

acl goodclients {
        192.0.2.0/24;
        localhost;
        localnets;
};

options {
        directory "/var/cache/bind";

        recursion yes;
        allow-query { goodclients; };

        dnssec-validation auto;

        auth-nxdomain no;    # conform to RFC1035
        listen-on-v6 { any; };
};

我们将使用相同的ACL列表来将我们的DNS服务器限制为特定的客户端列表。 但是，我们需要更改配置，以使服务器不再尝试执行递归查询本身。

要做到这一点，我们不改变recursion没有。 转发服务器仍然通过回答其不是权威的区域的查询来提供递归服务。 相反，我们需要设置一个缓存服务器列表来转发我们的请求。

这将在内部完成options {}块。 首先，我们创建一个名为内部的块forwarders包含我们想请求转发到递归域名服务器的IP地址。 在我们的指南中，我们将使用谷歌的公共DNS服务器（ 8.8.8.8和8.8.4.4 ）：

. . .
options {
        directory "/var/cache/bind";

        recursion yes;
        allow-query { goodclients; };

        forwarders {
                8.8.8.8;
                8.8.4.4;
        };
        . . .

随后，我们应该设置forward指令“唯一”，因为该服务器转发所有请求，不应试图解决它自身的请求。

完成后，配置文件将如下所示：

acl goodclients {
        192.0.2.0/24;
        localhost;
        localnets;
};

options {
        directory "/var/cache/bind";

        recursion yes;
        allow-query { goodclients; };

        forwarders {
                8.8.8.8;
                8.8.4.4;
        };
        forward only;

        dnssec-validation auto;

        auth-nxdomain no;    # conform to RFC1035
        listen-on-v6 { any; };
};

我们应该做的最后一个变化是将dnssec参数。 使用当前配置，根据转发的DNS服务器的配置，您可能会看到在日志中看起来像这样的一些错误：

Jun 25 15:03:29 cache named[2512]: error (chase DS servers) resolving 'in-addr.arpa/DS/IN': 8.8.8.8#53
Jun 25 15:03:29 cache named[2512]: error (no valid DS) resolving '111.111.111.111.in-addr.arpa/PTR/IN': 8.8.4.4#53

为了避免这种情况，改变dnssec-validation设置为“是”，并明确支持DNSSEC：

. . .
forward only;

dnssec-enable yes;
dnssec-validation yes;

auth-nxdomain no;    # conform to RFC1035
. . .

保存并在完成后关闭文件。 您现在应该有一个转发DNS服务器。 继续到下一部分以验证配置文件并重新启动守护程序。

测试您的配置并重新启动绑定

现在您的Bind服务器已配置为缓存DNS服务器或转发DNS服务器，我们已准备好实施更改。

在我们采取行动并重新启动我们的系统上的绑定服务器之前，我们应该使用Bind的包含的工具来检查我们的配置文件的语法。

我们可以轻松地通过键入：

sudo named-checkconf

如果配置中没有语法错误，shell提示将立即返回，而不显示任何输出。

如果您的配置文件中有语法错误，您将收到错误和行号的警告。 如果发生这种情况，请返回并检查您的文件是否有错误。

验证配置文件没有任何语法错误后，重新启动绑定守护程序以实现更改：

sudo service bind9 restart

之后，在设置客户端计算机时要注意服务器日志，以确保一切顺利。 将此运行在服务器上：

sudo tail -f /var/log/syslog

现在，打开一个新的终端窗口来配置客户端计算机。

配置客户端计算机

现在您的服务器已启动并正在运行，您可以将客户端计算机配置为使用此DNS服务器进行查询。

登录到您的客户端计算机。 确保您在为DNS服务器设置的ACL组中指定了您正在使用的客户端。 否则DNS服务器将拒绝为客户端提供请求。

我们需要编辑/etc/resolv.conf文件到我们的服务器指向域名服务器。 这里做的更改只会持续到重新启动，这是伟大的测试。 如果我们对测试结果感到满意，我们可以使这些更改永久生效。

在文本编辑器中使用sudo权限打开文件：

sudo nano /etc/resolv.conf

该文件将列出的DNS服务器使用通过设置来解析查询nameserver的指令。 注释掉的当前所有条目，并添加一个nameserver指向你的DNS服务器产品线：

nameserver 192.0.2.1
# nameserver 8.8.4.4
# nameserver 8.8.8.8
# nameserver 209.244.0.3

保存并关闭文件。

现在，您可以测试以确保查询可以通过使用一些常用工具正确解决。

您可以使用ping来测试连接可以在域进行：

ping -c 1 google.com

PING google.com (173.194.33.1) 56(84) bytes of data.
64 bytes from sea09s01-in-f1.1e100.net (173.194.33.1): icmp_seq=1 ttl=55 time=63.8 ms

--- google.com ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 63.807/63.807/63.807/0.000 ms

这意味着我们的客户端可以连接google.com使用我们的DNS服务器。

我们可以通过使用DNS就像特定的工具获得更详细的信息dig 。 本次尝试其他网域：

dig linuxfoundation.org

; <<>> DiG 9.9.5-3-Ubuntu <<>> linuxfoundation.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35417
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;linuxfoundation.org.       IN  A

;; ANSWER SECTION:
linuxfoundation.org.    6017    IN  A   140.211.169.4

;; Query time: 36 msec
;; SERVER: 192.0.2.1#53(192.0.2.1)
;; WHEN: Wed Jun 25 15:45:57 EDT 2014
;; MSG SIZE  rcvd: 64

您可以看到查询需要36毫秒。 如果我们再次提出请求，服务器应该从其缓存中提取数据，减少响应时间：

dig linuxfoundation.org

; <<>> DiG 9.9.5-3-Ubuntu <<>> linuxfoundation.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18275
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;linuxfoundation.org.       IN  A

;; ANSWER SECTION:
linuxfoundation.org.    6012    IN  A   140.211.169.4

;; Query time: 1 msec
;; SERVER: 192.0.2.1#53(192.0.2.1)
;; WHEN: Wed Jun 25 15:46:02 EDT 2014
;; MSG SIZE  rcvd: 64

正如你所看到的，缓存的响应明显更快。

我们也可以通过使用我们发现（IP地址测试反向查找140.211.169.4在我们的例子中）与挖的-x选项：

dig -x 140.211.169.4

; <<>> DiG 9.9.5-3-Ubuntu <<>> -x 140.211.169.4
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61516
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;4.169.211.140.in-addr.arpa.    IN  PTR

;; ANSWER SECTION:
4.169.211.140.in-addr.arpa. 3402 IN CNAME   4.0-63.169.211.140.in-addr.arpa.
4.0-63.169.211.140.in-addr.arpa. 998 IN PTR load1a.linux-foundation.org.

;; Query time: 31 msec
;; SERVER: 192.0.2.1#53(192.0.2.1)
;; WHEN: Wed Jun 25 15:51:23 EDT 2014
;; MSG SIZE  rcvd: 117

如您所见，反向查找也成功。

回到您的DNS服务器，您应该看看在测试期间是否记录了任何错误。 一个常见的错误可能会显示如下：

. . .
Jun 25 13:16:22 cache named[2004]: error (network unreachable) resolving 'ns4.apnic.net/A/IN': 2001:dc0:4001:1:0:1836:0:140#53
Jun 25 13:16:22 cache named[2004]: error (network unreachable) resolving 'ns4.apnic.com/A/IN': 2001:503:a83e::2:30#53
Jun 25 13:16:23 cache named[2004]: error (network unreachable) resolving 'sns-pb.isc.org/AAAA/IN': 2001:500:f::1#53
Jun 25 13:16:23 cache named[2004]: error (network unreachable) resolving 'ns3.nic.fr/A/IN': 2a00:d78:0:102:193:176:144:22#53

这些表示服务器正在尝试解析IPv6信息，但服务器未配置为IPv6。 你可以通过告诉绑定只使用IPv4来解决这个问题。

要做到这一点，打开/etc/default/bind9使用sudo权限的文件：

sudo nano /etc/default/bind9

在内部，修改OPTIONS参数包括-4标志，强制仅限IPv4的行为：

OPTIONS="-u bind -4"

保存并关闭文件。

重新启动服务器：

sudo service bind9 restart

您不应该再次在日志中看到这些错误。

使客户端DNS设置永久

如前面提到的， /etc/resolv.conf ，客户端机器指向我们的DNS服务器设置将无法生存重新启动。 要使更改最后一次，我们需要修改用于生成此文件的文件。

如果客户端机器运行Debian或Ubuntu，打开/etc/network/interfaces使用sudo权限的文件：

sudo nano /etc/network/interfaces

查找dns-nameservers参数。 您可以删除现有条目并将其替换为DNS服务器，或者仅将DNS服务器添加为以下选项之一：

. . .
iface eth0 inet static
        address 111.111.111.111
        netmask 255.255.255.0
        gateway 111.111.0.1
        dns-nameservers 192.0.2.1
. . .

保存并在完成后关闭文件。 下次启动时，将应用您的设置。

如果客户端运行的CentOS或Fedora，你需要打开/etc/sysconfig/network/network-scripts/ifcfg-eth0文件，而不是：

sudo nano /etc/sysconfig/network-scripts/ifcfg-eth0

在内部，查找以开头的行DNS 。 更改DNS1到您的DNS服务器。 如果您不想使用其他DNS服务器作为回退，请删除其他条目：

DNS1=192.0.2.1

保存并在完成后关闭文件。 您的客户端应在下次启动时使用这些设置。

结论

您现在应该有一个缓存或转发DNS服务器配置为服务您的客户端。 这可以是加快您正在管理的计算机的DNS查询的好方法。

如果你想创造一个权威为自己的域名区的DNS服务器，则可以配置仅权威DNS服务器或合并这些解决方案。