淺談DNS 體系結(jié)構(gòu)DNS 是目前互聯(lián)網(wǎng)上最不可或缺的服務(wù)器之一，每天我們在互聯(lián)網(wǎng)上沖浪都需要DNS 的幫助。DNS 服務(wù)器能夠為我們解析域名，定位電子郵件服務(wù)器，找到域中的域控制器??面對這么一個重

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

DNS 是目前互聯(lián)網(wǎng)上最不可或缺的服務(wù)器之一，每天我們在互聯(lián)網(wǎng)上沖浪都需要DNS 的幫助。DNS 服務(wù)器能夠為我們解析域名，定位電子郵件服務(wù)器，找到域中的域控制器??面對這么一個重要的服務(wù)器角色，我們有必要對它進(jìn)行一番深入研究，本文嘗試探討一下DNS 的體系結(jié)構(gòu)，從而讓大家能更好地了解DNS 的原理。 DNS 的主要工作是域名解析，也就是把計算機(jī)名翻譯成IP 地址，這樣我們就可以直接用易于聯(lián)想記憶的計算機(jī)名來進(jìn)行網(wǎng)絡(luò)通訊而不用去記憶那些枯燥晦澀的IP 地址了。現(xiàn)在我們給出一個問題，在DNS 出現(xiàn)之前，互聯(lián)網(wǎng)上是如何進(jìn)行計算機(jī)名稱解析的？這個問題顯然是有實際意義的，描述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ī)模確實非常小，最早互聯(lián)網(wǎng)上只有4臺主機(jī)，分別在猶他大學(xué)，斯坦福大學(xué)，加州洛杉磯分校和加州圣芭芭拉分校，即使在整個70年代互聯(lián)網(wǎng)上也只有幾百臺主機(jī)而已。這樣一來，解決名稱解析的問題就可以使用一個非常簡單的辦法，每臺主機(jī)利用一個Hosts 文件就可以把互聯(lián)網(wǎng)上所有的主機(jī)都解析出來。這個Hosts 文件現(xiàn)在我們還在使用，路徑就在WindowsSystem32Driversetc目錄下，如下圖所示就是一個Hosts 文件的例子，我們在圖中可以很清楚地看到Hosts 文件把

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

在一個小規(guī)模的互聯(lián)網(wǎng)上，使用Hosts 文件是一個非常簡單的解決方案，一般情況下，斯坦福大學(xué)的主機(jī)管理員每周更新一次Hosts 文件，其他的主機(jī)管理員每周都定時下載更新的Hosts 文件。但顯然這種解決方案在互聯(lián)網(wǎng)規(guī)模迅速膨脹時就不太適用了，就算現(xiàn)在的互聯(lián)網(wǎng)上有一億臺主機(jī)，想想看，如果每個人的計算機(jī)中都要有一個容納一億臺主機(jī)的Hosts 文件！呵呵，是不是快要崩潰了！ 互聯(lián)網(wǎng)的管理者們及時為Hosts 文件找到了繼任者－DNS ，DNS 的設(shè)計要求使用分布式結(jié)構(gòu)，既可以允許主機(jī)分散管理數(shù)據(jù)，同時數(shù)據(jù)又可以被整個網(wǎng)絡(luò)所使用。管理的分散有利于緩解單一主機(jī)的瓶頸，緩解流量壓力，同時也讓數(shù)據(jù)更新變得簡單。DNS 還被設(shè)計使用有層次結(jié)構(gòu)的名稱空間為主機(jī)命名，以確保主機(jī)域名的唯一性。

DNS 的設(shè)計要求您已經(jīng)看到了，下面我來具體解釋一下。DNS 的前身Hosts 文件是一個完全的分散解析方案，每臺主機(jī)都自己負(fù)責(zé)名稱解析，這種方法已經(jīng)被我

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

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

每個被委派的DNS 服務(wù)器同樣使用委派的方式向下發(fā)展，例如和訊公司想申請使用hexun.com 域名，這時和訊就要向負(fù)責(zé).com 域名的DNS 服務(wù)器提出申請，只要hexun.com 還沒有被其他公司或個人使用，而且申請者按時足額繳納了費用，負(fù)責(zé).com 域名的服務(wù)器就會把hexun.com 域名委派到和訊公司自己的DNS 服務(wù)器60.28.251.1。只要DNS 服務(wù)器使用委派，域名空間就會逐步形成現(xiàn)有的分布

式解析架構(gòu)。這種架構(gòu)把域名解析權(quán)下放到各公司自己的DNS 服務(wù)器上，既有利于及時更新記錄，同時對平衡流量壓力也很有好處。

那么，在這種分布式的解析結(jié)構(gòu)中，DNS 服務(wù)器如何進(jìn)行域名解析呢？換句話說，其他的DNS 服務(wù)器怎么知道由60.28.251.1負(fù)責(zé)解析hexun.com 的域名呢？如果一個互聯(lián)網(wǎng)用戶想解析域名[url]www.hexun.com[/url]，過程是怎么樣的呢？如下圖所示，用戶把解析請求發(fā)送到自己使用的DNS 服務(wù)器上，DNS 服務(wù)器發(fā)現(xiàn)自己無法解析[url]www.hexun.com[/url]這個域名，于是就把這個域名發(fā)送到根服務(wù)器請求解析，根服務(wù)器發(fā)現(xiàn)這個域名是以com 結(jié)尾的，于是告訴查詢者這個域名應(yīng)該詢問負(fù)責(zé)com 的DNS 服務(wù)器。這時查詢者會轉(zhuǎn)而向負(fù)責(zé)com 的域名服務(wù)器發(fā)出查詢請求，負(fù)責(zé)com 域名的DNS 服務(wù)器回答說[url]www.hexun.com[/url]是以hexun.com 結(jié)尾的域名，以hexun.com 結(jié)尾的域名已經(jīng)被委派到DNS 服務(wù)器60.28.251.1了，因此這個域名的解析應(yīng)該詢問60.28.251.1。于是查詢者最后向60.28.251.1發(fā)出查詢請求，這次應(yīng)該可以如愿以償了，60.28.251.1會告訴查詢者所需要的答案，查詢者拿到這個答案后，會把這個查詢結(jié)果放入自己的緩存中，如果在緩存的有效期內(nèi)有其他DNS 客戶再次請求這個域名，DNS 服務(wù)器就會利用自己緩存中的結(jié)果響應(yīng)用戶，而不用再去根服務(wù)器那里跑一趟了。

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

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

打開抓包工具Ethereal ，如下圖所示，我們看到第8條記錄顯示DNS 服務(wù)器Berlin 向198.41.0.4發(fā)出了一個查詢請求，請求解析

[url]www.hexun.com[/url]，198.41.0.4何許人也，13個根服務(wù)器之一！

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

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

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

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

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

通過這個實驗，希望大家能夠更好地理解DNS 的分布式結(jié)構(gòu)，下篇博文中我們要討論一下如何DNS 服務(wù)器的常用記錄類型。

本文出自 “岳雷的微軟網(wǎng)絡(luò)課堂” 博客，請務(wù)必保留此出處

詳解DNS 的常用記錄（上）

在上篇博文中，我們介紹了DNS 服務(wù)器的體系結(jié)構(gòu)，從中我們了解到如果我們希望注冊一個域名，那么必須經(jīng)過頂級域名服務(wù)器或其下級的域名服務(wù)器為我們申請的域名進(jìn)行委派，把解析權(quán)委派到我們的DNS 服務(wù)器上，這樣我們才可以獲得對所申請域名的解析權(quán)。本文中我們將再進(jìn)一步，假設(shè)我們已經(jīng)為公司成功申請了一個域名hexun.com ，現(xiàn)在hexun.com 的解析權(quán)被委派到公司的DNS 服務(wù)器202.99.16.1，那我們在202.99.16.1服務(wù)器上該進(jìn)行什么樣的配置呢？

一 安裝DNS 服務(wù)器

首先我們要在服務(wù)器上安裝DNS 組件，服務(wù)器的TCP/IP配置如下圖所示。

安裝DNS 組件非常簡單，依次點擊 控制面板－添加或刪除程序－添加/刪除Windows 組件－網(wǎng)絡(luò)服務(wù)，如下圖所示，選擇“域名系統(tǒng)”即可。

二 創(chuàng)建區(qū)域

DNS 服務(wù)器創(chuàng)建完畢之后，我們接下來就要創(chuàng)建DNS 區(qū)域了，區(qū)域是DNS 服務(wù)器所負(fù)責(zé)的名稱空間，DNS 服務(wù)器有正向區(qū)域和反向區(qū)域，正向區(qū)域負(fù)責(zé)把域名解析為IP ，而反向區(qū)域負(fù)責(zé)把IP 解析為域名。

DNS 區(qū)域有三種類型，正向區(qū)域，反向區(qū)域和存根區(qū)域。要理解區(qū)域類型，先要明白DNS 服務(wù)器有主服務(wù)器和輔助服務(wù)器的區(qū)別。一般情況下，企業(yè)申請域名時會考慮配備兩個DNS 服務(wù)器，一個是主服務(wù)器，另一個是輔助服務(wù)器。一般的解析請求由主服務(wù)器負(fù)責(zé)，輔助服務(wù)器的數(shù)據(jù)是從主服務(wù)器復(fù)制而來的，輔助服務(wù)器的數(shù)據(jù)是只讀的，當(dāng)主服務(wù)器出現(xiàn)故障或由于負(fù)載太重?zé)o法響應(yīng)客戶機(jī)的解析請求時，輔助服務(wù)器會挺身而出擔(dān)負(fù)起域名解析的任務(wù)。現(xiàn)在我們回過頭來解釋一下什么是主要區(qū)域，主服務(wù)器使用的區(qū)域就是主要區(qū)域，同樣，輔助服務(wù)器使用的區(qū)域是輔助區(qū)域。存根區(qū)域可以看做是一個特殊的，簡化的輔助區(qū)域，具體區(qū)別我們在后續(xù)博文中會加以介紹。

一般我們使用較多的是正向區(qū)域，而且從邏輯上考慮，必然是先創(chuàng)建主要區(qū)域，因為輔助區(qū)域和存根區(qū)域都需要從主要區(qū)域復(fù)制數(shù)據(jù)，因此我們現(xiàn)在的任務(wù)是要為區(qū)域hexun.com 創(chuàng)建一個正向的主要區(qū)域。如下圖所示，我們在DNS 服務(wù)器上選擇創(chuàng)建一個正向區(qū)域。

出現(xiàn)新建區(qū)域向?qū)Вc擊下一步繼續(xù)。

選擇創(chuàng)建一個主要區(qū)域。

區(qū)域名稱和申請的域名是一樣的，hexun.com 。

區(qū)域數(shù)據(jù)文件是hexun.com.dns ，區(qū)域內(nèi)的所有記錄都存儲在這個文件里，注意，這個文件我們以后會用到的。

向?qū)г儐柺欠裨试S區(qū)域動態(tài)更新，一般來說，如果DNS 區(qū)域在企業(yè)內(nèi)網(wǎng)使用，我們會允許動態(tài)更新；如果用于Internet ，那么一般不需要動態(tài)更新。

如下圖所示，區(qū)域創(chuàng)建完畢。

區(qū)域創(chuàng)建完畢之后，如下圖所示，區(qū)域中只有一個NS 記錄和一個SOA 記錄，我們接下來要做的工作就是在區(qū)域中創(chuàng)建適當(dāng)?shù)腄NS 記錄。

三 創(chuàng)建記錄

DNS 記錄是DNS 區(qū)域數(shù)據(jù)的具體表現(xiàn)形式，我們接下來為大家介紹幾種最常見的DNS 記錄，大家掌握了這些記錄就可以基本掌握DNS 的基本應(yīng)用了。

1、 A記錄

A 記錄也稱為主機(jī)記錄，是使用最廣泛的DNS 記錄，A 記錄的基本作用就是說明一個域名對應(yīng)的IP 是多少，例如，我們想通過A 記錄說明一臺主機(jī)的域名是bbs.hexun.com ，IP 是202.99.16.185，那么我們就可以進(jìn)行下列操作。如下圖所示，我們在hexun.com 區(qū)域中選擇“新建主機(jī)”。

如下圖所示，我們在A 記錄中說明了域名bbs.hexun.com 對應(yīng)的IP 是

202.99.16.185。其中提到了一個完全合格域名的概念，這里我們介紹一下。完全合格域名指的是點結(jié)尾的域名，例如bbs.hexun.com. 就是一個完全合格域名。在一般的網(wǎng)絡(luò)應(yīng)用中，我們可以省略完全合格域名最右側(cè)的點，但DNS 對這個點不能隨便省略。因為這個點代表了DNS 的根，有了這個點，完全合格域名就可以表達(dá)為一個絕對路徑，例如bbs.hexun.com. 就可以表示為DNS 根下的com 子域下hexun.com 域中一個名為bbs 的主機(jī)。如果DNS 發(fā)現(xiàn)一個域名不是以點結(jié)尾的完全合格域名，就會把這個域名加上當(dāng)前的區(qū)域名稱作為后綴，讓其滿足完全合格域名的形式需求。例如DNS 會把域名bbs 處理為bbs.hexun.com. 。因此，如果要求輸入完全合格域名，我們應(yīng)該注意讓域名以點結(jié)尾。

A 記錄的基本用法是描述域名和IP 的對應(yīng)關(guān)系，其實A 記錄還有一個高級用法，A 記錄有負(fù)載平衡的作用。DNS 經(jīng)常被用作一個低成本的負(fù)載平衡解決方案，主要就是依靠A 記錄來實現(xiàn)的。舉個例子加以說明，例如我們有四個Web 服務(wù)器共同負(fù)責(zé)[url]www.hexun.com[/url]這個網(wǎng)站，四個Web 服務(wù)器的IP 地址分別為202.99.16.81，202.99.16.82，202.99.16.83和202.99.16.84，那么我們就應(yīng)該創(chuàng)建如下的主機(jī)記錄。