我是guyue，guyue就是我O(∩_∩)O
2014年1月21日全國DNS汙染始末以及分析 - 51CTO.COM
什麼事DNS汙染!域名遭遇DNS汙染怎麼解決_建站經驗_網站運營_指令碼之家
DNS汙染_百度百科
費勁九牛二虎之力，終於將在萬網註冊的wangyueblog.com這個域名轉移到godaddy，然而舒心的日子沒有幾天，麻煩又來了，由於日益嚴重的DNS汙染，域名常常出現解析錯誤，真是屋漏偏逢連夜雨，不過，blogging還得繼續，所以還是得想辦法，在這裡將想法和辦法分享，僅供參考。
什麼是DNS汙染？
按照百度百科的解釋就是：某些網路運營商為了某些目的，對DNS進行了某些操作，導致使用ISP的正常上網設定無法通過域名取得正確的IP地址。某些國家或地區為出於某些目的防止某網站被訪問，而且其又掌握部分國際DNS根目錄伺服器或映象，也可以利用此方法進行遮蔽。
（盜用可能吧的一張圖片）和某些流氓運營商利用DNS劫持域名發些小廣告不同，DNS汙染則讓域名直接無法訪問了，非得修改DNS伺服器不可。
怎麼驗證是否遭遇DNS汙染？
1.點“開始”-“執行”-輸入CMD，再輸入 ipconfig /all ，在下“DNS SERVER”裡找到你使用的DNS伺服器地址。
2.再輸入 nslookup wangyueblog.com（你的域名） 你的DNS伺服器IP ，來檢視是否能解析。
3.再輸入 nslookup wangyueblog.com 8.8.8.8 使用Google的DNS伺服器驗證。
域名遭遇DNS汙染怎麼解決？
1.更換DNS解析伺服器。一般來說，域名註冊商家都是提供免費的DNS解析服務的，以我所實用的Godaddy為例，就提供了許多免費的DNS解析服務，而且解析速度很快，比之前實用的什麼萬網之流要快得多，不可能全部被汙染，所以更換兩個DNS伺服器即可。
2.使用第三方DNS解析服務。目前有很多第三方網站提供DNS解析服務，不少都是免費的，國內也有免費提供DNS解析服務的，使用第三方DNS服務可以部分解決問題，比如望月正在使用的DNSpod服務，就是國內還算比較穩定的DNS解析服務。
注意事項一：在換用第三方解析服務的時候，應該先到DNSPOD之類的解析服務商那裡將域名解析，過幾個小時再到godaddy之類的域名註冊商那裡去修改DNS伺服器，這樣可以避免部落格出現因解析時間造成的空白期。
注意事項二：Godaddy目前本身域名就被DNS汙染了，即使掛VPN也訪問不了，只有更改自己電腦的DNS（比如改成google的8.8.8.8）才能訪問。
3.搭建自己的DNS伺服器。這樣子最保險，當然也最是費時廢財，有條件的朋友可以嘗試。
///////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
///////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
///////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
-
DNS汙染
編輯
- DNS汙染
- DNS cache poisoningDNS cache pollution
- DNS汙染
定義編輯
某些網路運營商為了某些目的，對DNS進行了某些操作，導致使用ISP的正常上網設定無法通過域名取得正確的IP地址。 某些國家或地區出於某些目的為了防止某網站被訪問，而且其又掌握部分國際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 |
一個奇怪的查詢
| 源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 |
原理解析
我們假設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伺服器的IP地址即可解決。 對於DNS汙染，一般除了使用代理伺服器和VPN之類的軟體之外，並沒有什麼其它辦法。但是利用我們對DNS汙染的瞭解，還是可以做到不用代理伺服器和VPN之類的軟體就能解決DNS汙染的問題，從而在不使用代理伺服器或VPN的情況下訪問原本訪問不了的一些網站。當然這無法解決所有問題，當一些無法訪問的網站本身並不是由DNS汙染問題導致的時候，還是需要使用代理伺服器或VPN才能訪問的。 DNS汙染的資料包並不是在網路資料包經過的路由器上，而是在其旁路產生的。所以DNS汙染並無法阻止正確的DNS解析結果返回，但由於旁路產生的資料包發回的速度較國外DNS伺服器發回的快，作業系統認為第一個收到的資料包就是返回結果，從而忽略其後收到的資料包，從而使得DNS汙染得逞。而某些國家的DNS汙染在一段時期內的汙染IP卻是固定不變的，從而可以忽略返回結果是這些IP地址的資料包，直接解決DNS汙染的問題。驗證方法編輯
我們在命令列下通過這樣一條命令： nslookup 域名 144.223.234.234，即可判斷該域名是否被汙染，由於144.223.234.234不存在，理應沒有任何返回。但我們卻得到了一個錯誤的IP（不確定）。即可證明這個域名已經被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。//////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
//////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
//////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
大概1月21日15:30的時候，Ovear正在除錯新的伺服器，結果發現腫麼突然上不去了。。結果ping了以下，結果發現Ovear的域名都指向到[65.49.2.178]這個IP。Ovear第一反應就是，DNSPOD又被黑了! 為什麼說DNSPOD被黑了呢，其實以前DNSPOD就出過一次類似的問題，導致所有的域名都跪了，剛好Ovear這個域名還有測試的幾個域名都是那裡的，然後就到某交流群吐槽。結果管理員說他們的DNS被汙染了，Ovear心想不會是全國DNS都被汙染了吧。結果烏鴉嘴說中了。還真的是全國劫持。
然後Ovear就很好奇，到底是怎麼回事呢~有誰能做到這樣的事情~於是就有了以下的分析和科普~
—————–以下內容為Ovear家電腦中病毒所致，跟本人無任何關係，謝絕跨省————————
balablabala說了這麼久，肯定有同學問了，窩又不是學計算機的，dns是什麼，跟我有什麼關係!
那麼DNS是什麼呢，Ovear就來科普下。
我們訪問一般是通過域名[Domain]來訪問的，咦DNS怎麼也是D開頭的，難道有關係?說對了!就是有關係:DNS的全稱其實是[Domain Name System]翻譯過來就是域名系統。
在網際網路中，是隻存在IP的，IP其實就是一串數字，相當於你家裡的門牌號，大家在網路中想找到你，必須通過這個，所以IP對於每個人來說是唯一的。但是第四代IP都是http://XXX.XXX.XXX.XXX這樣的，多難記啊，誰會沒事記住IP呢，更何況以後天那麼長的IPV6，要記住不是得要人命!
這時候一個聰明的科學家出來，我們給IP加一個別名，大家通過別名不就可以不記住這個IP，也可以知道這個IP了!於是就有了域名[Domain]這個東西.
當你訪問Ovear's Blog的時候
電腦的DNS解析系統就會自動問DNS伺服器：尼知道Ovear's Blog對應的IP地址是神馬麼?
DNS：窩幫你查查，奧，找到了，IP是[122.10.94.169]. Ovear的電腦：謝啦，再見 DNS：恩
對應現實就是，問知道張三的人：尼知道張三家在哪裡麼? 回答 在南山區 balabalabla。
當然這樣解釋還是不怎麼恰當的，因為一個DNS伺服器是不可能知道所有域名的地址的，因為這需要耗費極大地代價，所以這時候就出現了遞迴DNS和根DNS。
(由於篇幅原因，Ovear就簡單的說一下，其實還是有問題的。Ovear以後再寫一篇文章詳細闡述下DNS的工作原理，或者看[Domain Name System] QAQ)
(補充：QAQ這裡Ovear說的有點過簡單了，其實根DNS(ROOT DNS)指的是全球一共13臺的根DNS，負責記錄各字尾所對應的TOPLEVEL Domain Server[頂級域名根伺服器],然後接下來的就是[權威DNS伺服器]，就是這個域名用的DNS伺服器(可以在whois中看到)
總結一下:
[根伺服器]:全球一共13個A-M[.http://root-servers.net]，儲存著各個字尾域名的[頂級域名根伺服器] [頂級域名根伺服器]：每個字尾對應的DNS伺服器，儲存著該[字尾]所有域名的權威DNS [權威DNS]:這個域名所使用的DNS，比如說我設定的DNSPOD的伺服器，權威DNS就是DNSPOD。在WHOIS(一個檢視域名資訊的東西)中可以看到。儲存著這個域名[對應著的每條資訊] 如IP等~
所以正確的解析過程應該跟下面的圖一樣
使用者使用的DNS(邊緣DNS)->(還會網上推很多級最終到)根DNS->頂級域名根伺服器->權威DNS)
根DNS是什麼呢?大家想想，每個域名都有一個字尾,比如說ovear是[.info]字尾的。那麼就有一個專門記錄[.info]字尾的dns伺服器，其他字尾也一樣。這個DNS就是該域名的根DNS。
那麼遞迴DNS呢?其實遞迴DNS就是一個代理人，是用來緩解[根DNS]壓力的，如果大家都去問[根DNS]，那[根DNS]不早就跪了。畢竟一個人(網站)的地址不是經常變的，所以就有了TTL這一說法，根據DNS的規定，在一個TTL時間呢，大家就認為你家裡(域名所指向的IP)的地址是不會變的，所以代理人[遞迴DNS]在這個時間內，是隻會問一次[根DNS]的，如果你第二次問他，他就會直接告訴你域名所指向的IP地址。這樣就可以解決[根DNS]負載過大的問題啦。
順便這一張圖也可以很準確反映出來之前所說的~
說了這麼久，口水都幹了，那麼DNS到底跟這次事件有什麼關係呢~
首先來看張圖
瓦特!腫麼這麼多域名都指向同一個IP了，這是什麼情況0 0。其實這就是典型的[DNS汙染]了。
我們知道網際網路有兩種協議，一種是TCP，一種則是UDP了(知道泥煤啊(╯‵□′)╯︵┻━┻都說我不是學計算機的了)。
TCP和UDP的主要差別就是：能不能保證傳遞資訊的可靠性。UDP是不管訊息是否到達了目標，也不管通過什麼途徑的，他只管我發出去了就好，所以UDP比TCP快得多，但是可靠性沒有TCP好。
而DNS查詢預設就是用的是UDP，那麼就很好劫持啦。在UDP包任何傳輸的路途上，直接攔截，然後返回給接收端就行了。
嘖嘖，說道這大家也隱隱約約知道這次事件的問題了吧，範圍如此之廣的劫持，必須要在各個省市的主幹網上進行，而能處理這麼大資料，同時能控制這麼多主幹網的。。嘖嘖嘖。。。沒錯!就是***了~至於***是什麼，Ovear在這就不說了，不然可能大家都見不到Ovear了QAQ。
說道這裡，Ovear就準備手動查一下，到底是不是所推測的***呢?於是拿到了這個圖(From XiaoXin)
與此同時運維也在各地的伺服器上開始了跟蹤查詢，發現全國各地解析時間均為25ms左右。這時候結論就出來了。
這樣就明顯了，肯定是***做的了~~於是Ovear又好奇的查了下，這個IP是什麼來頭，為什麼都要指向到這裡去，於是Ovear發現了一些好玩的東西~(65.49.2.0/24)
從側面點出了此次事件的始作俑者。
那麼某FW為什麼要這麼做呢?Ovear在這裡做一個無責任的推測，最有可能的就是：某FW的員工本來是想遮蔽這個IP段的，但是呢一不小心點進去了DNS汙染這個選項，然後又沒寫汙染目標，於是就全域性汙染了嘖嘖嘖~
但是有些童鞋會問了，為什麼他們都說用8.8.8.8就沒事了~
其實這樣子說是不正確的，因為Ovear之前用的就是8.8.8.8，上面也說了DNS查詢預設使用的UDP查詢，所以不管你用什麼，照樣劫持不誤。其實8.8.8.8沒問題是因為汙染事件已經基本結束導致的，那麼為什麼汙染結束後其他國內DNS都不能用，而Goole的DNS確可以正常的使用~於是Ovear就找到了張有趣的圖片~
我先來解釋下上面命令的用途吧~這個命令是用來直接向DNS伺服器查詢域名的~
其中的[-vc]引數是強制使用TCP來查詢DNS伺服器，這樣就可以避免UDP汙染的地圖炮。
那麼為什麼汙染結束後，DNS還會受到汙染呢?其實原因很簡單。Ovear之前說了，[遞迴DNS]是需要詢問[根DNS]的，而預設的詢問方式是採用的UDP，所以在國內的DNS伺服器，自然就受到汙染了。而之前Ovear也提到過TTL這件事~
在TTL週期內，根據協議[遞迴DNS]是直接吧結果快取在自己那，是不會再去查詢[根DNS]的，所以國內的DNS就把錯誤的結果快取起來了~
而Google的DNS伺服器基本都是在國外，所以查詢的時候影響並不大，但是國內挺多域名使用DNSPOD啦，DNSLA的DNS，所以Google進國內查，還是會受到一定影響的。
因此，如果要完全避免這次的影響，有兩個條件
1、你的域名的DNS必須是在國外
2、你查詢的DNS必須在國外，而且如果在汙染期需要通過TCP查詢。
這樣就可以避免這個問題了。
然後Ovear又手賤查了下這次的TTL，嘖嘖
如果沒有人員來手動干預，這次的事件還是要持續蠻久的~。