构建企业级DNS系统（七）搭建bind主/辅DNS

主/辅DNS介绍

DNS为什么要有主和辅

DNS系统作为网络基础服务，其系统必须具备足够强的冗余性，于是我们在搭建DNS系统时自然的想到要多搭建几台DNS服务器。那么问题来了，当有DNS业务变更时，管理员面对多台DNS服务器如何做业务变更呢？是一台一台的改？这显然不太理想。于是，我们希望在其中的一台DNS服务器上做业务变更，其他DNS服务器自动的同步，对于一个区域只维护一个区数据文件，这样工作量大大下降，而且也降低了过多人为操作带来的系统风险。

主/辅DNS重要概念

在正式搭建主/辅DNS之前，必须要了解一些重要的概念，如下：

• primary master和slave
  primary名字服务器就是主DNS，通常我们也称之为master；slave名字服务器就是辅DNS，有的时候我们也叫sencondary。slave DNS也可能是其他DNS的master（串联~），通过这个机制我们可以构建一个多主+多辅的DNS系统。当然，大多时候不需要搞这么复杂，最重要的是不能只有1台DNS！
• zone transfer
  slave DNS通过网络从master DNS那里加载数据，这个过程被称作区域传输即zone transfer。
• AXFR
  完全区域传输（Full zone transfer）或者称DNS全量更新协议，它传送的是整个区域的数据。
• IXFR
  增量区域传输（Incremental zone transfer），slave名称服务器告诉master服务器自己目前所持有得区域数据是哪个版本，而只要求发生该版本和当前版本之间有变动的部分数据即可。这样就可以大幅降低区域数据传输的大小和时间。
• NOTIFY
  众所周知，slave DNS通过区域的SOA记录中的refresh 时间定期的询问master DNS实现区域数据的自动更新。占位置轮询的机制导致区域数据变更后DNS系统全局生效有一段间隔时间。RFC 1996给出一种机制，允许master DNS通知slave DNS，区域数据已经变更，这个机制就是 DNS NOTIFY。
• 区数据传输时的端口和协议
  master和slave之间在进行zone transfer过程中会用到UDP和TCP的53端口，这个我们下面的举例会详细介绍。
• SOA中的几个数值说明
  例如：dns1.test.com. manager.test.com. 14 10800 3600 604800 800
  dns1.test.com：test.com区的primary DNS。
  manager.test.com：test.com区的管理员邮箱manager@test.com。
  14：serial number当slave联系master服务器获取区域数据时，会首先请求SOA记录，并查看这个serial number是不是比master服务器的小，如果小就表示slave的区数据过时的，然后slave才会下载一份新的区域数据副本。所以管理员要是在master 服务器上手动维护zone文件，那么一定要在每次更新zone文件时更新这个serial number。有时候管理员习惯用YYYYMMDDNN来设置这个数值，YYYY代表年份，MM代表月份，DD代表天，NN代表当日区数据被修改的次数。
  10800：更新间隔时间refresh，用于告知区域的slave间隔多长时间检查一次区数据是否有更新。
  3600：重试时间retry，如果slave服务器在更新时间到来后无法访问其master服务器（估计是挂了），它会开始每隔这个重试时间尝试重新连接一次。通常这个时间比refresh时间短。
  604800：过期时间expire，如果slave服务器在过期时间到来时无法联系到其master服务器，则slave就会使该区域失效。这个时候如果向slave查询相关域名的时候会应答SERVFAIL。理由是：与其提供旧的数据还不如不提供的好。
  800：否定缓存时间negative caching TTL，否定响应NXDOMAIN在递归服务器上的缓存时间。

bind主/辅DNS搭建举例

环境说明：
master节点192.168.3.160，bind版本bind-9.16.3
slave节点192.168.3.161，bind版本bind-9.16.3

创建test.com的辅区

• 在slave节点的named.conf配置文件中创建test.com辅区，配置语句块如下。

zone "test.com" {
       type slave;
       masters { 192.168.3.160; };
       file "test.com.zone";
};

master节点的named.conf中test.com区相关配置语句如下：

zone "test.com" {
   type master;
   allow-update { key mytest; };
   file "test.com.zone";
};

• 重启slave节点的named进程，并tcpdump抓53端口的数据包。
• 查看slave节点的软件日志能看到如下信息。

24-Jun-2020 22:08:48.232 xfer-in: info: zone test.com/IN: Transfer started.
24-Jun-2020 22:08:48.233 xfer-in: info: transfer of 'test.com/IN' from 192.168.3.160#53: connected using 192.168.3.161#51943
24-Jun-2020 22:08:48.234 xfer-in: info: zone test.com/IN: transferred serial 5
24-Jun-2020 22:08:48.234 xfer-in: info: transfer of 'test.com/IN' from 192.168.3.160#53: Transfer status: success
24-Jun-2020 22:08:48.235 xfer-in: info: transfer of 'test.com/IN' from 192.168.3.160#53: Transfer completed: 1 messages, 17 records, 393 bytes, 0.001 secs (393000 bytes/sec)
24-Jun-2020 22:08:48.235 notify: info: zone test.com/IN: sending notifies (serial 5)

查看master节点的软件日志能看到如下信息：

24-Jun-2020 22:08:48.230 xfer-out: info: client @0x7fcf18023fa0 192.168.3.161#51943 (test.com): transfer of 'test.com/IN': AXFR started (serial 5)
24-Jun-2020 22:08:48.231 xfer-out: info: client @0x7fcf18023fa0 192.168.3.161#51943 (test.com): transfer of 'test.com/IN': AXFR ended: 1 messages, 17 records, 393 bytes, 0.0

查看抓包数据如下：


通过以上的测试，我们得出以下重要结论：

• 辅区的搭建比较简单，如果是多个master则类似这样配置 masters { 192.168.3.160; 192.168.3.180; };
• 辅区首次加载时slave发的是AXFR，即要做全量的区数据同步，从截图中能看到整个区的的数据内容，是明文的。抓包的过程能看到slave先请求SOA，然后通过建立TCP连接的方式传送区数据，并用到经典53端口。
• slave数据同步成功后，会在本地生成相关zone文件，但文件的内容是无法正常浏览的，类似二进制文件。管理员一定要做解析测试，确认数据同步和加载正常。
• 此后如果人为重启slave节点的named进程，并不会再触发区传输请求。而重启master时会立即触发。

手动维护master 区数据测试了解notify和IXFR机制

管理员如果手动修改master上的test.com区文件，然后重启master服务器的named进程。此时master会立即发送notify报文给zone文件中除了soa记录中primay之外的其他NS，master相关日志如下：

24-Jun-2020 23:05:36.609 xfer-out: info: client @0x7f3924028be0 192.168.3.161#40480 (test.com): transfer of 'test.com/IN': AXFR-style IXFR started (serial 9)
24-Jun-2020 23:05:36.609 xfer-out: info: client @0x7f3924028be0 192.168.3.161#40480 (test.com): transfer of 'test.com/IN': AXFR-style IXFR ended: 1 messages, 17 records, 393 bytes, 0.001 secs (393000 bytes/sec)

slave的相关日志如下：

24-Jun-2020 23:05:36.609 general: info: zone test.com/IN: notify from 192.168.3.160#42296: serial 9
24-Jun-2020 23:05:36.610 xfer-in: info: zone test.com/IN: Transfer started.
24-Jun-2020 23:05:36.612 xfer-in: info: transfer of 'test.com/IN' from 192.168.3.160#53: connected using 192.168.3.161#40480
24-Jun-2020 23:05:36.613 xfer-in: info: zone test.com/IN: transferred serial 9
24-Jun-2020 23:05:36.613 xfer-in: info: transfer of 'test.com/IN' from 192.168.3.160#53: Transfer status: success
24-Jun-2020 23:05:36.613 xfer-in: info: transfer of 'test.com/IN' from 192.168.3.160#53: Transfer completed: 1 messages, 17 records, 393 bytes, 0.001 secs (393000 bytes/sec)
24-Jun-2020 23:05:36.613 notify: info: zone test.com/IN: sending notifies (serial 9)

相关过程抓包如下：


通过以上的测试，我们得出以下重要结论：

• master重启后会立即触发notify通知给slave，这个是bind机制，就是说bind9默认就开启了notify，不需要在配置文件中显示的开启。
• slave接到master的notify消息后，会应答这个notify消息，然后再发一次SOA记录查询，查询自己的serial number是不是最新的，如果不是，那么就进入区数据传输过程，而且是IXFR类型即增量数据传输。
• 通过抓包可见，这种情况下，虽然管理员只是修改了zone文件的一条域名，而且报文中也显示是IXFR类型，但传输的数据还是整个区域的数据。所以IXFR增量区数据传送这个方式更适合在动态更新的场景中。

动态更新方式测试IXFR和NOTIFY

• 在master上使用nsupdate动态更新test.com区，新增fff.test.com域名。

[root@localhost bind]# nsupdate -y mytest:7fDlWke7zAvqD+I6ubgXwA==
> server 127.0.0.1
> update add fff.test.com 300 A 9.9.9.9
> send
> quit

• master的相关日志如下

24-Jun-2020 23:55:14.900 update-security: info: client @0x7f90a8005670 127.0.0.1#28046/key mytest: signer "mytest" approved
24-Jun-2020 23:55:14.900 update: info: client @0x7f90a8005670 127.0.0.1#28046/key mytest: updating zone 'test.com/IN': adding an RR at 'fff.test.com' A 9.9.9.9
24-Jun-2020 23:55:14.903 notify: info: zone test.com/IN: sending notifies (serial 14)
24-Jun-2020 23:55:14.907 xfer-out: info: client @0x7f90a4028be0 192.168.3.161#44235 (test.com): transfer of 'test.com/IN': IXFR started (serial 13 -> 14)
24-Jun-2020 23:55:14.908 xfer-out: info: client @0x7f90a4028be0 192.168.3.161#44235 (test.com): transfer of 'test.com/IN': IXFR ended: 1 messages, 5 records, 203 bytes, 0.001 secs (203000 bytes/sec)

• slave的相关日志如下

24-Jun-2020 23:55:14.905 notify: info: client @0x7f6fdc00a2b0 192.168.3.160#34758: received notify for zone 'test.com'
24-Jun-2020 23:55:14.905 general: info: zone test.com/IN: notify from 192.168.3.160#34758: serial 14
24-Jun-2020 23:55:14.906 xfer-in: info: zone test.com/IN: Transfer started.
24-Jun-2020 23:55:14.907 xfer-in: info: transfer of 'test.com/IN' from 192.168.3.160#53: connected using 192.168.3.161#44235
24-Jun-2020 23:55:14.911 xfer-in: info: zone test.com/IN: transferred serial 14
24-Jun-2020 23:55:14.911 xfer-in: info: transfer of 'test.com/IN' from 192.168.3.160#53: Transfer status: success
24-Jun-2020 23:55:14.911 xfer-in: info: transfer of 'test.com/IN' from 192.168.3.160#53: Transfer completed: 1 messages, 5 records, 203 bytes, 0.003 secs (67666 bytes/sec)
24-Jun-2020 23:55:14.912 notify: info: zone test.com/IN: sending notifies (serial 14)

• 相关抓包如下
  
  通过以上的测试，我们得出以下重要结论：
• master上执行动态更新后，master会立即发送notify消息给slave。
• 此时slave请求的是IXFR增量区数据更新，并且master应答的也是增量的数据即fff.test.com这个域名的更新。

要考虑哪些安全问题及相关配置优化

讲到这里，基本我们已经DNS的主辅同步以及bind软件的主辅配置及工作机制有了基础的了解。但目前还有一些问题需要我们思考：

• 我们在任何到master网络可达的客户端执行dig @192.168.3.160 test.com axfr都能拿到整个区的数据。如果有人恶意发送，那么master肯定会X尽人亡，拒绝服务的。
• mater给slave发notify消息，slave也会应答notify消息。如果有人伪造master给slave发送notify，那么slave就会不停的确认是不是要更新区数据，如果有人恶意这么搞，那么master肯定又要X尽人亡，拒绝服务的。
• 传输的数据是明文的，那么怎么能证明这个传输的过程中没有人修改过呢？
  于是，我们需要用如下的几个参数来做一些安全控制。

参数名称	参数说明
allow-transfer	指定哪些主机允许从服务器接收区传送，这个语句可以在named.conf的options全局配置，也可以在zone语句中配置，例如 allow-transfer { 192.168.3.161; };如果都配置了，那么zone语句中的配置会覆盖设置在options或view中的相关配置。这个时候不在这个允许的主机IP再发AXFR时结果就是Transfer failed.
allow-notify	这个指定哪些主机可以发生NOTIFY消息通知本服务器，这个仅适用于slave，可以设置在view、options、zone中。如果未指定，那么缺省是处理来自区中配置在master中的服务器的NOTIFY消息。allow-notify可以用于扩展允许的主机名单，但不能缩写它。
also-notify	名字服务器IP列表，无论何时只要有更新的内容加载，都会向这个表中的IP发出NOTIFY消息，还包括在区文件中NS记录列出的服务器，相当于扩展。有助于区拷贝同步到隐藏的服务器，有一个端口的可选参数。

综上，我们举一个master的例子如下：

zone "example.com" {
	type master;
	file "example.com.zone";
	allow-update { key "mytest"; };
    also-notify { 10.10.10.10 port 53; 10.10.10.11 port 53; };
    allow-transfer { key "mytest";  10.10.10.10; 10.10.10.11;};
    };

对应slave的例子如下：

zone "example.com" {
	type slave;
	file "example.com.zone";
    masters { 10.10.10.100 port 53; };
    allow-notify { 10.10.10.100; };
    };