DNS服務(wù)基礎(chǔ)知識點有哪些

DNS( Domain Name System)是“域名系統(tǒng)”的英文縮寫，是一種組織成域?qū)哟谓Y(jié)構(gòu)的計算機和網(wǎng)絡(luò)服務(wù)命名系統(tǒng)，使用的是UDP協(xié)議的53號端口，它用于TCP/IP網(wǎng)絡(luò)，它所提供的服務(wù)是用來將主機名和域名轉(zhuǎn)換為IP地址的工作。DNS就是這樣的一位“翻譯官”。

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

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

研究現(xiàn)狀

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

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

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

DNS通信鏈路加密

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

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

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

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

DNS密文通信方法

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

報文結(jié)構(gòu)

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

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

客戶端的公鑰由客戶端在DNS 報文的附加段以EDNS0 格式添加，通過 DNS 查詢發(fā)送給 DNS 服務(wù)端。具體格式如圖1所示。

密鑰的具體內(nèi)容存放在上面的選項數(shù)據(jù)中，其中前兩個字節(jié)為算法標記位，標識該密鑰使用的加密算法，之后兩個字節(jié)為預(yù)留的標識位，最后一部分為具體的公鑰數(shù)據(jù)。具體格式如圖2所示。

3)密報文格式。加密的 DNS報文的頭部與普通的 DNS報文保持一致，頭部后一個字節(jié)為加密標記位。標記位后兩個字節(jié)為加密數(shù)據(jù)的長度，最后一部分為的加密數(shù)據(jù)，具體格式如圖3所示。

加密查詢方法

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

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

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

具體流程如圖 4所示。以 www.example.com查詢?yōu)槔?，實現(xiàn)加密查詢方法，主要分以下步驟：(1)服務(wù)端通過 PKI發(fā)布公鑰，客戶端手動配置服務(wù)端公鑰;(2)客戶端生成密鑰對;(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)容。

實驗及分析

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

實驗方法

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

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

實驗結(jié)果與分析 ，

1)固定通信字節(jié)時延對比。采用10 Bit的通信數(shù)據(jù)，利用不同強度的密鑰進行測試，實驗結(jié)果如圖5所示。

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

由于 DTLS在密鑰協(xié)商成功后，采用對稱密鑰加密數(shù)據(jù)，因此隨著 DNS報文的加大，基于 DTLS 的 DNS加密方法時延增長不明顯，而 DNSDEA 在 DNS 報文較大時，其傳輸時延明顯增長。實驗可以看出，在 1024 位密鑰加密條件下，采用DNSDEA 傳輸時延整體明顯低于基于DTLS 的 DNS 加密方法。

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

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

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