基于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 結束語

隨著科技的不斷發展，大數據、人工智能、區塊鏈等新技術的出現，業務越來越依賴于數據。數據逐漸成為整個企業的命脈，大量數據需要在不同機器、設備間傳輸，數據的安全性問題不僅要考慮到數據被截獲的問題，還需要高度關注數據傳輸過程中接收人驗證的問題，以避免因數據安全問題給企業造成嚴重的經濟損失。