複製鏈接
請複製以下鏈接發送給好友

DNS污染

鎖定
網域服務器緩存污染(DNS cache pollution),又稱域名服務器緩存投毒(DNS cache poisoning),是指一些刻意製造或無意中製造出來的域名服務器數據包,把域名指往不正確的IP地址。一般來説,在互聯網上都有可信賴的網域服務器,但為減低網絡上的流量壓力,一般的域名服務器都會把從上游的域名服務器獲得的解析記錄暫存起來,待下次有其他機器要求解析域名時,可以立即提供服務。一旦有關網域的局域域名服務器的緩存受到污染,就會把網域內的計算機導引往錯誤的服務器或服務器的網址。
中文名
DNS污染
外文名
DNS pollution
名    稱
DNS污染
別名1
域名服務器緩存污染
別名2
域名服務器快照侵害
類似手段
DNS劫持
污染源
旁路路由器

DNS污染定義

某些網絡運營商為了某些目的,對DNS進行了某些操作,導致使用ISP的正常上網設置無法通過域名取得正確的IP地址。
某些國家或地區出於某些目的為了防止某網站被訪問,而且其又掌握部分國際DNS根目錄服務器或鏡像,也會利用此方法進行屏蔽。
常用的手段有:DNS劫持和DNS污染。

DNS污染常用方法

對於運營商,網絡管理員等人,尤其是在辦公室等地方,管理員希望網絡使用者無法瀏覽某些與工作無關的網站,通常採用DNS搶答機制。機器查詢DNS時,採用的是UDP協議進行通訊,隊列的每個查詢有一個id進行標識。

DNS污染查詢

源IP
目的IP
內容
192.168.2.2
8.8.8.8
Standard query 0x0001 PTR 8.8.8.8.in-addr.arpa
8.8.8.8
192.168.2.2
Standard query response 0x0001 PTR google-public-dns-a.google.com
192.168.2.2
8.8.8.8
Standard query 0x0002 A baidu.com
8.8.8.8
192.168.2.2
Standard query response 0x0002 A 220.181.57.217 A 123.125.114.144 A 180.149.132.47
192.168.2.2
8.8.8.8
Standard query 0x0003 AAAA baidu.com
8.8.8.8
192.168.2.2
Standard query response 0x0003
我們對一次正常的DNS請求進行抓包,結果如下表:
這裏我們查詢了百度的A記錄(ipv4)以及AAAA記錄(ipv6)每一個請求都有一個迴應。

DNS污染奇怪的查詢

源IP
目的IP
內容
192.168.2.2
8.8.8.8
Standard query 0x0001 PTR 8.8.8.8.in-addr.arpa
8.8.8.8
192.168.2.2
Standard query response 0x0001 PTR google-public-dns-a.google.com
192.168.2.2
8.8.8.8
Standard query 0x0002 A facebook.com
8.8.8.8
192.168.2.2
Standard query response 0x0002 A 8.7.198.45
8.8.8.8
192.168.2.2
Standard query response 0x0002 A 159.106.121.75
192.168.2.2
8.8.8.8
Standard query 0x0003 AAAA facebook.com
8.8.8.8
192.168.2.2
Standard query response 0x0003 A 93.46.8.89
8.8.8.8
192.168.2.2
Standard query response 0x0002 A 31.13.90.2
8.8.8.8
192.168.2.2
Standard query response 0x0003 AAAA 2a03:2880:f01a:1:face:b00c:0:1
從上表中我們可以看到一個神奇的東西,本地在向服務器發送id為3的查詢時,返回的結果竟然有以id2標識的結果,同時在整個查詢中,A記錄居然返回了三條,通過whois來對上述的三條A記錄進行檢查,我們發現,只有31.13.90.2才是facebook的ip地址,也就是那個姍姍來遲的id為2的查詢結果,而標記着編號為3的AAAA查詢結果中,我們竟然發現了一個A記錄的查詢結果。由此可見,上表用底色標記的就是被污染的DNS。下面我們就來講述一下這個的實現方法。

DNS污染原理解析

我們假設A為用户端,B為DNS服務器,C為A到B鏈路的一個節點的網絡設備(路由器,交換機,網關等等)。然後我們來模擬一次被污染的DNS請求過程。
A向B構建UDP連接,然後,A向B發送查詢請求,查詢請求內容通常是:“A baidu.com”,這一個數據包經過節點設備C繼續前往DNS服務器B;然而在這個過程中,C通過對數據包進行特徵分析(遠程通訊端口為DNS服務器端口,激發內容關鍵字檢查,檢查特定的域名如上述的“baidu.com",以及查詢的記錄類型"A記錄"),從而立刻返回一個錯誤的解析結果(如返回了"A 123.123.123.123"),眾所周知,作為鏈路上的一個節點,C機器的這個結果必定會先於真正的域名服務器的返回結果到達用户機器A,而我們的DNS解析機制有一個重要的原則,就是隻認第一,因此C節點所返回的查詢結果就被A機器當作了最終返回結果,用於構建鏈接。

DNS污染防除方法

對付DNS劫持,只需要把系統的DNS設置手動切換為國外的DNS服務器的IP地址即可解決。
對於DNS污染,一般除了使用代理服務器和VPN之類的軟件之外,並沒有什麼其它辦法。但是利用我們對DNS污染的瞭解,還是可以做到不用代理服務器和VPN之類的軟件就能解決DNS污染的問題,從而在不使用代理服務器或VPN的情況下訪問原本訪問不了的一些網站。當然這無法解決所有問題,當一些無法訪問的網站本身並不是由DNS污染問題導致的時候,還是需要使用代理服務器或VPN才能訪問的。
DNS污染的數據包並不是在網絡數據包經過的路由器上,而是在其旁路產生的。所以DNS污染並無法阻止正確的DNS解析結果返回,但由於旁路產生的數據包發回的速度較國外DNS服務器發回的快,操作系統認為第一個收到的數據包就是返回結果,從而忽略其後收到的數據包,從而使得DNS污染得逞。而某些國家的DNS污染在一段時期內的污染IP卻是固定不變的,從而可以忽略返回結果是這些IP地址的數據包,直接解決DNS污染的問題。

DNS污染驗證方法

我們在命令行下通過這樣一條命令:
nslookup 域名 144.223.234.234,即可判斷該域名是否被污染,由於144.223.234.234不存在,理應沒有任何返回。但我們卻得到了一個錯誤的IP(不確定)。即可證明這個域名已經被DNS污染了。 [1] 

DNS污染解決方案

1、使用各種SSH加密代理,在加密代理裏進行遠程DNS解析,或者使用VPN上網。
2、修改hosts文件,操作系統中Hosts文件的權限優先級高於DNS服務器,操作系統在訪問某個域名時,會先檢測HOSTS文件,然後再查詢DNS服務器。可以在hosts添加受到污染的DNS地址來解決DNS污染和DNS劫持。
3、通過一些軟件編程處理,可以直接忽略返回結果是虛假IP地址的數據包,直接解決DNS污染的問題。
4、如果你是Firefox only用户,並且只用Firefox,又懶得折騰,直接打開Firefox的遠程DNS解析就行了。在地址欄中輸入:
找到network.proxy.socks_remote_dns一項改成true。
5、使用DNSCrypt軟件,此軟件與使用的OpenDNS直接建立相對安全的TCP連接並加密請求數據,從而不會被污染。 [1] 
參考資料
  • 1.    Matthäus Wander, Torben Weis: Measuring Occurrence of DNSSEC Validation. In: Passive and Active Measurement. 2013, ISBN 978-3-642-36516-4, S. 125–134, doi:10.1007/978-3-642-36516-4_13 (PDF-Datei).