簡單說，就是用戶端發起正常的一次dns請求，得到的确是一個異常或者不真實的dns資訊。一般造成這樣的情況，很有可能dns資訊在某個環節被通過某種方式篡改。
主要的方式，可以歸納為如下兩種：
方式一、攻擊者監測到dns查詢的請求封包時，僞裝成dns伺服器向送出請求主機發送響應封包。因為dns封包通常是無連接配接的udp封包，沒有确認機制，源主機不能識别出這個封包并非出自dns伺服器。攻擊者并不需要丢棄真正dns伺服器發回來的響應封包，因為dns的機制會導緻源主機隻接受最先到達的響應封包（甚至不管是誰發的）而忽略後繼到達的其他封包。這樣，源主機得到的就是攻擊者僞造的域名解析結果。
條件：1、攻擊者能截獲客戶的資料包。2、能最短時間接替傳回消息
方式二、本地dns伺服器的緩存已受到污染，裡面緩存的是錯誤的結果。dns伺服器通常将dns查詢的結果緩存在本地一段時間，這本意是為了減少重複dns查詢，進而降低dns封包占用的網絡帶寬。可如果某次dns查詢的結果受到污染，則後繼一段時間内向該dns伺服器查詢的結果都會受到污染。
條件：1、本地dns存在攻擊漏洞 2、本地dns成為被污染的對象
我們可以拿通路google 、facebook來示範：
[email protected]:/opt# nslookup www.google.com 8.8.8.8 #使用nds8.8.8.8 解析 www.google.com
server:8.8.8.8
address:8.8.8.8#53
non-authoritative answer:
name:www.google.com
address: 37.61.54.158
[email protected]:/opt# nslookup -vc www.google.com 8.8.8.8 #同樣，不過改使用tcp的方式解析
address: 216.58.221.228
＃我們再同樣查查臉書
[email protected]:/opt# nslookup www.facebook.com 8.8.8.8
name:www.facebook.com
address: 37.61.54.158 #發現什麼了？dns受到了污染。
我們仔細來查查這個什麼玩意位址37.61.54.158
下面是一個正常的google位址傳回，因該如下：