左 鵬,賀智謀,袁 夢(mèng),張海闊,楊衛(wèi)平

(中國(guó)互聯(lián)網(wǎng)絡(luò)信息中心,北京 100190)

0 引 言

目前主流的標(biāo)識(shí)解析技術(shù)在設(shè)計(jì)之初，并未過(guò)多考慮安全因素，其產(chǎn)生的數(shù)據(jù)均明文傳輸[1-2]，導(dǎo)致相關(guān)協(xié)議在運(yùn)行過(guò)程中存在用戶隱私泄露問題。2013年6月，斯諾登曝光了美國(guó)國(guó)家安全局的“棱鏡計(jì)劃”，披露了美國(guó)政府對(duì)公眾用戶數(shù)據(jù)的大范圍監(jiān)控行為，引發(fā)舉世震驚[3]。標(biāo)識(shí)解析系統(tǒng)作為互聯(lián)網(wǎng)應(yīng)用的入口服務(wù)，其解析過(guò)程中產(chǎn)生的數(shù)據(jù)是互聯(lián)網(wǎng)用戶隱私保護(hù)的重要環(huán)節(jié)[4]。

針對(duì)域名解析隱私保護(hù)問題，業(yè)界提出了一些基于加密傳輸?shù)臋C(jī)制，如DoH、DoT等，這些技術(shù)標(biāo)準(zhǔn)旨在解決用戶端和DNS遞歸服務(wù)器間數(shù)據(jù)傳送的隱私保護(hù)問題，不能覆蓋遞歸服務(wù)器和權(quán)威服務(wù)器間查詢流程[5-6]。2016年，IETF發(fā)布了谷歌公司提出的RFC7871，允許遞歸服務(wù)器在外發(fā)查詢過(guò)程中攜帶用戶的IP地址，以獲取最優(yōu)的DNS應(yīng)答[7]，目前谷歌公司的公共遞歸服務(wù)8.8.8.8已支持該標(biāo)準(zhǔn)。由于該標(biāo)準(zhǔn)將客戶端的IP地址傳遞到了DNS權(quán)威服務(wù)器，因此DNS隱私保護(hù)問題被進(jìn)一步拓展到了遞歸服務(wù)器和權(quán)威服務(wù)器的交互環(huán)節(jié)。

截至目前，沒有成熟的技術(shù)方案支撐域名解析過(guò)程中遞歸服務(wù)器和權(quán)威服務(wù)器各節(jié)點(diǎn)間的加密傳輸，導(dǎo)致此過(guò)程中的用戶數(shù)據(jù)存在隱私泄露風(fēng)險(xiǎn)。為此，本文通過(guò)充分調(diào)研國(guó)內(nèi)外研究現(xiàn)狀，并借鑒DNSSEC的信任鏈思想，提出一種新的基于加密傳輸?shù)臉?biāo)識(shí)解析模型?；谠撃Ｐ?，從客戶端到遞歸解析器，及遞歸解析器到權(quán)威服務(wù)器的每一步查詢，都通過(guò)加密傳輸完成，保障用戶隱私和數(shù)據(jù)的安全。

1 國(guó)內(nèi)外研究現(xiàn)狀

1.1 基于加密傳輸?shù)腄NS

針對(duì)域名隱私保護(hù)問題，2014年，國(guó)際互聯(lián)網(wǎng)工程任務(wù)組(Internet Engineering Task Force， IETF)成立了DNS隱私傳輸交換工作組，發(fā)布了基于TLS和DTLS加密傳輸?shù)腄NS技術(shù)標(biāo)準(zhǔn)[8]。2018年，IETF發(fā)布的RFC8484定義了基于HTTPS傳輸?shù)腄NS。此外，丹尼爾.伯恩斯坦提出了基于橢圓曲線加密算法的DNSCurve[9-10]，使用Curve25519交換會(huì)話密鑰，在緩存和服務(wù)器之間提供認(rèn)證和加密。這些標(biāo)準(zhǔn)可以較好地解決客戶端和遞歸服務(wù)器之間DNS隱私和查詢劫持等問題，但都無(wú)法覆蓋DNS遞歸服務(wù)器和DNS權(quán)威服務(wù)器之間的解析流程，且缺乏類似DNSSEC的信任傳遞模型，因此不能解決DNS解析全流程的隱私保護(hù)問題。

1.2 基于簽名技術(shù)的DNSSEC

2005年，IETF的DNS運(yùn)維工作組發(fā)布了DNS安全擴(kuò)展方案DNSSEC，其基于數(shù)字簽名技術(shù)實(shí)現(xiàn)遞歸解析器對(duì)DNS報(bào)文進(jìn)行完整性驗(yàn)證和來(lái)源性驗(yàn)證[11-13]，主要解決類似卡明斯基攻擊之類的數(shù)據(jù)篡改問題[14-15]。截至2018年底，超過(guò)90%的頂級(jí)域名已部署實(shí)施[16]。實(shí)施DNSSEC后，DNS報(bào)文仍然通過(guò)明文傳輸，因此DNSSEC本身無(wú)法解決DNS隱私保護(hù)問題。但其建立了權(quán)威服務(wù)器的信任鏈機(jī)制，實(shí)現(xiàn)了權(quán)威服務(wù)器各節(jié)點(diǎn)的信任傳遞，為實(shí)現(xiàn)全流程加密傳輸?shù)臉?biāo)識(shí)模型提供了借鑒思路。

1.3 域名最小化查詢

2016年，IETF發(fā)布RFC7816，提出了查詢域名最小化的DNS查詢方式[17]。普通的DNS查詢中，用戶查詢的域名全名將暴露給查詢過(guò)程中經(jīng)過(guò)的所有權(quán)威服務(wù)器，容易產(chǎn)生隱私泄露問題。DNS查詢最小化遵循發(fā)送的數(shù)據(jù)越少，隱私問題就越少的原則[18]，僅向較高級(jí)的權(quán)威服務(wù)器暴露部分域名，從而提升了DNS查詢過(guò)程中的私密性。在查詢域名最小化中，遞歸服務(wù)器和較低級(jí)的權(quán)威服務(wù)器依然能獲取到用戶所請(qǐng)求的域名全名，同時(shí)遞歸服務(wù)器仍能記錄用戶所有訪問記錄，查詢域名最小化只能提供較為有限的隱私保護(hù)。

1.4 域名廣播技術(shù)

域名廣播技術(shù)由Federrath等人[19]于2011年提出，主要是將近一段時(shí)間內(nèi)查詢量比較大的域名廣播到用戶機(jī)器上。遞歸服務(wù)器由于參與到了廣播的過(guò)程中，不再直接獲取用戶的訪問記錄，因此可緩解用戶隱私泄露問題。同時(shí)，由于熱門域名被緩存在用戶的機(jī)器上，域名廣播技術(shù)能較大程度地提升用戶的訪問速度。域名廣播技術(shù)的問題在于對(duì)現(xiàn)有的DNS解析架構(gòu)改動(dòng)較大，同時(shí)需要在用戶的機(jī)器上占用大量空間，部署難度較大。

2 基于加密傳輸?shù)臉?biāo)識(shí)解析模型

2.1 模型總體架構(gòu)

本文提出一種新的基于加密傳輸?shù)娜鞒虡?biāo)識(shí)解析模型，借鑒DNSSEC的思想，并使用加密連接的身份認(rèn)證機(jī)制實(shí)現(xiàn)權(quán)威節(jié)點(diǎn)的身份認(rèn)證和信任傳遞，實(shí)現(xiàn)遞歸服務(wù)器和權(quán)威服務(wù)器間查詢隱私保護(hù)?？傮w架構(gòu)如圖1所示，分為安全套接層、傳輸層和應(yīng)用層，其核心在于應(yīng)用層實(shí)現(xiàn)基于加密傳輸?shù)男湃捂満凸?jié)點(diǎn)信任傳遞，將在2.2節(jié)詳細(xì)描述。其中，安全套接層采用SSL協(xié)議，為上層提供加密功能。傳輸層作為數(shù)據(jù)傳輸?shù)墓艿?，采用TCP或HTTP等協(xié)議實(shí)現(xiàn)。應(yīng)用層由樁解析器、遞歸解析器和權(quán)威解析器組成，實(shí)現(xiàn)基于加密傳輸?shù)臉?biāo)識(shí)解析功能。

圖1 系統(tǒng)總體架構(gòu)

模型的信任鏈部分借鑒了DNSSEC信任鏈的思想，但技術(shù)原理和目標(biāo)問題不同。從技術(shù)原理上講，DNSSEC通過(guò)電子簽名實(shí)現(xiàn)信任傳遞。具體地，各節(jié)點(diǎn)掌握一對(duì)或多對(duì)非對(duì)稱密鑰，使用私鑰對(duì)各自數(shù)據(jù)簽名，并提供公鑰給遞歸服務(wù)器用于數(shù)據(jù)驗(yàn)證。其中，子節(jié)點(diǎn)將公鑰的摘要提交至父節(jié)點(diǎn)，父節(jié)點(diǎn)對(duì)其簽名。遞歸解析器通過(guò)驗(yàn)證該公鑰的摘要并與子節(jié)點(diǎn)的公鑰進(jìn)行比對(duì)，從而驗(yàn)證子節(jié)點(diǎn)的身份。由此類推，實(shí)現(xiàn)各節(jié)點(diǎn)身份認(rèn)證傳遞。本文模型通過(guò)加密連接確保數(shù)據(jù)的隱私性。加密連接建立的過(guò)程中，通信雙方首先驗(yàn)證對(duì)方的身份，之后通過(guò)協(xié)商機(jī)制選擇加密傳輸所使用的密鑰。在上述過(guò)程中，通信雙方的身份通過(guò)非對(duì)稱加密進(jìn)行驗(yàn)證，非對(duì)稱加密同時(shí)確保了密鑰協(xié)商過(guò)程的私密性和可靠性，即使攻擊者對(duì)通信進(jìn)行攔截，也無(wú)法獲取密鑰協(xié)商期間的具體內(nèi)容或?qū)ζ溥M(jìn)行篡改[20-21]。從目標(biāo)問題上看，DNSSEC主要解決遞歸服務(wù)器解析過(guò)程中數(shù)據(jù)被篡改的問題。本文模型主要解決解析全流程的用戶隱私保護(hù)問題。

2.2 信任鏈建立

本文模型信任鏈通過(guò)加密連接過(guò)程中的身份認(rèn)證和加密傳輸實(shí)現(xiàn)。具體地，遞歸解析器首先與根節(jié)點(diǎn)建立加密連接，在此過(guò)程中，遞歸解析器根據(jù)根節(jié)點(diǎn)發(fā)布的證書對(duì)其身份進(jìn)行驗(yàn)證。一旦連接建立成功，則根節(jié)點(diǎn)身份認(rèn)證通過(guò)，之后遞歸解析器向根節(jié)點(diǎn)查詢一級(jí)節(jié)點(diǎn)的證書信息。由于全程加密傳輸，可保證該證書來(lái)自于根節(jié)點(diǎn)且無(wú)法被篡改。在獲取到一級(jí)節(jié)點(diǎn)證書后，遞歸解析器嘗試使用該證書和一級(jí)節(jié)點(diǎn)建立加密連接，一旦連接建立成功，則一級(jí)節(jié)點(diǎn)身份得到認(rèn)證，并繼續(xù)向一級(jí)節(jié)點(diǎn)查詢二級(jí)節(jié)點(diǎn)證書信息。由此，通過(guò)加密連接的身份認(rèn)證和加密傳輸下級(jí)節(jié)點(diǎn)的證書實(shí)現(xiàn)權(quán)威解析器各級(jí)節(jié)點(diǎn)的身份認(rèn)證。DNSSEC信任鏈與本文模型信任鏈如圖2所示。

圖2 DNSSEC信任鏈與本文模型信任鏈

對(duì)比DNSSEC和本文模型，DNSSEC的優(yōu)勢(shì)在于可實(shí)現(xiàn)數(shù)據(jù)來(lái)源性驗(yàn)證，即經(jīng)過(guò)DNSSEC簽名后的數(shù)據(jù)，傳輸鏈路上無(wú)論經(jīng)過(guò)何種方式傳輸，鏈路上的任何一方都不需要掌握簽名者的私鑰，最終接收方都可以驗(yàn)證該數(shù)據(jù)來(lái)自于簽名者。因此，實(shí)際應(yīng)用中，域名擁有者可以對(duì)自有數(shù)據(jù)簽名，再將域名托管至第三方運(yùn)營(yíng)，方便簽名業(yè)務(wù)和解析托管業(yè)務(wù)分離。但DNSSEC的主要局限在于無(wú)法實(shí)現(xiàn)用戶的隱私保護(hù)，由于其使用電子簽名技術(shù)，經(jīng)過(guò)DNSSEC簽名后的報(bào)文仍然明文傳輸，第三方可以獲取用戶數(shù)據(jù)并窺探用戶隱私。此外，DNSSEC無(wú)法覆蓋用戶端和遞歸解析器間的鏈路，存在“最后一公里”問題[22]。本文模型的優(yōu)勢(shì)在于實(shí)現(xiàn)了標(biāo)識(shí)解析所有流程的加密傳輸，因此可實(shí)現(xiàn)全流程的用戶隱私保護(hù)。此外，由于數(shù)據(jù)加密傳輸，也保障了數(shù)據(jù)無(wú)法篡改。但其局限在于無(wú)法實(shí)現(xiàn)數(shù)據(jù)來(lái)源驗(yàn)證，域名擁有者若需托管域名到第三方，則第三方需要掌握域名擁有者用于加密連接的私鑰。因此，實(shí)際應(yīng)用中，若域名擁有者和域名托管第三方存在信任風(fēng)險(xiǎn)，可采用DNSSEC和本模型結(jié)合的方式，同時(shí)實(shí)現(xiàn)數(shù)據(jù)來(lái)源性驗(yàn)證和用戶隱私保護(hù)。

2.3 系統(tǒng)工作流程

本文模型通過(guò)建立信任鏈，實(shí)現(xiàn)標(biāo)識(shí)解析過(guò)程中全流程加密傳輸。遞歸解析器和根節(jié)點(diǎn)的公鑰通過(guò)帶外方式發(fā)布，分別配置到樁解析器和遞歸解析器。假設(shè)遞歸解析器無(wú)緩存數(shù)據(jù)，解析數(shù)據(jù)存儲(chǔ)于二級(jí)節(jié)點(diǎn)。一次典型的標(biāo)識(shí)解析流程如圖3所示。

圖3 系統(tǒng)工作流程

系統(tǒng)工作流程具體描述如下：

1)樁解析器使用遞歸解析器的公鑰與其建立加密連接，并發(fā)送查詢請(qǐng)求。

2)遞歸解析器使用根節(jié)點(diǎn)的公鑰與其建立加密連接，并發(fā)送查詢請(qǐng)求。

3)根節(jié)點(diǎn)返回一級(jí)節(jié)點(diǎn)的服務(wù)地址和公鑰給遞歸解析器。

4)遞歸解析器使用一級(jí)節(jié)點(diǎn)的公鑰與其建立加密連接，并發(fā)送查詢請(qǐng)求。

5)一級(jí)節(jié)點(diǎn)返回二級(jí)節(jié)點(diǎn)的服務(wù)地址和公鑰給遞歸解析器。

6)遞歸解析器使用二級(jí)節(jié)點(diǎn)的公鑰與其建立加密連接，并發(fā)送查詢請(qǐng)求。

7)二級(jí)節(jié)點(diǎn)返回查詢應(yīng)答結(jié)果給遞歸解析器。

8)遞歸解析器返回查詢應(yīng)答結(jié)果給樁解析器。

2.4 與現(xiàn)有安全模型對(duì)比分析

目前，域名領(lǐng)域主要的安全模型有基于簽名技術(shù)的DNSSEC以及基于加密技術(shù)的DoT、DoH等。其中DNSSEC通過(guò)數(shù)字簽名實(shí)施來(lái)源性驗(yàn)證，通過(guò)數(shù)字摘要連接父子節(jié)點(diǎn)信任鏈，可保障遞歸解析器和權(quán)威解析器間的數(shù)據(jù)安全。但部署DNSSEC后，數(shù)據(jù)仍然明文傳輸，無(wú)法解決隱私保護(hù)問題。DoT等安全模型通過(guò)樁解析器和遞歸解析器的加密傳輸解決用戶端和遞歸解析器鏈路上的DNS劫持問題，但無(wú)法實(shí)現(xiàn)各權(quán)威節(jié)點(diǎn)的信任傳遞，因此不能覆蓋標(biāo)識(shí)解析全流程。本文模型基于加密傳輸技術(shù)，通過(guò)加密過(guò)程的身份認(rèn)證實(shí)現(xiàn)權(quán)威節(jié)點(diǎn)的信任傳遞，可實(shí)現(xiàn)標(biāo)識(shí)解析全流程加密傳輸，保障用戶隱私和數(shù)據(jù)完整性。各模型具體對(duì)比如表1所示。

表1 各安全模型技術(shù)對(duì)比

3 實(shí)驗(yàn)與分析

3.1 實(shí)驗(yàn)方法

為測(cè)試不同加密算法、密鑰長(zhǎng)度、傳輸數(shù)據(jù)量等因素對(duì)加密傳輸下解析性能的影響及實(shí)際可用性，共設(shè)計(jì)了5組實(shí)驗(yàn)?；舅悸窞榛诓煌膫鬏攨f(xié)議和加密方法，在客戶端與服務(wù)端之間建立加密連接，并發(fā)送一定量的數(shù)據(jù)，計(jì)算平均解析時(shí)延和服務(wù)端CPU使用率并進(jìn)行安全性分析。

實(shí)驗(yàn)基于TLS協(xié)議對(duì)RSA和EC這2種加密算法進(jìn)行測(cè)試。其中，RSA算法測(cè)試的密鑰長(zhǎng)度分別為512 bit、1024 bit和2048 bit(以下簡(jiǎn)稱RSA512、RSA1024和RSA2048)，EC算法測(cè)試的密鑰長(zhǎng)度分別為160 bit、256 bit和384 bit(以下簡(jiǎn)稱EC160、EC256和EC384)。實(shí)驗(yàn)中密鑰對(duì)由JDK中的keytool工具生成，客戶端和服務(wù)端均為Java程序，JDK版本為JDK1.7.0_80。服務(wù)端和客戶端均運(yùn)行在CentOS release 6.5操作系統(tǒng)上。

3.2 實(shí)驗(yàn)結(jié)果與分析

3.2.1 不同加密算法和密鑰長(zhǎng)度下解析時(shí)延測(cè)試(實(shí)驗(yàn)1)

本組實(shí)驗(yàn)基于TLS協(xié)議，使用不同加密算法和密鑰長(zhǎng)度，以復(fù)用連接和不復(fù)用連接的方式與服務(wù)端進(jìn)行5000次通信，計(jì)算平均時(shí)延。不同加密算法和密鑰長(zhǎng)度下基于TLS的平均時(shí)延如圖4所示。

圖4 不同加密算法和密鑰長(zhǎng)度下基于TLS的平均時(shí)延

圖4結(jié)果顯示，不復(fù)用連接時(shí)，平均時(shí)延在11.48 ms～21.55 ms之間，復(fù)用連接時(shí)，平均解析時(shí)延顯著降低，相較于不復(fù)用連接，下降約98.5%。復(fù)用連接情況下，由于連接初始化過(guò)程會(huì)產(chǎn)生2次RTT(Round-Trip Time)的時(shí)延，因此復(fù)用連接可以明顯降低時(shí)延。此外，握手過(guò)程中使用指定的非對(duì)稱密鑰進(jìn)行密鑰協(xié)商，因此解析時(shí)延與算法復(fù)雜度和密鑰長(zhǎng)度呈正相關(guān)。復(fù)用連接時(shí)，由于連接建立后雙方采用對(duì)稱加密進(jìn)行通信，因此握手過(guò)程中使用不同的加密算法和密鑰長(zhǎng)度對(duì)解析時(shí)延影響不明顯。

3.2.2 不同響應(yīng)包大小下解析時(shí)延測(cè)試(實(shí)驗(yàn)2)

本組實(shí)驗(yàn)基于TLS協(xié)議，分別使用100 B、500 B、1 kB、10 kB和70 kB的報(bào)文，以復(fù)用連接和不復(fù)用連接的方式進(jìn)行5000次通信，計(jì)算平均時(shí)延。其中，加密連接使用RSA算法，密鑰長(zhǎng)度為1024 bit。不同大小報(bào)文基于TLS的平均時(shí)延如圖5所示。

圖5 不同大小報(bào)文基于TLS的平均時(shí)延

與實(shí)驗(yàn)1類似，復(fù)用連接相較于不復(fù)用連接，解析時(shí)延顯著降低，平均約下降95.8%?？傮w上，解析時(shí)延與報(bào)文大小呈正相關(guān)。當(dāng)報(bào)文在10 kB及以下時(shí)，報(bào)文大小對(duì)解析時(shí)延影響不明顯，其中復(fù)用連接時(shí)，平均時(shí)延約為0.3 ms，不復(fù)用連接時(shí)平均時(shí)延約為10.46 ms。當(dāng)報(bào)文增長(zhǎng)到70 kB時(shí)，解析時(shí)延出現(xiàn)明顯增長(zhǎng)，相較與10 kB報(bào)文，復(fù)用連接情況下時(shí)延增加約161%，不復(fù)用連接情況下時(shí)延增加約40%。由此可看出，當(dāng)響應(yīng)包在70 kB以內(nèi)時(shí)，TLS建立連接消耗的時(shí)間遠(yuǎn)大于連接建立后數(shù)據(jù)加密傳輸?shù)臅r(shí)間。

3.2.3 加密傳輸下服務(wù)端CPU使用率測(cè)試(實(shí)驗(yàn)3)

本組實(shí)驗(yàn)測(cè)試了基于TCP協(xié)議和TLS協(xié)議通信時(shí)，服務(wù)端CPU使用率的變化情況，測(cè)試結(jié)果見圖6，圖中橫坐標(biāo)為采集CPU使用率的時(shí)間點(diǎn)，t為連接建立后采集的第一份CPU使用率數(shù)據(jù)。

圖6 TCP和TLS協(xié)議對(duì)服務(wù)端CPU的占用率

圖6結(jié)果顯示，無(wú)論是否采用加密連接，服務(wù)端的CPU使用率在連接建立時(shí)(t時(shí)刻)均有顯著增加，其中，TLS加密連接達(dá)到約24%，TCP非加密連接達(dá)到約17%，TLS加密連接相比TCP非加密連接CPU使用率提高約41%。在連接建立后(t時(shí)刻后)，TLS傳輸?shù)腃PU平均使用率約為13%，TCP傳輸?shù)腃PU平均使用率約為8%，TLS加密傳輸相比TCP非加密傳輸CPU使用率提高約63%。因此，加密連接傳輸相較于非加密連接傳輸將占用更高的CPU資源，實(shí)際環(huán)境中，若大量加密連接并發(fā)而造成資源不足，可通過(guò)拒絕接受新的加密連接或?qū)Σ糠钟脩糁С旨用苓B接的方式以節(jié)省資源，保障解析服務(wù)正常運(yùn)行。

3.2.4 現(xiàn)網(wǎng)環(huán)境下DNS查詢時(shí)延和報(bào)文大小測(cè)試(實(shí)驗(yàn)4)

為分析本文模型在實(shí)際場(chǎng)景下的可用性，本組實(shí)驗(yàn)測(cè)試了現(xiàn)網(wǎng)環(huán)境下DNS解析時(shí)延及報(bào)文大小。其中DNS查詢的解析時(shí)延，通過(guò)向1.2.4.8、8.8.8.8、114.114.114.114這3個(gè)公共遞歸服務(wù)查詢Alexa網(wǎng)站上排名前五的中國(guó)網(wǎng)站域名各5000次并計(jì)算平均時(shí)延得到，DNS報(bào)文大小通過(guò)向DNS根服務(wù)器、.com和.baidu.com的權(quán)威服務(wù)查詢各自域名的A記錄、NS記錄和DNSKEY記錄得到。

表2 現(xiàn)網(wǎng)環(huán)境DNS遞歸服務(wù)查詢時(shí)延 單位:ms

從表2可以看出，目前主流的公共遞歸服務(wù)平均解析時(shí)延均在100 ms以內(nèi)。其中，由于測(cè)試機(jī)到1.2.4.8的路由跳數(shù)最少，時(shí)延最小，為2 ms以內(nèi)。到8.8.8.8的時(shí)延最大，約50 ms～90 ms之間。到114.114.114.114的時(shí)延在兩者之間，約16 ms。

表3 現(xiàn)網(wǎng)環(huán)境DNS報(bào)文大小情況 單位:B

表3結(jié)果顯示，現(xiàn)網(wǎng)環(huán)境大部分DNS報(bào)文大小都在1 kB以下。其中，最大的DNS報(bào)文是根NS記錄的DNSSEC查詢，非DNSSEC查詢時(shí)，常見的A記錄、NS記錄的DNS報(bào)文大小一般在200 B以內(nèi)。

結(jié)合前3組實(shí)驗(yàn)情況，并以114.114.114.114解析結(jié)果為例，在解析時(shí)延方面，采用TLS復(fù)用連接方式時(shí)延約提升1.8%，不復(fù)用連接時(shí)延將提升95%。因此，為降低加密傳輸帶來(lái)的時(shí)延提升，在實(shí)際應(yīng)用中，應(yīng)盡可能復(fù)用已建立的鏈接，降低加密傳輸所帶來(lái)的時(shí)延和服務(wù)器的處理壓力，RFC1035也建議服務(wù)端在連接空閑2分鐘以上后再將連接關(guān)閉。同時(shí)，客戶端應(yīng)該將連接數(shù)量最小化，通過(guò)復(fù)用一個(gè)活躍的加密連接，在客戶端和服務(wù)端之間進(jìn)行多次通信，以有效降低時(shí)延[23]。

在報(bào)文大小方面，實(shí)驗(yàn)2結(jié)果顯示，當(dāng)報(bào)文在10 kB以下時(shí)，解析時(shí)延變化不明顯，以TLS為例，復(fù)用連接時(shí)，時(shí)延增加約0.3 ms。目前現(xiàn)網(wǎng)環(huán)境DNS報(bào)文大小大部分小于1 kB，因此該因素對(duì)解析時(shí)延無(wú)顯著影響。

3.2.5 模型安全性分析(實(shí)驗(yàn)5)

本組實(shí)驗(yàn)通過(guò)搭建2級(jí)權(quán)威節(jié)點(diǎn)解析器(10.192.195.17和10.192.195.21)及遞歸解析器(218.241.111.162)，對(duì)模型信任傳遞機(jī)制的安全性進(jìn)行驗(yàn)證和分析。結(jié)果如圖7和圖8所示，從圖中結(jié)果可知，遞歸解析器從初始狀態(tài)開始，通過(guò)查詢學(xué)習(xí)到各級(jí)權(quán)威節(jié)點(diǎn)的證書信息，實(shí)現(xiàn)信任傳遞，并全程通過(guò)加密方式傳送數(shù)據(jù)，保障了數(shù)據(jù)的私密性和完整性。

圖7 根服務(wù)器與下級(jí)節(jié)點(diǎn)的信任傳遞過(guò)程

圖8 本文模型下加密傳輸?shù)慕馕鼋Y(jié)果

本文模型依賴加密連接過(guò)程的身份認(rèn)證來(lái)實(shí)現(xiàn)信任傳遞，因此保障證書的安全非常關(guān)鍵。在證書發(fā)布方面，由于遞歸服務(wù)器和根服務(wù)器分別是用戶和遞歸服務(wù)器的查詢起點(diǎn)，因此它們的證書需通過(guò)帶外方式發(fā)布。實(shí)際應(yīng)用中，可采用加密傳輸、官方發(fā)布等類似DNS根區(qū)發(fā)布密鑰的方式，保障查詢起點(diǎn)的安全。在證書密鑰方面，由于現(xiàn)代計(jì)算機(jī)計(jì)算能力不斷增強(qiáng)，為防止密鑰被暴力破解，參考DNSSEC相關(guān)部署經(jīng)驗(yàn)，推薦使用的RSA密鑰長(zhǎng)度應(yīng)不低于1024 bit，EC密鑰長(zhǎng)度應(yīng)不低于160 bit，同時(shí)應(yīng)定期更換密鑰，保障密鑰安全。

4 結(jié)束語(yǔ)

本文提出的基于加密通信的標(biāo)識(shí)解析模型，實(shí)現(xiàn)了標(biāo)識(shí)系統(tǒng)各節(jié)點(diǎn)在加密方式下的信任傳遞，保障了標(biāo)識(shí)解析全流程下用戶隱私，同時(shí)由于數(shù)據(jù)加密傳輸，防止了數(shù)據(jù)被篡改，保障了數(shù)據(jù)傳輸安全。與現(xiàn)有的技術(shù)相比，本文模型具有一定的技術(shù)優(yōu)勢(shì)，但也存在一定的局限。與DNSSEC不同，本文設(shè)計(jì)的模型依賴標(biāo)識(shí)解析服務(wù)提供方的信任傳遞，由于缺乏數(shù)字簽名，不能實(shí)現(xiàn)類似DNSSEC的來(lái)源性驗(yàn)證。對(duì)于實(shí)際應(yīng)用較復(fù)雜的場(chǎng)景，如標(biāo)識(shí)擁有方與解析服務(wù)提供商存在信任風(fēng)險(xiǎn)時(shí)，可采用數(shù)字簽名與本文模型結(jié)合的方式，進(jìn)一步加強(qiáng)數(shù)據(jù)安全的保護(hù)。同時(shí)，由于全流程加密傳輸，對(duì)于網(wǎng)絡(luò)流量監(jiān)測(cè)分析、惡意流量監(jiān)管等也提出了新的挑戰(zhàn)，需要進(jìn)一步研究。