黃 鍇，孔 寧

HUANG Kai1,2,3,KONG Ning3

1.中國(guó)科學(xué)院 計(jì)算機(jī)網(wǎng)絡(luò)信息中心，北京 100190

2.中國(guó)科學(xué)院大學(xué)，北京100049

3.中國(guó)互聯(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)上幾乎每個(gè)活動(dòng)都會(huì)以DNS查詢開(kāi)始，它也成為目前互聯(lián)網(wǎng)中各個(gè)應(yīng)用連接的一個(gè)紐帶。DNS的結(jié)構(gòu)是一個(gè)全球性的分布式數(shù)據(jù)庫(kù)，維護(hù)了域名（domain）到主機(jī)名（host）的映射關(guān)系。通過(guò)DNS，用戶可以通過(guò)簡(jiǎn)單易懂的域名更加便捷地訪問(wèn)互聯(lián)網(wǎng)上的資源。

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

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

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

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

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

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

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

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

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

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

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

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

2 DNS存在的隱私隱患

2.1 DNS查詢過(guò)程分析

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

一個(gè)簡(jiǎn)單的DNS查詢大概會(huì)經(jīng)歷如圖1所示過(guò)程。

圖1 DNS查詢過(guò)程

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

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

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

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

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

2.1.1 主動(dòng)查詢

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

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

2.1.2 被動(dòng)查詢

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

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

2.2 DNS請(qǐng)求中的敏感字段

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

2.2.1QNAME

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

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

2.2.2 源IP地址

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

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

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

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

2.3.1 通信鏈路竊聽(tīng)

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

2.3.2 服務(wù)器收集

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

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

3 DNS隱私泄露情況的研究

3.1 DNS查詢會(huì)泄露用戶的行為

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

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

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

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

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

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

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

OpenDNS直接公開(kāi)表明會(huì)收集和保存DNS日志，用戶也可以通過(guò)設(shè)置（付費(fèi)）帳戶功能來(lái)訪問(wèn)自己的日志。

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

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

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

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

3.3 國(guó)家安全局監(jiān)聽(tīng)用戶DNS查詢

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

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

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

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

4.1 鏈路上的隱私保護(hù)

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

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

4.1.1 DNS-over-TLS

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

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

4.1.2 DNS-over-DTLS

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

4.1.3 DNSCurve

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

所有這些方案都采用不同的加密手段來(lái)減少DNS數(shù)據(jù)中隱私信息的泄漏。盡管這些提案都可取，但I(xiàn)ETF并不期望現(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ù)越少，隱私問(wèn)題就越少[44]。

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

圖2 查詢最小化

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

4.2.2 加入混淆

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

圖3 范圍查詢

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

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

4.2.3 域名廣播

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

4.3 全面匿名化方案

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

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

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

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

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

4.4 方案總結(jié)

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

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

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

5 后續(xù)研究建議

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

5.1 技術(shù)層面考慮

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

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

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

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

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

表2 各種隱私保護(hù)方案比較

5.2 部署難度考慮

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

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

5.3 法律層面考慮

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

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

6 結(jié)束語(yǔ)

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

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

參考文獻(xiàn)：

[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ò)與信息安全學(xué)報(bào)，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].中國(guó)科技論文在線，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]馬軍鋒，侯樂(lè)青.中美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]王平水，王建東.匿名化隱私保護(hù)技術(shù)研究綜述[J].小型微型計(jì)算機(jī)系統(tǒng)，2011，32（2）：248-252.

[56]徐靜，王振興.基于IPv6的接收者匿名Crowds系統(tǒng)[J].計(jì)算機(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/.