對于 DNS(Domain Name System) 大家肯定不陌生，不就是用來將一個網(wǎng)站的域名轉(zhuǎn)換為對應(yīng)的IP嗎。當(dāng)我們發(fā)現(xiàn)可以上QQ但不能瀏覽網(wǎng)頁時，我們會想到可能是域名服務(wù)器掛掉了;當(dāng)我們用別人提供的hosts文件瀏覽到一個"不存在"的網(wǎng)頁時，我們會了解到域名解析系統(tǒng)的脆弱。

[[268231]]

然而關(guān)于DNS還有一大堆故事值得我們?nèi)A聽，去思考。

DNS源起

要想訪問網(wǎng)絡(luò)上的一臺計算機，我們必須要知道它的IP地址，但是這些地址(比如243.185.187.39)只是一串?dāng)?shù)字，沒有規(guī)律，因此我們很難記住。并且如果一臺計算機變更IP后，它必須通知所有的人。

顯然，直接使用IP地址是一個愚蠢的方案。于是人們想出了一個替代的方法，即為每一臺計算機起一個名字，然后建立計算機名字到地址的一個映射關(guān)系。我們訪問計算機的名字，剩下的名字到地址的轉(zhuǎn)換過程則由計算機自動完成。

早期，名字到地址的轉(zhuǎn)換過程十分簡單。每臺計算機保存一個hosts文件，里面列出所有計算機名字和對應(yīng)的IP地址，然后定期從一個維護(hù)此文件的站點更新里面的記錄。當(dāng)我們訪問某個計算機名字時，先在hosts文件找到對應(yīng)的IP，然后就可以建立連接。

hosts 管理主機

早期的ARPANET就是這樣做的，但是隨著網(wǎng)絡(luò)規(guī)模的擴大，這種方法漸漸吃不消了。主要有以下三個原因：

1：hosts文件變得非常大;

2：主機名字會沖突;

3：集中的維護(hù)站點會不堪重負(fù)(需要給幾百萬機器提供hosts文件，想想就可怕)。

為了解決上面的問題，1983年P(guān)aul Mockapetris提出了域名系統(tǒng)(DNS, Domain Name System)，這是一種層次的、基于域的命名方案，并且用一個分布式數(shù)據(jù)庫系統(tǒng)加以實現(xiàn)。當(dāng)我們需要訪問一個域名(其實就是前面說的計算機的名字)時，應(yīng)用程序會向DNS服務(wù)器發(fā)起一個DNS請求，DNS服務(wù)器返回該域名對應(yīng)的IP地址。通過下面三種手段解決了上面的問題：

1：用戶計算機上并沒有存儲所有的名字到IP的映射，這樣避免了hosts文件過于龐大(現(xiàn)在各操作系統(tǒng)中hosts文件默認(rèn)都是空的)。

2：規(guī)定了域名的命名規(guī)則，保證主機名字不會重復(fù)。

3：DNS服務(wù)器不再是單一的一臺機器，而是一個層次的、合理組織的服務(wù)器集群。

這樣訪問一個域名的過程可以簡化為下圖：

域名hosts解析過程

DNS協(xié)議

那么如何具體實現(xiàn)這個所謂的域名系統(tǒng)呢，要知道管理一個超大型并且不斷變化的域名到IP的映射集合可不是一個簡單的事，況且還要去應(yīng)付成千上萬的DNS查詢請求。人們最終想出了一套不錯的協(xié)議，規(guī)定如何來實現(xiàn)這個系統(tǒng)，下面我們一起來看看吧。

首先我們需要制定一套命名規(guī)則，防止域名出現(xiàn)重復(fù)。DNS關(guān)于域名的規(guī)則和我們生活中的快遞系統(tǒng)類似，使用層次的地址結(jié)構(gòu)。快遞系統(tǒng)中要給某人郵寄物品，地址可能是這樣：中國、廣東省、廣州市、番禺區(qū)、中山西路12號 XXX。而一個域名看起來則是這樣的groups.google.com(為什么不是com.google.groups?我猜可能和老外寫地址的習(xí)慣有關(guān))。

對于Internet來說，域名層次結(jié)構(gòu)的***(相當(dāng)于國際快遞地址中的國家部分)由ICANN(互聯(lián)網(wǎng)名稱與數(shù)字地址分配機構(gòu))負(fù)責(zé)管理。目前，已經(jīng)有超過250個***域名，每個***域名可以進(jìn)一步劃為一些子域(二級域名)，這些子域可被再次劃分(三級域名)，依此類推。所有這些域名可以組織成一棵樹，如下圖所示(圖片來自Computer Networks: 7-1 )：

域名空間樹

DNS設(shè)計之初是用來建立域名到IP地址的映射，理論上對于每一個域名我們只需要在域名服務(wù)器上保存一條記錄即可。這里的記錄一般叫作域名資源記錄，它是一個五元組，可以用以下格式表示：

Domain_name Time_to_live Class Type Value 

其中：

Domain_name：指出這條記錄適用于哪個域名;

Time_to_live：用來表明記錄的生存周期，也就是說最多可以緩存該記錄多長時間(后面會講到緩存機制);

Class：一般總是IN;

Type：記錄的類型;

Value：記錄的值，如果是A記錄，則value是一個IPv4地址。

我們看到域名資源記錄有一個Type字段，用來表明記錄的類型。這是為什么呢?因為對于一個域名來說，通常并非只記錄其IP地址，還可能需要一些其他種類的記錄，一些常見的記錄類型如下：

我們知道不能只用一臺域名服務(wù)器來響應(yīng)所有的DNS查詢，因為沒有一臺機器能夠給全球的用戶提供查詢服務(wù)，計算能力、存儲、帶寬都不允許。只能合理組織一個域名服務(wù)器集群，使他們協(xié)同工作，共同提供域名解析服務(wù)。接下來首先要面對的一個問題是如何合理地將所有的域名資源記錄存儲到不同的域名服務(wù)器上。

前面說過域名的名字空間可以組織為一棵樹，這里我們可以進(jìn)一步將其劃分為不重疊的區(qū)域(DNS zone)，針對上圖的域名空間，一種可能的域名劃分如下圖：

域名劃分

然后將每個區(qū)域與多個域名服務(wù)器(其中一個是master，其他slave服務(wù)器則用來提供數(shù)據(jù)備份、加快解析速度、保證服務(wù)可用性)關(guān)聯(lián)起來，稱這些域名服務(wù)器為該區(qū)域的權(quán)威域名服務(wù)器(Authoritative Name Servers )，它保存兩類域名資源記錄：

1：該區(qū)域內(nèi)所有域名的域名資源記錄。

2：父區(qū)域和子區(qū)域的域名服務(wù)器對應(yīng)的域名資源記錄(主要是NS記錄)。

這樣，所有的域名資源記錄都保存在多個域名服務(wù)器中，并且所有的域名服務(wù)器也組成了一個層次的索引結(jié)構(gòu)，便于我們后面進(jìn)行域名解析。下面以一個簡化的域名空間為例子，說明域名資源記錄是如何保存在域名服務(wù)器中的，如下圖a： 

域名服務(wù)器

圖中域名空間劃分為A, B, C, D, E, F, G七個DNS區(qū)域，每個DNS區(qū)域都有多個權(quán)威域名服務(wù)器，這些域名服務(wù)器里面保存了許多域名解析記錄。對于上圖的NDS區(qū)域E來說，它的權(quán)威域名服務(wù)器里面保存的記錄如圖中表格所示。

仔細(xì)觀察上圖你可能會發(fā)現(xiàn)區(qū)域A、B并沒有父區(qū)域，他們之間并沒有一條路徑連在一起。這將導(dǎo)致一個很麻煩的問題，那就是區(qū)域A的權(quán)威域名服務(wù)器可能根本不知道區(qū)域B的存在。認(rèn)識到這一點后，你可能會想出一個很自然的解決方案，就是在A中記錄B域名服務(wù)器的地址，同時在B中記錄A的，這樣它們兩個就聯(lián)系起來了。但是考慮到我們有超過250個***域名，這樣做并不是很恰當(dāng)。

而我們使用的域名系統(tǒng)則采用了一種更加聰明的方法，那就是引入根域名服務(wù)器，它保存了所有***區(qū)域的權(quán)威域名服務(wù)器記錄?，F(xiàn)在通過根域名服務(wù)器，我們可以找到所有的***區(qū)域的權(quán)威域名服務(wù)器，然后就可以往下一級一級找下去了。下圖為全球根域名服務(wù)器的分布圖，可以在這里找到。 

***域名服務(wù)器

現(xiàn)在為止，我們的權(quán)威域名服務(wù)器和根域名服務(wù)器其實組成了一個樹，樹根為根域名服務(wù)器，下面每個節(jié)點都是一個區(qū)域的權(quán)威域名服務(wù)器，對于圖a中各個DNS區(qū)域的權(quán)威域名服務(wù)器，它們組成了下面這棵樹(實際中，一個權(quán)威域名服務(wù)器可能保存有多個DNS區(qū)域的記錄，因此權(quán)威域名服務(wù)器之間的聯(lián)系并不構(gòu)成一棵樹。這部分的詳細(xì)內(nèi)容可以參考RFC 1034: 4. NAME SERVERS。下面為了容易理解，將其簡化為一棵樹)： 

域名服務(wù)器樹

域名解析

我們已經(jīng)有了一個域名服務(wù)器集群，該集群合理地保存了域名空間和域名資源記錄的對應(yīng)關(guān)系?，F(xiàn)在我們要做的就是發(fā)送一個DNS請求給域名服務(wù)器，然后坐等它返回正確的域名資源記錄，這個過程叫作域名解析。

嚴(yán)格來說，域名解析的過程最早要追溯到建立網(wǎng)絡(luò)連接。因為每當(dāng)連接上網(wǎng)絡(luò)之后，計算機會自動獲得一個默認(rèn)的DNS服務(wù)器，當(dāng)然你也可以用自己信任的DNS服務(wù)器，比如8.8.8.8(DNS服務(wù)器也有信任不信任之分，是的，實踐篇會講到)，我們把這個域名服務(wù)器也叫作本地域名服務(wù)器。接下來當(dāng)我們需要知道一個域名對應(yīng)的資源記錄時，會向本地域名服務(wù)器發(fā)起請求，如果該域名恰好在本地域名服務(wù)器所轄屬的域名區(qū)域(DNS zone)內(nèi)，那么可以直接返回記錄。

如果在本地域名服務(wù)器沒有發(fā)現(xiàn)該域名的資源記錄，就需要在整個域名空間搜索該域名。而整個域名空間的資源記錄存儲在一個分層的、樹狀聯(lián)系的一系列域名服務(wù)器上，所以本地域名服務(wù)器首先要從根域名服務(wù)器開始往下搜索。這里有一個問題就是本地域名服務(wù)器如何找到根域名服務(wù)器在哪里呢?其實域名服務(wù)器啟動的時候，就會加載一個配置文件，里面保存了根域名服務(wù)器的NS記錄(要知道根域名服務(wù)器地址一般非常穩(wěn)定，不會輕易改變，并且數(shù)量很少，所以這個配置文件會很小)。找到根域名服務(wù)器之后，就可以一級一級地往下查找啦。

仍然以我們的圖a為例，現(xiàn)在假設(shè)區(qū)域E內(nèi)的某個用戶想訪問math.sysu.edu.cn，那么請求的過程如下：

域名解析過程

用語言簡單描述如下：

1：用戶：喂，本地域名服務(wù)器，告訴我math.sysu.edu.cn的地址;

2：本地域名服務(wù)器：哎呀，我不知道啊，不在我的轄區(qū)，容我去問問老大哥吧。root老大，能告訴我math.sysu.edu.cn的地址嗎;

3：根域名服務(wù)器：忙著呢，你去問B(.cn);

4：本地域名服務(wù)器：喂，B，告訴我math.sysu.edu.cn的地址;

5：B：你去問D(.edu.cn);

6：本地域名服務(wù)器：喂，D，告訴我math.sysu.edu.cn的地址;

7：D：你去問F(sysu.edu.cn);

8：本地域名服務(wù)器：喂，F(xiàn)，告訴我math.sysu.edu.cn的地址;

9：F：容老衲看看，哎呀，找到了，是X.X.X.X;

10：本地域名服務(wù)器：踏破鐵鞋終于找到啦，喂用戶，出來啊，我找到了，是X.X.X.X

仔細(xì)想想，這和我們郵寄快遞實在是如出一轍啊，假設(shè)你從美國郵東西到廣州市番禺區(qū)，首先快遞送到中國(不過這里沒有一個類似根域名服務(wù)器的中轉(zhuǎn)站而已)，然后往下到廣東省，接下來是廣州市，再往下是番禺了。

上面的是本地域名服務(wù)器的迭代解析過程，其實也可以遞歸查詢，這里就不說了，道理差不多。

緩存機制

現(xiàn)在整個域名系統(tǒng)已經(jīng)可以為我們提供域名解析服務(wù)了，當(dāng)我們輸入域名，計算機發(fā)送DNS請求，然后DNS服務(wù)器返回給我們解析的結(jié)果，一切看起來很***。然而是不是可以更***呢?

回顧一下平時瀏覽網(wǎng)站的情況，我們會發(fā)現(xiàn)兩個比較有意思的結(jié)論：

1：80%的時間我們都在看那些20%的網(wǎng)站，這就是大名鼎鼎的80/20 Rule;

2：我們會在一個網(wǎng)站的不同網(wǎng)頁之間跳轉(zhuǎn)，也就是不斷地訪問同一個域名，類似程序訪問的局部性原理。

這兩條結(jié)論很容易讓我們聯(lián)想到緩存機制。如果我們將已經(jīng)訪問過的那些域名的解析結(jié)果緩存在自己的計算機上，那么下次訪問的時候可以直接讀取結(jié)果，不用再次重復(fù)DNS查詢過程，給自己和域名服務(wù)器都節(jié)省了麻煩。

當(dāng)然，這樣做的一個前提是要緩存的解析結(jié)果不會頻繁更改，也就是說我十分鐘后解析一個域名的結(jié)果和現(xiàn)在解析的結(jié)果是一樣的。對大多數(shù)域名來說，這都是一個不爭的事實。但是難免有一些“善變”的域名，他們可能會頻繁更改自己的解析結(jié)果。為了使緩存機制適應(yīng)這兩類情況，我們在域名資源記錄里面添加一個Time_ti_live字段，表明這條記錄最多可以緩存多久。對于那些“穩(wěn)如泰山”的域名，給一個比較大的值，而那些“朝三暮四”的域名，則可以給定一個小的值。

我們既然可以在本機利用緩存，那么可不可以在域名服務(wù)器上也利用緩存機制呢，答案當(dāng)然是可以的。因為對于域名服務(wù)器來說，上面的兩條有意思的結(jié)論仍然有效。所以，域名服務(wù)器可以將那些訪問過的域名資源記錄緩存，用戶再次發(fā)起請求時，可以直接返回緩存結(jié)果，不用去迭代或者遞歸解析。