DSN 系列教程DNS 系列教程本文所有內(nèi)容均出自岳雷的微軟網(wǎng)絡(luò)課堂 http://yuelei.blog.51cto.com51cto_bbs_Kirin整理匯總歡迎訪問岳雷的網(wǎng)絡(luò)課堂| http:

DSN 系列教程

DNS 系列教程

本文所有內(nèi)容均出自岳雷的微軟網(wǎng)絡(luò)課堂 http://yuelei.blog.51cto.com

51cto_bbs_Kirin整理匯總

歡迎訪問岳雷的網(wǎng)絡(luò)課堂

| http://yuelei.blog.51cto.com

DSN 系列教程

目錄

DSN 系列之一 淺談DNS 體系結(jié)構(gòu)

DNS 系列之二 詳解DNS 的常用記錄（上）

DNS 系列之三 詳解DNS 的常用記錄（下）

DNS 系列之四 配置DNS 輔助服務器

DNS 系列之五 揭秘DNS 后臺文件

DNS 系列之六 親手締造DNS 體系，創(chuàng)建DNS 私有根

DSN 系列教程

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

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

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

DSN 系列教程

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

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

DSN 系列教程

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

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

DSN 系列教程

以JP 結(jié)尾的域名委派給日本互聯(lián)網(wǎng)管理中心，CN ，JP 這些頂級域名被稱為頂級地理域名。

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

那么，在這種分布式的解析結(jié)構(gòu)中，DNS 服務器如何進行域名解析呢？換句話說，其他的DNS 服務器怎么知道由60.28.251.1負責解析hexun.com 的域名呢？如果一個互聯(lián)網(wǎng)用戶想解析域名www.hexun.com ，過程是怎么樣的呢？如下圖所示，用戶把解析請求發(fā)送到自己使用的DNS 服務器上，DNS 服務器發(fā)現(xiàn)自己無法解析www.hexun.com 這個域名，于是就把這個域名發(fā)送到根服務器請求解析，根服務器發(fā)現(xiàn)這個域名是以com 結(jié)尾的，于是告訴查詢者這個

DSN 系列教程

域名應該詢問負責com 的DNS 服務器。這時查詢者會轉(zhuǎn)而向負責com 的域名服務器發(fā)出查詢請求，負責com 域名的DNS 服務器回答說www.hexun.co hexun.com 結(jié)尾的域名，以hexun.com 結(jié)尾的域名已經(jīng)被委派到D NS 服務器60.28.251.1了，因此這個域名的解析應該詢問60.28.251.1。于是查詢者最后向60.28.251.1發(fā)出查詢請求，這次應該可以如愿以償了，

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

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

DSN 系列教程

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

DSN 系列教程

打開抓包工具Ethereal ，如下圖所示，我們看到第8條記錄顯示DNS 服務器B

erlin 向198.41.0.4發(fā)出了一個查詢請求，請求解析www.hexun.com ，19

8.41.0.4何許人也，13個根服務器之一！

接下來看第9條記錄，198.41.0.4給Berlin 一個回應，告訴了Berlin 這個域名解析問題應該詢問負責com 區(qū)域的DNS 服務器，而且198.41.0.4還給出

DSN 系列教程

了負責com 區(qū)域服務器的域名和IP 地址。

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