黃 鍇，孔 寧

HUANG Kai1,2,3,KONG Ning3

1.中國科學院 計算機網(wǎng)絡(luò)信息中心，北京 100190

2.中國科學院大學，北京100049

3.中國互聯(lián)網(wǎng)絡(luò)信息中心，北京 100190

1.Computer Network Information Center,ChineseAcademy of Sciences,Beijing 100190,China

2.University of ChineseAcademy of Sciences,Beijing 100049,China

3.China Internet Network Information Center,Beijing 100190,China

1 引言

1.1 DNS發(fā)展現(xiàn)狀

互聯(lián)網(wǎng)域名系統(tǒng)（Domain Name System，DNS）是互聯(lián)網(wǎng)最重要的基礎(chǔ)設(shè)施組件之一，互聯(lián)網(wǎng)上幾乎每個活動都會以DNS查詢開始，它也成為目前互聯(lián)網(wǎng)中各個應(yīng)用連接的一個紐帶。DNS的結(jié)構(gòu)是一個全球性的分布式數(shù)據(jù)庫，維護了域名（domain）到主機名（host）的映射關(guān)系。通過DNS，用戶可以通過簡單易懂的域名更加便捷地訪問互聯(lián)網(wǎng)上的資源。

DNS最早于1983年由Mockapetris提出的[1]，它的主要功能是解決域名和地址轉(zhuǎn)換的問題。經(jīng)過這么多年的發(fā)展。DNS的工作機制和協(xié)議層面的研究已經(jīng)基本成熟[1-2]，截止2017年8月，與DNS直接相關(guān)的規(guī)范已經(jīng)達到185條[3]。與DNS相關(guān)的討論也從基礎(chǔ)設(shè)施建設(shè)上升到安全層面，DNS已經(jīng)從一個簡單的查詢系統(tǒng)，逐步發(fā)展成為一個復雜的生態(tài)系統(tǒng)[4]。

正是由于DNS在當前互聯(lián)網(wǎng)世界中扮演著重要角色，DNS的安全日漸受到業(yè)界的重視，特別是近些年有關(guān)DNS的安全事件層出不窮[5-7]，把將大家對DNS安全的關(guān)注提升到了一個前所未有的高度。但是目前DNS中有關(guān)安全的命題真正被解決的還很少，還有大量的問題亟待解決，而隱私問題就是其中十分關(guān)鍵的一個，自斯諾登事件[8]后，大家對隱私的關(guān)注度顯著提升。當其他協(xié)議層都開始關(guān)注隱私問題，并通過各種加密手段保護用戶隱私的時候，DNS就成了所有環(huán)節(jié)中最脆弱的一環(huán)[9]。

1.2 隱私問題相關(guān)討論

目前網(wǎng)絡(luò)標準的研究和制定工作主要是由國際互聯(lián)網(wǎng)工程任務(wù)組（The Internet Engineering Task Force，IETF）負責，考慮到整個互聯(lián)網(wǎng)上的隱私問題日漸顯著，IETF于2013年開始就互聯(lián)網(wǎng)協(xié)議的隱私問題開展了一系列的討論，并提出了一系列的技術(shù)協(xié)議文檔（如表1）。

表1 隱私相關(guān)標準制定情況

2013年IETF正式提出了互聯(lián)網(wǎng)協(xié)議存在的隱私問題[10]。在2014年又提出被動監(jiān)聽也是對互聯(lián)網(wǎng)用戶和組織隱私的一種攻擊手段[11]。

IETF于2014年成立DNS隱私傳輸交換工作組（DNS Private Exchange，DPRIVE），專門研究DNS隱私保護相關(guān)的課題，希望通過對DNS傳輸過程進行加密保護，以保護用戶的隱私。該工作組擬定了隱私相關(guān)的RFC7626正式討論DNS的隱私問題。同時提出來RFC7858和RFC8094討論DNS傳輸過程中的加密手段。

在2017年IETF 99大會上，DNS Privacy項目組（dnsprivacy.org）專門就DNS隱私做了普及型匯報[12]。會上指出，目前DNS是互聯(lián)網(wǎng)上隱私泄露的關(guān)鍵一環(huán)，而且泄露情況不容樂觀。

1.3 DNS協(xié)議的脆弱性

早在2003年，IETF就對DNS的安全問題展開了討論[13]。它列舉了目前常見的安全威脅。同時文獻[14]將DNS系統(tǒng)面臨的安全威脅分為拒絕服務(wù)（denial of service）攻擊、數(shù)據(jù)虛假和信息泄露。DNS系統(tǒng)之所以面臨上述安全威脅，其根本因為是協(xié)議脆弱性[15]。

DNS協(xié)議設(shè)計之初就沒有過多考慮安全問題。由于DNS的工作原理比較簡單，考慮到效率問題，幾乎所有的DNS流量都是基于UDP明文傳輸?shù)腫16]，而且資源記錄未加上任何的認證和加密措施，所以很早就有人提出了觀點“DNS的數(shù)據(jù)是公開的”[17]。DNS協(xié)議由于以上缺陷，很容易受到中間人攻擊（man-in-the-middle attack）[18-19]，中間人可以通過竊聽、篡改和偽造DNS數(shù)據(jù)包實施攻擊。

DNS協(xié)議的脆弱性導致用戶隱私在一層很容易被泄漏。

2 DNS存在的隱私隱患

2.1 DNS查詢過程分析

用戶每一次與互聯(lián)網(wǎng)的交互基本都是從一次DNS查詢開始的，要了解DNS上隱私問題，需要對DNS的查詢方式有個大致了解。

一個簡單的DNS查詢大概會經(jīng)歷如圖1所示過程。

圖1 DNS查詢過程

（1）發(fā)起請求：用戶的主機會向自己配置的遞歸服務(wù)器發(fā)送查詢請求：“www.cnnic.cn的地址是多少”。

（2）遞歸查詢：遞歸服務(wù)器會根據(jù)用戶查詢的信息，查詢自己的緩存（cache），如果有匹配信息，直接返回。否則先向根域（root zone）服務(wù)器發(fā)起查詢，由于根域中只記錄了頂級域.cn的服務(wù)器地址，因此會返回.cn頂級域的權(quán)威服務(wù)器地址。遞歸服務(wù)器然后轉(zhuǎn)而向.cn的頂級域名服務(wù)器發(fā)起查詢……直到最后訪問到負責cnnic.cn.這個域的權(quán)威服務(wù)器，拿到了對應(yīng)主機的實際IP地址。

（3）返回結(jié)果：遞歸服務(wù)器會將拿到的主機地址返回給用戶。再由用戶向?qū)?yīng)主機發(fā)起后續(xù)請求。

從這里可以看出，由于當初設(shè)計的問題，DNS的這種查詢手段，會在一次次與不同的主機對話的過程中，泄露很多沒必要的信息，而這些信息都有可能包含用戶的隱私。

根據(jù)用戶主機產(chǎn)生DNS查詢的方式，可以將查詢分為兩種：主動查詢和被動查詢。

2.1.1 主動查詢

主動查詢，顧名思義是指用戶主動發(fā)起的行為所產(chǎn)生的DNS查詢。這也是最為用戶所熟知的一種查詢方式。一般來說，當用戶在使用瀏覽器，訪問特定網(wǎng)站的時候就會觸發(fā)主動查詢。瀏覽器會根據(jù)用戶輸入的域名向DNS發(fā)起查詢請求，得到查詢結(jié)果，然后去特定服務(wù)器上獲取用戶想要的資源信息（網(wǎng)頁、圖片、腳本文件等）。

主動查詢一般會泄漏用戶上網(wǎng)習慣的偏好，盡管現(xiàn)在很多用戶有清除瀏覽器訪問歷史記錄的習慣，但該行為只能清除本機的數(shù)據(jù)，瀏覽器產(chǎn)生的每條DNS查詢記錄依然會被服務(wù)器收集到。

2.1.2 被動查詢

除了主動查詢外，還有更多的DNS查詢是在用戶沒有察覺的情況下產(chǎn)生的，而這類查詢往往會被用戶忽視。例如當用戶進入一個網(wǎng)頁的時候，后臺可能會同時執(zhí)行多個復雜的請求，它可能涉及到請求不同域名下的圖片、視頻、腳本等資源，而每次資源請求都會重新發(fā)起一次DNS查詢[20]。加上目前智能化的搜索引擎還會預測用戶可能的查詢信息，預先發(fā)起一些請求，甚至是在用戶還未觸發(fā)任何超連接的情況下，就已經(jīng)預先發(fā)起了請求[21]。此外，用戶主機上幾乎所有需要的聯(lián)網(wǎng)應(yīng)用在向服務(wù)器獲取數(shù)據(jù)的過程中都會涉及到DNS查詢，這些查詢都是后臺自動產(chǎn)生的，無形中泄漏了用戶使用軟件的行為。

以上的兩種情況都可能泄漏用戶隱私，通過分析用戶主機產(chǎn)生的網(wǎng)絡(luò)流量數(shù)據(jù)，可以發(fā)現(xiàn)第二種情況發(fā)生頻率遠高過第一種，而且由于不被用戶熟知，在日常生活中可能會泄漏更多的用戶隱私信息。

2.2 DNS請求中的敏感字段

DNS請求包括許多字段[1]，但其中兩個與隱私問題特別相關(guān)：QNAME和源IP地址[9]。QNAME是用戶請求的域名全名，它提供了用戶的操作的信息，而IP地址提供的用戶主機的信息，可以看做是用戶標識。

2.2.1QNAME

不同的QNAME包含的敏感信息不一樣。例如，查詢知名的域名所能泄露的個人隱私很少，但查詢一些長尾的域名，可能會帶來更多的隱私隱患。例如，查詢www.veryrare.com的A記錄（其中，veryrare.com是一個很少有人訪問，具有特定主題的網(wǎng)站）可能會泄漏用戶的某種習慣，愛好等信息。

此外，QNAME經(jīng)常被嵌入到日常所使用的軟件中，這可能會導致隱私問題。例如，當用戶使用輕量目錄訪問協(xié)議 LDAP（Lightweight Directory Access Protocol）或者使用BitTorrent這樣的軟件的時候，都會觸發(fā)被動DNS查詢，產(chǎn)生特定格式的QNAME信息。例如：ldap.name.msdcs.cn，example.bittorrent-tracker.tcp.domain.，這些QNAME信息可能會泄漏用戶使用軟件的行為。

2.2.2 源IP地址

這里的IP地址包括IPv4和IPv6地址，由于IPv4地址空間的有限性，用戶的IPv4地址經(jīng)常會經(jīng)過網(wǎng)絡(luò)地址轉(zhuǎn)換（Network Address Translation，NAT），因此可能不能特別具體地標識特定的用戶。但隨著IPv6技術(shù)的日漸成熟，并逐漸在全球得以應(yīng)用[22]，未來每個IPv6地址很可能就能唯一標識用戶主機或設(shè)備，也更有可能泄漏用戶身份。

在一次DNS查詢中，不同層面的IP地址的含義不太一樣。一般來說，在遞歸服務(wù)器上，源IP地址基本就是用戶主機的IP地址，但是在權(quán)威服務(wù)器上，源IP地址一般是發(fā)起遞歸查詢的服務(wù)器的地址（但是有一種情況除外，用戶在自己的電腦上部署了本地遞歸服務(wù)）。

2.3 DNS敏感數(shù)據(jù)可能的泄漏途徑

通過前面的描述和分析，這里歸納出隱私泄漏主要有以下兩個途徑：通信鏈路竊聽和服務(wù)器收集。

2.3.1 通信鏈路竊聽

由于DNS的開放性，竊聽者可以像竊聽其他流量一樣監(jiān)聽DNS流量。同時DNS查詢并不經(jīng)過任何的加密手段，因此，任何第三方的機構(gòu)或個人很容易通過在用戶和服務(wù)器之間進行搭線竊聽，查看到用戶所有的DNS查詢信息。這也是目前被討論最多的DNS上的隱私問題。

2.3.2 服務(wù)器收集

服務(wù)器被動收集用戶隱私是目前DNS面臨的第二個問題。全球現(xiàn)有超過1 000萬臺域名服務(wù)器，每天產(chǎn)生的域名查詢信息已經(jīng)達到了萬億級別[23]，同時，由于DNS日志已被廣泛應(yīng)用于各種DNS解析器（DNS Resolver）軟件中[24]，因此，用戶的每條查詢信息都可以被服務(wù)器被動記錄到。

其中，遞歸服務(wù)器是最接近用戶的，所以它擁有最全面的用戶查詢記錄，同時由于遞歸服務(wù)器上緩存的緣故，各級權(quán)威服務(wù)器所能記錄的用戶查詢信息相對而言會有所缺失。但是考慮到權(quán)威服務(wù)器上每日接收到的查詢數(shù)量巨大，當其掌握到一定量的數(shù)據(jù)后，它上面的隱私泄漏問題依然不可小覷。

3 DNS隱私泄露情況的研究

3.1 DNS查詢會泄露用戶的行為

K?nings等人[25]通過校園網(wǎng)收集了一周DNS的查詢數(shù)據(jù)，發(fā)現(xiàn)其中存隱私泄露風險，如用戶真實姓名、設(shè)備名稱等都有可能得到泄漏。Krishnan等人[21]證明了目前很多瀏覽器為了優(yōu)化性能，往往會對網(wǎng)址所包含的內(nèi)容進行預先提取處理，從而推導出用戶可能的搜索行為，他提出這種做法有一定的隱私威脅并有可能被攻擊者濫用。

Herrmann等人[26]發(fā)表論文指出，用戶與DNS的交互存在暴露自身行為的風險。他指出用戶在瀏覽網(wǎng)頁時會形成特定的“行為鏈（behavior chain）”。通過分析用戶瀏覽網(wǎng)頁的行為特征，可以精確地匹配到特定用戶。為驗證猜想，他收集了大學數(shù)千名學生兩個月的匿名DNS數(shù)據(jù)，然后使用樸素貝葉斯分類器（Naive Bayes Classifier）對該數(shù)據(jù)進行分析。在包含3 600名學生的樣本中，通過“行為鏈”從IP地址中準確識別了85.4%的用戶。當覆蓋的用戶量提高到1.2萬時，準確率也有75.6%。許多國家的數(shù)據(jù)保存機制會禁止記錄瀏覽器的訪問歷史記錄。但作者聲稱執(zhí)法機構(gòu)通過使用DNS記錄、IP地址記錄和行為鏈可以重構(gòu)更詳細的瀏覽歷史。

以上都表明惡意攻擊者完全有可能通過分析用戶的DNS請求來獲取用戶的隱私，通過分析用戶的DNS查詢?nèi)罩就茢嘤脩舻男袨?，喜好甚至能定位到特定用戶?/p>

3.2 第三方服務(wù)器收集用戶查詢?nèi)罩?/h3>

通過之前的分析可以知道，遞歸服務(wù)器擁有更多用戶信息，更了解用戶的習慣和興趣。Banse等人[27]指出遞歸服務(wù)器在DNS查詢中所處的位置最適合用來做用戶行為追蹤。

通常來說，用戶的遞歸服務(wù)器地址默認會被配置成互聯(lián)網(wǎng)服務(wù)提供商（Internet Service Provider，ISP）的地址，用戶也可以根據(jù)需求，選擇將其配置成第三方提供的免費公共遞歸解析服務(wù)器的地址。

截止到2015年底，Google在報告指出它的公用域名解析服務(wù)器平均每天要返回超過4 000億次查詢結(jié)果，大約占到全球解析總量的12%[28]。根據(jù)Google官方文檔中對中“隱私（privacy）”一節(jié)的描述，Google承認有記錄用戶查詢記錄的行為[29]。并且記錄的字段十分多，包括用戶的IP，用戶查詢的域名，查詢類型，甚至還包括用戶地理位置信息。

OpenDNS直接公開表明會收集和保存DNS日志，用戶也可以通過設(shè)置（付費）帳戶功能來訪問自己的日志。

另一方面，Golden Frog剛剛推出了一個加密的零日志（zero-logging）DNS[30]。并宣稱其能增加用戶的隱私，并能突破全球的DNS審查制度。

美國電信運營商AT&T在他們的官網(wǎng)公布了一種名為GigaPower的計劃[31]，它為用戶提供300 Mb/s光纖接入計劃，在定價方案中，它明確地把保護用戶的隱私作為一種可選擇的增值付費服務(wù)。

現(xiàn)在國內(nèi)各大互聯(lián)網(wǎng)公司也都紛紛開始推出自己的公用域名解析服務(wù)。但由于目前第三方的公用域名解析服務(wù)大多都是由商業(yè)公司提供的，因此基于商業(yè)目的，用戶的隱私很可能會遭到侵犯。

同時，國內(nèi)外目前也有很多被動DNS（passive DNS），被動DNS最初于2004年由Florian Weimer發(fā)明，旨在對抗惡意軟件[32]。它會將響應(yīng)記錄并將日志數(shù)據(jù)復制到中央數(shù)據(jù)庫當中，以便用來分析惡意行為。知名的被動DNS系統(tǒng)宣稱他們只保留DNS響應(yīng)，而不保存客戶端的源IP地址，這正是出于用戶隱私的考慮[32]。但是并不是所有的被動DNS系統(tǒng)都會嚴格遵循以上規(guī)則[33]，所以依然存在泄漏用戶隱私的風險。

3.3 國家安全局監(jiān)聽用戶DNS查詢

美國國家安全局（National Security Agency，NSA）是美國政府機構(gòu)中最大的情報部門，專門負責收集和分析外國及本國通訊資料，隸屬于美國國防部。自從斯諾登事件之后，NSA的大量資料被泄漏，其中有關(guān)DNS的各種文件顯示，現(xiàn)有的針對DNS的秘密行動已經(jīng)不僅限于大規(guī)模監(jiān)視，而是已經(jīng)逐漸開始成為一種輔助攻擊手段[34]。隨著NSA的QUANTUMTHEORY系列項目（如QUANTUM DNS等子項目）的揭露，可以知道像國家這樣強大的攻擊者不僅可以竊聽DNS流量，還可以注入DNS響應(yīng)來修改名稱解析的結(jié)果，甚至使得特定的查詢完全失效。由于DNS不提供加密手段保護用戶的隱私，加上NSA這樣具有強大背景的機構(gòu)能獲取最全面的用戶查詢信息，因此很容易根據(jù)每個用戶的瀏覽行為創(chuàng)建用戶的概況[21]。這些信息都可以被用來對特定目標實施QUANTUMTHEORY攻擊。根據(jù)國家安全局自己公布的評估文件的顯示，他們的QUANTUMTHEORY項目進展開展的十分成功[35]。

由此可見，DNS上確實有隱私泄漏隱患。特別是服務(wù)器上收集的大量數(shù)據(jù)很有可能會泄漏用戶隱私。隨著第三方公用解析服務(wù)器的普及使用，大大加劇了這一層面隱私泄漏風險，同時還必須注意到，像國家安全局這樣的機構(gòu)想要竊取用戶隱私是非常容易的。因此，如果要徹底解決DNS的隱私問題，只關(guān)注通信鏈路上的隱私安全是遠不夠的。

4 DNS隱私保護的相關(guān)研究

考慮到目前互聯(lián)網(wǎng)上隱私泄漏的情況，目前學術(shù)界和工業(yè)界都在提出自己的解決方案去解決DNS上的隱私問題，不同的解決方案關(guān)注點也不盡相同，主要是集中在以下幾個方面。

4.1 鏈路上的隱私保護

DNS的開放性，使得它十分容易受到中間人攻擊。雖然目前DNSSEC的部署情況已經(jīng)有所好轉(zhuǎn)，但是DNSSEC明確地將機密性排除在其目標之外[36]。DNSSEC的主要目的是提供簽名認證，防止DNS被惡意篡改，并不提供加密服務(wù)。IETF的DPRIVE工作組一直在研究這個主題，研究如何以某種加密手段保護DNS客戶端和DNS服務(wù)器之間的查詢和響應(yīng)交互。

實現(xiàn)鏈路上的加密，最簡單的想法就是利用現(xiàn)有的非對稱加密算法對鏈路上的信息進行安全加密，保證信息無法破解。下面是目前提出的幾種針對鏈路上的隱私保護的方案。

4.1.1 DNS-over-TLS

Zhu等人[37]提出了T-DNS，通過使用安全傳輸層協(xié)議（Transport Layer Security，TLS）來保障用戶到解析器或者到權(quán)威服務(wù)器的隱私安全。TLS已經(jīng)被廣泛應(yīng)用在多種應(yīng)用層協(xié)議中為其提供加密服務(wù)。但TLS通常需要TCP提供的可靠傳輸信道，因此不能直接用于保護UDP的數(shù)據(jù)報業(yè)務(wù)，因此傳輸層協(xié)議必須由UDP換成TCP。

2016年IETF正式提出的RFC7858，在標準層面討論基于TLS的DNS的可行性。作者指出，使用TLS不僅有利于保護隱私，而且從無連接的UDP轉(zhuǎn)到面向連接的TCP，可能有助于減輕DNS服務(wù)器上的擴大攻擊（amplification attacks）[38]。通過重用TCP連接能同時處理多個DNS請求，并通過請求管道化和無序處理，能最大限度地減少延遲。但是使用TCP和TLS帶來的開銷依然不小。

4.1.2 DNS-over-DTLS

為了解決這些問題，另一個討論開始考慮將TLS的功能映射到數(shù)據(jù)報傳輸（datagram transport）環(huán)境。出于這種考慮，出現(xiàn)了一種新的協(xié)議：數(shù)據(jù)報傳輸層安全性協(xié)議（Datagram Transport Layer Security，DTLS）。它是對TLS功能的改進，可以向應(yīng)用程序呈現(xiàn)一種不需要可靠傳輸服務(wù)的數(shù)據(jù)報傳輸功能。DTLS可以從數(shù)據(jù)包丟失和重新排序中恢復，但不能容忍UDP數(shù)據(jù)包分片[39]。它建立在TLS 1.2的基礎(chǔ)上，并使用一些附加功能，允許TLS在數(shù)據(jù)報傳輸上運行。但由于其在傳輸信息之前需完成握手、認證、交換密鑰操作之后才能傳輸數(shù)據(jù)，往返需要7步才能完成通信任務(wù)。

4.1.3 DNSCurve

另外，針對鏈路上的安全問題，還有學者提出了DNSCurve[40]，它使用 Curve25519[41]交換會話密鑰，然后在緩存和服務(wù)器之間提供認證和加密。只要相互通信的兩臺服務(wù)器都安裝了DNSCurve緩存，那么它就能自動加密所有的DNS數(shù)據(jù)包，DNSCurve改進了現(xiàn)有域名系統(tǒng)在保密性和完整性上的不足，同時也不需要創(chuàng)建“昂貴”的簽名或（D）TLS會話。

所有這些方案都采用不同的加密手段來減少DNS數(shù)據(jù)中隱私信息的泄漏。盡管這些提案都可取，但IETF并不期望現(xiàn)有的這些行業(yè)解決方案能夠在短期內(nèi)改變DNS的現(xiàn)狀[42]。畢竟現(xiàn)階段，大規(guī)模加密DNS流量的可能性非常小。

4.2 減少服務(wù)器上隱私收集

4.2.1 查詢最小化

IETF近期在提高DNS隱私性方面的討論包括了查詢最小化（query minimization）[43]的提案，由于并不需要修改現(xiàn)有的DNS協(xié)議，所以該提案很快被采用了。DNS查詢最小化遵循的原則是發(fā)送的數(shù)據(jù)越少，隱私問題就越少[44]。

回顧DNS的一次查詢過程（圖1），用戶查詢的域名全名會暴露給所有權(quán)威服務(wù)器，但通常這種信息的暴露是沒必要的，因為較頂級的域名服務(wù)器通常不知道負責該域名的權(quán)威服務(wù)器的地址。因此，查詢的全名只需暴露給最終權(quán)威的DNS服務(wù)器即可。查詢最小化就是這樣實現(xiàn)的，遞歸服務(wù)器每次只需要查詢必要的信息（比如向頂級域發(fā)起查詢的時候，只需要查詢.cn的NS記錄，而不需向其發(fā)送www.cnnic.cn的A記錄查詢信息），可以減少根服務(wù)器和頂級域服務(wù)獲取到的用戶信息，如圖2所示。

圖2 查詢最小化

查詢最小化的優(yōu)勢在于：只需要改變遞歸服務(wù)器配置，但是它只能提供非常有限的保護。但是，威瑞信公司（Verisign Inc.）聲明該方案早已被其注冊了專利，因此可能會通過該專利阻礙查詢最小化的部署[45]，盡管如此，由于實現(xiàn)難度不大，目前市場上已經(jīng)有部分軟件宣布支持查詢最小化。

4.2.2 加入混淆

加入混淆是一種比較簡易實現(xiàn)的減少隱私泄漏的方案。通過加入混淆的信息，讓用戶原本的意圖得到隱藏，一定程度上可以緩解用戶信息泄漏的風險。Zhao等人[46]在研究了DNS每個環(huán)節(jié)的隱私泄漏問題之后，引入了一種解決方案，稱之為范圍查詢（range query），它基于隨機集（random set），即每個客戶端都配備有一個有效域名的數(shù)據(jù)庫（虛擬數(shù)據(jù)庫）。每次客戶端要向解析器發(fā)出DNS查詢時，它就會從數(shù)據(jù)庫中隨機選取N-1個啞名（dumb name），并將N個查詢發(fā)送到遞歸服務(wù)器。當從遞歸服務(wù)器接收到所有的回復后，虛擬查詢的回復將被丟棄，所需的回復被呈現(xiàn)給發(fā)出查詢的應(yīng)用程序。他聲稱這個策略讓對手只有機會猜出用戶查詢的真實域名，如圖3所示。

圖3 范圍查詢

但是范圍查詢是一個理想化的模型。Herrmann等人[47]通過實際的測試表明，在實際瀏覽網(wǎng)頁的時候，往往會觸發(fā)特定的查詢模式，通過語義分析，很容易就能破解用戶的訪問請求。

Zhao等人[48]在之前的范圍查詢的基礎(chǔ)上，又提出同時使用通信噪音和私人信息檢索（Private Information Retrieval，PIR）的方式來降低用戶隱私泄漏的風險，同時Castillo-Perez等人[49]進一步對這兩種解決方案進行了評估，評估結(jié)果表明，第一種方法的優(yōu)點是簡單易于實現(xiàn)，缺點是增加了延遲和帶寬。而第二種方法需要對DNS協(xié)議進行修改，不具備兼容性。

4.2.3 域名廣播

Federrath等人[50]在前人的研究基礎(chǔ)上又提出了一種基于熱門域名廣播和混合查詢結(jié)合的隱私保護機制。整體的思路就像殺毒軟件的病毒特征庫的更新模式，定時廣播域名庫到用戶機器上。遞歸服務(wù)器會參與熱門域名轉(zhuǎn)發(fā)，通過廣播最頻繁訪問的域名，使得遞歸服務(wù)器無法直接獲知用戶對熱點互聯(lián)網(wǎng)業(yè)務(wù)的訪問興趣。同時用戶可以本地緩存數(shù)據(jù)，實現(xiàn)80.2%的訪問零延遲，且沒有隱私泄漏的風險。同時對于長尾域名，加入混合的匿名機制，以保證隱私性。但是潛在的問題是用戶的機器上需要緩存大量的數(shù)據(jù)，而且定時廣播大量域名對服務(wù)器的要求比較高，而且需要修改現(xiàn)有的DNS架構(gòu)，部署起來工作量比較大。

4.3 全面匿名化方案

Victors等人[51]提出使用洋蔥路由（The Onion Router，TOR）的傳統(tǒng)匿名手段來保護DNS隱私，但是這種隱私保護手段由于使用多跳路由會引入相當大的延遲。

Herrmann等人[52]提出 EncDNS，一種輕量級隱私保護名稱解析服務(wù)器，用來替代傳統(tǒng)的第三方解析器。EncDNS使用的傳輸協(xié)議基于DNSCurve，將加密的消息封裝在標準的DNS消息中。通過使用EncDNS服務(wù)器代替用戶向DNS服務(wù)器發(fā)送請求，隱藏真實的查詢者，從而保護用戶隱私。

Lu等人[53]提出了PPDNS（Privacy Preserving DNS），在域名解析過程中提供一定程度的隱私保護。PPDNS采用分布式散列表來取代傳統(tǒng)的層次結(jié)構(gòu)，使用可計算隱私查詢方法（computation PIR，cPIR）實現(xiàn)查詢過程中對信息發(fā)送者的隱藏。

Lammertink等人[54]提出借鑒比特幣（bitcoin）的成熟方案，用基于比特幣技術(shù)的分布式域名系統(tǒng)Namecoin來解決這個問題，Namecoin使用一個新的區(qū)塊鏈（blockchain），獨立于比特幣的區(qū)塊鏈之外，在上面維護域名列表。每個用戶通過拷貝區(qū)塊鏈副本，可以在本地實現(xiàn)DNS查詢，從而實現(xiàn)完全匿名化。

以上的幾種方案都通過改變現(xiàn)有的DNS架構(gòu)，加入了相應(yīng)的隱私保護措施，但由于改變了現(xiàn)有架構(gòu)，只能被小范圍應(yīng)用，難以得到廣泛部署。

4.4 方案總結(jié)

總結(jié)分析以上的各種方案，本文列舉了每種方案主要的優(yōu)缺點（如表2所示），可以發(fā)現(xiàn)，目前提出的隱私保護方案或多或少都還有一些不足，每種方案都是針對當前DNS隱私泄漏的某一個側(cè)面進行研究的。根據(jù)前文分析，目前隱私保護應(yīng)該從兩個方面入手，一是在數(shù)據(jù)傳輸過程中進行加密處理，保護DNS查詢鏈路上的隱私性，二是盡量地減少服務(wù)器對用戶的隱私的收集。要真正徹底解決DNS上面的隱私問題，需要同時解決這兩方面的問題。

其中針對傳輸鏈路加密手段的研究進展很快，除了DNSCurve未被IETF標準化，其他方案都已經(jīng)被標準化，其中DNS-over-TLS已經(jīng)有了多個具體實現(xiàn)和大量的實驗性服務(wù)器部署。

但是針對服務(wù)器上的隱私收集問題，目前還沒有真正意義上的解決方案。不管是查詢最小化，加入混淆還是廣播域名都沒辦法有效地隱藏長尾域名。使用EncDNS通過代理服務(wù)器代替用戶查詢的思路值得借鑒，但是單代理服務(wù)器有嚴重的性能瓶頸和單點失效問題。而類似PPDNS，NameCoin這些解決方案雖然實現(xiàn)了全面的匿名化，但都修改了現(xiàn)有架構(gòu)，只能小范圍應(yīng)用，缺乏大規(guī)模部署性。

5 后續(xù)研究建議

為了后續(xù)研究的開展，這里提出后續(xù)隱私保護方案可以考慮的幾個方面。

5.1 技術(shù)層面考慮

目前有關(guān)鏈路上加密研究已經(jīng)很成熟了，多個方案都以被標準化了。相較而言服務(wù)器層面的隱私泄漏問題更值得研究。

Schomp等人通過對當前網(wǎng)絡(luò)中解析器進行探測，發(fā)現(xiàn)當前網(wǎng)絡(luò)中的大約有1 500～3 200萬個公用遞歸解析器[23]。這些解析器有些是可信任的，有些則是半可信任甚至不可信任的。一次看似簡單的域名解析過程，很可能會涉及多臺位于多個不同層級、不同地域的域名服務(wù)器和解析器。由此可見，服務(wù)器上的隱私泄漏問題可能更加嚴峻。

后續(xù)研究一方面可以研究通過DNS查詢?nèi)罩救绾晤A測用戶行為，給后續(xù)解決方案提供理論支撐。另一方面可以考慮借鑒或使用新的手段減少服務(wù)器上隱私泄漏，比如減少或合并查詢量，打亂查詢時間線，偽造查詢，或者加入混淆的時候考慮網(wǎng)頁間的語義關(guān)系從而優(yōu)化虛擬域名的選擇策略。

現(xiàn)有解決方案部分實現(xiàn)匿名化，但是都不是從構(gòu)建匿名化模型角度出發(fā)，后續(xù)研究可以考慮借鑒現(xiàn)有成熟的匿名化網(wǎng)絡(luò)的方案[55]。

匿名保護通?？梢苑譃椋喊l(fā)送者匿名、接收者匿名和通信關(guān)系匿名[56]。把一次DNS查詢比作一個雙方通信，用戶看作發(fā)送者，DNS服務(wù)器看作接收者。在這個特定的場景實現(xiàn)匿名化，實際上是要實現(xiàn)發(fā)送者匿名，即服務(wù)器無法獲知真實的發(fā)送者。同時需要考慮到匿名化對延遲的影響，盡量要選擇低延遲的匿名化方法，比如引入crowds協(xié)議，在保證查詢延遲的情況下提供對發(fā)送者的匿名化[57]。

表2 各種隱私保護方案比較

5.2 部署難度考慮

目前全球已經(jīng)有上千萬臺的DNS服務(wù)器，需要他們同時升級，難度重重，DNSSEC從1997年由網(wǎng)絡(luò)工作組提出，直到2016年底依然沒有實現(xiàn)全部頂級域的部署[58]。因此新的方案必須要考慮系統(tǒng)的部署難度，協(xié)議層的修改注定需要經(jīng)歷非常長的時間。

因此比較好的解決方案是盡量不要修改現(xiàn)有的DNS架構(gòu)，而是采取“補丁”的方式，在現(xiàn)有的架構(gòu)基礎(chǔ)上進行功能改進。

5.3 法律層面考慮

除了從技術(shù)層面解決DNS的隱私問題外，還可以考慮從法律政策層面去減輕這個問題的影響。目前還沒有任何國家地區(qū)正式發(fā)布與DNS隱私數(shù)據(jù)的相關(guān)的法律法規(guī)，這一塊是一個空白。正因為沒有立法，目前所有隱私的研究只能是在道德層面去約束和避免用戶的隱私收到威脅。但是真正侵犯用戶隱私的行為也不會受到任何的實際制裁，導致其犯罪成本很低。

考慮到隱私侵犯的判定比較難，因此在法律政策層面也需要進一步的推進。

6 結(jié)束語

本文通過對目前DNS隱私問題的現(xiàn)狀做了一定的分析，提出了目前DNS架構(gòu)中可能泄漏隱私的途徑和可能泄漏的用戶隱私信息，并且通過對目前國內(nèi)外DNS隱私泄漏情況進行了研究，發(fā)現(xiàn)目前DNS有嚴重的隱私隱患，需要得到業(yè)界的重視。

與此處同時，近兩年，國內(nèi)外很多機構(gòu)也開始在DNS的安全性和隱私性上下功夫，IETF中以DPRIVE為主的工作組開始就下一代安全可靠的DNS協(xié)議開展研究，有關(guān)DNS隱私的標準和草案也將會陸續(xù)推出。國內(nèi)外的學者也針對不同環(huán)境下的DNS隱私泄漏問題提出了自己的解決方案，這些方案距離實際應(yīng)用還有許多問題需要解決，但是依然給解決DNS隱私泄漏問題提供了很多創(chuàng)造性的思路。本文通過對現(xiàn)有方案進行總結(jié)和整理，希望能為后續(xù)研究提供一定的參考價值。

參考文獻：

[1]Mockapetris P V.RFC 1034 Domain names concepts and facilities[S].1987.

[2]Mockapetris P.RFC 1035 Domain names implementation and specification[S].USC/Information Sciences Institute，1987.

[3]DNS RFC[EB/OL].（2017-02-07）.https：//www.isc.org/community/rfcs/dns/.

[4]DNS Ecosystem[EB/OL].（2016）.https：//www.nsrc.org/workshops/2016/nsrc-nicsn-aftld-iroc/documents/prezo/DNS_Org.pdf.

[5]Dyn cyberattack[EB/OL].（2016）.https：//en.wikipedia.org/wiki/2016_Dyn_cyberattack.

[6]Turkey DNS servers under attack[EB/OL].（2015-12）.https：//blog.radware.com/security/2015/12/turkey-dns-servers-under-attack/.

[7]Cyberattacks in China[EB/OL].http：//www.scmp.com/news/china/article/1410423/major-internet-outage-hits-millionschina-cyberattacks-suspected.

[8]Wikipedia.Global surveillance disclosures[EB/OL].（2013）.https：//en.wikipedia.org/wiki/Global_surveillance_disclosures_（2013%E2%80%93present）.

[9]Bortzmeyer S.RFC 7626 DNS privacy considerations[S].IETF，2015-08.

[10]Aboba B，Peterson J，Tschofenig H，et al.Privacy considerations for Internet protocols[S].2013.

[11]Farrell S，Tschofenig H.RFC 7258 Pervasive monitoring is an attack[S].IETF，2014-05.

[12]Dnsprivacy.org.DNS privacy tutorial[EB/OL].（2017）.https：//dnsprivacy.org/wiki/display/DP/IETF+DNS+Privacy+Tutorial?preview=/1277990/3145807/IETF_99_EDU_DNS_Privacy.pdf.

[13]Atkins D，Austein R.RFC 3833 Threat analysis of the Domain Name System（DNS）[S].Internet Engineering Task Force，2004.

[14]Conrad D.Towards improving DNS security，stability，and resiliency[EB/OL].（2012）.http：//www.internetsociety.org/sites/default/files/bp-dnsresiliency-201201-en_0.pdf.

[15]胡寧，鄧文平，姚蘇.互聯(lián)網(wǎng)DNS安全研究現(xiàn)狀與挑戰(zhàn)[J].網(wǎng)絡(luò)與信息安全學報，2017，3（3）：13-21.

[16]Bellis R.DNS transport over TCP-implementation requirements[J].Poultry Science，2010，75（11）.

[17]Osterweil E，Massey D，Zhang L.Deploying and monitoring DNS security（DNSSEC）[C]//Twenty-Fifth Annual Computer Security Applications Conference（ACSAC 2009），Honolulu，Hawaii，2009：429-438.

[18]Ariyapperuma S，Mitchell C J.Security vulnerabilities in DNS and DNSSEC[C]//Proceedings of the International Conference on Availability，Reliability and Security，2007.

[19]王洪芬.基于DNS和DNSSEC安全的脆弱性分析[J/OL].中國科技論文在線，2008.http：//www.paper.edu.cn.

[20]Wills C E，Shang H.The contribution of DNS lookup costs to Web object retrieval[R].Worcester Polytechnic Institute，2000.

[21]Krishnan S，Monrose F.DNS prefetching and its privacy implications：When good things go bad[C]//Proceedings of the 3rd USENIX Conference on Large-scale Exploits and Emergent Threats：Botnets，Spyware，Worms，and More，2010.

[22]馬軍鋒，侯樂青.中美IPv6發(fā)展現(xiàn)狀分析[J].電信網(wǎng)技術(shù)，2016（12）：28-31.

[23]Schomp K，Callahan T，Rabinovich M，et al.On measuring the client-side DNS infrastructure[C]//Proceedings of the Conference on Internet Measurement，2013.

[24]Leonhard W.Another privacy threat：DNS logging and how to avoid it[EB/OL].（2014）.https：//www.infoworld.com/article/2608352/privacy/internet-privacy-another-privacy-threat-dns-logging-and-how-to-avoid-it.html.

[25]K?nings B，Bachmaier C，Schaub F，et al.Device names in the wild：Investigating privacy risks of zero configuration networking[C]//Proceedings of the IEEE International Conference on Mobile Data Management，2013.

[26]Herrmann D，Banse C，F(xiàn)ederrath H.Behavior-based tracking：Exploiting characteristic patterns in DNS traffic[J].Computers&Security，2013，39（4）：17-33.

[27]Banse C，Herrmann D，F(xiàn)ederrath H.Tracking users on the Internet with behavioral patterns：Evaluation of its practical feasibility[C]//IFIP Advances in Information&Communication Technology，2017，376：235-248.

[28]Google[EB/OL].（2014-12）.https：//webmasters.googleblog.com/2014/12/google-public-dns-and-location.html.

[29]Google privacy[EB/OL].https：//developers.google.com/speed/public-dns/privacy.

[30]Vyprdns[EB/OL].https：//www.goldenfrog.com/zh/vyprvpn/features/vyprdns.

[31]Gigapower[EB/OL].（2014-05-13）.https：//gigaom.com/2014/05/13/atts-gigapower-plans-turn-privacy-into-a-luxury-thatfew-would-choose/.

[32]Weimer F.Passive DNS replication[J].Analysis，2005（4）：1-13.

[33]Spring J M，Huth C L.The impact of passive DNS collection on end-user privacy[EB/OL].（2012）.https：//resources.sei.cmu.edu/library/asset-view.cfm?assetID=57021.

[34]Wired.A close look at the NSA’s most powerful internet attack tool[J].Communications of the ACM，2014.

[35]National Security Agency.There is more than one way to quantum[EB/OL]https：//www.documentcloud.org/documents/1076891-there-is-more-than-one-way-to-quantum.html-document/p1.

[36]US department of commerce N.DNS security introduction and requirements[C]//Proceedings of the BCP 78&BCP 79 Copies of IPR Disclosures Made To the IETF Secretariat，2005.

[37]Zhu L，Hu Z，Heidemann J，et al.T-DNS：Connectionoriented DNS to improve privacy and security（poster abstract）[J].ACM Sigcomm Computer Communication Review，2015，44（4）：379-380.

[38]Hu Z，Zhu L，Heidemann J，et al.Specification for DNS over Transport Layer Security（TLS）[S].IETF，2016，

[39]Netze H.RFC 6347 Datagram transport layer security version 1.2[S].2012-01.

[40]Dempsky M.DNSCurve：Link-level security for the domain name system[EB/OL].（2010-02-26）.https：//tools.ietf.org/html/draft-dempsky-dnscurve-01.

[41]Bernstein D J.Curve25519：New Diffie-Hellman speed records[C]//Lecture Notes in Computer Science，2006，3958（1）：207-228.

[42]Bortzmeyer S.Possible solutions to DNS privacy issues[EB/OL].（2013-12-17）.https：//tools.ietf.org/html/draft-bortzmeyer-dnsop-privacy-sol-00.

[43]Bortzmeyer S.RFC7816 DNS query name minimisation to improve privacy[S].2016-03.

[44]Steve Kenny C.Assuring data privacy compliance[J].Information Systems Control Journal，2004，4.

[45]Verisign Inc.’s Statement about IPR related to draftbortzmeyer-dns-qname-minimisation-02[EB/OL].（2014-10-27）.https：//datatracker.ietf.org/ipr/2469/.

[46]Zhao F，Hori Y，Sakurai K.Analysis of privacy disclosure in DNS query[C]//Proceedings of the International Conference on Multimedia and Ubiquitous Engineering，2007.

[47]Herrmann D，Maa? M，F(xiàn)ederrath H.Evaluating the security of a DNS query obfuscation scheme for private web surfing[C]//Proceedings of the IFIP SEC，2016.

[48]Zhao F，Hori Y，Sakurai K.Two-servers PIR based DNS query scheme with privacy-preserving[C]//Proceedings of the International Conference on Intelligent Pervasive Computing，2007.

[49]Castillo-Perez S，Garcia-Alfaro J.Evaluation of two privacy-preserving protocols for the DNS[C]//Proceedings of the International Conference on Information Technology：New Generations，2009.

[50]Federrath H，F(xiàn)uchs K P，Herrmann D，et al.Privacypreserving DNS：Analysis of broadcast，range queries and mix-based protection methods[C]//16th European Symposium on research in Computer Security（ESORICS 2011），Leuven，Belgium，September 12-14，2011.Berlin：Springer，2011，6879：665-683.

[51]Victors J.The onion name system：Tor-powered distributed DNS for tor hidden services[J].Dissertations&Theses-Gradworks，2015.

[52]Herrmann D，F(xiàn)uchs K P，Lindemann J，et al.EncDNS：A lightweight privacy-preserving name resolution service[C]//Proceedings of the European Symposium on Research in Computer Security，2014.

[53]Lu Y.PPDNS：Privacy-preserving domain name system[J].oai：CiteSeerX.psu：10.1.1.188.296，2011.

[54]Lammertink X，Davids M.Namecoin as alternative to the Domain Name System[D].UvA System and Network Engineering，SIDN Labs，2011.

[55]王平水，王建東.匿名化隱私保護技術(shù)研究綜述[J].小型微型計算機系統(tǒng)，2011，32（2）：248-252.

[56]徐靜，王振興.基于IPv6的接收者匿名Crowds系統(tǒng)[J].計算機工程，2009，35（23）：1-3.

[57]Reiter M K.Crowds：anonymity for Web transactions[J].ACM Transactions on Information&System Security，1997，1（1）：66-92.

[58]Chung T.Why DNSSEC deployment remains so low[EB/OL].（2017）.https：//blog.apnic.net/2017/12/06/dnssec-deploymentremains-low/.