DNS 系列淺談DNS 體系結(jié)構(gòu)DNS 是目前互聯(lián)網(wǎng)上最不可或缺的服務(wù)器之一，每天我們?cè)诨ヂ?lián)網(wǎng)上沖浪都需要DNS 的幫助。DNS 服務(wù)器能夠?yàn)槲覀兘馕鲇蛎?，定位電子郵件服務(wù)器，找到域中的域控制器??面

DNS 系列

淺談DNS 體系結(jié)構(gòu)

DNS 是目前互聯(lián)網(wǎng)上最不可或缺的服務(wù)器之一，每天我們?cè)诨ヂ?lián)網(wǎng)上沖浪都需要DNS 的幫助。DNS 服務(wù)器能夠?yàn)槲覀兘馕鲇蛎?，定位電子郵件服務(wù)器，找到域中的域控制器??面對(duì)這么一個(gè)重要的服務(wù)器角色，我們有必要對(duì)它進(jìn)行一番深入研究，本文嘗試探討一下DNS 的體系結(jié)構(gòu)，從而讓大家能更好地了解DNS 的原理。

DNS 的主要工作是域名解析，也就是把計(jì)算機(jī)名翻譯成IP 地址，這樣我們就可以直接用易于聯(lián)想記憶的計(jì)算機(jī)名來(lái)進(jìn)行網(wǎng)絡(luò)通訊而不用去記憶那些枯燥晦澀的IP 地址了?，F(xiàn)在我們給出一個(gè)問(wèn)題，在DNS 出現(xiàn)之前，互聯(lián)網(wǎng)上是如何進(jìn)行計(jì)算機(jī)名稱解析的？這個(gè)問(wèn)題顯然是有實(shí)際意義的，描述DNS 的RFC882和883出現(xiàn)在1984年，但1969年11月互聯(lián)網(wǎng)就誕生了，難道在DNS 出現(xiàn)之前互聯(lián)網(wǎng)的先驅(qū)們都是互相用IP 地址進(jìn)行通訊的？當(dāng)然不是，但早期互聯(lián)網(wǎng)的規(guī)模確實(shí)非常小，最早互聯(lián)網(wǎng)上只有4臺(tái)主機(jī)，分別在猶他大學(xué)，斯坦福大學(xué)，加州洛杉磯分校和加州圣芭芭拉分校，即使在整個(gè)70年代互聯(lián)網(wǎng)上也只有幾百臺(tái)主機(jī)而已。這樣一來(lái)，解決名稱解析的問(wèn)題就可以使用一個(gè)非常簡(jiǎn)單的辦法，每臺(tái)主機(jī)利用一個(gè)Hosts 文件就可以把互聯(lián)網(wǎng)上所有的主機(jī)都解析出來(lái)。這個(gè)Hosts 文件現(xiàn)在我們還在使用，路徑就在WindowsSystem32Driversetc目錄下，如下圖所示就是一個(gè)Hosts 文件的例子，我們?cè)趫D中可以很清楚地看到Hosts 文件把

[url]www.baidu.com[/url]解析為202.108.22.5。

在一個(gè)小規(guī)模的互聯(lián)網(wǎng)上，使用Hosts 文件是一個(gè)非常簡(jiǎn)單的解決方案，一般情況下，斯坦福大學(xué)的主機(jī)管理員每周更新一次Hosts 文件，其他的主機(jī)管理員每周都定時(shí)下載更新的Hosts 文件。但顯然這種解決方案在互聯(lián)網(wǎng)規(guī)模迅速膨脹時(shí)就不太適用了，就算現(xiàn)在的互聯(lián)網(wǎng)上有一億臺(tái)主機(jī)，想想看，如果每個(gè)人的計(jì)算機(jī)中都要有一個(gè)容納一億臺(tái)主機(jī)的Hosts 文件！呵呵，是不是快要崩潰了！

互聯(lián)網(wǎng)的管理者們及時(shí)為Hosts 文件找到了繼任者－DNS ，DNS 的設(shè)計(jì)要求使用分布式結(jié)構(gòu)，既可以允許主機(jī)分散管理數(shù)據(jù)，同時(shí)數(shù)據(jù)又可以被整個(gè)網(wǎng)絡(luò)所使用。管理的分散有利于緩解單一主機(jī)的瓶頸，緩解流量壓力，同時(shí)也讓數(shù)據(jù)更新變得簡(jiǎn)單。DNS 還被設(shè)計(jì)使用有層次結(jié)構(gòu)的名稱空間為主機(jī)命名，以確保主機(jī)域名的唯一性。

DNS 的設(shè)計(jì)要求您已經(jīng)看到了，下面我來(lái)具體解釋一下。DNS 的前身Hosts 文件是一個(gè)完全的分散解析方案，每臺(tái)主機(jī)都自己負(fù)責(zé)名稱解析，這種方法已經(jīng)被我們否定了。那我們能否使用一個(gè)完全集中的解析方案呢？也就是全世界只有一個(gè)Hosts 文件，互聯(lián)網(wǎng)用戶都利用這個(gè)文件進(jìn)行名稱解析！這個(gè)方案咋一聽(tīng)還是有可取之處的，至少大家都解脫出來(lái)了，不用每臺(tái)計(jì)算機(jī)都更新那個(gè)Hosts 文件了，全世界只要把這個(gè)唯一的Hosts 文件維護(hù)好就完事大吉了。實(shí)際上仔細(xì)考慮一下，有很多的問(wèn)題，例如這臺(tái)存放Hosts 文件的主機(jī)會(huì)成為性能瓶頸，面臨巨大的流量壓力，而且每個(gè)域名解析的結(jié)果都要通過(guò)這個(gè)文件進(jìn)行更新，更新的速度可想而知不會(huì)太及時(shí)。因此，DNS 也沒(méi)有采用這種完全集中的解析方案。

目前DNS 采用的是分布式的解析方案。具體是這樣的，互聯(lián)網(wǎng)管理委員會(huì)規(guī)定，域名空間的解析權(quán)都?xì)w根服務(wù)器所有，也就是說(shuō)，根服務(wù)器對(duì)互聯(lián)網(wǎng)上所有的域名都享有完全的解析權(quán)！且慢，有讀者要提問(wèn)了，那這個(gè)根服務(wù)器不就相當(dāng)于全世界唯一的Hosts 文件了嗎？呵呵，不要著急，根服務(wù)器用了一個(gè)簡(jiǎn)單的操作，就改變了這種結(jié)構(gòu)。根服務(wù)器使用的是什么操作？委派！下圖就是根服務(wù)器委派的示意圖，如下圖所示，根服務(wù)器把com 結(jié)尾的域名解析權(quán)委派給其他的DNS 服務(wù)器，以后所有以com 結(jié)尾的域名根服務(wù)器就都不負(fù)責(zé)解析了，而由被委派的服務(wù)器負(fù)責(zé)解析。而且根服務(wù)器還把以net ，org ，edu ，gov 等結(jié)尾的域名都一一進(jìn)行了委派，這些被委派的域名被稱為頂級(jí)域名，每個(gè)頂級(jí)域名都有預(yù)設(shè)的用途，例如com 域名用于商業(yè)公司，edu 域名用于教育機(jī)構(gòu)，gov 域名用于政府機(jī)關(guān)等等，這種頂級(jí)域名也被稱為頂級(jí)機(jī)構(gòu)域名。根服務(wù)器還針對(duì)不同國(guó)家進(jìn)行了域名委派，例如把所有以CN 結(jié)尾的域名委派給中國(guó)互聯(lián)網(wǎng)管理中心，以JP 結(jié)尾的域名委派給日本互聯(lián)網(wǎng)管理中心，CN ，JP 這些頂級(jí)域名被稱為頂級(jí)地理域名。

每個(gè)被委派的DNS 服務(wù)器同樣使用委派的方式向下發(fā)展，例如和訊公司想申請(qǐng)使用hexun.com 域名，這時(shí)和訊就要向負(fù)責(zé).com 域名的DNS 服務(wù)器提出申請(qǐng)，只要hexun.com 還沒(méi)有被其他公司或個(gè)人使用，而且申請(qǐng)者按時(shí)足額繳納了費(fèi)用，負(fù)責(zé).com 域名的服務(wù)器就會(huì)把hexun.com 域名委派到和訊公司自己的DNS 服務(wù)器60.28.251.1。只要DNS 服務(wù)器使用委派，域名空間就會(huì)逐步形成現(xiàn)有的分布式解析架構(gòu)。這種架構(gòu)把域名解析權(quán)下放到各公司自己的DNS 服務(wù)器上，既有利于及時(shí)更新記錄，同時(shí)對(duì)平衡流量壓力也很有好處。

那么，在這種分布式的解析結(jié)構(gòu)中，DNS 服務(wù)器如何進(jìn)行域名解析呢？換句話說(shuō)，其他的DNS 服務(wù)器怎么知道由60.28.251.1負(fù)責(zé)解析hexun.com 的域名呢？如果一個(gè)互聯(lián)網(wǎng)用戶想解析域名

[url]www.hexun.com[/url]，過(guò)程是怎么樣的呢？如下圖所示，用戶把解析請(qǐng)求發(fā)送到自己使用的DNS 服務(wù)器上，DNS 服務(wù)器發(fā)現(xiàn)自己無(wú)法解析[url]www.hexun.com[/url]這個(gè)域名，于是就把這個(gè)域名發(fā)送到根服務(wù)器請(qǐng)求解析，根服務(wù)器發(fā)現(xiàn)這個(gè)域名是以com 結(jié)尾的，于是告訴查詢者這個(gè)域名應(yīng)該詢問(wèn)負(fù)責(zé)com 的DNS 服務(wù)器。這時(shí)查詢者會(huì)轉(zhuǎn)而向負(fù)責(zé)com 的域名服務(wù)器發(fā)出查詢請(qǐng)

求，負(fù)責(zé)com 域名的DNS 服務(wù)器回答說(shuō)[url]www.hexun.com[/url]是以hexun.com 結(jié)尾的域名，以hexun.com 結(jié)尾的域名已經(jīng)被委派到DNS 服務(wù)器60.28.251.1了，因此這個(gè)域名的解析應(yīng)該詢問(wèn)60.28.251.1。于是查詢者最后向60.28.251.1發(fā)出查詢請(qǐng)求，這次應(yīng)該可以如愿以償了，

60.28.251.1會(huì)告訴查詢者所需要的答案，查詢者拿到這個(gè)答案后，會(huì)把這個(gè)查詢結(jié)果放入自己的緩存中，如果在緩存的有效期內(nèi)有其他DNS 客戶再次請(qǐng)求這個(gè)域名，DNS 服務(wù)器就會(huì)利用自己緩存中的結(jié)果響應(yīng)用戶，而不用再去根服務(wù)器那里跑一趟了。

以上介紹的域名解析過(guò)程我們可以通過(guò)一個(gè)實(shí)驗(yàn)來(lái)加以說(shuō)明，Berlin 是一個(gè)DNS 服務(wù)器，IP 地址為192.168.1.200，其他IP 參數(shù)如下圖所示。我們現(xiàn)在用Berlin 來(lái)解析一個(gè)域名，我們用抓包工具ethereal 追蹤一下域名解析的軌跡。

在DNS 服務(wù)器上查詢[url]www.hexun.com[/url]，如下圖所示，DNS 服務(wù)器已經(jīng)解析了這個(gè)域名，但到底解析的過(guò)程是什么樣的呢？向下看！

打開(kāi)抓包工具Ethereal ，如下圖所示，我們看到第8條記錄顯示DNS 服務(wù)器Berlin 向198.41.0.4發(fā)出了一個(gè)查詢請(qǐng)求，請(qǐng)求解析[url]www.hexun.com[/url]，198.41.0.4何許人也，13個(gè)根服務(wù)器之一！

接下來(lái)看第9條記錄，198.41.0.4給Berlin 一個(gè)回應(yīng)，告訴了Berlin 這個(gè)域名解析問(wèn)題應(yīng)該詢問(wèn)負(fù)責(zé)com 區(qū)域的DNS 服務(wù)器，而且198.41.0.4還給出了負(fù)責(zé)com 區(qū)域服務(wù)器的域名和IP 地址。

接下來(lái)的第10條記錄顯示了Berlin 向192.55.83.30發(fā)出了域名解析請(qǐng)求，從上圖可知，192.55.83.30就是負(fù)責(zé)com 區(qū)域的域名服務(wù)器之一，這次查詢會(huì)有什么樣的回應(yīng)呢？

從下圖的第11條記錄可以看出，負(fù)責(zé)com 區(qū)域的域名服務(wù)器告訴Berlin ，以hexun.com 結(jié)尾的域名已經(jīng)委派出去，現(xiàn)在有四個(gè)服務(wù)器負(fù)責(zé)，Berlin 可以向這四個(gè)服務(wù)器中的任何一個(gè)提出查詢請(qǐng)求。

從第12條記錄可以看出，Berlin 這次向59.173.14.26提出了查詢請(qǐng)求，59.173.14.26就是上圖中提到的負(fù)責(zé)hexun.com 區(qū)域的四個(gè)服務(wù)器之一。這次查詢會(huì)有什么樣的結(jié)果呢？

如下圖的第13條記錄所示，這次查詢終于有了結(jié)果，負(fù)責(zé)hexun.com 的59.173.14.26終于告訴Berlin ，[url]www.hexun.com[/url]對(duì)應(yīng)的IP 是60.28.250.55。