Who Is Answering My Quries:Understanding and Characterizing Interception of the DNS Resolution Path

誰在響應我的查詢：理解和描繪DNS解析路徑攔截

劉寶軍，陸超一，段海鑫，劉穎，清華大學；

李洲，IEEE會員；

郝爽，University of Texas at Dallas；

楊敏，復旦大學。

本文收錄在第27屆USENIX安全研討會上

摘要

來自終端用戶的DNS查詢由遞歸DNS服務器處理，以實現可伸縮性。爲了方便起見，當客戶端選擇默認的網絡設置時，Internet服務提供商（ISPs）自動的爲其客戶分配遞歸服務器。但是用戶也應該有使用他們喜歡的遞歸服務器的靈活性，比如使用公共DNS服務器。然而，這種信任可能被隱藏的DNS解析路徑的攔截（我們稱之爲DNS攔截）所破壞。具體來說，沿路的設備可能冒充用戶指定的DNS服務器的IP地址，並暗中攔截DNS查詢，從而帶來隱私和安全問題。

在本文中，我們進行了大規模的沿途DNS攔截分析，並闡明瞭其範圍和特點。我們設計了新穎的方法去檢測DNS攔截，並利用全球148 478個住宅和蜂窩IP地址進行分析。結果是，我們發現在我們調查的3047個自治系統中有259個表現出DNS攔截行爲，包括像中國移動這樣的大型提供商。此外，我們發現攔截請求的自治系統DNS服務器可能使用過時的易受攻擊的軟件（2009年以前已經棄用）並且缺乏安全相關的功能，如處理DNSSEC請求。我們的工作突出關於路徑上DNS攔截的問題並且爲解決這些問題提出了新的見解。

1 介紹

域名系統（DNS）爲因特網應用提供了一項關鍵的服務——將人類可讀的域名解析爲數字的IP地址。幾乎每一個因特網連接都需要提前進行地址查找。因此，DNS故障將會嚴重影響用戶使用互聯網服務的體驗。以往的研究表明，流氓DNS[38,42]，DNS透明代理和未經授權的根域名服務器可能破壞互聯網通信的完整性和可用性。

在這項工作中，我們研究了一個關於DNS的新問題，即DNS解析路徑被沿途設備隱藏攔截，這是以前的工作所沒有完全研究和理解的。來自客戶端的DNS查詢通過遞歸域名服務器處理，以提高因特網的性能並且減少因特網上的流量擁塞。在默認的配置下，用戶的遞歸域名服務器指向由網絡服務提供商控制的域名服務器。另一方面，用戶應該有選擇他們自己的DNS服務器或者公共遞歸域名服務器的靈活性，如谷歌公共DNS8.8.8.8。然而，我們發現沿途設備攔截髮往公共DNS的DNS查詢，並且偷偷的使用替換了的遞歸域名服務器解析的DNS應答作爲迴應。沿途設備欺騙在DNS響應中用戶指定的遞歸域名服務器的IP地址，比如使用谷歌公共DNS的8.8.8.8替換解析IP地址，這樣用戶不會注意到DNS解析路徑已經被操縱了。

DNS攔截的目的包括顯示廣告（如通過NXDOMAIN響應的操作），收集統計數據和組織惡意軟件連接等等。但是，這種做法可能會引起多方面的關注：（1）未經用戶允許的攔截和很難在用戶一方檢測這些將導致倫理擔憂；（2）用戶對備選遞歸DNS服務器存在較高的信任風險，與知名公共DNS服務器相比，備選遞歸DNS服務器通常缺乏適當的維護（比如配置過時的DNS軟件）。（3）某些安全相關的功能受到影響甚至破壞，比如一些備用DNS解析器不提供DNSSEC。

本文對DNS攔截進行了大規模分析。我們的研究調查了這個問題的嚴重性，描述了DNS攔截的各個方面，並且檢測了對終端用戶的影響。最後我們提供了緩解問題的見解。

挑戰。系統的分析DNS攔截主要有兩個挑戰。首先是獲取來自不同自制系統（ASes）的客戶端來進行大規模的測量，這些也允許對測量參數微調。以前的作品提出的測量框架不能同時滿足條件，包括廣告網絡[33]，HTTP代理網絡[19,36,37,52]，和互聯網掃描儀[42,48]。另一個挑戰是去核實DNS解析式被攔截了還是到達用戶指定的遞歸域名服務器。因爲沿途設備可能欺騙DNS響應中的IP地址，僅從客戶端很難感覺到DNS攔截的存在。

我們的方法。爲了應對這些挑戰，我們設計了一種新的測量方法並且將其應用於兩種不同的大規模實驗，即全球分析和全中國分析。對於全球分析，我們使用了一個基於TCP SOCKS（而不是HTTP）的住宅代理網絡，它提供了173個國家的36173個獨特的住宅住宅IP地址。這讓我們可以從世界範圍的角度理解DNS攔截。然而，這個代理網絡只允許我們通過TCP SOCKS發送DNS數據包。爲了瞭解更全面的特徵，我們和一家領先的安全公司合作，該公司爲數百萬活躍的移動用戶提供網絡測試工具。我們從112305個IP地址（分佈在356個自治系統中）獲取UDP和TCP之上的DNS流量，這些流量主要來自中國。

爲了去檢測DNS攔截流量，我們註冊了一組域（像OurDomain.TLD)並且使用被我們控制的權威域名服務器處理解析。每一個客戶端被指示發送DNS包到一個DNS服務器列表中，並且在我們的域名下查詢臨時的子域，我們的域名如UUID.Google.OurDomain.TLD（我們使用Google來指示將DNS請求發送到谷歌公共DNS）。需要注意的是，我們不改變客戶機的DNS配置，而是直接將DNS請求發送到公共DNS服務器。由於每一個子域UUID都是不存在的，因此任何級別的DNS緩存都無法解析，必須通過DNS服務器層次結構。在我們操縱的權威域名服務器上，我們記錄IP地址，這個地址是我們控制查詢子域名得來的。通過檢查IP地址是否屬於最初請求的公共DNS服務，我們可以瞭解DNS解析是否被替代的解析器截獲。根據Alexa流量排名[57]，我們選擇三個流行的公共DNS服務器作爲研究目標，包括Google公共DNS[12],OpenDNS[22],Dynamic DNS[9]，此外，我們自己建立了一個名叫EDU DNS的公共DNS服務器來進行比較。

我們的發現。在這項工作中，我們有以下關鍵的發現。

在我們調查的3047個自治系統中，有259個自制系統（8.5%）發現被攔截，包括像中國移動這樣的大型提供商。另外，中國對谷歌公共DNS的UDP DNS請求中有27.9%被攔截。
攔截策略因不同類型的DNS流量而異。特別地，對UDP的DNS查詢以及發往知名公共DNS查詢的A類記錄的DNS查詢更可能被截獲。
攔截器使用的DNS服務器可能使用過時的軟件，例如，我們確定的所有97個DNS服務器都安裝了2009年後就應該棄用了的舊的BIND軟件，並且容易受到像DoS[6]等的攻擊。而且，有57%的DNS服務器不接受 DNSSEC請求。
DNS攔截對於終端用戶來說限制了性能發展。事實上，對於公共DNS服務的UDP DNS流量，有15.37%甚至比替代DNS服務器發出的流量還要快。

貢獻。我們研究的貢獻總結如下。

理解：我們系統的測量了DNS攔截，它欺騙用戶指定的DNS服務器的IP地址，以便暗中攔截DNS流量。
方法：我們設計了新穎的方法來進行大規模分析，通過全球148478個住宅和蜂窩IP地址來描繪DNS攔截。
發現：我們發現在一些著名的ASes中存在隱藏的攔截行爲，包括屬於中國移動等這樣的大型提供商。我們的研究結果表明攔截器使用的DNS服務器通常很少有安全維護，並且容易受到攻擊，這可能會破壞終端用戶DNS解析的完整性和可用性。
檢測工具：我們在http://whatismydnsresolver.co[25]發佈了在線檢測工具來幫助因特網用戶檢測DNS攔截。

2 危險模型和機制

在本節中，我們首先概述如何使用DNS將域名轉換爲地址。然後我們介紹我們的DNS攔截威脅模型，根據我們的觀察，我們對攔截路徑進行了分類。最後，我們討論一下潛在的攔截器及其行爲。

2.1領域解析過程

DNS是一種分級命名系統，用於處理不同級別的域解析。在層次結構的頂部是DNS根，它管理頂級域（TLD）解析。二級域（SLD）委託給DNS根目錄下的解析器。全限定域名（FQDN）由來自所有域級別的標籤組成，全限定域名（FQDN）指定其在DNS層次結構中的確切位置，從最低級別到根。例如：www.example.com是一個FQDN，其對應的TLD和SLD是com和example.com。

當客戶端請求域的解析時，解析通常首先由遞歸DNS解析器執行，該解析器可以由ISP分配或者由Internet用戶指定。如圖1所示，遞歸解析器迭代地聯繫根、TLD 和SLD名稱服務器來解析域名，並最終將答案返回給客戶端。因此，將DNS流量攔截到遞歸解析器直接影響到用戶的域解析過程。

2.2威脅模型

圖2展示了我們的威脅模型。我們假設用戶的DNS解析請求被沿途設備監視了。這些沿途設備能夠攔截和選擇性操縱DNS請求的路由（例如，通過檢查目的地和端口），這些請求本來是要發送到遞歸解析器，如公共DNS服務器。沿途設備將請求重定向或者複製到執行標準解析過程的替代解析器（通常是本地DNS解析器）。最後，在將替代解析器的響應發送回客戶端之前，將源替換爲原來的解析器的地址。因此，從客戶端的角度來看，DNS響應根據他們的源地址來看似乎是來自於最初的DNS解析器，這使得實際的攔截行爲難以識別。

默認情況下，爲了處理DNS請求，ISP爲Internet用戶分配本地DNS解析器。同時，用戶保留指定首選遞歸解析器以啓動DNS請求（特別是公共DNS服務器）的權利。然而，我們的研究表明對於使用指定DNS服務器的用戶來說，DNS攔截不僅違背了用戶的意願，而且它也可能帶來安全問題。

研究的範圍。我們的目標是通過大規模的數據分析來測量和描述DNS攔截。我們聚焦於在客戶端和知名公共DNS解析器之間的DNS解析路徑如何被篡改。其他類型的網絡流量操縱機制，比如BGP前綴攔截和未經授權對DNS根服務器進行操作，這些在之前已經系統的研究過了，這裏我們不再研究。

DNS解析路徑的分類。在本研究中，我們根據請求階段解析路徑的構造，將DNS解析機制分爲四類。除正常解析外，其餘三種情況都視爲DNS攔截。圖3顯示了四種DNS解析機制的DNS請求路徑。

正常的請求。解析嚴格遵循標準程序。客戶端發送的DNS查詢只到達指定的解析器，未經任何沿途設備的修改。如果解析沒有被緩存，指定解析器通過聯繫權威域名服務器來執行解析。
請求重定向。發送到用戶指定的解析器的原始DNS查詢被扔掉。同時，採用替代的解析器進行解析。指定的解析器完全從解析過程中移除。
請求克隆。發送到用戶指定的解析器的DNS查詢沒有被修改或者阻塞。但是，請求被沿途設備複製，並且由另一個解析器同時處理。因此，權威域名服務器從用戶指定的解析器（即in-band請求）和替代解析器（即out-band請求[46]）收到兩個確認請求。當返回多個響應時，客戶端通常會接收最快的響應。
直接回應。和請求重定向類似，用戶的DNS請求被沿途設備重定向到替代的解析器，而沒有到達指定的解析器。但是，即使對於沒有緩存的域，替代解析器也直接響應用戶，而不再聯繫任何其他的名稱服務器。

2.3潛在的攔截器

有趣的是，沿途設備主要由網絡運營商（像ISPs）部署，以攔截DNS流量[16]。但是，同樣的攔截也可以由如下所述的其他人進行。我們設計了自己的測量方法以減少觸發研究所不想要的攔截的機率。然而，我們承認，由於我們的方法和優勢點的限制，其他攔截器不能被完全移除。

審查和防火牆。爲了組織訪問某些網站（如有關政治的和色情網站），審查人員和防火牆可以操縱DNS查詢的路徑，並返回虛假的響應。正如之前工作的研究[28]，這種DNS攔截通常發生在域名包含敏感關鍵字或者匹配黑名單時。我們通過在DNS請求中嵌入一個正常的域名來儘量避免這種類型的攔截。
惡意軟件和反病毒（AV）軟件。和釣魚網站的目的類似，惡意軟件可以改變其主機的DNS解析器的配置，並將DNS重新路由到流氓解析器[38]。另一方面，AV軟件也可能攔截DNS請求，以防止客戶端DNS請求被劫持。例如，Avast AV軟件通過使用加密通道[3]將DNS請求從客戶機從新路由到自己的DNS服務器來提供這種功能。在這兩種情況下，解析器都可能直接由惡意軟件和反病毒軟件的操作人員控制，這些軟件由雲提供商或者專門託管服務託管。
企業代理。大量企業部署網絡代理來規範員工設備和互聯網之間的通信。一些代理能夠仔細檢查DNS請求並決定是否允許相應的web訪問，比如 Cisco Umbrella intelligent proxy。和反病毒設置類似，用戶需要將他們的DNS解析器指向代理的解析器。

由於解析器的IP地址與其所有者之間的映射是我們所不知道的，所以我們的研究包括網絡服務商以外的各方擁有的替代解析器，比如反病毒軟件和企業代理解析器。直接使用自制系統信息進行分類並不總是可靠的。例如，如果企業租用ISP的子網，那麼企業解析器就可能被錯誤的歸類爲ISP解析器。我們現在正在開發一種方法來實現精確解析器分析以解決這個問題。

3 方法和數據集

在本節中，我們描述了我們研究的方法和數據收集，試圖解決第一節中描述的兩個主要挑戰。首先我們描述我們方法的高級概念和它需要滿足的設計需求。然後我們詳細闡述度量框架的每個組件，以及如何獲取大量全球分佈有利位置。最後討論了有關數據收集的倫理問題。

3.1 概述

首先說明我們識別DNS攔截的方法，包括請求重定向、請求克隆、和直接響應。

方法。檢測DNS攔截在概念上很簡單。回顧正常的解析，當從客戶端收到請求時，如果結果沒有被緩存，遞歸解析器就會試圖聯繫權威域名服務器以獲得答案。然而，正如圖3所示，當攔截髮生時，請求被替代解析器轉發到權威名服務器。

因此，我們識別攔截的方法包括以下步驟。（1）我們指示一個客戶端向公共解析器A發送關於我們控制的域的DNS請求，（2）在我們的權威名服務器上記錄其相應的請求，該請求來自遞歸解析器B，（3）將A與B比較。作爲補充步驟，我們還（4）驗證客戶端最終收到的響應。

只有當A和B匹配時，認爲請求是正常解析的。否則，對於客戶端發送爲公共解析器A的每一個得到有效響應的請求，（1）如果沒有相應的請求被權威名服務器捕獲，我們將其視爲直接響應；（2）如果捕獲的不是來自解析器A的耽擱請求，我們將其視爲請求重定向；（3）如果來自解析器的多個相同的請求（其中一個是A）被捕獲，我們將其視爲請求克隆。

設計要求。我們的方法應滿足幾個要求，以獲得有效的結果。

第一，每個來自客戶端的請求的查詢域名應該相異，以避免緩存。第二，當我們從客戶端和權威命名服務器分別鋪貨數據包時，我們應該能夠將來自客戶機的請求與權威命名服務器在相同解析度下捕獲的請求關聯起來。正如將在3.2節討論的那樣，這兩個問題通過對每個請求設置唯一前綴來解決。

第三，我們的研究中的客戶端應該是多樣化的，即使本地DNS解析器已經由ISP分配，也能夠將DNS數據包直接發送到指定的公共解析器。第四，爲了深入的研究攔截特性，期望優勢點能夠解決不同的DNS請求（例如，不同傳輸協議和不同RR類型的請求）。之前研究中使用的度量基礎框架都不符合要求，包括廣告網絡[33]、HTTP代理網絡[19,36,37,52]，和互聯網掃描器[42,48]。如何處理這兩個問題將會在3.3節中討論。

最後，使用anycast地址（如谷歌的8.8.8.8）被客戶端訪問的公共DNS服務。當請求被轉發到我們的權威命名服務器時，這些地址很少能與單播地址匹配（比如，谷歌的74.125.41.0/24）。我們提出了一種識別公共DNS服務出口IP的新方法，將在第3.2節中詳細介紹。

3.2 方法

在介紹我們的方法之前，我們先用攔截器可能考慮的元素來描述一個攔截模型。在此基礎上，我們詳細闡述如何生存DNS請求以及如何識別公共DNS服務的出口IP。攔截模型。部署在路徑上的設備來檢查和操作DNS包。我們認爲每個DNS包由五個字段的元素表示：

{Src IP, Dst IP, Protocol , RR Type, Requested Domain}

每個字段都可以決定如何進行攔截。因此，要全面瞭解DNS攔截，我們需要具有不同字段的DNS數據包。爲此我們構建了一個擁有大量分佈在全球的源IP的客戶機池（即客戶機IP）。目標IP指向我們指定的公共DNS解析器。調查所有的公共解析器將花費大量的時間和資源，因此我們根據Alexa流量排名[57],將範圍縮小到三個具有代表性和廣泛使用的公共DNS服務，包括谷歌公共DNS[12]，OpenDNS[22]和Dynamic DNS[9]。作爲補充，我們還包括了一個自檢的公共DNS服務，名爲EDU DNS，以進行比較。傳輸協議可以是TCP或者UDP。對於資源記錄（resource record，RR)，我們考慮了五種安全相關的記錄，包括A，AAAA，CNAME，MX和NS。最後，我們專門爲我們的研究註冊了四個域名，涵蓋四個TLDs，包括一個新的gTLD（com，net，org和club）。我們避免任何含有敏感字的域名。

生成DNS請求。在本研究中，我們需要解決客戶端請求與其相應請求之間的源IP不一致的問題，該問題應該是遞歸解析器引起的。爲此我們設計了一種通過唯一域前綴鏈接這些請求的方法。前綴包括爲每個客戶端生成的唯一UUID（代表源IP）和用於處理解析的公共DNS服務標籤（代表目的IP）。通過同時考慮RR類型，我們能夠以相同的解析度識別DNS包。例如，當客戶端發起了一個DNS A類請求UUID.Google.OurDomain.TLD時，這個請求應該由Google公共DNS處理。權威命名服務器捕獲的相應請求也應該是A類型的，並且能匹配域前綴中的每個標籤。

生成DNS響應。在請求克隆情形中，客戶機接收in-band響應和out-band響應。我們我們想要對這兩種情況進行分類，但是權威命名服務器的常規響應無法區分這兩種情況。因此，我們需要一個可靠的機制將客戶機接收到的響應和權威命名服務器的響應鏈接起來。與前面的組件類似，我們在響應中編碼了一個唯一的場景。特別地，我們的權威命名服務器將時間戳，源地址和請求的域名一起哈希，並從哈希字符串匹配到記錄類型中生成唯一的響應。例如，一旦收到一個A類型的請求，響應則是一個從哈希值轉換過來的IPv4地址（使用哈希的最後32位二進制位）。

需要注意的是，通過這種方法合成的響應可能將客戶機指向一個未知的服務器。例如，僵屍網絡服務器可能偶爾使用響應IP。我們想要強調的是，因爲客戶端的行爲只不過是DNS查找，所以這不會對我們的優勢點造成實際的傷害。這裏沒有對服務器進行後續連接。

解析器能夠根據權威名稱解析器及其策略返回的內容操縱響應的TTL值。我們嘗試通過選擇一個介於1到86400之間的隨機TTL值來度量這個場景。

識別公共DNS的出口IP。我們的下一個任務是識別與我們權威命名服務器聯繫的源IP是否屬於公共DNS服務，即，是一個出口IP。從客戶端的角度來看，anycast地址是可訪問的，它本質上代表了一組遞歸解析器前面的代理。這種設計是爲了負載均衡。然而，關聯解析器的單播地址（由我們的權威命名服務器監視）通常與他們的anycast地址不匹配。anycast地址的所有者通常不爲公衆所知。因此，我們需要推斷出所有者身份。

先前的研究利用IP WHOIS數據和來自公共論壇的信息[37,49]來識別出口IP，當我們對數據進行檢查時，這些這些IP不夠精確。我們提出了一種利用DNS PTR和SOA記錄的更爲可靠的方法。我們的方法基於一個假設，即公共DNS服務傾向於使用多個網絡前綴（例如/24網絡）聚合的地址，而不是分散的IP地址。因此，爲了便於管理，網絡管理員通常將IP地址的標識信息嵌入PTR和SOA記錄。我們根據Alexa流量[57]排名前12的公共DNS服務，從5個自治系統不同位置優勢位置驗證了這一假設，並發現所有12個DNS服務都將身份信息嵌入到PTR（如Norton ConnectSafe）或者SOA記錄（如Freenom），或者兩者（如OpenDNS）。例如，對谷歌公共DNS的出口IP反向查找的響應都是 dns-admin.google.com。

實際上，對於與我們的權威命名服務器聯繫的IP，我們首先執行它的反向DNS查找。隨後，我們遞歸的請求響應域名的SOA記錄，並構建其SOA依賴項（5次迭代），類似於[43]。如果依賴鏈中存在特定的SLDs（例如opendns.com），我們將改地址視爲響應公共DNS服務的出口IP。例如，PTR中45.76.11.166這個記錄（AS20473；Choopa，LLC）是hivecast-234-usewr.as15135.net。這個域名的SOA記錄是ns0.dynamicnetworkservices.net，因此我們將45.76.11.166視爲Dynamic DNS的出口IP。

使用這種方法，我們可以推斷和我們權威命名服務器連接的85%的地址的所有者身份。同時，和IP WHOIS方法相比，我們的方法發現了新的公共DNS服務的出口ASes。例如，發現AS20473（使用Dynamic DNS）和AS30607（使用OpenDNS）是ASes出口。但是使用IP WHOIS和BGP信息方法都沒有發現他們。

討論。正如2.3節所討論的，我們的方法可能無法準確的區分攔截是網絡運營商還是其他的攔截器引起的。其次，通過給替代解析器設置虛假的PTR和SOA記錄，將無法準確識別它們的出口IP。但是，應該從Passive DNS數據中觀察到這些隱祕的變化，例如Farsight[10]和DNS Pai[15]管理的數據。目前，由於訪問限制，我們沒有包含Passive DNS數據，之後的工作會考慮加入。同時，在以往的研究中，PTR記錄被證明是一個可靠的IP地址分類來源。例如，[48]使用PTR記錄來識別特定CDNs上託管的域。

3.3 有利位置

我們的研究需要大量分佈在全球的客戶端。此外，我們的客戶端應該能夠向指定的公共解析器發送關於域的定製DNS請求。爲此，我們首先利用一個基於TCP SOCKS的住宅代理網絡，

未完待續。。。。