基於隱私保護技術的DNS通訊協議介紹

本文提出了一種基於使用者資料包協議的DNS傳輸中使用者隱私保護的加密方法：DNSDEA。該方法採用PKI加密體系與DNS協議相融合，不僅解決了域名隱私保護問題，而且與傳統DNS體系相相容，保持了DNS系統的簡單、高效的技術特點。

域名系統(DNS)是網際網路基礎服務，是網際網路訪問的重要入口，域名隱私保護是 DNS安全的研究熱點。本文提出了一種基於使用者資料包協議的DNS傳輸中使用者隱私保護的加密方法：DNSDEA。該方法採用PKI加密體系與DNS協議相融合，不僅解決了域名隱私保護問題，而且與傳統DNS體系相相容，保持了DNS系統的簡單、高效的技術特點。

域名系統(domain name system，DNS)是網際網路的重要基礎服務之一，主要通過域名和網際網路協議地址(IP)等網際網路基礎資源之間的對映與轉換，實現標識和定位網際網路上伺服器和服務入口。DNS是一個相對成熟的全球性分散式資料庫，為網際網路提供高效穩定的網際網路標識解析服務。

1983 年，Mockapetris提出 DNS 架構，隨後該構架在不斷地持續演進和優化。在設計之初，域名系統在域名協議方面並沒有考慮完備的安全機制。1999年，DNS安全擴充套件協議(domain name system security extensions，DNSSEC)被提出，其能夠有效降低中間人攻擊的風險，保證 DNS傳輸資料的完整性，從而提升 DNS系統的安全服務能力。2010年，網際網路域名的根服務開始部署 DNSSEC服務，標誌著域名服務開始向安全服務方向邁進，DNS 也從一個簡單的名址轉換服務向複雜的、可信的解析服務發展，傳輸層安全協議DANE(DNS-based authentication of named entities)就是基於 DNSSEC協議將數字證照通過 DNS服務進行釋出，以確保證照來自特定的證照頒發機構。

隨著網際網路普及率的不斷提高及其對生產生活的不斷滲透，人們已經對網際網路產生了越來越強的依賴性，當前的網際網路已不僅是獲取和分享資訊的途徑，而且已成為大多數傳統行業業務系統的基礎載體，因此隱私問題已經成為網際網路亟待解決的一個重要問題。DNS 主要採用使用者資料包協議(user datagram protocol，UDP)協議明文傳輸方式進行名址轉換，雖然DNSSEC協議提升了資料篡改難度，但是依然採用明文方式提供解析服務。作為網際網路基礎服務，DNS 對於使用者隱私保護依然表現出了脆弱性。目前 DNS 有關安全的命題被真正解決得還較少，而其中的隱私問題也已成為行業關注的焦點問題並逐漸得到重視。一方面，行業內採用查詢最小化(query minimization)方法降低隱私竊取風險，使用資料最小化(data minimization)原理減少 DNS權威服務收集個人隱私資訊;另一方面，針對 DNS解析服務過程中隱私洩露的問題，國際組織Internet Engineering Task Force(IETF)於2014年專門成立 The DNS PRIVate Exchange(DPRIVE)工作組討論並制定 DNS 隱私保護協議，希望採用資料加密傳輸的方式實現 DNS隱私保護。基於此背景，本文提出一種基於UDP的DNS傳輸中使用者隱私保護的加密方法。

當前，絕大多數 DNS 服務和終端之間的資料交換(主要包含請求和反饋)採用明文、非加密的方式進行，這將導致使用者隱私暴露在網際網路通訊中，其隱私方面的脆弱性將會被黑客所利用，例如黑客可以收集使用者的訪問痕跡(查詢時間、訪問內容、使用者IP地址等)等資訊分析使用者習慣等。針對這個問題，目前主要有以下兩種方法保護DNS查詢過程中的使用者隱私。

Dempsky 提出了 DNSCurve 方法，該方法基於現有 DNS 體系架構，使用Curve25519 在客戶端和伺服器端交換金鑰以及提供認證和資料加密。服務端的公鑰存放在“NS”記錄中傳送給客戶端，因此使用 DNSCurve加密DNS報文並不會帶來額外查詢延遲。DNSCrypt是DNSCurve比較有名的一個實現，已在 OpenDNS的服務上得到廣泛部署，用來解決終端使用者的隱私保護問題。類似的ConfidentialDNS也使用了 DNS的擴充套件機制為 DNS協議增加加密功能。它提出一種新的資源記錄型別“ENCRYPT”來傳送 DNS伺服器的公鑰到客戶端。然後客戶端使用伺服器公鑰加密 DNS 查詢請求，以及用來加密 DNS響應的客戶端公鑰，從而實現對 DNS請求和反饋資料進行加密保護。這兩種方案雖然能有效解決DNS 明文傳輸所帶來的脆弱性問題，但是需要在DNS通訊兩端都部署安裝外掛(或升級解析軟體)實現DNS通訊從明文到密文的目標，推廣成本較大，所以目前使用並不廣泛。

TLS(transport layer security)是一種為網路通訊提供資料保密以及完整性的安全協議，它在傳輸層對網路連線進行加密。目前 TLS 最常見的一種應用是HTTPS協議，它使用公鑰加密對網站進行認證，同時使用對稱加密對資料傳輸進行加密。TLS需要 TCP協議來保證通道的可靠傳輸，不能直接用來加密保護 UDP協議的資料，如果 DNS希望使用 TLS加密保護資料，就必須使用 TCP協議。然而現狀是絕大部分的 DNS查詢使用 UDP協議，切換為 TCP協議是一個長期的過程，並且代價巨大。因此，就現階段來說，DNS-over-TLS並不是一個可行的隱私保護方案。

DTLS(datagram transport layer security)資料包傳輸層安全協議是在TLS架構上提出的一種擴充套件，能夠支援 UDP 協議。DTLS 使得直接加密 UDP 協議的 DNS 查詢報文變得可行。IETF草案提出的DNS-over-DTLS詳細描述瞭如何使用DTLS技術加密DNS報文。

DNS-over-TLS 和 DNS-over-DTLS 使用網際網路標準協議 TLS 和 DTLS 來實現 DNS 密文通訊。這兩種方法都是採用 TLS 協議進行 DNS 改進，但該方法需要在通訊之前需要建立握手、認證等一系列複雜網路通訊才能實現，對於訪問量巨大、開銷相對較小的 DNS服務提出了較高的網路開銷和效能要求。

上述兩種方法對於延遲敏感、高吞吐量的網際網路基礎服務DNS來說，都帶來了較大挑戰。

提出了一種新的 DNS加密通訊方法DNSDEA(DNS data encryption algorithm)，該方法在現有 DNS架構和報文格式下采用非對稱加密演算法的密文方式通訊。通過DNS查詢傳輸客戶端的公鑰，以降低基於TLS等方法建立連結的開銷，減低查詢延時。同時，利用其無狀態特性提高服務端的併發性。

1)加密標記位。為標記一個 DNS 報文是否為加密報文，將 DNS 報文頭部後的第一個位元組定位為加密標記位。對於一個正常的未加密 DNS 報文，該位元組表示查詢域名第一段的長度，按照網際網路協議標準(request for comments，RFC)，長度應小於 64。將該位元組擴充為加密標記位，若該位元組小於 64，表示 DNS報文為非加密報文，若大於64，表示該報文為加密報文。

2)金鑰格式。DNSDEA 採用非對稱加密方法，在 DNS 終端和DNS 服務端分別獨立生成通訊金鑰對(含公鑰和私鑰)。DNS 服務端的公鑰通過現有的證照頒發架構(certificate authority infrastructure)釋出，使用該 DNS 服務端的客戶需手動配置該公鑰。DNS客戶端使用的金鑰在查詢過沖中臨時生成。考慮到查詢效率等因素，DNS客戶端金鑰在一段時間內可重複使用。

客戶端的公鑰由客戶端在DNS 報文的附加段以EDNS0 格式新增，通過 DNS 查詢傳送給 DNS 服務端。具體格式如圖1所示。

金鑰的具體內容存放在上面的選項資料中，其中前兩個位元組為演算法標記位，標識該金鑰使用的加密演算法，之後兩個位元組為預留的標識位，最後一部分為具體的公鑰資料。具體格式如圖2所示。

3)密報文格式。加密的 DNS報文的頭部與普通的 DNS報文保持一致，頭部後一個位元組為加密標記位。標記位後兩個位元組為加密資料的長度，最後一部分為的加密資料，具體格式如圖3所示。

使用 DNSDEA 方法時，DNS 終端需要手動配置DNS服務端的公鑰。服務端的公鑰可通過 PKI體系進行驗證。在 DNS終端向 DNS服務端傳送查詢請求時，使用 DNS 服務端的公鑰對請求資源記錄(RRset)進行加密，將DNS終端的公鑰製作成RRset並使用DNS服務端的公鑰將其加密，生成 DNS 報文格式資料，傳輸給DNS服務端。

DNS 終端將按照 DNS 協議要求，將生成的 DNS 查詢報文傳送給 DNS 服務端，DNS服務端使用自身私鑰進行解密還原待查詢的域名記錄和 DNS終端的公鑰資訊，按照 DNS查詢邏輯尋找查詢結果，使用還原出來的DNS終端公鑰對查詢結果進行加密，傳送給DNS終端。

DNS 終端接收到應答報文後，使用其私鑰資訊將應答報文的應答資源記錄(RRset)進行解密，並按照DNS協議進行處理。

具體流程如圖 4所示。以 www.example.com查詢為例，實現加密查詢方法，主要分以下步驟：(1)服務端通過 PKI釋出公鑰，客戶端手動配置服務端公鑰;(2)客戶端生成金鑰對;(3)客戶端構造 www.example.com 的查詢包，將客戶端的公鑰新增在查詢包的附加段，並用服務端公鑰加密後，將查詢包傳送給服務端;(4)服務端收到加密的查詢包，使用服務端私鑰解密，獲取 DNS查詢內容和客戶端公鑰;(5)服務端構造www.example.com的應答包，並用客戶端的公鑰加密後，將應答包傳送給客戶端;(6)客戶端收到加密的應答包，使用客戶端私鑰解密，獲得www.example.com的應答內容。

為測試 DNSDEA 的可行性，進行了相關實驗，對DNSDEA 和基於 TLS、DTLS 加密方法的 DNS 查詢進行對比，以驗證DNSDEA 的可行性及相對於目前較流行加密方法的低延遲優勢。

由於 DNS 查詢主要通過 UDP 傳輸，因此實驗主要關注 DNSDEA 和基於 DTLS 加密方法下 DNS 查詢包延遲。實驗分別測試了兩種加密方法使用RSA和ECC演算法情況下不同大小資料包的效能表現，通過發起多次DNS查詢取平均值，計算各方法下DNS查詢時延，比較兩種方法在DNS加密使用上的特點。

實驗使用openssl-0.9.8 和crypto++5.6.5 加密庫實現 RSA和 ECDSA加密，通過程式設計模擬了兩種加密方法下DNS服務端和客戶端的軟體行為。客戶端DNS查詢均通過 指令碼 定時迴圈呼叫實現，因此基於 DTLS加密的查詢每次觸發新的 DTLS連線，未使用歷史會話。實驗執行環境為 CentOS  5.7，服務端和客戶端分別部署在北京同城的不同節點。

1)固定通訊位元組時延對比。採用10 Bit的通訊資料，利用不同強度的金鑰進行測試，實驗結果如圖5所示。

從實驗結果來看，在金鑰長度相等的情況下，基於DTLS 加密的 DNS 查詢由於在建立連線的過程中金鑰協商耗時較大，DNS 查詢整體延時大於 DNSDEA 方法下DNS延時。在RSA加密演算法下，加密強度越小，金鑰越短，與 DTLS方法比較，DNSDEA效能是 DTLS方法的2.79倍(定義加速比為DTLS方法與DNSDEA時延之比，其比率越高則說明 DNSDEA 時延越低，速度越快);隨著RSA金鑰長度的增長到2048 Bit時，由於DNSDEA需要將客戶端的金鑰加密後，通過 DNS 報文傳送給服務端，加密耗時明顯增長，但總時延仍低於 DTLS 加密方法。
使用 ECDSA 加密演算法情況下，金鑰長度為 112、160、256 Bit時，DNSDEA對金鑰加密的開銷小於DTLS金鑰協商的通訊開銷，因此總體網路延時優於 DTLS方法，但隨著加密強度增加到521Bit時，DNSDEA對金鑰本身加密的開銷顯著增長，明顯大於 DTLS金鑰協商的通訊開銷，造成加密後的 DNS 查詢時延急劇增長，在ECDSA 512下，效能低於DTLS方法。
2)固定金鑰長度時延對比。使用RSA演算法，選取金鑰長度為1024位，測試了不同長度的DNS報文在DNSDEA、DTLS方法的時延情況，實驗結果如圖7所示。

由於 DTLS在金鑰協商成功後，採用對稱金鑰加密資料，因此隨著 DNS報文的加大，基於 DTLS 的 DNS加密方法時延增長不明顯，而 DNSDEA 在 DNS 報文較大時，其傳輸時延明顯增長。
實驗可以看出，在 1024 位金鑰加密條件下，採用DNSDEA 傳輸時延整體明顯低於基於DTLS 的 DNS 加密方法。

綜上所述，在金鑰長度和傳輸報文較小時，DNSDEA時延明顯低於 DTLS方法;基於DTLS加密的方法，由於在連線建立後，雙方採用對稱金鑰加密，其耗時的增長幅度要小於DNSDEA;由於多數 DNS 報文的大小一般都在 200Byte 以內，因此相較於 DTLS 方法，DNSDEA 可以明顯降低 DNS 加密傳輸時延。此外，DNSDEA 基於 DNS傳輸，其無狀態的特性也可以明顯提升服務端的併發性。

隨著網際網路個人隱私問題得到更多人的關注，DNS隱私洩露問題將會越發突出。針對DNS個人隱私問題的現有技術進行分析，在現有技術解決方法基礎上提出了一種新的DNS加密通訊方法：DNSDEA。與傳統方法相比，該方法在現有 DNS 架構和報文格式下采用非對稱加密演算法的密文方式通訊，不僅完成了 DNS 個人隱私保護，而且提升了域名解析核心演算法的並行粒度，降低了 DNS終端與 DNS服務端之間的通訊開銷，有效保持了DNS低延遲的特性。

針對 RSA、橢圓加密演算法(ECC)等加密演算法進行了實驗，以期為後續通訊加密應用研究和 DNS 安全解析並行化研究提供一定參考，並且深入探索 DNSDEA 方法針對 DNSSEC TLSA協議的擴充套件，提升加密通訊安全水平。後續將深入研究 DNSDEA方法對於網路社交和大資料交換領域的改進與影響，進一步減小網際網路隱私洩露風險。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/31559985/viewspace-2649772/，如需轉載，請註明出處，否則將追究法律責任。