周 聰,陶 靜,趙寶康,李安藝

(國防科技大學(xué)計算機學(xué)院,湖南 長沙 410073)

1 引言

隨著互聯(lián)網(wǎng)的快速發(fā)展,為了方便人們利用域名形式訪問網(wǎng)絡(luò)中的主機,域名服務(wù)系統(tǒng)DNS(Domain Name System)應(yīng)運而生。RFC1034[1]取代之前的RFC882系統(tǒng)地描述了DNS的基本思想(標(biāo)志著DNS的誕生),其原理是客戶端根據(jù)查詢得到的資源記錄類型和關(guān)聯(lián)數(shù)據(jù)進行下一步的通信。

Linux系統(tǒng)的DNS服務(wù)由BIND (Berkeley Internet Name Domain)軟件實現(xiàn),目前95%以上的DNS服務(wù)器都是由其搭建的[2]。中小型企業(yè)也可以選擇微軟公司的Windows server系列搭建域名服務(wù)器。目前對域名解析系統(tǒng)的研究主要集中在安全性方面[3-6],也有文獻將其與大數(shù)據(jù)方法結(jié)合后實現(xiàn)數(shù)據(jù)可視化[7],還有去中心化架構(gòu)的DNS系統(tǒng)設(shè)計[8]。

在安全性方面,針對隱私保護問題,由于DNS基于明文傳輸數(shù)據(jù),使用加密技術(shù)將DNS請求與響應(yīng)的數(shù)據(jù)包進行加密,從而保證數(shù)據(jù)包不被監(jiān)聽和利用,其代表性技術(shù)包括DoT(DNS-over-TLS)[9]、DoH(DNS-over-HTTPS)[10]、DNS-over-QUIC(Quick UDP Internet Connections)[11]和DNSCrypt[12]。在性能優(yōu)化設(shè)計方面,張偉等[13]設(shè)計了一種支持多進程共享的高效哈希表,用于存儲域名數(shù)據(jù)、實現(xiàn)域名快速查詢和解決緩存大量域名時的哈希沖突問題;還依據(jù)域名和資源記錄類型預(yù)先構(gòu)建應(yīng)答數(shù)據(jù),對重復(fù)域名數(shù)據(jù)進行壓縮,加快DNS請求處理時構(gòu)建應(yīng)答報文的速度,提高緩存服務(wù)器的處理性能。秦豐林等[14]根據(jù)雙棧環(huán)境的特點,設(shè)計了IPv6協(xié)議的地址自動配置機制,為用戶終端無感知地自動配置DNSv6服務(wù)器,通過增加DNS配置的冗余方式來提高DNS服務(wù)的可靠性。

DNSSEC(Domain Name System SECurity extensions)[15]協(xié)議引入了數(shù)字簽名技術(shù),通過對響應(yīng)數(shù)據(jù)進行簽名可以驗證響應(yīng)結(jié)果的正確性。針對實施條件中存在的安全隱患,Bau等[16]模擬了DNSSEC中的加解密操作并成功發(fā)現(xiàn)了一些偽造的漏洞。Herzberg等[17]分析了DNSSEC面臨的挑戰(zhàn)和存在的不足。Goldberg等[18]的研究表明DNSSEC部署很容易受到區(qū)域枚舉攻擊。

DNS技術(shù)旨在幫忙用戶以容易記憶的方式檢索網(wǎng)絡(luò)資源,從互聯(lián)網(wǎng)出現(xiàn)之初使用IP地址通信,到目前的計算機網(wǎng)絡(luò)尋訪定位方式,該項技術(shù)已取得了很大的發(fā)展,DNS域名服務(wù)被應(yīng)用于更多的領(lǐng)域。彭巍等[19]基于Hadoop技術(shù)分析運營商的DNS海量數(shù)據(jù),并對分析的結(jié)果進行闡述,通過報表、圖形等多種方式進行呈現(xiàn),實現(xiàn)DNS數(shù)據(jù)多維度分析。蔡榮彥等[20]提出了基于域名關(guān)聯(lián)的惡意移動應(yīng)用檢測方法,以DNS域名為檢測分析對象識別網(wǎng)絡(luò)流量中的惡意域名,利用DNS請求流量的時間特征尋找惡意域名的關(guān)聯(lián)域名,并將關(guān)聯(lián)域名與文本分類樣本庫進行對比,確定惡意移動應(yīng)用的名稱。Cui等[21]利用數(shù)據(jù)挖掘的方法對域名的日志數(shù)據(jù)進行分析,從而檢測出異常。

在DNS去中心化設(shè)計方面,朱國庫等[22]設(shè)計了根域去中心化的方案,從而形成聯(lián)盟來對根服務(wù)器的數(shù)據(jù)進行解析;朱建明等[23]提出了利用區(qū)塊鏈來構(gòu)建數(shù)據(jù)動態(tài)認證的模型;趙赫等[24]提出用區(qū)塊鏈來保護數(shù)據(jù)。

ENUM(Electronic Numbers to URI Mapping)是電話號碼映射工作組制定的協(xié)議[25,26],它定義了將E.164號碼映射為域名的規(guī)則,以及在互聯(lián)網(wǎng)DNS系統(tǒng)中存儲該域名信息的方法。每個E.164號碼轉(zhuǎn)化成的域名對應(yīng)系統(tǒng)的唯一資源標(biāo)識,從而使其成為可以在互聯(lián)網(wǎng)中使用的網(wǎng)絡(luò)地址。采用ENUM技術(shù),通過電話號碼可以獲得用戶郵件、IP傳真和個人網(wǎng)頁等多種信息。

ENUM技術(shù)是當(dāng)前計算機網(wǎng)絡(luò)資源尋址方式的熱點,在三網(wǎng)融合中被大量應(yīng)用[27]。該技術(shù)的核心分為3部分:電話號碼預(yù)處理、DNS配置和ENUM解析。

在電話號碼預(yù)處理階段:當(dāng)用戶輸入的號碼為“+86-01-234567”時,去掉數(shù)字以外的其它符號,并在數(shù)字之前加“.”,得到“8.6.0.1.2.3.4.5.6.7”,將其反轉(zhuǎn)并添加后綴得到符號串“7.6.5.4.3.2.1.0.6.8.e164.arpa”。在DNS配置階段:上述字符串按NAPTR(Naming Authority PoinTeR)記錄[1]的格式存儲于區(qū)域文件。在ENUM解析階段:當(dāng)用戶使用支持ENUM技術(shù)的設(shè)備輸入電話號碼后,該設(shè)備完成號碼預(yù)處理,并將字符串按DNS協(xié)議發(fā)出,從DNS服務(wù)器得到與此ENUM相應(yīng)的唯一資源標(biāo)識集合,用戶根據(jù)自身的需求選擇相關(guān)的資源,繼續(xù)執(zhí)行相應(yīng)的協(xié)議完成操作。如:用戶在Outlook Express輸入“+86-01-234567”,DNS服務(wù)器將對應(yīng)的“Sip:xxx”和“Mailto:xxx”等資源標(biāo)識給用戶,用戶若選擇“Mailto:xxx”,可與電話號碼為“+86-01-234567”的使用者進行郵件溝通。

2 最長匹配規(guī)則

ENUM支持在NAPTR記錄中使用符號“*”,以實現(xiàn)解析過程模糊匹配。模糊匹配過程依據(jù)最長匹配策略,如下所示:

以BIND(版本9.7.3)為例,在DNS配置階段,使用4個號碼:1*,12,13*,141。注冊NAPTR記錄如下:

*.1.e164.arpa.IN NAPTR 1 1 “U” “sip+E2U” “resolving result:A”

2.1.e164.arpa.IN NAPTR 1 1 “U” “sip+E2U” “resolving result:B”

*.3.1.e164.arpa.IN NAPTR 1 1 “U” “sip+E2U” “resolving result:C”

1.4.1.e164.arpa.IN NAPTR 1 1 “U” “sip+E2U” “resolving result:D”

當(dāng)用戶需要查詢號碼1311時,按最長匹配規(guī)則,域名系統(tǒng)BIND返回解析結(jié)果C;當(dāng)用戶查詢號碼13,14或者142時,域名系統(tǒng)BIND返回“無結(jié)果”,以號碼142為例,按最長匹配規(guī)則,用戶應(yīng)該收到解析結(jié)果A。

為進一步驗證RFC關(guān)于最長匹配規(guī)則的定義,在Windows server 2003上注冊相同號碼進行解析,兩者的解析結(jié)果之間存在差異,詳細如表1所示。由此可知:BIND系統(tǒng)的最長匹配規(guī)則功能不符合RFC描述。

Table 1 BIND and Windows server’s domain name resolution

通過比較不同的版本BIND-9.8、BIND-9.9和BIND-9.17.18,其解析的結(jié)果與BIND-9.7.3的一致,即后續(xù)版本的最長匹配規(guī)則功能亦不符合RFC描述。

3 雙重檢索規(guī)則

根據(jù)表1的解析過程,可將結(jié)果分為4類:

(1)Ⅰ類(表1的第2個和第8個用例):在DNS系統(tǒng)中明確注冊的記錄,如號碼12和141,BIND與Windows server均能得到正確的解析結(jié)果。

(2)Ⅱ類(表1的第6個和第7個用例):在DNS系統(tǒng)中注冊通配符“*”記錄,可匹配變長的號碼,如果已注冊13*,則131和1311將被解析為其結(jié)果。

(3)Ⅲ類(表1的第3個、第4個和第9個用例):按RFC1034關(guān)于通配符的定義,當(dāng)出現(xiàn)“*”時,解析結(jié)果應(yīng)滿足模糊檢索的要求,但BIND與Windows server的解析結(jié)果存在差異。

從用戶的角度來看,最長匹配規(guī)則更趨向于認同Windows server的解析結(jié)果,與RFC1034的描述一致。

(4)Ⅳ類(表1的第1個和第5個用例):不滿足上述3種場景,即未注冊的記錄。

針對第Ⅲ類情況,本文提出了雙重檢索匹配算法,即:在BIND系統(tǒng)中,當(dāng)號碼E無法獲得解析結(jié)果時,系統(tǒng)生成一個新的號碼E′,以E′重新進行檢索,最終結(jié)果返回至用戶,具體流程如圖1所示。

Figure 1 Search process comparison

圖1a為原BIND系統(tǒng)的檢索流程,圖1b為改進后的檢索流程。從圖1可知,當(dāng)號碼E的解析結(jié)果不存在時,將生成新號碼E′再次檢索,故稱為雙重檢索規(guī)則。

由于系統(tǒng)在檢索前,需要保存檢索的內(nèi)容,所以在第2次檢索時,需要先保持原號碼的檢索條件,重置新的檢索狀態(tài),執(zhí)行新號碼檢索后,恢復(fù)原號碼的檢索條件,并返回給用戶。

為提高2次檢索的效率,本文設(shè)計新號碼生成算法,如算法1所示。

算法1生成雙重檢索號碼E′

輸入：待檢測的號碼E。

輸出：新的號碼E′。

步驟1若號碼E不包含*,退出;否則執(zhí)行步驟2。

步驟2根據(jù)號碼E獲取區(qū)域文件名。

步驟3獲取區(qū)域文件中所有記錄,形成2個鏈表ts與tn,其中ts以“*” 開頭,tn以數(shù)字開頭。若ts為*.1和*.3.1,則分別對應(yīng)號碼1*和13*;若tn為2.1和1.4.1,則分別對應(yīng)號碼12和141。

步驟4若tn不為空,依次刪除號碼E的最低位,并與鏈表tn各項比較,如若存在相同項,則置E′為空,跳轉(zhuǎn)至步驟6。若號碼E為123*,則與tn比較的字符串依次為2.1和1。

步驟5若ts不為空,依次將號碼E的最低位置為“*”,并與鏈表ts各項比較,若存在相同項,則置E′為ts的當(dāng)前值,跳轉(zhuǎn)至步驟6。若號碼E為123*,則與ts比較的字符串依次為*.2.1和*.1。

步驟6清空鏈表ts和tn,關(guān)閉區(qū)域文件,返回E′。

4 雙重檢索過程實現(xiàn)

圖1b中的陰影部分通過調(diào)用原系統(tǒng)函數(shù)實現(xiàn),其它部分均在BIND系統(tǒng)的函數(shù)query_find中實現(xiàn)。

(1)存在記錄判斷。

此處為雙重檢索的入口,判斷記錄是否存在的標(biāo)志為變量result與type。第1次檢索完成后,result變量返回檢索結(jié)果。經(jīng)實驗發(fā)現(xiàn),當(dāng)值為196611(針對141注冊后無法解析142的場景)或65628(針對141注冊后無法解析14的場景),且變量type的值為35(ENUM記錄類型的值)時,需進入圖1b的雙重檢索流程。

(2)保護號碼E的檢索條件。

號碼E的內(nèi)容(變量名為client→query.qname→ndate)與長度(變量名為client→query.qname→length)分別存入臨時變量數(shù)據(jù)組t中。

(3)重置檢索狀態(tài)。

①清空第1次的檢索結(jié)果,將變量fname→ndata,fname→length,fname→label和fname→attributes置空或置零。

②將號碼E′的內(nèi)容和長度分別賦值檢索變量client→query.qname→ndate和client→query.qname→length。

③為檢索數(shù)量(變量名為segment)、標(biāo)識位(變量名為client→query.qname→label)、偏移量(變量名為client→query.qname→offsets)賦初值。

(4)以號碼E′執(zhí)行檢索。

調(diào)用原BIND的檢索方法dns_db_find(),但當(dāng)前狀態(tài)下檢索的內(nèi)容從第1次的號碼E變成為E′。

(5)恢復(fù)號碼E檢索狀態(tài)。

以E′完成檢索,恢復(fù)至號碼E時的狀態(tài),將臨時變量t的內(nèi)容分別賦值給lient→query.qname→ndate和client→query.qname→length。

雙重檢索實際上是通過算法1找到了與號碼E最長匹配的另一個新號碼E′,重新調(diào)用BIND的檢索方法得到新的結(jié)果,并恢復(fù)到原號碼E的情景返回給用戶,這一過程對用戶透明。

為了滿足BIND系統(tǒng)應(yīng)用DNSSEC[15]的要求,在重置初始化檢索狀態(tài)過程中將2個變量置為NULL即可,即node與rdateset→methods;其它變量與非DNSSEC處理過程一致。

5 實驗驗證

本文在BIND-9.7.3基礎(chǔ)上完成雙重檢索修改最長匹配規(guī)則,對比前后2次的解析結(jié)果,如表2所示。

Table 2 Domain name resolutions of BIND after being modified

從表2可知,使用雙重檢索修正后,BIND的解析結(jié)果與Windows server 2003的解析結(jié)果一致,同時符合標(biāo)準(zhǔn)文獻RFC1034對通配符最長匹配的定義。

使用DNS性能測試工具dnsperf對雙重檢索修正后的BIND服務(wù)進行測試,其每秒查詢次數(shù)(并發(fā)數(shù))、響應(yīng)時間2項指標(biāo)與修正前的基本一致,因此,修正過程對性能影響可忽略不計,詳細數(shù)據(jù)如表3所示。

Table 3 Performance of BIND before and after being modified

表3的前1～6列為dnsperf配置的參數(shù):C指定客戶端數(shù)量;Q限制每秒查詢數(shù)量;i指定查詢的間隔;符號“√”表示當(dāng)前參數(shù)值有效,且值為表頭第2行的方框內(nèi)容。表3的后2列為dnsperf測試結(jié)果,在上述3個參數(shù)選定的前提下,每個場景運行100次,分別計算查詢消耗時間和每秒查詢次數(shù)的平均值。由于某些場景的查詢消耗時間為0,符號“/”表示查詢結(jié)果無法計算。

從表3可以看出,基于修改后的雙重檢索BIND服務(wù)與原服務(wù)性能在同一個量級,兩者數(shù)值相差不大。

通過計算每秒查詢次數(shù)的兩者之差與兩者之和的比值,比較兩者在每秒查詢次數(shù)上的相對偏差,其結(jié)果如圖2所示。

Figure 2 Relative deviation of query times per second

從圖2可知,3個場景的偏差非常小,如〈c,i,Q〉=〈1,10,1000〉、〈c,i,Q〉=〈100,1,1〉、〈c,i,Q〉=〈100,10,1〉;2個場景的偏差較大,如〈c,i,Q〉=〈100,1,1000〉、〈c,i,Q〉=〈100,10,1000〉。

在用戶并發(fā)數(shù)與查詢總量增加的情況下,由于基于二次檢索的BIND服務(wù)查詢次數(shù)增加,性能與原BIND的偏差有所增長,相應(yīng)的性能有所下降,但都處于15%以下,性能影響不大。

6 結(jié)束語

BIND軟件在域名服務(wù)系統(tǒng)中占比很高,但實現(xiàn)最長匹配功能時與RFC描述存在偏差,需要通過對比Windows server 解析結(jié)果進一步確認。本文在保持BIND原有架構(gòu)不變的基礎(chǔ)上,使用雙重檢索規(guī)則,修正后的BIND解析結(jié)果更符合RFC中關(guān)于最長匹配規(guī)則的定義,同時不影響軟件性能。這種修改策略將為標(biāo)準(zhǔn)服務(wù)更多定制化需求提供了一種可行的方案。同時,該系統(tǒng)已在實網(wǎng)中部署應(yīng)用。