防DNS汙染方案調研報告
網站被劫持了怎麽辦？
域名是否被墻。
DNS汙染如何檢測。 網站劫持檢測
網站打開速度檢測。
檢測網站是否被黑、被入侵、被改標題、被掛黑鏈。
在G+上碰到了出現DNS相關問題的網友，於是今天又測試了一下DNS的現狀。整個過程很簡單，只需一個命令即可：nslookup
在Windows的命令提示符下測試，基本的格式為：
nslookup DOMAIN DNS_IP
而國內的DNS問題基本分兩種：
一、DNS記錄劫持
DNS記錄劫持是指DNS服務器上的DNS記錄被惡意設定為不正確的內容。DNS劫持是長期的，不經手動更改不會修復。
一類是政策問題導致國內DNS會劫持某些站點，GFW你懂的。而另一類：
ISP為了其自身利益（妨礙訪問競爭對手WZ、植入廣告等等）進行的DNS劫持，這個在國內ISP中普遍存在，都有劫持DNS的能力。特點是，域名解析結果會一股腦的指向同一個IP，下面我們拿我所在的青島聯通的默認DNS（202.102.128.68）試試，得到以下兩類結果：
C:Userscokebar>nslookup baidu.com 202.102.128.68 服務器: ns.sdjnptt.net.cn Address: 202.102.128.68 非權威應答: 名稱: baidu.com.lan Address: 220.250.64.228 C:Userscokebar>nslookup facebook.com 202.102.128.68 服務器: ns.sdjnptt.net.cn Address: 202.102.128.68 非權威應答: 名稱: facebook.com.lan Address: 220.250.64.228 C:Userscokebar>nslookup duowan.com 202.102.128.68 服務器: ns.sdjnptt.net.cn Address: 202.102.128.68 非權威應答: 名稱: duowan.com.lan Address: 220.250.64.228 C:Userscokebar>nslookup taobao.com 202.102.128.68 服務器: ns.sdjnptt.net.cn Address: 202.102.128.68 非權威應答: 名稱: taobao.com.lan Address: 123.129.254.19
一種是全劫持到123.129.254.18/123.129.254.19這兩個地址，經查屬於山東省濟南市聯通
另一種是劫持到220.250.64.228這個地址，經查是北京市聯通
同時域名名稱也在末尾多出了一個”.lan”
至此得出結論，202.102.128.68這個DNS並不是其實際的DNS服務器，他只是完成DNS劫持的使命的。下面分析一下整個的過程：
假如你通過瀏覽器訪問google.com，那麽202.102.128.68向你返回了123.129.254.18，於是你向這個IP發出了相應的打開google.com主頁的請求，而這個請求被123.129.254.18這個服務器收到後，他會根據事先設定的規則判斷，如果規則裏說不對這個域名進行幹擾，那麽你的訪問請求就會被forward到真正的google.com的服務器上去，可能對於大部分網站都屬於這個情況，整個過程比直接返回真實IP慢不了多少，從延遲上肯定分辨不出。
而如果你要訪問的域名在黑名單上，或者你輸入了一個錯誤的不存在的域名，那麽服務器處理的方式就多種多樣了：
1、對於不存在的域名，直接返回一個聯通預定義的提示你“輸入的域名不存在”的網頁，在提示用戶的同時還能植入點廣告可謂是一舉兩得，這個還屬於良性的，比如說我將DNS改為聯通的DNS，隨便敲了個域名，得到下面的頁面：http://nfdnserror17.wo.com.cn:8080/sdjc/self0.jsp?UserUrl=
我們可以ping以下這個不存在的域名來看看到底被指向到哪裏了：
C:Userscokebar>ping dfslaw343412.com
正在 Ping dfslaw343412.com [220.250.64.228] 具有 32 字節的數據:
來自 220.250.64.228 的回復: 字節=32 時間=21ms TTL=247
再ping一下nfdnserror17.wo.com.cn
C:Userscokebar>ping nfdnserror17.wo.com.cn
正在 Ping nfdnserror17.wo.com.cn [220.250.64.228] 具有 32 字節的數據:
來自 220.250.64.228 的回復: 字節=32 時間=20ms TTL=247
可以看到得到的結果正是220.250.64.228這個IP，上面提到了，部分域名被劫持到這個IP。
2、forward到一個不正確的IP地址，導致無法連接服務器或者其他奇怪的現象，通常只針對被特殊照顧的極少數國外站點，比如說twitter可是說是重點照顧，facebook、youtube都沒像twitter那樣有DNS劫持+汙染、封IP、TCP_RESET等那麽全面的封鎖形式。
我們可以試著ping以下twitter看看最終連接到哪裏了：
C:Userscokebar>ping twitter.com
正在 Ping twitter.com [59.24.3.173] 具有 32 字節的數據:
請求超時。
可以看到被指向了59.24.3.173這一無法訪問的IP。我們通過nslookup的-v參數來通過TCP方式查詢google DNS看到真正的地址是199.59.X.X的三個地址：
C:Userscokebar>nslookup -v twitter.com 8.8.8.8
服務器: google-public-dns-a.google.com
Address: 8.8.8.8
非權威應答:
名稱: twitter.com
Addresses: 199.59.148.82
199.59.150.7
199.59.149.198
杯具的是G+同樣遭受聯通的劫持，IPv4被解析到google其他服務器的IP上去了，導致G+無法打開，而在家裏的鐵通網實測是沒有劫持的：
C:Userscokebar>ping plus.google.com
正在 Ping plus.google.com [74.125.39.102] 具有 32 字節的數據:
請求超時。
請求超時。
不過IPv6幸免於難可以連接並正常打開G+：
C:Userscokebar>ping plus.google.com
正在 Ping plus-china.l.google.com [2404:6800:4005:806::1009] 具有 32 字節的數據:
來自 2404:6800:4005:806::1009 的回復: 時間=288ms
來自 2404:6800:4005:806::1009 的回復: 時間=288ms
3、植入廣告。返回一個帶有廣告的網頁並將原網頁嵌套進去，看起來就像你訪問的站點放的廣告一樣，這個其實算違法了，以前這情況挺多，現在還這樣搞的ISP沒那麽多了。
綜上,DNS中間過了這麽一道關後，實際劫不劫持全看ISP自己，雖然多數情況不會發生（被特殊照顧的某些國外網站除外 這些是必劫持），不過還是存在部分域名在部分省市存在劫持現象，影響正常訪問某些站點或者被植入廣告。
解決辦法自不用說，對於多數ISP，如聯通電信，使用114DNS通常沒有問題，將DNS改為114.114.114.114/114.114.115.115，114DNS為各大運營商做DNS記錄備份，號稱無劫持，不過其實某些站點還是有劫持的比如說twitter，不過還好G+是完好的。
[2014.2.27]今天又使用了校園網測試，發現114DNS對於教育網政策不同，存在不解析Google的部分域名，劫持facebook等站點的現象，114DNS也不是最佳方案，對於這些站點還是老老實實掛上代理比較好。
二、DNS記錄汙染
DNS記錄汙染，指的是有人通過惡意偽造身份、利用漏洞等方式，向用戶或者其他DNS服務器提供虛假的DNS記錄。由於DNS記錄存在一個生存期（TTL），在生存期內，DNS保存在緩存中，除非經過了大於一個TTL的時間，或者經手工刷新DNS緩存，虛假的記錄會一直存在下去，並且如果汙染了DNS服務器，這種汙染還具有傳染性。遠程桌面連接軟件
DNS汙染具有暫時性，過了TTL周期，如果不進行再汙染，汙染就會消失。
DNS記錄汙染同劫持的不同之處，在於汙染是對本來正確的DNS查詢結果進行篡改，而劫持是DNS服務器自己把記錄改成錯誤的內容。對於GFW來說，DNS劫持用於國內服務器，而對於國外服務器GFW無法更改其內容，故采用DNS汙染方式篡改用戶收到的信息。
GFW的DNS汙染過程，是當你向國外DNS服務器查詢DNS記錄時候，這些流量走到國外出口處即會遭到GFW的關鍵字審查，如果上了黑名單，GFW會立即向你返回一個虛假的DNS記錄。由於默認的DNS查詢方式是UDP，加上DNS查詢結果只認最快返回的結果，所以你一定是先收到了GFW給你返回的虛假DNS記錄；就算100ms後你收到了真正的來自國外DNS的回復，那也會被你的系統無視掉。如果GFW想徹底汙染一個域名，那麽不只是普通用戶，連國內所有的DNS服務器也會收到虛假的DNS紀錄導致全國性的DNS汙染。
前一段，不明原因的發生了國內大規模的DNS汙染事件，國內大部分站點和部分地區均受到影響無法通過域名訪問。這必定與GFW強大的DNS汙染能力有關。
不過不僅僅是國外出口處DNS記錄可能汙染，各省市的ISP也可能利用現有GFW的技術進行自己的DNS汙染，這種汙染範圍小一些，也是GFW的一環。
防止DNS汙染的方法目前來說就是使用TCP協議代替UDP來進行DNS查詢，因為TCP協議是有連接的協議需要雙方握手成功才能通訊，從而避免GFW這種簡單的DNS汙染方式。目前GFW對於TCP方式的DNS查詢其實已有阻斷能力，但未大規模部署，目前貌似只有dl.dropbox.com會遭遇TCP阻斷：
C:Userscokebar>nslookup -v -d dl.dropbox.com 8.8.8.8
------------
Got answer:
HEADER:
opcode = QUERY, id = 1, rcode = NOERROR
header flags: response, want recursion, recursion avail.
questions = 1, answers = 1, authority records = 0, additional =
QUESTIONS:
8.8.8.8.in-addr.arpa, type = PTR, class = IN
ANSWERS:
-> 8.8.8.8.in-addr.arpa
name = google-public-dns-a.google.com
ttl = 15619 (4 hours 20 mins 19 secs)
------------
服務器: google-public-dns-a.google.com
Address: 8.8.8.8
read failed: Result too large
read failed: Result too large
read failed: Result too large
read failed: Result too large
*** google-public-dns-a.google.com 找不到 dl.dropbox.com: Unspecified error
然而遺憾的是，目前主流的操作系統，如果不借助第三方軟件是無法將系統的DNS查詢方式從默認的UDP改成TCP的，實現起來頗為不便。
下面我們測試一下通過google dns：8.8.8.8來查詢twitter.com的情況：
C:Userscokebar>nslookup -v twitter.com 8.8.8.8
服務器: google-public-dns-a.google.com
Address: 8.8.8.8
非權威應答:
名稱: twitter.com
Addresses: 199.59.148.82
199.59.150.7
199.59.149.198
C:Userscokebar>nslookup twitter.com 8.8.8.8
服務器: google-public-dns-a.google.com
Address: 8.8.8.8
非權威應答:
名稱: twitter.com
Addresses: 59.24.3.173
243.185.187.39
加了-v 參數的nslookup命令是通過TCP查詢的，下面沒有加 -v 的是通過默認UDP查詢的結果，可以看到出現了不同的結果，證明GFW會對twitter.com進行DNS汙染，twitter的汙染估計是全國性的，發生在國際出口處。
同樣，在這裏通過8.8.8.8查詢plus.google.com也出現了DNS汙染，解析出的IP同樣是谷歌的服務器然而並不是提供G+服務的服務器，這樣最直接的現象是無法連接服務器，同時也可能出現下圖這種詭異的現象，而這樣，就偽造出一種是谷歌服務器自己出問題的假象。
另：關於IPv6下狀況的討論
去年下半年，我在青島這邊測試，曾出現針對IPv6的非常嚴格的DNS劫持，並在不久後加入了DNS汙染，後來甚至加入了極為嚴格的關鍵字審查策略，導致google許多頁面遭遇tcp_reset，不過目前又逐步和IPv4的策略保持一致了。我當時測試的一個圖，分別用IPv4和IPv6來ping G+：
IPv6時候返回了一個非常奇葩的[10::2222]的IPv6地址，假到離譜… 實測IPv6下也存在針對DNS的汙染，而且會汙染到比較奇葩的IP上：
C:Userscokebar>nslookup plus.google.com 2001:4860:4860::8888
服務器: google-public-dns-a.google.com
Address: 2001:4860:4860::8888
名稱: plus.google.com.lan
Addresses: 2001:da8:112::21ae
1.1.1.1
C:Userscokebar>nslookup -v plus.google.com 2001:4860:4860::8888
服務器: google-public-dns-a.google.com
Address: 2001:4860:4860::8888
非權威應答:
名稱: plus-china.l.google.com
Addresses: 2404:6800:4005:804::1006
74.125.31.102
74.125.31.139
74.125.31.100
74.125.31.113
74.125.31.138
74.125.31.101
Aliases: plus.google.com
而聯通DNS和學校的DNS的狀況都是只對IPv4做了劫持，IPv6無事：
C:Userscokebar>nslookup plus.google.com 2001:da8:7007:107::77
服務器: ns2.dnscache.upc.edu.cn
Address: 2001:da8:7007:107::77
非權威應答:
名稱: plus-china.l.google.com
Addresses: 2404:6800:4005:c00::66
74.125.39.102
Aliases: plus.google.com
不過目前GFW對IPv6的研究不足還無法做到像IPv4上那樣的方式屏蔽youtube和facebook，開了https，規避了關鍵字審查後就能通過IPv6正常瀏覽了，而IPv4下就算你開了https你也上不了。
總結
DNS這種方式在設計出來後就遺留給了我們這樣那樣的安全問題，要偽造DNS記錄太簡單了，讓其成為了GFW前期封殺網站的得力手段。不過通過DNS封殺風險也不小，出國前不久的全國性DNS汙染事件，還有更早些時候GFW汙染了國外DNS服務器導致某些國外國家無法正常上網的事件。同樣DNS也是ISP植入廣告、屏蔽競爭對手網站的給力方式。
就目前來說，對於聯通、電信、移動之類的多數ISP，使用114DNS是較好的解決方案，在規避ISP惡意劫持DNS的同時，保證了像G+這樣的能直連的google服務器的訪問，而google DNS建議棄用吧，不像前幾年好用了，現在一來可能會遭遇DNS汙染，二來google dns對國內某些CDN的支持可能不是太好，三來ping比較高。
如果是教育網等一些用114DNS仍然會有劫持的用戶，可以考慮使用dns代理，這樣可以保證谷歌站點的直連，而其他被墻站點多數不僅僅是dns問題，仍然需要掛代理解決
防DNS汙染方案調研報告