鮮爲人知的網絡編程(九)：理論聯繫實際，全方位深刻理解DNS

本文原做者：selfboot，博客地址：selfboot.cn，Github地址：github.com/selfboot，感謝原做者的技術分享。

一、引言

對於 DNS(Domain Name System) 你們確定不陌生，不就是用來將一個網站的域名轉換爲對應的IP嗎。當咱們發現能夠上QQ但不能瀏覽網頁時，咱們會想到多是域名服務器掛掉了；當咱們用別人提供的hosts文件瀏覽到一個「不存在」的網頁時，咱們會了解到域名解析系統的脆弱。

然而關於DNS還有一大堆故事值得咱們去傾聽，去思考。

（本文同步發佈於：http://www.52im.net/thread-27...）

二、系列文章

本文是系列文章中的第9篇，本系列文章的大綱以下：

《鮮爲人知的網絡編程(一)：淺析TCP協議中的疑難雜症(上篇)》
《鮮爲人知的網絡編程(二)：淺析TCP協議中的疑難雜症(下篇)》
《鮮爲人知的網絡編程(三)：關閉TCP鏈接時爲何會TIME_WAIT、CLOSE_WAIT》
《鮮爲人知的網絡編程(四)：深刻研究分析TCP的異常關閉》
《鮮爲人知的網絡編程(五)：UDP的鏈接性和負載均衡》
《鮮爲人知的網絡編程(六)：深刻地理解UDP協議並用好它》
《鮮爲人知的網絡編程(七)：如何讓不可靠的UDP變的可靠？》
《鮮爲人知的網絡編程(八)：從數據傳輸層深度解密HTTP》
《鮮爲人知的網絡編程(九)：理論聯繫實際，全方位深刻理解DNS》（本文）

三、參考資料

《DNS cache poisoning》
《DNS Spoofing vs DNS Cache Poisoning》
《Reset the DNS cache in OS X》
《人爲網絡故障》
《DNS欺騙原理及工做工程分析》
《全面瞭解移動端DNS域名劫持等雜症：技術原理、問題根源、解決方案等》
《美圖App的移動端DNS優化實踐：HTTPS請求耗時減少近半》
《百度APP移動端網絡深度優化實踐分享(一)：DNS優化篇》

四、DNS 源起

要想訪問網絡上的一臺計算機，咱們必需要知道它的IP地址，可是這些地址（好比243.185.187.39）只是一串數字，沒有規律，所以咱們很難記住。而且若是一臺計算機變動IP後，它必須通知全部的人。

顯然，直接使用IP地址是一個愚蠢的方案。因而人們想出了一個替代的方法，即爲每一臺計算機起一個名字，而後創建計算機名字到地址的一個映射關係。咱們訪問計算機的名字，剩下的名字到地址的轉換過程則由計算機自動完成。

4.1 hosts映射
早期，名字到地址的轉換過程十分簡單。每臺計算機保存一個hosts文件，裏面列出全部計算機名字和對應的IP地址，而後按期從一個維護此文件的站點更新裏面的記錄。當咱們訪問某個計算機名字時，先在hosts文件找到對應的IP，而後就能夠創建鏈接。

▲ hosts 管理主機

早期的 ARPANET 就是這樣作的，可是隨着網絡規模的擴大，這種方法漸漸吃不消了。

主要有如下三個緣由：

1）hosts文件變得很是大；
2）主機名字會衝突；
3）集中的維護站點會不堪重負（須要給幾百萬機器提供hosts文件，想一想就可怕）。

4.2 域名系統

爲了解決上面的問題，1983年Paul Mockapetris提出了域名系統（DNS, Domain Name System)，這是一種層次的、基於域的命名方案，而且用一個分佈式數據庫系統加以實現。當咱們須要訪問一個域名（其實就是前面說的計算機的名字）時，應用程序會向DNS服務器發起一個DNS請求，DNS服務器返回該域名對應的IP地址。

人物介紹：保羅·莫卡派喬斯（Paul V. Mockapetris）：

保羅·莫卡派喬斯是發明Domain Name System (DNS域名系統)體系結構的RFCs882和883技術創始人和計算機科學家，同時也是現代Internet的奠定者之一。他在1983年的第882和在南加州大學裏資訊科學研究院所提出的883號因特網標準草案中提出DNS的架構。他發現了早期因特網，包括阿帕網中基於單個主機單一層面上的域名-IP地址轉換的缺陷，並提議將其改進爲分佈式和動態的數據庫域名系統,也就是咱們今天所用的域名系統的雛形。在2005年，他得到了ACM（美國計算機協會）數據通訊專業組終身成就獎。

經過下面三種手段解決了上面的問題：

1）用戶計算機上並無存儲全部的名字到IP的映射，這樣避免了hosts文件過於龐大（如今各操做系統中hosts文件默認都是空的）；
2）規定了域名的命名規則，保證主機名字不會重複；
3）DNS服務器再也不是單一的一臺機器，而是一個層次的、合理組織的服務器集羣。

這樣訪問一個域名的過程能夠簡化爲下圖：

▲ 域名hosts解析過程

五、DNS 協議

那麼如何具體實現這個所謂的域名系統呢，要知道管理一個超大型而且不斷變化的域名到IP的映射集合可不是一個簡單的事，何況還要去應付成千上萬的DNS查詢請求。人們最終想出了一套不錯的協議，規定如何來實現這個系統，下面咱們一塊兒來看看吧。

5.1 域名空間

首先咱們須要制定一套命名規則，防止域名出現重複。DNS關於域名的規則和咱們生活中的快遞系統相似，使用層次的地址結構。快遞系統中要給某人郵寄物品，地址多是這樣：中國、廣東省、廣州市、番禺區、中山西路12號 XXX。而一個域名看起來則是這樣的groups.google.com（爲何不是com.google.groups？我猜可能和老外寫地址的習慣有關）。

對於Internet來講，域名層次結構的頂級（至關於國際快遞地址中的國家部分）由ICANN（互聯網名稱與數字地址分配機構）負責管理。目前，已經有超過250個頂級域名，每一個頂級域名能夠進一步劃爲一些子域（二級域名），這些子域可被再次劃分（三級域名），依此類推。

全部這些域名能夠組織成一棵樹，以下圖所示：

▲ 域名空間樹

5.2域名資源記錄

DNS設計之初是用來創建域名到IP地址的映射，理論上對於每個域名咱們只須要在域名服務器上保存一條記錄便可。

這裏的記錄通常叫做域名資源記錄，它是一個五元組，能夠用如下格式表示：

Domain_name Time_to_live Class Type Value

其中：

1）Domain_name: 指出這條記錄適用於哪一個域名；
2）Time_to_live: 用來代表記錄的生存週期，也就是說最多能夠緩存該記錄多長時間（後面會講到緩存機制）；
3）Class: 通常老是IN；
4）Type: 記錄的類型；
5）Value: 記錄的值，若是是A記錄，則value是一個IPv4地址。

咱們看到域名資源記錄有一個Type字段，用來代表記錄的類型。這是爲何呢？由於對於一個域名來講，一般並不是只記錄其IP地址，還可能須要一些其餘種類的記錄。

一些常見的記錄類型以下：

關於這些域名資源記錄的實例咱們將在文章後半部分看到。

5.3 域名服務器

咱們知道不能只用一臺域名服務器來響應全部的DNS查詢，由於沒有一臺機器可以給全球的用戶提供查詢服務，計算能力、存儲、帶寬都不容許。只能合理組織一個域名服務器集羣，使他們協同工做，共同提供域名解析服務。接下來首先要面對的一個問題是：如何合理地將全部的域名資源記錄存儲到不一樣的域名服務器上。

前面說過域名的名字空間能夠組織爲一棵樹，這裏咱們能夠進一步將其劃分爲不重疊的區域（DNS zone）。

針對上圖的域名空間，一種可能的域名劃分以下圖：

▲ 域名劃分

而後將每一個區域與多個域名服務器（其中一個是master，其餘slave服務器則用來提供數據備份、加快解析速度、保證服務可用性）關聯起來，稱這些域名服務器爲該區域的權威域名服務器(Authoritative Name Servers )。

它保存兩類域名資源記錄：

1）該區域內全部域名的域名資源記錄；
2）父區域和子區域的域名服務器對應的域名資源記錄（主要是NS記錄）。

這樣，全部的域名資源記錄都保存在多個域名服務器中，而且全部的域名服務器也組成了一個層次的索引結構，便於咱們後面進行域名解析。下面以一個簡化的域名空間爲例子，說明域名資源記錄是如何保存在域名服務器中的。

以下圖a：

▲ 域名服務器

圖中域名空間劃分爲A, B, C, D, E, F, G七個DNS區域，每一個DNS區域都有多個權威域名服務器，這些域名服務器裏面保存了許多域名解析記錄。對於上圖的NDS區域E來講，它的權威域名服務器裏面保存的記錄如圖中表格所示。

仔細觀察上圖你可能會發現區域A、B並無父區域，他們之間並無一條路徑連在一塊兒。這將致使一個很麻煩的問題，那就是區域A的權威域名服務器可能根本不知道區域B的存在。認識到這一點後，你可能會想出一個很天然的解決方案，就是在A中記錄B域名服務器的地址，同時在B中記錄A的，這樣它們兩個就聯繫起來了。可是考慮到咱們有超過250個頂級域名，這樣作並非很恰當。

而咱們使用的域名系統則採用了一種更加聰明的方法，那就是引入根域名服務器，它保存了全部頂級區域的權威域名服務器記錄。如今經過根域名服務器，咱們能夠找到全部的頂級區域的權威域名服務器，而後就能夠往下一級一級找下去了。

下圖爲全球根域名服務器的分佈圖：

（本圖的清晰大圖，來自：http://www.root-servers.org/）

如今爲止，咱們的權威域名服務器和根域名服務器其實組成了一個樹，樹根爲根域名服務器，下面每一個節點都是一個區域的權威域名服務器，對於圖a中各個DNS區域的權威域名服務器，它們組成了下面這棵樹（實際中，一個權威域名服務器可能保存有多個DNS區域的記錄，所以權威域名服務器之間的聯繫並不構成一棵樹。這部分的詳細內容能夠參考RFC 1034: 4. NAME SERVERS。

下面爲了容易理解，將其簡化爲一棵樹）：

5.4 域名解析

咱們已經有了一個域名服務器集羣，該集羣合理地保存了域名空間和域名資源記錄的對應關係。如今咱們要作的就是發送一個DNS請求給域名服務器，而後坐等它返回正確的域名資源記錄，這個過程叫做域名解析。

嚴格來講，域名解析的過程最先要追溯到創建網絡鏈接。由於每當鏈接上網絡以後，計算機會自動得到一個默認的DNS服務器，固然你也能夠用本身信任的DNS服務器，好比8.8.8.8（DNS服務器也有信任不信任之分，是的，實踐篇會講到），咱們把這個域名服務器也叫做本地域名服務器。接下來當咱們須要知道一個域名對應的資源記錄時，會向本地域名服務器發起請求，若是該域名剛好在本地域名服務器所轄屬的域名區域（DNS zone）內，那麼能夠直接返回記錄。

若是在本地域名服務器沒有發現該域名的資源記錄，就須要在整個域名空間搜索該域名。而整個域名空間的資源記錄存儲在一個分層的、樹狀聯繫的一系列域名服務器上，因此本地域名服務器首先要從根域名服務器開始往下搜索。這裏有一個問題就是：本地域名服務器如何找到根域名服務器在哪裏呢？其實域名服務器啓動的時候，就會加載一個配置文件，裏面保存了根域名服務器的NS記錄（要知道根域名服務器地址通常很是穩定，不會輕易改變，而且數量不多，因此這個配置文件會很小）。找到根域名服務器以後，就能夠一級一級地往下查找啦。

仍然以咱們的圖a爲例，如今假設區域E內的某個用戶想訪問math.sysu.edu.cn，那麼請求的過程以下：

用語言簡單描述以下：

1）用戶：喂，本地域名服務器，告訴我math.sysu.edu.cn的地址；
2）本地域名服務器：哎呀，我不知道啊，不在個人轄區，容我去問問老大哥吧。root老大，能告訴我math.sysu.edu.cn的地址嗎；
3）根域名服務器：忙着呢，你去問B（.cn）；
4）本地域名服務器：喂，B，告訴我math.sysu.edu.cn的地址；
5）B：你去問D（.edu.cn）；
6）本地域名服務器：喂，D，告訴我math.sysu.edu.cn的地址；
7）D：你去問F（sysu.edu.cn）；
8）本地域名服務器：喂，F，告訴我math.sysu.edu.cn的地址；
9）F：容老衲看看，哎呀，找到了，是X.X.X.X；
10）本地域名服務器：踏破鐵鞋終於找到啦，喂用戶，出來啊，我找到了，是X.X.X.X。

仔細想一想，這和咱們郵寄快遞實在是一模一樣啊，假設你從美國郵東西到廣州市番禺區，首先快遞送到中國（不過這裏沒有一個相似根域名服務器的中轉站而已），而後往下到廣東省，接下來是廣州市，再往下是番禺了。

上面的是本地域名服務器的迭代解析過程，其實也能夠遞歸查詢，這裏就不說了，道理差很少。

六、緩存機制

如今整個域名系統已經能夠爲咱們提供域名解析服務了，當咱們輸入域名，計算機發送DNS請求，而後DNS服務器返回給咱們解析的結果，一切看起來很完美。然而是否是能夠更完美呢？

回顧一下平時瀏覽網站的狀況，咱們會發現兩個比較有意思的結論：

1）80%的時間咱們都在看那些20%的網站，這就是大名鼎鼎的 80/20 Rule；
2）咱們會在一個網站的不一樣網頁之間跳轉，也就是不斷地訪問同一個域名，相似程序訪問的局部性原理。

這兩條結論很容易讓咱們聯想到緩存機制。若是咱們將已經訪問過的那些域名的解析結果緩存在本身的計算機上，那麼下次訪問的時候能夠直接讀取結果，不用再次重複DNS查詢過程，給本身和域名服務器都節省了麻煩。

固然，這樣作的一個前提是要緩存的解析結果不會頻繁更改，也就是說我十分鐘後解析一個域名的結果和如今解析的結果是同樣的。對大多數域名來講，這都是一個不爭的事實。可是不免有一些「善變」的域名，他們可能會頻繁更改本身的解析結果。爲了使緩存機制適應這兩類狀況，咱們在域名資源記錄裏面添加一個 Time_to_live 字段，代表這條記錄最多能夠緩存多久。對於那些「穩如泰山」的域名，給一個比較大的值，而那些「朝秦暮楚」的域名，則能夠給定一個小的值。

咱們既然能夠在本機利用緩存，那麼可不能夠在域名服務器上也利用緩存機制呢，答案固然是能夠的。由於對於域名服務器來講，上面的兩條有意思的結論仍然有效。因此，域名服務器能夠將那些訪問過的域名資源記錄緩存，用戶再次發起請求時，能夠直接返回緩存結果，不用去迭代或者遞歸解析。

關於DNS理論部分，更多內容還能夠參考這兩個文本：《RFC 1034: Domain Names - Concepts and Facilities》。

七、文章並無結束

在上面的理論內容章節裏，咱們基本瞭解了DNS的整個協議原理。

可是可能還會有着下面的疑問：

1）爲何我想申請的域名都沒了？
2）DNS 域名還要備案，這是爲何啊？
3）如何將剛申請的域名綁定到本身的網站呢？
4）怎麼才能看到那些在背後默默給我解析的域名服務器呢？
5）他們說用一個什麼文件就能夠訪問好多好多不存在的網站，是真的嗎？
6）可信任的域名服務器是怎麼一回事，難道有些域名服務器會作壞事？
7）怎麼知道我如今用的域名服務器有沒有使壞呢？
8）……

我不許備一個一個地去回答這些問題，不過相信我，讀完下面的內容，對於上面問題的答案你會有一個清晰的認識，而且能夠解決其餘各類各樣關於 DNS 方面的問題。

八、域名註冊、綁定

首先明確一點，每一個人均可以去註冊域名。大多數時候咱們但願去註冊一個頂級域名（好比52im.net、google.com等），那些二級域名畢竟不夠好記（好比github託管博客的域名：username.github.io）。有的頂級域名（好比.tk域名）提供免費的一年域名試用，不過絕大多時候仍是要爲本身的域名付費的（通常是按年付費，也不是很貴）。要想去註冊域名，首先得找到域名註冊商，國內的比較著名的有萬網等（PS：萬網已被阿埋裏收購了），國外的有godaddy等。相信註冊過域名的人都知道絕大多數咱們能想到的本身喜歡的域名都已名花有主了，只剩那些不是那麼惹人關注的域名供咱們選擇。因此，註冊域名時，發現本身每想到一個域名都顯示被人註冊後，那太正常不過了，說明你的品味比較正常。

這裏一點我的建議，選中一個域名後不要輕易去改了，由於換域名成本挺高的（我猜如今就算給淘寶一千萬，它也不會換另成一個域名吧）。因此，最好不要去用免費的域名，由於指不定啥時候就不讓你用了。你應該相信這麼一個觀點：天下沒有免費的午飯。拓展一下就是，掏錢買服務，內心踏實。

接下來你可能會但願將本身的站點或者博客掛在本身選中的域名下，這其實很簡單，只須要找到一個提供域名解析的服務商，而後填寫相應的域名解析記錄。大多時候，你註冊域名的服務商都會免費提供域名解析服務。

現實中，大部分人可能會擁有我的博客，之前咱們都是依賴一個博客平臺（如CSDN），或者是買一臺VPS託管本身的博客。不過自從Github推出了Blog服務，好多程序員都轉而將博客託管在上面。Github Blog支持綁定我的域名，並提供了詳細的綁定文檔：Adding a CNAME file to your repository。假設你的博客已經能夠經過 username.github.io 訪問，接下來只須要用 CNAME 告訴Github你的博客綁定了哪一個域名（好比說是selfboot.cn），而後在域名解析商那裏添加解析記錄便可。

下圖是我我的博客在DNSpod的解析記錄：

▲ 域名解析記錄

如今當咱們訪問 selfboot.cn 時，DNSpod就會將請求解析到 Github 提供的 IP 地址上。以後 Github 上面的博客託管服務器在全部用戶的 CNAME 記錄中，找到本次請求的域名對應的博客項目地址，好比說是 xuelangZF.github.io，而後返回博客內容。

九、域名解析

咱們都知道一個域名的解析過程當中，可能會有多臺域名服務器給咱們幫助，那麼咱們怎麼能看到這些背後的功臣呢？先介紹兩個經常使用的關於DNS的命令。

9.1 dig和nslookup命令

dig(Domain Information Groper), 是 UNIX/BSD 系統自帶的 DNS 診斷工具，使用十分靈活、方便。

查詢 selfboot.cn 的A記錄，並返回簡短的結果：
$ dig selfboot.cn -t A +short
192.30.252.153
192.30.252.154

用 dig 還能夠查詢某一 ip 對應的域名，以下：
$ dig -x 192.30.252.153 +short
pages.github.com.

這裏返回的是pages.github.com，由於當你訪問博客地址 selfboot.cn 時，實際上是Github的pages 服務器（域名是：pages.github.com）在後臺返回該博客內容的（根據 CNAME 肯定返回哪一個博客）。

nslookup 也是一個 DNS 診斷工具，幾乎全部平臺都自帶該工具，使用也很簡答，能夠用 man 查詢手冊。

9.2 解析路徑查詢

接下來用 dig 命令查看從根域名到指定域名中間可能通過的全部域名服務器，使用 +trace 選項便可。
dig selfboot.cn +trace @8.8.8.8
; <<>> DiG 9.8.3-P1 <<>> selfboot.cn +trace @8.8.8.8
;; global options: +cmd
. 474418 IN NS j.root-servers.net.
. 474418 IN NS g.root-servers.net.
......
. 474418 IN NS l.root-servers.net.
. 474418 IN NS m.root-servers.net.
;; Received 496 bytes from 8.8.8.8#53(8.8.8.8) in 12 ms
cn. 172800 IN NS a.dns.cn.
......
cn. 172800 IN NS e.dns.cn.
cn. 172800 IN NS ns.cernet.net.
;; Received 292 bytes from 2001:500:1::803f:235#53(2001:500:1::803f:235) in 382 ms
selfboot.cn. 86400 IN NS f1g1ns2.dnspod.net.
selfboot.cn. 86400 IN NS f1g1ns1.dnspod.net.
;; Received 83 bytes from 203.119.25.1#53(203.119.25.1) in 816 ms
selfboot.cn. 14400 IN A 192.30.252.153
selfboot.cn. 14400 IN A 192.30.252.154
selfboot.cn. 600 IN NS f1g1ns1.dnspod.net.
selfboot.cn. 600 IN NS f1g1ns2.dnspod.net.
;; Received 125 bytes from 115.236.137.40#53(115.236.137.40) in 31 ms

能夠看到最開始是13臺頂級域名服務器的NS記錄（中間省去一些記錄減小行數，方便觀察更清楚），接下來是頂級域名 cn. 的權威域名服務器（省略一些輸出），而後是 selfboot.cn 的 NS 記錄，即 DNSpod 的兩條 NS 記錄，最後從 f1g1ns2.dnspod.net 找到 selfboot.cn 的 A 記錄。

seveas 提供了一個可視化的路徑查詢工具：dnsgraph，能夠在線繪製跟域名到指定域名的全部可能路徑。

固然，實際查詢過程當中，大多時候咱們在本地緩存或者本地域名服務器緩存就能直接找到須要的域名記錄，不須要每次都向根域名服務器發起請求，而後重複迭代或者遞歸查詢過程。

十、DNS目前存在的缺陷

域名系統設計的很理想很美好，然而仍有一些小的瑕疵，可能會給咱們帶來些許困擾。

10.1 域名搶注

首先，有些域名對註冊人沒有限制，而另一些域名則對誰能夠獲得一個域名空間中的名字有限制。好比pro域名是分配給合適的專業人員，但問題是誰纔是專業的呢？顯然醫生、工程師是專業人員，但理髮師、管道工呢？

此外，域名也能夠被倒賣。黃牛們會批量註冊大量域名（聽說com域名下幾乎每個普通詞都被人嘗試註冊了域名），而後轉身就以高價轉賣給那些對該域名感興趣的人，這就是所謂的域名搶注。因此，如今你想註冊一個符合本身網站特色的域名是很難的。

這個問題其實還不算嚴重，更要命的是下面兩個問題。

10.2 DNS 劫持

咱們知道一個域名服務器對其區域內的用戶解析請求負責，可是並無一個機制去監督它有沒有真地負責。也就是說域名服務器的權力並無被關在籠子裏，因此它既能夠認真地「爲人民服務」，也能夠混淆是非。因而有些流氓的域名服務器故意更改一些域名的解析結果，將用戶引向一個錯誤的目標地址。這就叫做 DNS 劫持，主要用來阻止用戶訪問某些特定的網站，或者是將用戶引導到廣告頁面。

▲ DNS 劫持原理

下面驗證下我所用的域名服務器有沒有幹這種壞事，只須要一條簡單的命令便可：
➜ ~ nslookup google.com
Server: 10.8.4.4
Address: 10.8.4.4#53
Non-authoritative answer:
Name: google.com
Address: 120.196.0.5

個人DNS服務器地址爲10.8.4.4，他告訴我google.com的地址是120.196.0.5，我纔不信呢。因而用whois 120.196.0.5一看，果然不是Google的地址。針對DNS劫持，咱們能夠簡單地更換域名服務器，比較靠譜的一個是Google提供的8.8.8.8。下面用 8.8.8.8 來解析一下 www.google.com 就能看到正確的地址了。

$ nslookup [url=http://www.google.com]www.google.com[/url] 8.8.8.8
Server: 8.8.8.8
Address: 8.8.8.8#53
Non-authoritative answer:
Name: [url=http://www.google.com]www.google.com[/url]
Address: 216.58.221.68

更多關於DNS劫持這方面的內容，能夠詳見：《全面瞭解移動端DNS域名劫持等雜症：技術原理、問題根源、解決方案等》。

10.3 DNS 欺騙

DNS 劫持經過簡單的切換域名服務器就能夠繞過，不過一旦你趕上了 DNS 欺騙，就沒法簡單地繞過了。下面咱們用不一樣的域名服務器來查看 fb 的 IP 地址，結果都返回了同一個地址，看起來好像是真的同樣，不過也僅僅是看起來而已。

$ nslookup facebook.com
Server: 10.8.4.4
Address: 10.8.4.4#53
Non-authoritative answer:
Name: facebook.com
Address: 159.106.121.75
$ nslookup facebook.com 8.8.8.8
Server: 8.8.8.8
Address: 8.8.8.8#53
Non-authoritative answer:
Name: facebook.com
Address: 159.106.121.75

這個地址並非 fb 的服務器地址（能夠在 ViewDNS 查詢全部域名真實的域名資源記錄，ViewDNS 是個很好玩的網站，裏面有許多有意思的工具）。其實我Google了一下這個地址，居然發現了一篇不錯的 譯文 ，看來這個地址早在 2011 年就有了特殊的含義（英文原文是相關閱讀第一個）。

DNS 欺騙簡單來講就是用一個假的 DNS 應答來欺騙用戶計算機，讓其相信這個假的地址，而且拋棄真正的 DNS 應答。在一臺主機發出 DNS 請求後，它就開始等待應答，若是此時有一個看起來正確（擁有和DNS請求同樣的序列號）的應答包，它就會信覺得真，而且丟棄稍晚一點到達的應答。

▲ DNS欺騙原理

實施 DNS 欺騙的關鍵在於僞造一個有特定序列號的應答包，而且讓其搶先一步到達發起請求的主機。這對於我的來講還有點難度，可是對於擁有骨幹網節點的組織來講，實在是易如反掌，因此這麼多網站都已淪陷。不過使用網上流傳的那些 hosts文件，就能夠在本機緩存許多網站的ip地址，進而能夠和部分網站通訊。可是經過hosts文件並不能徹底 Cross the Great FireWall，由於人家還有不少其餘手段。

附錄：更多網絡編程基礎資料

《TCP/IP詳解 - 第11章·UDP：用戶數據報協議》
《TCP/IP詳解 - 第17章·TCP：傳輸控制協議》
《TCP/IP詳解 - 第18章·TCP鏈接的創建與終止》
《TCP/IP詳解 - 第21章·TCP的超時與重傳》
《技術往事：改變世界的TCP/IP協議（珍貴多圖、手機慎點）》
《通俗易懂-深刻理解TCP協議（上）：理論基礎》
《通俗易懂-深刻理解TCP協議（下）：RTT、滑動窗口、擁塞處理》
《理論經典：TCP協議的3次握手與4次揮手過程詳解》
《理論聯繫實際：Wireshark抓包分析TCP 3次握手、4次揮手過程》
《計算機網絡通信協議關係圖（中文珍藏版）》
《UDP中一個包的大小最大能多大？》
《P2P技術詳解(一)：NAT詳解——詳細原理、P2P簡介》
《P2P技術詳解(二)：P2P中的NAT穿越(打洞)方案詳解》
《P2P技術詳解(三)：P2P技術之STUN、TURN、ICE詳解》
《通俗易懂：快速理解P2P技術中的NAT穿透原理》
《高性能網絡編程(一)：單臺服務器併發TCP鏈接數到底能夠有多少》
《高性能網絡編程(二)：上一個10年，著名的C10K併發鏈接問題》
《高性能網絡編程(三)：下一個10年，是時候考慮C10M併發問題了》
《高性能網絡編程(四)：從C10K到C10M高性能網絡應用的理論探索》
《高性能網絡編程(五)：一文讀懂高性能網絡編程中的I/O模型》
《高性能網絡編程(六)：一文讀懂高性能網絡編程中的線程模型》
《技術掃盲：新一代基於UDP的低延時網絡傳輸層協議——QUIC詳解》
《讓互聯網更快：新一代QUIC協議在騰訊的技術實踐分享》
《現代移動端網絡短鏈接的優化手段總結：請求速度、弱網適應、安全保障》
《聊聊iOS中網絡編程長鏈接的那些事》
《移動端IM開發者必讀(一)：通俗易懂，理解移動網絡的「弱」和「慢」》
《移動端IM開發者必讀(二)：史上最全移動弱網絡優化方法總結》
《IPv6技術詳解：基本概念、應用現狀、技術實踐（上篇）》
《IPv6技術詳解：基本概念、應用現狀、技術實踐（下篇）》
《從HTTP/0.9到HTTP/2：一文讀懂HTTP協議的歷史演變和設計思路》
《以網遊服務端的網絡接入層設計爲例，理解實時通訊的技術挑戰》
《邁向高階：優秀Android程序員必知必會的網絡基礎》
《Android程序員必知必會的網絡通訊傳輸層協議——UDP和TCP》
《IM開發者的零基礎通訊技術入門(一)：通訊交換技術的百年發展史(上)》
《IM開發者的零基礎通訊技術入門(二)：通訊交換技術的百年發展史(下)》
《IM開發者的零基礎通訊技術入門(三)：國人通訊方式的百年變遷》
《IM開發者的零基礎通訊技術入門(四)：手機的演進，史上最全移動終端發展史》
《IM開發者的零基礎通訊技術入門(五)：1G到5G，30年移動通訊技術演進史》
《IM開發者的零基礎通訊技術入門(六)：移動終端的接頭人——「基站」技術》
《IM開發者的零基礎通訊技術入門(七)：移動終端的千里馬——「電磁波」》
《IM開發者的零基礎通訊技術入門(八)：零基礎，史上最強「天線」原理掃盲》
《IM開發者的零基礎通訊技術入門(九)：無線通訊網絡的中樞——「核心網」》
《IM開發者的零基礎通訊技術入門(十)：零基礎，史上最強5G技術掃盲》
《IM開發者的零基礎通訊技術入門(十一)：爲何WiFi信號差？一文即懂！》
《IM開發者的零基礎通訊技術入門(十二)：上網卡頓？網絡掉線？一文即懂！》
《IM開發者的零基礎通訊技術入門(十三)：爲何手機信號差？一文即懂！》
《IM開發者的零基礎通訊技術入門(十四)：高鐵上無線上網有多難？一文即懂！》
《IM開發者的零基礎通訊技術入門(十五)：理解定位技術，一篇就夠》
《技術大牛陳碩的分享：由淺入深，網絡編程學習經驗乾貨總結》
《可能會搞砸你的面試：你知道一個TCP鏈接上能發起多少個HTTP請求嗎？》
《知乎技術分享：知乎千萬級併發的高性能長鏈接網關技術實踐》

更多同類文章 ……

（本文同步發佈於：http://www.52im.net/thread-27...）