基于隱私保護技術的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方法對于網絡社交和大數據交換領域的改進與影響，進一步減小互聯網隱私泄露風險。