定義
某些網路運營商為了某些目的，對DNS進行了某些操作，導致使用ISP的正常上網設定無法通過域名取得正確的IP位址。
某些國家或地區出於某些目的為了防止某網站被訪問，而且其又掌握部分國際DNS根目錄伺服器或鏡像，也會利用此方法進行禁止。
常用的手段有：DNS劫持和DNS污染。
常用方法
對於運營商，網路管理員等人，尤其是在辦公室等地方，管理員希望網路使用者無法瀏覽某些與工作無關的網站，通常採用DNS搶答機制。機器查詢DNS時，採用的是UDP協定進行通訊，佇列的每個查詢有一個id進行標識。
查詢
| 源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）每一個請求都有一個回應。
奇怪的查詢
| 源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。下面我們就來講述一下這個的實現方法。
原理解析
我們假設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解析就行了。在地址欄中輸入：
about:config
找到network.proxy.socks_remote_dns一項改成true。
5、使用DNSCrypt軟體，此軟體與使用的OpenDNS直接建立相對安全的TCP連線並加密請求數據，從而不會被污染。
