域名系統(tǒng)（DNS）是互聯(lián)網(wǎng)基礎(chǔ)服務(wù)，是互聯(lián)網(wǎng)訪問(wèn)的重要入口，域名隱私保護(hù)是 DNS安全的研究熱點(diǎn)。本文提出了一種基于用戶數(shù)據(jù)報(bào)協(xié)議的DNS傳輸中用戶隱私保護(hù)的加密方法：DNSDEA。該方法采用PKI加密體系與DNS協(xié)議相融合，不僅解決了域名隱私保護(hù)問(wèn)題，而且與傳統(tǒng)DNS體系相兼容，保持了DNS系統(tǒng)的簡(jiǎn)單、高效的技術(shù)特點(diǎn)。

域名系統(tǒng)（domain name system，DNS）是互聯(lián)網(wǎng)的重要基礎(chǔ)服務(wù)之一，主要通過(guò)域名和互聯(lián)網(wǎng)協(xié)議地址（IP）等互聯(lián)網(wǎng)基礎(chǔ)資源之間的映射與轉(zhuǎn)換，實(shí)現(xiàn)標(biāo)識(shí)和定位互聯(lián)網(wǎng)上服務(wù)器和服務(wù)入口。DNS是一個(gè)相對(duì)成熟的全球性分布式數(shù)據(jù)庫(kù)，為互聯(lián)網(wǎng)提供高效穩(wěn)定的互聯(lián)網(wǎng)標(biāo)識(shí)解析服務(wù)。

1983 年，Mockapetris提出 DNS 架構(gòu)，隨后該構(gòu)架在不斷地持續(xù)演進(jìn)和優(yōu)化。在設(shè)計(jì)之初，域名系統(tǒng)在域名協(xié)議方面并沒(méi)有考慮完備的安全機(jī)制。1999年，DNS安全擴(kuò)展協(xié)議（domain name system security extensions，DNSSEC）被提出，其能夠有效降低中間人攻擊的風(fēng)險(xiǎn)，保證 DNS傳輸數(shù)據(jù)的完整性，從而提升 DNS系統(tǒng)的安全服務(wù)能力。2010年，互聯(lián)網(wǎng)域名的根服務(wù)開(kāi)始部署 DNSSEC服務(wù)，標(biāo)志著域名服務(wù)開(kāi)始向安全服務(wù)方向邁進(jìn)，DNS 也從一個(gè)簡(jiǎn)單的名址轉(zhuǎn)換服務(wù)向復(fù)雜的、可信的解析服務(wù)發(fā)展，傳輸層安全協(xié)議DANE（DNS-based authentication of named entities）就是基于 DNSSEC協(xié)議將數(shù)字證書(shū)通過(guò) DNS服務(wù)進(jìn)行發(fā)布，以確保證書(shū)來(lái)自特定的證書(shū)頒發(fā)機(jī)構(gòu)。

隨著互聯(lián)網(wǎng)普及率的不斷提高及其對(duì)生產(chǎn)生活的不斷滲透，人們已經(jīng)對(duì)互聯(lián)網(wǎng)產(chǎn)生了越來(lái)越強(qiáng)的依賴性，當(dāng)前的互聯(lián)網(wǎng)已不僅是獲取和分享信息的途徑，而且已成為大多數(shù)傳統(tǒng)行業(yè)業(yè)務(wù)系統(tǒng)的基礎(chǔ)載體，因此隱私問(wèn)題已經(jīng)成為互聯(lián)網(wǎng)亟待解決的一個(gè)重要問(wèn)題。DNS 主要采用用戶數(shù)據(jù)報(bào)協(xié)議（user datagram protocol，UDP）協(xié)議明文傳輸方式進(jìn)行名址轉(zhuǎn)換，雖然DNSSEC協(xié)議提升了數(shù)據(jù)篡改難度，但是依然采用明文方式提供解析服務(wù)。作為互聯(lián)網(wǎng)基礎(chǔ)服務(wù)，DNS 對(duì)于用戶隱私保護(hù)依然表現(xiàn)出了脆弱性。目前 DNS 有關(guān)安全的命題被真正解決得還較少，而其中的隱私問(wèn)題也已成為行業(yè)關(guān)注的焦點(diǎn)問(wèn)題并逐漸得到重視。一方面，行業(yè)內(nèi)采用查詢最小化（query minimization）方法降低隱私竊取風(fēng)險(xiǎn)，使用數(shù)據(jù)最小化（data minimization）原理減少 DNS權(quán)威服務(wù)收集個(gè)人隱私信息;另一方面，針對(duì) DNS解析服務(wù)過(guò)程中隱私泄露的問(wèn)題，國(guó)際組織Internet Engineering Task Force（IETF）于2014年專門(mén)成立 The DNS PRIVate Exchange（DPRIVE）工作組討論并制定 DNS 隱私保護(hù)協(xié)議，希望采用數(shù)據(jù)加密傳輸?shù)姆绞綄?shí)現(xiàn) DNS隱私保護(hù)?；诖吮尘?，本文提出一種基于UDP的DNS傳輸中用戶隱私保護(hù)的加密方法。

研究現(xiàn)狀

當(dāng)前，絕大多數(shù) DNS 服務(wù)和終端之間的數(shù)據(jù)交換（主要包含請(qǐng)求和反饋）采用明文、非加密的方式進(jìn)行，這將導(dǎo)致用戶隱私暴露在互聯(lián)網(wǎng)通信中，其隱私方面的脆弱性將會(huì)被黑客所利用，例如黑客可以收集用戶的訪問(wèn)痕跡（查詢時(shí)間、訪問(wèn)內(nèi)容、用戶IP地址等）等信息分析用戶習(xí)慣等。針對(duì)這個(gè)問(wèn)題，目前主要有以下兩種方法保護(hù)DNS查詢過(guò)程中的用戶隱私。

DNS數(shù)據(jù)報(bào)文加密

Dempsky 提出了 DNSCurve 方法，該方法基于現(xiàn)有 DNS 體系架構(gòu)，使用Curve25519 在客戶端和服務(wù)器端交換密鑰以及提供認(rèn)證和數(shù)據(jù)加密。服務(wù)端的公鑰存放在“NS”記錄中發(fā)送給客戶端，因此使用 DNSCurve加密DNS報(bào)文并不會(huì)帶來(lái)額外查詢延遲。DNSCrypt是DNSCurve比較有名的一個(gè)實(shí)現(xiàn)，已在 OpenDNS的服務(wù)上得到廣泛部署，用來(lái)解決終端用戶的隱私保護(hù)問(wèn)題。類似的ConfidentialDNS也使用了 DNS的擴(kuò)展機(jī)制為 DNS協(xié)議增加加密功能。它提出一種新的資源記錄類型“ENCRYPT”來(lái)傳送 DNS服務(wù)器的公鑰到客戶端。然后客戶端使用服務(wù)器公鑰加密 DNS 查詢請(qǐng)求，以及用來(lái)加密 DNS響應(yīng)的客戶端公鑰，從而實(shí)現(xiàn)對(duì) DNS請(qǐng)求和反饋數(shù)據(jù)進(jìn)行加密保護(hù)。這兩種方案雖然能有效解決DNS 明文傳輸所帶來(lái)的脆弱性問(wèn)題，但是需要在DNS通信兩端都部署安裝插件（或升級(jí)解析軟件）實(shí)現(xiàn)DNS通信從明文到密文的目標(biāo)，推廣成本較大，所以目前使用并不廣泛。

DNS通信鏈路加密

TLS（transport layer security）是一種為網(wǎng)絡(luò)通信提供數(shù)據(jù)保密以及完整性的安全協(xié)議，它在傳輸層對(duì)網(wǎng)絡(luò)連接進(jìn)行加密。目前 TLS 最常見(jiàn)的一種應(yīng)用是HTTPS協(xié)議，它使用公鑰加密對(duì)網(wǎng)站進(jìn)行認(rèn)證，同時(shí)使用對(duì)稱加密對(duì)數(shù)據(jù)傳輸進(jìn)行加密。TLS需要 TCP協(xié)議來(lái)保證信道的可靠傳輸，不能直接用來(lái)加密保護(hù) UDP協(xié)議的數(shù)據(jù)，如果 DNS希望使用 TLS加密保護(hù)數(shù)據(jù)，就必須使用 TCP協(xié)議。然而現(xiàn)狀是絕大部分的 DNS查詢使用 UDP協(xié)議，切換為 TCP協(xié)議是一個(gè)長(zhǎng)期的過(guò)程，并且代價(jià)巨大。因此，就現(xiàn)階段來(lái)說(shuō)，DNS-over-TLS并不是一個(gè)可行的隱私保護(hù)方案。

DTLS（datagram transport layer security）數(shù)據(jù)包傳輸層安全協(xié)議是在TLS架構(gòu)上提出的一種擴(kuò)展，能夠支持 UDP 協(xié)議。DTLS 使得直接加密 UDP 協(xié)議的 DNS 查詢報(bào)文變得可行。IETF草案提出的DNS-over-DTLS詳細(xì)描述了如何使用DTLS技術(shù)加密DNS報(bào)文。

DNS-over-TLS 和 DNS-over-DTLS 使用互聯(lián)網(wǎng)標(biāo)準(zhǔn)協(xié)議 TLS 和 DTLS 來(lái)實(shí)現(xiàn) DNS 密文通信。這兩種方法都是采用 TLS 協(xié)議進(jìn)行 DNS 改進(jìn)，但該方法需要在通信之前需要建立握手、認(rèn)證等一系列復(fù)雜網(wǎng)絡(luò)通信才能實(shí)現(xiàn)，對(duì)于訪問(wèn)量巨大、開(kāi)銷(xiāo)相對(duì)較小的 DNS服務(wù)提出了較高的網(wǎng)絡(luò)開(kāi)銷(xiāo)和性能要求。

上述兩種方法對(duì)于延遲敏感、高吞吐量的互聯(lián)網(wǎng)基礎(chǔ)服務(wù)DNS來(lái)說(shuō)，都帶來(lái)了較大挑戰(zhàn)。

DNS密文通信方法

提出了一種新的 DNS加密通信方法DNSDEA（DNS data encryption algorithm），該方法在現(xiàn)有 DNS架構(gòu)和報(bào)文格式下采用非對(duì)稱加密算法的密文方式通信。通過(guò)DNS查詢傳輸客戶端的公鑰，以降低基于TLS等方法建立鏈接的開(kāi)銷(xiāo)，減低查詢延時(shí)。同時(shí)，利用其無(wú)狀態(tài)特性提高服務(wù)端的并發(fā)性。

報(bào)文結(jié)構(gòu)

1）加密標(biāo)記位。為標(biāo)記一個(gè) DNS 報(bào)文是否為加密報(bào)文，將 DNS 報(bào)文頭部后的第一個(gè)字節(jié)定位為加密標(biāo)記位。對(duì)于一個(gè)正常的未加密 DNS 報(bào)文，該字節(jié)表示查詢域名第一段的長(zhǎng)度，按照互聯(lián)網(wǎng)協(xié)議標(biāo)準(zhǔn)（request for comments，RFC），長(zhǎng)度應(yīng)小于 64。將該字節(jié)拓展為加密標(biāo)記位，若該字節(jié)小于 64，表示 DNS報(bào)文為非加密報(bào)文，若大于64，表示該報(bào)文為加密報(bào)文。

2）密鑰格式。DNSDEA 采用非對(duì)稱加密方法，在 DNS 終端和DNS 服務(wù)端分別獨(dú)立生成通信密鑰對(duì)（含公鑰和私鑰）。DNS 服務(wù)端的公鑰通過(guò)現(xiàn)有的證書(shū)頒發(fā)架構(gòu)（certificate authority infrastructure）發(fā)布，使用該 DNS 服務(wù)端的客戶需手動(dòng)配置該公鑰。DNS客戶端使用的密鑰在查詢過(guò)沖中臨時(shí)生成?？紤]到查詢效率等因素，DNS客戶端密鑰在一段時(shí)間內(nèi)可重復(fù)使用。

客戶端的公鑰由客戶端在DNS 報(bào)文的附加段以EDNS0 格式添加，通過(guò) DNS 查詢發(fā)送給 DNS 服務(wù)端。

密鑰的具體內(nèi)容存放在上面的選項(xiàng)數(shù)據(jù)中，其中前兩個(gè)字節(jié)為算法標(biāo)記位，標(biāo)識(shí)該密鑰使用的加密算法，之后兩個(gè)字節(jié)為預(yù)留的標(biāo)識(shí)位，最后一部分為具體的公鑰數(shù)據(jù)。

3）密報(bào)文格式。加密的 DNS報(bào)文的頭部與普通的 DNS報(bào)文保持一致，頭部后一個(gè)字節(jié)為加密標(biāo)記位。標(biāo)記位后兩個(gè)字節(jié)為加密數(shù)據(jù)的長(zhǎng)度，最后一部分為的加密數(shù)據(jù)。

加密查詢方法

使用 DNSDEA 方法時(shí)，DNS 終端需要手動(dòng)配置DNS服務(wù)端的公鑰。服務(wù)端的公鑰可通過(guò) PKI體系進(jìn)行驗(yàn)證。在 DNS終端向 DNS服務(wù)端發(fā)送查詢請(qǐng)求時(shí)，使用 DNS 服務(wù)端的公鑰對(duì)請(qǐng)求資源記錄（RRset）進(jìn)行加密，將DNS終端的公鑰制作成RRset并使用DNS服務(wù)端的公鑰將其加密，生成 DNS 報(bào)文格式數(shù)據(jù)，傳輸給DNS服務(wù)端。

DNS 終端將按照 DNS 協(xié)議要求，將生成的 DNS 查詢報(bào)文發(fā)送給 DNS 服務(wù)端，DNS服務(wù)端使用自身私鑰進(jìn)行解密還原待查詢的域名記錄和 DNS終端的公鑰信息，按照 DNS查詢邏輯尋找查詢結(jié)果，使用還原出來(lái)的DNS終端公鑰對(duì)查詢結(jié)果進(jìn)行加密，發(fā)送給DNS終端。

DNS 終端接收到應(yīng)答報(bào)文后，使用其私鑰信息將應(yīng)答報(bào)文的應(yīng)答資源記錄（RRset）進(jìn)行解密，并按照DNS協(xié)議進(jìn)行處理。

以 www.example.com查詢?yōu)槔?，?shí)現(xiàn)加密查詢方法，主要分以下步驟：（1）服務(wù)端通過(guò) PKI發(fā)布公鑰，客戶端手動(dòng)配置服務(wù)端公鑰;（2）客戶端生成密鑰對(duì);（3）客戶端構(gòu)造 www.example.com 的查詢包，將客戶端的公鑰添加在查詢包的附加段，并用服務(wù)端公鑰加密后，將查詢包發(fā)送給服務(wù)端;（4）服務(wù)端收到加密的查詢包，使用服務(wù)端私鑰解密，獲取 DNS查詢內(nèi)容和客戶端公鑰;（5）服務(wù)端構(gòu)造www.example.com的應(yīng)答包，并用客戶端的公鑰加密后，將應(yīng)答包發(fā)送給客戶端;（6）客戶端收到加密的應(yīng)答包，使用客戶端私鑰解密，獲得www.example.com的應(yīng)答內(nèi)容。

實(shí)驗(yàn)及分析

為測(cè)試 DNSDEA 的可行性，進(jìn)行了相關(guān)實(shí)驗(yàn)，對(duì)DNSDEA 和基于 TLS、DTLS 加密方法的 DNS 查詢進(jìn)行對(duì)比，以驗(yàn)證DNSDEA 的可行性及相對(duì)于目前較流行加密方法的低延遲優(yōu)勢(shì)。

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

由于 DNS 查詢主要通過(guò) UDP 傳輸，因此實(shí)驗(yàn)主要關(guān)注 DNSDEA 和基于 DTLS 加密方法下 DNS 查詢包延遲。實(shí)驗(yàn)分別測(cè)試了兩種加密方法使用RSA和ECC算法情況下不同大小數(shù)據(jù)包的性能表現(xiàn)，通過(guò)發(fā)起多次DNS查詢?nèi)∑骄担?jì)算各方法下DNS查詢時(shí)延，比較兩種方法在DNS加密使用上的特點(diǎn)。

實(shí)驗(yàn)使用openssl-0.9.8 和crypto++5.6.5 加密庫(kù)實(shí)現(xiàn) RSA和 ECDSA加密，通過(guò)編程模擬了兩種加密方法下DNS服務(wù)端和客戶端的軟件行為?？蛻舳薉NS查詢均通過(guò)腳本定時(shí)循環(huán)調(diào)用實(shí)現(xiàn)，因此基于 DTLS加密的查詢每次觸發(fā)新的 DTLS連接，未使用歷史會(huì)話。實(shí)驗(yàn)運(yùn)行環(huán)境為CentOS 5.7，服務(wù)端和客戶端分別部署在北京同城的不同節(jié)點(diǎn)。

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

1）固定通信字節(jié)時(shí)延對(duì)比。采用10 Bit的通信數(shù)據(jù)，利用不同強(qiáng)度的密鑰進(jìn)行測(cè)試。

從實(shí)驗(yàn)結(jié)果來(lái)看，在密鑰長(zhǎng)度相等的情況下，基于DTLS 加密的 DNS 查詢由于在建立連接的過(guò)程中密鑰協(xié)商耗時(shí)較大，DNS 查詢整體延時(shí)大于 DNSDEA 方法下DNS延時(shí)。在RSA加密算法下，加密強(qiáng)度越小，密鑰越短，與 DTLS方法比較，DNSDEA性能是 DTLS方法的2.79倍（定義加速比為DTLS方法與DNSDEA時(shí)延之比，其比率越高則說(shuō)明 DNSDEA 時(shí)延越低，速度越快）;隨著RSA密鑰長(zhǎng)度的增長(zhǎng)到2048 Bit時(shí)，由于DNSDEA需要將客戶端的密鑰加密后，通過(guò) DNS 報(bào)文傳送給服務(wù)端，加密耗時(shí)明顯增長(zhǎng)，但總時(shí)延仍低于 DTLS 加密方法。

使用 ECDSA 加密算法情況下，密鑰長(zhǎng)度為 112、160、256 Bit時(shí)，DNSDEA對(duì)密鑰加密的開(kāi)銷(xiāo)小于DTLS密鑰協(xié)商的通信開(kāi)銷(xiāo)，因此總體網(wǎng)絡(luò)延時(shí)優(yōu)于 DTLS方法，但隨著加密強(qiáng)度增加到521Bit時(shí)，DNSDEA對(duì)密鑰本身加密的開(kāi)銷(xiāo)顯著增長(zhǎng)，明顯大于 DTLS密鑰協(xié)商的通信開(kāi)銷(xiāo)，造成加密后的 DNS 查詢時(shí)延急劇增長(zhǎng)，在ECDSA 512下，性能低于DTLS方法。

2）固定密鑰長(zhǎng)度時(shí)延對(duì)比。使用RSA算法，選取密鑰長(zhǎng)度為1024位，測(cè)試了不同長(zhǎng)度的DNS報(bào)文在DNSDEA、DTLS方法的時(shí)延情況。

由于 DTLS在密鑰協(xié)商成功后，采用對(duì)稱密鑰加密數(shù)據(jù)，因此隨著 DNS報(bào)文的加大，基于 DTLS 的 DNS加密方法時(shí)延增長(zhǎng)不明顯，而 DNSDEA 在 DNS 報(bào)文較大時(shí)，其傳輸時(shí)延明顯增長(zhǎng)。

實(shí)驗(yàn)可以看出，在 1024 位密鑰加密條件下，采用DNSDEA 傳輸時(shí)延整體明顯低于基于DTLS 的 DNS 加密方法。

綜上所述，在密鑰長(zhǎng)度和傳輸報(bào)文較小時(shí)，DNSDEA時(shí)延明顯低于 DTLS方法;基于DTLS加密的方法，由于在連接建立后，雙方采用對(duì)稱密鑰加密，其耗時(shí)的增長(zhǎng)幅度要小于DNSDEA;由于多數(shù) DNS 報(bào)文的大小一般都在 200Byte 以內(nèi)，因此相較于 DTLS 方法，DNSDEA 可以明顯降低 DNS 加密傳輸時(shí)延。此外，DNSDEA 基于 DNS傳輸，其無(wú)狀態(tài)的特性也可以明顯提升服務(wù)端的并發(fā)性。

隨著互聯(lián)網(wǎng)個(gè)人隱私問(wèn)題得到更多人的關(guān)注，DNS隱私泄露問(wèn)題將會(huì)越發(fā)突出。針對(duì)DNS個(gè)人隱私問(wèn)題的現(xiàn)有技術(shù)進(jìn)行分析，在現(xiàn)有技術(shù)解決方法基礎(chǔ)上提出了一種新的DNS加密通信方法：DNSDEA。與傳統(tǒng)方法相比，該方法在現(xiàn)有 DNS 架構(gòu)和報(bào)文格式下采用非對(duì)稱加密算法的密文方式通信，不僅完成了 DNS 個(gè)人隱私保護(hù)，而且提升了域名解析核心算法的并行粒度，降低了 DNS終端與 DNS服務(wù)端之間的通信開(kāi)銷(xiāo)，有效保持了DNS低延遲的特性。

針對(duì) RSA、橢圓加密算法（ECC）等加密算法進(jìn)行了實(shí)驗(yàn)，以期為后續(xù)通信加密應(yīng)用研究和 DNS 安全解析并行化研究提供一定參考，并且深入探索 DNSDEA 方法針對(duì) DNSSEC TLSA協(xié)議的擴(kuò)展，提升加密通信安全水平。后續(xù)將深入研究 DNSDEA方法對(duì)于網(wǎng)絡(luò)社交和大數(shù)據(jù)交換領(lǐng)域的改進(jìn)與影響，進(jìn)一步減小互聯(lián)網(wǎng)隱私泄露風(fēng)險(xiǎn)。

責(zé)任編輯：ct