基于TSIG机制的DNS主从服务器MFA安全加密传输的研究与实践

周鸣爱

（赛迪研究院网络安全研究所，北京 100846）

1 引言

域名管理系统（Domain Name System，DNS）域名解析是互联网基础中非常重要的一部分，将域名转换成IP地址，这样通过域名可以方便地访问到网站。域名解析就是将域名转换成IP的过程，解析过程由DNS服务器完成。DNS作为将域名和IP地址相互映射的分布式数据库，是互联网重要的基础设施之一，几乎大部分的网络想要正常运行，都需要依靠DNS。因此，DNS服务器一旦发生故障，即使E-mail或Web网站此时能够正常运行，用户也无法使用。

在互联网中超过95%的DNS服务器的搭建都是基于BIND域名解析服务，为保障解析服务安全，BIND服务程序已提供了对TSIG（RFC 2845）加密机制的支持。TSIG加密机制主要是通过密码编码方式对Zone Transfer（区域信息传输）保护，即保证DNS服务器间传送区域信息的安全。针对企业内网自建DNS服务器网络环境可变性较大，技术人员流动性较强的特点，本文结合多因素认证，提出了一种新的DNS安全加密认证的实践方案。

2 DNS域名解析

域名与由一串数字构成的IP地址相比，更容易记忆和理解，用户对网络资源进行访问时，一般情况下都是通过域名访问，但是在互联网中计算机之间身份的相互识别只能是基于IP地址，并且数据在互联网中的传输，也必须通过外网IP实现。

DNS技术的出现，方便了用户对网络资源的访问，该技术主要是对域名和IP地址的对应关系进行管理和解析，即在获取到用户输入的IP地址或域名后，自动查找与之具有映射关系的域名或IP地址，简而言之，就是进行正向解析和反向解析，所谓正向解析即查找到与输入域名相对应的IP地址；反向解析即查找与IP地址相对应的域名。有了DNS技术，用户只需在浏览器中输入方便记忆的域名，就可以访问到自己想访问的网站，其中DNS域名解析中的正向解析技术是最为常用工作模式。

从工作形式上来看DNS域名解析服务包括主服务器、从服务器和缓存服务器，其中主服务器负责维护特定区域内IP地址和域名的对应关系，主服务器在该区域内具有唯一性。从服务器主要是作为主服务器的备机，从服务器会从主服务器中获取域名和IP地址的映射关系并维护。缓存服务器主要是从其他域名解析服务器获取IP地址和域名的对应关系，提高非第一次查询效率。

随着互联网技术的发展，IP地址和域名对应关系数据库越来越庞大，因此DNS域名解析服务器使用树形结构来记录IP地址和域名的映射关系，从而形成了一个树形结构的分布式数据库系统，如图1所示。

在通常情况下，在浏览器中输入网址域名时，最后的根域（.）不需要输入，通常顶级域表示的是国家或组织形式，如edu表示政府机构组织；com表示商业公司；cn表示中国。二级域名表示公司或者组织。三级域名表示的是公司或组织内部的主机名称。因此通过一个完整的域名可以精确的定位全球唯一一台主机。这种结构的优势在于全球所有的域名信息不需要都由根域服务器来管理，只有顶级域信息由根域服务器管理，二级域信息由顶级域服务器管理。依此类推，实行分层管理。

图1 DNS域名解析服务器树形目录结构

3 BIND服务的安装

BIND—伯克利因特网名称域，其全称为Berkeley Internet Name Domain Service，在全世界范围内是使用安全、更广泛、高效且可靠的域名解析服务程序。Internet中超过50%的DNS服务器的架设都使用的是BIND。作为互联网基础设施服务的DNS域名解析服务有着至关重要的作用，因此为确保整个服务器的安全，BIND服务程序在生产环境中安装部署时应加上chroot扩展包即牢笼机制。这样，将BIND服务程序文件操作范围限制在自身配置文件范围内，具体步骤有三。

（1）首先需要查看是否存在chroot扩展包

查看所有rpm包信息，包括可更新的和可安装的

[root@MiWiFi-R3-srv ~]# yum list | grep bind-chroot

b in d -ch ro o t.x86 _ 6 4 32:9.11.4-16.P2.el7_8.6 @updates

[root@MiWiFi-R3-srv ~]# 1.37.1-9.el7 base。

（2）有安装源，直接安装

[root@MiWiFi-R3-srv ~]# yum install bindchroot。

（3）查看是否安装成功

[root@MiWiFi-R3-srv ~]# rpm -qa | grep bind

bind-libs-9.11.4-16.P2.el7_8.6.x86_64

bind-9.11.4-16.P2.el7_8.6.x86_64

bind-export-libs-9.11.4-16.P2.el7.x86_64

bind-license-9.11.4-16.P2.el7_8.6.noarch

bind-libs-lite-9.11.4-16.P2.el7_8.6.x86_64

bind-chroot-9.11.4-16.P2.el7_8.6.x86_64。

在通常情况下，若想要提供全面的DNS查询服务，就需在本地机器上存储相关的域名数据库，但是若在某个配置文件中记录所有的IP地址和域名对应关系，这个文件将会非常庞大，程序的执行效率将会下降，且之后的维护和修改也必将会非常混乱困难。为此，在BIND服务程序中，有三个至关重要的配置文件。

第一个是/etc/named.conf主配置文件：该配置文件加上空行和注释信息一共只有58行，实际的有效行数大概只有30行，BIND服务程序的运行主要由这30行左右的参数进行定义。

第二个是/etc/named.rfc1912.zones区域配置文件：该文件用于存储IP地址信息和域名映射关系所在的位置，就如同书籍目录一样，记录着每一个IP地址及与其相对应的域名所在的具体位置，如果要进行修改或查看操作时，可依据该位置查到相关文件。

第三个是/var/named数据配置文件目录，该目录存储了IP地址信息和域名真实映射关系的数据配置文件。

BIND服务程序在Linux系统中的名称为named，为了使服务器上的所有IP地址都能够提供DNS域名解析服务，且为了使任何人都可以发送DNS查询请求给服务器，需要修改主配置文件，在/etc目录中找到该文件，然后将第11行的地址和第17行的地址修改为any：

[root@MiWiFi-R3-srv ~]# vi /etc/named.conf 1

11 listen-on port 53 { any; };

17 allow-query { any; }。

如上所述，/etc/named.rfc1912.zones区域配置文件保存了IP地址和域名映射关系的所在位置。该文件定义了保存域名和IP地址解析规则文件的位置和服务类型等内容，并不包含详细的域名、IP地址映射关系相关信息。

4 DNS从服务器部署

DNS域名解析服务，作为互联网基础设施的重要服务，为了使域名查询服务能够快速、稳定且不间断，保障DNS域名解析服务的正常非常重要。从服务器的作用主要是负载均衡和备份解析记录，在域名解析服务中，从服务器会从主服务器上获取指定区域数据文件。因此，部署从服务器不仅能够使主服务的负载压力降低，还能够使用户的查询效率提高。在本次部署中，主服务器和从服务器的IP地址和操作系统信息如表1所示。

从服务器的部署步骤有三。

（1）修改主服务器的/etc/named.rfc1912.zones区域配置文件中的allow-update{允许更新的主机IP地址信息}参数，使主服务器同意从服务器的更新请求，最后重新启动主服务器DNS服务程序。

表1 主服务器和从服务器的IP地址和操作系统信息

[root@MiWiFi-R3-srv ~]]# vim /etc/named.rfc1912.zones

zone "saidi.com" IN {

type master;

file "saidi.com.zone";

allow-update { 192.168.199.20; };

};

zone "199.168.192.in-addr.arpa" IN {

type master;

file "192.168.199.arpa";

allow-update { 192.168.199.20; };

};

[root@MiWiFi-R3-srv ~]]# systemctl restart named。

（2）修改从服务器的/etc/named.rfc1912.zones区域配置文件，将从服务器想要获取的区域信息和对应的主服务器的IP地址信息填写在该文件中。在该步骤中，需要注意此时服务类型type为slave不是master。master参数后边的IP地址信息为主服务器IP，file参数后边为从服务器同步的数据配置文件保存位置。最后，重新启动从服务器DNS服务程序。

[root@MiWiFi-R3-srv ~]]# vim /etc/named.rfc1912.zones

zone "saidi.com" IN {

type slave;

masters { 192.168.199.199; };

file "slaves/saidi.com.zone";

};

zone "199.168.192.in-addr.arpa" IN {

type slave;

masters { 192.168.199.199; };

file "slaves/192.168.199.arpa";

};

[root@MiWiFi-R3-srv ~]]# systemctl restart named

（3）结果验证。在通常情况下，重启从服务器的DNS服务程序后，从服务器上的数据配置文件就会自动从主服务器上同步过来，且数据配置文件会放在上一步中所配置的目录下。然后，将从服务器的网络参数，即DNS地址修改为从服务器的IP地址，这样从服务器提供的DNS域名解析服务就可以使用了。最后，通过nslookup命令可以查看解析结果。

[root@MiWiFi-R3-srv ~]]# cd /var/named/slaves

[root@MiWiFi-R3-srv ~ slaves]# ls

192.168.199.arpa saidi.com.zone

[root@MiWiFi-R3-srv ~ slaves]# nslookup

> www.saidi.com

Server: 192.168.199.20

Address: 192.168.199.20#53

Name: www.saidi.com

使用BIND提供域名解析服务

Address: 192.168.199.199

> 192.168.199.199

Server: 192.168.199.20

Address: 192.168.199.20#53

199.199.168.192.in-addr.arpa name = www.saidi.com.

199.199.168.192.in-addr.arpa name =ns.saidi.com.

199.199.168.192.in-addr.arpa name = mail.saidi.com.

5 基于TSIG的安全加密传输部署

DNS域名解析服务的重要性不言而喻，在使用DNS域名解析服务器时，一个域一般会需要多个服务器，因此就会出现数据在不同NDS服务间的同步问题，主从服务架构的方式很好地解决了该问题。然而，在一般情况下，DNS间的Zone Transfer（区域信息传输）都是通过明文传输的，这种传输方式是非常危险的，为了保障解析服务安全，BIND服务程序使用TSIG（Transaction SIGnature）加密机制为数据安全传输提供保障。

该实验依然使用表1（主服务器和从服务器的IP地址和操作系统信息表）中的两台服务器。具体步骤如下。

以上实验在从服务器上部署好BIND服务程序并重启后，在从服务器上可以看到从主服务器上同步到的数据配置文件：

[root@MiWiFi-R3-srv ~]]# ls -al /var/named/slaves/

total 12

drwxrwx---. 2 named named 54 Jun 7 16:02 .

drwxr-x---. 6 root named 4096 Jun 7 15:58 ..

-rw-r--r--. 1 named named 432 Jun 7 16:02 192.168.199.arpa

-rw-r--r--. 1 named named 439 Jun 7 16:02 saidi.com.zone。

（1）在主服务器中生成密钥。生成安全的DNS服务密钥的命令为：dnssec-keygen，使用格式为dnssec-keygen[参数]，dnssec-keygen命令常用参数说明如表2所示。

参考表2中的常用参数说明，使用命令生成一个128位主机名称为master-slave的HMAC-MD5算法的密钥文件。然后，在当前目录中就会找到私钥文件和公钥文件，之后会需要将私钥文件中KEY写入到传输配置文件中，因此找到文件后要记录私钥中Key后边的参数值。

[root@MiWiFi-R3-srv ~]]# dnssec-keygen -a HMAC-MD5 -b 128 -n HOST master-slave

Kmaster-slave.+157+46845

[root@MiWiFi-R3-srv ~]]# ls -al Kmasterslave.+157+46845.*

-rw-------. 1 root root 56 Jun 7 16:06 Kmaster-slave.+157+46845.key

-rw-------. 1 root root 165 Jun 7 16:06 Kmaster-slave.+157+46845.private

[root@MiWiFi-R3-srv ~]]# cat Kmasterslave.+157+46845.private

Private-key-format: v1.3

Algorithm: 157 (HMAC_MD5)

Key: 1XEEL3tG5DNLOw+1WHfE3Q==

Bits: AAA=

Created: 20170607080621

Publish: 20170607080621

Activate: 20170607080621

（2）操作主服务器创建密钥认证文件。在该步骤中主要进行的操作，是把BIND服务程序中用来保存配置文件的目录中上一步中生成的加密算法、密钥名称及私钥加密字符串，写入到传输配置文件transfer.key中。出于安全考虑，把文件所在的组改成named，缩小文件权限，最后将该文件硬链接到/etc目录中。

[root@MiWiFi-R3-srv ~]]# cd /var/named/chroot/etc/

[root@MiWiFi-R3-srv ~ etc]# vim transfer.key

key "master-slave" {

algorithm hmac-md5;

secret "1XEEL3tG5DNLOw+1WHfE3Q==";

};

[root@MiWiFi-R3-srv ~]]# chown root:named transfer.key

[root@MiWiFi-R3-srv ~]]# chmod 640 transfer.key。

[root@MiWiFi-R3-srv ~]]# ln transfer.key /etc/transfer.key

（3）打开并加载BIND服务程序的密钥验证功能。在该步骤中，先要在主服务器的配置文件中加载密钥验证文件，然后修改文件，使只有带有master-slave密钥认证的DNS服务器才可以同步数据配置文件。

[root@MiWiFi-R3-srv ~]]# vim /etc/named.conf

9 include "/etc/transfer.key";

18 allow-transfer { key master-slave; };

[root@MiWiFi-R3-srv ~]]# systemctl restart named。

完成以上三个步骤后，DNS主服务器基于TSIG的安全加密传输就已经完全配置好了。然后，删除掉DNS从服务器从主服务器中同步的所有数据配置文件，重启BIND服务程序，发现此时从服务器不能自动同步数据配置文件。

[root@MiWiFi-R3-srv ~]]# rm -rf /var/named/slaves/*

[root@MiWiFi-R3-srv ~]]# systemctl restart named

[root@MiWiFi-R3-srv ~]]# ls /var/named/slaves/。

（4）为了使从服务器支持密钥验证，对其进行配置。配置方法和配置DNS主服务器的方法相近，均需要创建密钥认证文件，创建的位置仍在BIND服务程序的配置文件目录中。创建完成后设置相应的权限，最后把该文件做一个硬链接到/etc目录中。

[root@MiWiFi-R3-srv ~]]# cd /var/named/chroot/etc

[root@MiWiFi-R3-srv ~ etc]# vim transfer.key

key "master-slave" {

algorithm hmac-md5;

secret "1XEEL3tG5DNLOw+1WHfE3Q==";

};

[root@MiWiFi-R3-srv ~ etc]# chown root:named transfer.key

[root@MiWiFi-R3-srv ~ etc]# chmod 640 transfer.key

[root@MiWiFi-R3-srv ~ etc]# ln transfer.key/etc/transfer.key。

（5）操作从服务器，打开并加载其密钥验证功能。此操作也是在主配置文件中加载密钥认证文件，然后将主服务器的IP地址和密钥名称依据指定格式进行配置。但是，需要注意密钥名称等参数位置要适当，不能太靠前，这样能够避免BIND服务程序不会因为未加载完预设参数而报错，一般情况下写在第43行左右即可。

[root@MiWiFi-R3-srv ~ etc]# vim /etc/named.conf

9 include "/etc/transfer.key";

43 server 192.168.199.199

44 {

45 keys { master-slave; }。

（6）验证是否能够同步数据配置文件。主从DNS服务器的BIND服务程序都已经完全配置好，且匹配了相同的密钥认证文件。重启BIND服务程序后，看到能够成功的同步数据配置文件。

[root@MiWiFi-R3-srv ~]]# systemctl restart named

[root@MiWiFi-R3-srv ~]]# ls /var/named/slaves/

192.168.199.arpa saidi.com.zone。

6 基于MFA安全机密的可行性

大部分企业一般会自己搭建DNS服务器，但是这样不利于密钥的安全保存，对于密钥的安全性会存在严重的安全隐患，因为企业内部的机房和设备具有不稳定性，而且可能人员流动性也会比较大，假若离职的员工存储了相关的密钥文件信息，如果再在公司外部自己搭建了DNS从服务器，完全可以通过同步公司内部信息，盗取公司CDN域名信息。鉴于上述这种企业DNS主从服务器的类似问题，可通过使用多因素认证（MFA）来提高DNS服务器的安全性，因为其具有四个优势。

（1）Authing具有一个独特的功能，即微信小程序“终端认证功能”。采用手机接收小程序发送的动态口令方式，实现“多因素认证”，可以使账户安全系数提升到99.99%。

（2）可以对不同的成员、角色、组织设置再次验证规则。

（3）能够智能识别每次登录用户的安全级别，然后基于此设置不同的登录验证策略。

（4）能够根据应用的重要级别，对不同的应用设置对应级别的二次验证启动规则。

通过多因素认证（MFA）相结合，它能够在用户名和密码之外再增加一个保护层，如新地址登录、异地登录要求手机短信验证码验证、银行的电子密码器等方式，当有新的从DNS服务器进行同步时，应进行多因素的二次认证，以此来确保从DNS服务器的“合法性”，如图2所示。

表2 dnssec-keygen命令常用参数说明

图2 认证过程

7 结束语

随着科技的不断发展，大数据、人工智能、区块链等新技术的出现，业务越来越依赖于数据。数据逐渐成为整个企业的命脉，大量数据需要在不同机器、设备间传输，数据的安全性问题不仅要考虑到数据被截获的问题，还需要高度关注数据传输过程中接收人验证的问题，以避免因数据安全问题给企业造成严重的经济损失。