目录

1.DNS 现状以及面临的问题

2. DNS优化

a) 什么是 Bind

b)Bind 的解析过程

c)Bind 的特性

d) 性能测试

3.Bind 架构

a) 介绍现况

b) 配置文件详解

4. 那些年我们错过的注意事项与建议

a)match-clients

b) 监控

5. 总结

1.DNS 现状以及面临的问题

在现如今的公司内部，我们可能需要解析成千上万个内部域名以及内部机器名，而通过在机器上写死 host IP 对应关系来解决解析问题，在域名与机器数量如此多的情况下，维护机器的 host 文件是一个成本很高的事情，因此在内部提供了 DNS 解析服务，用于提供各个机房的特殊解析服务，是一件很重要的事情。

但是随着公司的发展越来越快，所需要提供解析也从几千发展到上万，我们可能会遇到一下这些问题：

1． 修改记录后生效时间慢，紧急故障切换时产生等待时间。

2． 无法高效的记录 DNS 请求日志，回查、统计不方便。

3． 每台 DNS 都管理自身的 Zone 文件，维护成本大。

4. Bind 性能差，无法充分利用宿主机性能。

在这种情况下，缩短记录生效时间，减少维护成本，提升 Bind 性能的工作就被提上了日程。

本文在 DNS 解析器的选择上，使用了 ISC 的开源软件–Bind。

2.DNS优化

2.1 什么是 Bind

要说 Bind，就要说什么是 DNS，DNS 是域名系统 (Domain Name System) 的缩写，它是由解析器和域名服务器组成的。域名服务器是指保存有该网络中所有主机的域名和对应 IP 地址，并具有将域名转换为 IP 地址功能的服务器。其中域名必须对应一个 IP 地址，而 IP 地址不一定有域名。域名系统采用类似目录树的等级结构。域名服务器为客户机 / 服务器模式中的服务器方，它主要有两种形式：主服务器和转发服务器。将域名映射为 IP 地址的过程就称为 “域名解析”。而 Bind 就是一款开源的实现 DNS 域名解析的软件，它由域名解析器、域名授权服务器和工具组成。

2.2 DNS 域名的解析过程

客户端向发起一个 DNS 请求，如果该请求被本机缓存，则直接返回，否则将会到达本地 DNS 服务器，本地 DNS 服务器首先会去查询自身的区域文件，如果匹配成功，返回结果，如果请求的解析不在自身的区域文件中，则将请求转发出去，此时该 DNS 请求会根据根提示，逐步查找顶级域名，直到查到结果。

2.3 Bind 特性

随着技术的革新，现在的机器的性能越来越高，但如果不修改 Bind 的一些配置限制，会导致 Bind 无法充分利用机器的性能，因此这里谈一下可以提升 Bind 性能的几个点

1.ISC_SOCKET_MAXEVENTS

Bind 默认会开启最多 64 个和内核的通信事件数，你可以通过修改源码来达到增加通信事件数，代码路径为 bind-x.x.xx/lib/isc/unix/socket.c

2.ISC_SOCKET_MAXSOCKETS

Bind 默认使用的最大的套接字数目为 4096，你可以通过 named –S 来增加套接字数，注意套接字只能调高无法调低，你也可以在编译前，在 bind-x.x.xx/lib/isc/unix/socket.c 中修改该参数，注意 1 和 2 的调节会增加 named 对内存的使用量。

3.RCVBUFSIZE

Bind 的默认 RCVBUFSIZE 为 32K，如果你想使用更大的接收队列，可以在编译前修改 define RCVBUFSIZE，代码路径为 bind-x.x.xx/lib/isc/unix/socket.c

RESOLVER_NTASKS

这个一个很重要的参数，Bind 之所以存在一个性能瓶颈而不是随着机器的 cpu 的提升而提升，很重要的一点就是因为 Bind 的域名解析过程是带锁的 (具体解析过程请参考 bind-x.x.xx/bin\named\server.c)，因此增加 Bind 的解析器任务的个数是非常重要的，增加解析器任务的数量能减少锁的争用并提高吞吐量，但这也很大的增加了 named 进程使用的内存，你可以在 bind-x.x.xx/bin\named\server.c 和 bind-x.x.xx/bin\named\client.c 中修改它。

2.4 性能测试

2.4.1 测试目标

1．PPS 峰值

2. 丢包率与时延

2.4.2 测试环境

机器系统版本：Centos 7.3

机器内核版本：3.18

机器 CPU 型号：Intel(R) Xeon(R) CPU E5-2620 v3 @ 2.40GHz

机器 CPU 个数：2

机器内存：128G

机器网卡：万兆网卡

2.4.3 测试步骤与方法

测试工具：queryperf

测试方法：在压力测试机上使用 queryperf 工具对 Bind 机器模拟请求，请求的总次数为 200W。测试命令为：./queryperf -d test.txt -s 1.1.1.1 -q X 逐渐提高 X，来模拟并发，q 的测试值为 20，30，40，50，60，70，80(-q 表示一次发送的请求数默认为 20)。

2.4.4 测试结果

a). 当 q 逐渐变大，QPS 逐渐升高。QPS 峰值为 21W 左右

b).Bind 服务器和压力测试机的网卡吞吐和 CPU 均未满。Cpu.busy 值在 20% 左右。

3.Bind 架构

3.1 架构介绍

为了解决同步生效时间慢，减少维护成本等问题，我们现在的 Bind 架构为 DNS Master/Slave。如下图所示，A，B 两个机房都有 Master DNS 与 Slave DNS，Slave DNS 通过宣告 VIP 的方式来提供集群服务，避免当单台 DNS 宕机时，影响整个 DNS 集群，这样能有效的提高 DNS 集群的的鲁棒性。

3.2 配置文件详解

上文提到由于现在使用了 M/S 架构，所以 Master 和 Slave 上的配置文件也是不同的，下面我们就来扯一扯两类机器配置的问题。先说 Master 的配置：

controls {

inet 127.0.0.1 port 953 allow {

127.0.0.1/32;

} keys {

"rndc-key";

};

};

logging {

channel "default_file" {

file "/home/named/default.log" versions 3 size 20971520;

severity dynamic;

print-time yes;

};

channel "general_file" {

file "/home/named/general.log" versions 3 size 20971520;

severity dynamic;

print-time yes;

};

………

category "default" {

"default_file";

};

category "general" {

"general_file";

};

……….

}

options {

directory "/usr/local/named/var";

pid-file "/usr/local/named/run/named.pid";

allow-query {

"any";

};

forwarders {

8.8.8.8;

};

notify explicit;

};

zone "." {

type hint;

file "/xxx/xx/xx/named.ca";

};

zone "example.com" IN {

type master;

file "example.com";

also-notify {

192.168.1.2;

};

};

key "rndc-key" {

algorithm hmac-md5;

secret "SUdSDGlCA8uCpjLJwCGYjw==";

};

接下来我们就来解释一下上述配置文件

Controls 中记录的是使用 RNDC 相关配置

inet 127.0.0.1 port 953 定义通信 IP 和端口

Keys：定义允许操作的 Key

Allow：来限制允许操作的 IP

Logging 中定义 DNS 的日志信息

Channel：后跟通道名，这个一个任意但是唯一的名字，用于将类别与通道定义相关连。

File：用于定义文件存放的路径

Versions：用于保存文件的数量

Size：用于限制单个文件的日志大小，默认单位为 bytes，你也可以使用 K，M，G 等单位

Category：用于控制各种已经定义或者默认的 Channel name 类别，默认可以采用以下值。

Options 中保存着 named 的配置文件

Directory：表示 named 存储的 Zone 文件路径

pid-file：表示运行 named 时，pid 文件的路径

allow-query：表示允许来查询的 IP 列表，其内容可以是 IP, 可以是网段，

forwarders：表示当本机没有对应解析时，DNS 会将请求递归下一跳机器。

Notify：用于表示是否发送 Notify 请求。可选参数为 notify yes | no | explicit;

Zone 中保存解析的详细内容

Type：表示该 Zone 的类型，

File：表示该 Zone 解析文件存放的路径

also-notify：表示当 Zone 文件修改时，Master DNS 会向哪些 Slave DNS 下发 Notify 请求。

最后是 Key ，Key 中保存着这台 DNS 持有的 TSIG 密钥。

algorithm：表示该密钥的加密方式，默认为 hmac-md5。

secret：表示该密钥的密文，

接下来说一下 Slave DNS 的配置文件

controls {

inet 127.0.0.1 port 953 allow {

127.0.0.1/32;

} keys {

"rndc-key";

};

};

logging {

channel "default_file" {

file "/home/named/default.log" versions 3 size 20971520;

severity dynamic;

print-time yes;

};

channel "general_file" {

file "/home/named/general.log" versions 3 size 20971520;

severity dynamic;

print-time yes;

};

………

category "default" {

"default_file";

};

category "general" {

"general_file";

};

……….

}

options {

directory "/usr/local/named/var";

pid-file "/usr/local/named/run/named.pid";

allow-query {

"any";

};

forwarders {

8.8.8.8;

};

notify explicit;

};

zone "." {

type hint;

file "/xxx/xx/xx/named.ca";

};

zone "example.com" IN {

type slave;

file "example.com";

masters {

"192.168.1.1";

};

};

key "rndc-key" {

algorithm hmac-md5;

secret "SUdSDGlCA8uCpjLJwCGYjw==";

};

Slave DNS 的配置文件与 Master DNS 的配置文件基本相同，主要的差距在于 Zone 中的 Type 为 Slave，且在 Zone 中还包含了 masters 字段，其作用是记录这个 Zone 文件会向哪台 Master 同步数据。

4. 那些年我们错过的注意事项与建议

4.1 match-clients

首先要说的是 match-clients， match-clients 只能在 view 中使用，其目的是让 view 被目标客户端匹配，match-clients 的配置参数如下：

match-clients {address_match_element ; ......};

address_match_list = element ; [element; ...]

element = [!] (ip [/prefix] | key key-name | "acl_name" | {address_match_list} )

当客户端的其中一条情况满足 match-clients 时，match-clients 就会将你的 Query 捕获进 View，一般来说，区域化解析和智能 DNS，都离不开这个参数。要注意当有一条情况满足 match-clients 的条件时，这个 Query 就会被这个 View 处理。当你的一个 query 中带有 TSIG 与 IP 时，match-clients，容易将这个 query 的 tsig 与 IP 当成两个条件或处理，最后导致你的 Query 命中了错误的 View

4.2 对 Zone 文件的监控

要对 Zone 文件进行监控，我们首先来讲一下 SOA，SOA 全称为 Start Of Authority，它存放在 Zone 文件的第一行，每个 Zone 文件只能有一个 SOA，SOA 记录了这个 Zone 负责的 name server，version number 等信息。

对 Zone 文件的监控主要有两点:

1）该文件是否有错误

引起错误的原因有很多，比如错误的 SOA 内容，一个域名同时存在 A 记录解析和 CNAME 记录解析等，当该文件错误时，Bind 就无法正常加载该 Zone 文件，而它的报错日常会记录在我上述所说的 logging 中

2）该文件是否实时生效

当你的 DNS 架构为 M/S 时，且确定 Master 上已经成功加载了对应的 Zone 文件，但是你如何知道 Slave 上已经生效了？有两个方法 1）通过查看 Slave 上的 Xfer-in 日志，来确定你的记录是否下发，2) 通过查看 Slave DNS 上 Zone 文件的 SOA 中的 serial number 与 Master 上的是否相同，来确定 Slave DNS 的记录是否已经生效。

5. 总结

本文介绍了 DNS 的相关知识，以及我们对开源软件 Bind 的一些理解，以及我们对 Bind 的部署方式，以及优化方法，希望对大家有帮助。