查看單個文章
舊 2004-07-30, 03:56 PM   #3 (permalink)
psac
榮譽會員
 
psac 的頭像
榮譽勳章
UID - 3662
在線等級: 級別:30 | 在線時長:1048小時 | 升級還需:37小時級別:30 | 在線時長:1048小時 | 升級還需:37小時級別:30 | 在線時長:1048小時 | 升級還需:37小時級別:30 | 在線時長:1048小時 | 升級還需:37小時級別:30 | 在線時長:1048小時 | 升級還需:37小時
註冊日期: 2002-12-07
住址: 木柵市立動物園
文章: 17381
現金: 5253 金幣
資產: 33853 金幣
預設

DNS伺服器工作原理

0000-00-00
分佈的資訊
解決方案就是採用DNS伺服器系統。與主機表不一樣,DNS伺服器不依賴一個大型映射文件,DNS服務 器只
包含有限的資訊,因為他們知道到哪裡能找到他們想知道的域的細節。當DNS伺服器得到對某個主機 的請
求,而該請求的主機又並不在其緩衝內,那麼DNS伺服器只是知道了這件事然後去詢問知道答案 的「某計
算機」。這台電腦是一種授權伺服器,負責維護DNS資訊。如果某台伺服器在被詢問到其域內的某 個地
址時它可以確定地指出該位址存在,那麼這台伺服器就是所謂的授權伺服器。

如果接觸的伺服器並不包含有關的域名資訊,該伺服器就會將請求傳遞給接觸鏈路上更進階別的授 權服務
器,這樣就形成了一系列查詢直到最後找到需要的資訊。實際上,這意味著請求可以被任意數量的 伺服器
處理,在Internet上這種來來回回的行為每時每刻都在發生。最早發出請求的伺服器將緩衝資訊以 滿足未
來的需求而無須向授權伺服器再發請求。DNS伺服器的管理員為這些資訊設定了超時限制以避免緩衝 中充
滿了名字請求的舊資料。

DNS轉換不會花費太多的時間,但它確實增加了你的請求到達遠端電腦的時間。你可以自己做個快 速測試
(雖然很簡單):首先用域名,比如www.microsoft.com來訪問對應的Web站點,然後用IP位址
198.105.232.4再實驗一下。如果你要這麼做,則請務必關閉你的瀏覽器然後再重新開啟以啟始化新 的會話;
否則你不過是載入了頁面的緩衝版本(記住裝載頁面的延遲原因可能來自許多因素,所以對結果要 有所保留)。

DNS服務的最常用軟體是Berkeley Internet Name Domain,也就是BIND,它源自U.C. Berkeley但現 在則由
Internet Software Consortium.負責。其最新版本4.9.3包含了標準的 Unix版本和附加的 Windows NT 連接阜。
BIND提供瞭解析器和名字伺服器軟體,解析器做實際的查詢工作而名字伺服器則提供回應。BIND將 名字服務
器分成三個部分:主伺服器包含了有關一個域的全部資料;次伺服器則有效地從主伺服器拷貝DNS數 據庫;
唯緩衝伺服器通過緩衝查詢來建立例外的DNS資料庫。只有主伺服器和次伺服器才被當作涉及特定域 的授權
伺服器。

要理解 DNS 伺服器怎麼操作就有必要理解域名層次本身。在這一層次的頂部是根域。這一域上的信 息駐留
在從整個Internet中所選的一些根伺服器上。在根域下面是頂級域,也就是國家程式碼或機構程式碼。 國家程式碼
的例子有SG (新加坡)和CA (加拿大)等。而機構程式碼則包括眾所周知的COM(商業機 構)、EDU(教育機
關)、GOV(政府機構)和NET(網路機構)等(注意在美國以外的頂級域通常是國家編碼,但是基 於美國的
地點通常省略國家編碼)。在頂級域下面是次級域 (whitehouse.gov、microsoft.com、inforamp.net 等諸
如此類),然後是第 3級域,等等等等向下以此類推。

如果你想在美國建立域名,那麼你必須聯繫網路資訊中心NIC。在它同意你的請求以前,你首先要保 證你想要
的名字還沒被使用,其次要保證目前至少有 2台伺服器可以提供新域名的服務。當 NIC 最後同意請 求時,它
將承認你的次級域,並將指向該名字的游標放到頂級域所在的伺服器內。例如,如果你請求域名 mybiz.com,
那麼你必須首先讓Internet上的2 台名字伺服器提供資訊服務(你的 ISP的伺服器能做到這一 點),然後
NIC 將把 mybiz 放到COM 域伺服器系統內,其游標將指向那2台特定伺服器。

一旦設定了適當的主域,你就可以增加所希望的任何數量的子域。你可能想要命名你的電腦為
sales.mybiz.com,而另一台則被叫做techsupport.mybiz.com等等。這些工作可就不需要 NIC 的同 意了,
而且,事實上NIC也不管這事。但是,如果你想要任何人都能實際地訪問你的子域,那麼你最好將有 關子域
的資訊儘快地放到上級域內。在特定的情況下,關於 sales.mybiz.com 和 techsupport.mybiz.com 的IP信
息必須放在mybiz.com伺服器上。這一層次中的每台伺服器都包含了一個DNS資料庫,其入口被稱作 NS記錄,
每條這樣的記錄包含了域或子域的名字,此外還加上作為域或者子域伺服器的主機的名字。在我們 的例子中,
我們將告訴根伺服器它能在我們的 DNS 伺服器上找到mybiz.com及其全部子域的資訊,而這些資訊 則位於
details.mybiz.com這台電腦上。

現在我們來看看這一切是如何運作的。某所大學的某人在指向你的最新子域的網頁上看見了一個鏈 接
techsupport.mybiz.com。然後她點擊該連接,於是她的本機DNS 伺服器(很可能位於這所大學的某 台計算
機上)開始工作。首先,伺服器搜尋它自己的 DNS資料庫以轉換資訊,但是,因為它以前從來沒遇 見過
techsupport.mybiz.com,所以伺服器沒有該域存在的記錄而且不能解析IP位址。不過,它 的 DNS 資料庫包
含了一個根伺服器的位址(所有的 DNS 伺服器必須設定該索引)。於是本機 DNS 伺服器就到 Internet上查
詢該根伺服器。根伺服器在其DNS 資料庫裡搜尋COM 頂級域,然後它用NS 記錄回覆該大學 的 DNS 伺服器,
告訴它可以從details.mybiz.com 處查詢到mybiz.com 的資訊。大學的伺服器就這樣做了,而且從
details.mybiz.com那裡知道了techsupport.mybiz.com 的對應IP 位址。在這一程序中最根本的階 段是,大
學的DNS 伺服器緩衝了該 NS 記錄,結果下次該大學的任何人在需要涉及到 mybiz.com、details.mybiz.com 、
ortechsupport.mybiz.com等對應的IP位址轉換時,相關資訊在本機即可獲得。

正如其他的Internet傳輸協定一樣,DNS由幾個Internet的RFC(請求評論)規範(最初是RFC 882、883 和973)。
不過要理解DNS 伺服器的工作原理最好的標準還是RFC 1035。你可以在Internet上的好幾個地方找 到
RFC 1035,比如在http://www.crynwr.com/crynwr/rfc1035/ 就有一個不錯的HTML 版本。正如你可 能想到
的那樣,RFC具有相當的技術性,你不大可能會對超出DNS 伺服器一般操作的細節感興趣。但是如果 你想做
個伺服器管理員,那麼就記住 RFC吧。


DNS循環復用與優先級

配置循環復用

循環復用是 DNS 伺服器用於共享和分配網路資源負載的本機平衡機制。如果發現主機名的多個 A RR,則可用它循環使用包含在查詢回應中的

主機 (A) 資源記錄 (RR)。
在預設情況下,DNS 伺服器的服務使用循環復用對資源記錄進行排序,這些資源記錄是在解析為多個映射 RR 的主機名回應中返回的。該功能

提供了一種非常簡便的方法,用於對客戶端機使用 Web 伺服器和其他頻繁查詢的多宿主電腦的負載平衡。
要使循環復用正常工作,必須首先在該區域中註冊所查詢名稱的多個 A RR。如果 DNS 伺服器禁用循環復用,那麼這些查詢的回應順序以回應

列表中 RR 在區域(或者是它的區域文件,或者是 Active Directory)中存儲時的靜態排序為基礎。
範例:循環復用

正向搜尋型查詢(對於所有匹配 DNS 域名的 A RR)用於有三個 IP 位址的多宿主電腦 (multihomed.example.microsoft.com)。獨立的 A

RR 用於將主機名映射到區域中的每個 IP 位址中。在存儲的 example.microsoft.com 區域中,RR 以如下類BIOS順序顯示:
multihomed IN A 10.0.0.2
multihomed IN A 10.0.0.3
multihomed IN A 10.0.0.1
查詢伺服器以解析該主機名的第一個 DNS 客戶端機以預設順序接收列表。第二個客戶端機傳送後續查詢以解析該名稱時,該列表將按以下方式循環

使用:
multihomed IN A 10.0.0.2
multihomed IN A 10.0.0.3
multihomed IN A 10.0.0.1
注意
本機子網優先級取代了多宿主名稱的循環復用。但是在啟用時,循環復用仍然是對多個 RR 進行排序的輔助方法,這些 RR 是在作為位址 (A)

查詢回應一部分的回應列表中返回的


區分本機子網的優先級

在預設情況下,當客戶端機查詢解析為映射到多個 IP 位址的主機名時,DNS 服務使用本機子網優先排序作為給出同一網路上首選 IP 位址的方

法。此功能要求客戶應用程式嘗試使用連接可用的最近(一般是最快的)IP 位址連接至主機。
DNS 服務按以下方式使用本機子網優先級:
DNS 服務確定是否需要本機子網的優先級排序查詢回應。
如果有多個 A 資源記錄 (RR) 與要查詢的主機名匹配,則 DNS 服務可按其子網位置重新對記錄進行排序。如果查詢的主機名只與一個 A 資源

記錄匹配,或者客戶端機的 IP 網路位址與多重 RR 回應列表上的任何映射位址的 IP 網路位址匹配,則不需要進行優先排列。
對於匹配回應列表中的每一個 RR,DNS 服務決定了哪些記錄(如果有)與查詢客戶端機的子網位置匹配。
DNS 服務重新對回應列表進行排序,以便將與發出請求的客戶端機的本機子網匹配的 A RR 排在回應列表中的第一位。
按子網的順序進行優先級排序後,回應列表將返回給發出請求的客戶端機。
簡單範例:本機網路的優先排序

多宿主電腦 multihomed.example.microsoft.com,在 example.microsoft.com 區域中有三個主機 IP 位址相互分開的 A RR。單獨的 A RR

用於每個主機的位址,該位址以如下順序出現在區域中:
multihomed IN A 192.168.1.27
multihomed IN A 10.0.0.14
multihomed IN A 172.16.20.4
如果在 IP 位址 10.4.3.2 上的 DNS 客戶端機解析程序向伺服器查詢主機 multihomed.example.microsoft.com 的 IP 位址,則 DNS 服務將記

錄客戶端機的源 IP 網路位址 (10.0.0.0) 與 RR 回應列表中 10.0.0.4 位址的網路(類型 A)部分匹配。但是,DNS 服務按如下方式重新排序

回應中的位址:
multihomed IN A 10.0.0.14
multihomed IN A 192.168.1.27
multihomed IN A 172.16.20.4
如果發出請求的客戶端機的 IP 位址沒有與回應列表中任何 RR 匹配的本機網路,在這個列表不進行按優先級的排序。
複雜範例:本機子網的優先排序

如果要在使用 IP 子網(非預設子網路遮罩)的網路上工作,那麼只存在很少的差異。如果在網路部分有多個位址匹配,則匹配的位址將被進一

步排序並且最接近匹配子網位址的 RR 排列在第一位。
例如,多宿主電腦 multihomed.example.microsoft.com,在 example.microsoft.com 區域有四個主機 IP 位址相互分開的 A RR。其中的兩

個 IP 位址不是本機網的。雖然另外兩個 IP 位址共享公用的 IP 網路位址,但是,因為使用了 IP 子網,因此它們代表關於自訂(非預設

)子網路遮罩值 255.255.248.0 的不同物理子網連接。這些 RR 的例子以下列順序出現在區域中:
multihomed IN A 192.168.1.27
multihomed IN A 172.16.22.4
multihomed IN A 10.0.0.14
multihomed IN A 172.16.31.5

如果發出請求的客戶端機的 IP 位址是 172.16.22.8,則與客戶端機相同的 IP 網路(172.16.0.0 網路)匹配的兩個 IP 位址從回應列表的頂端返

回到客戶端機。但是,在該例中,位址 172.16.22.4 被置於位址 172.16.31.5 之前,因為它與沿客戶端機 IP 位址一直到 172.16.20.0 的子網地

址相匹配。
由 DNS 服務返回的重新排序的回應列表應為:
multihomed IN A 172.16.22.4
multihomed IN A 172.16.31.5
multihomed IN A 192.168.1.27
multihomed IN A 10.0.0.14
注意
IP 子網通過使用網路上所有 IP 位址的自訂或非預設子網路遮罩值進行加強。詳細資料,請參閱子網路遮罩。
本機子網優先級取代了多宿主名稱的循環復用。但是在啟用循環復用時,通過將循環復用作為排序回應列表的輔助方法,RR 繼續得以循環使用



這兩個功能的最大的用處就是負載平衡,最常用的方式就是這樣的:
假設你現在有兩台WEB伺服器使用了相同的內容,一個在局內網一個在外網,為了減少局內網用戶訪問外網中的網路並為局內網用戶提供一個較高的速度

,你希望在使用一個DNS的情況下能夠做到局內網用戶在使用域名訪問時訪問的是局內網伺服器,外網用戶在使用域名訪問的是外網伺服器.
使用Win2000DNS這一點就非常容易做到,只要為每個伺服器在DNS中使用相同的主機名建立A記錄並啟用DNS的循環復用與啟用本機子網優先級功

能就可以了,DNS伺服器自然為你做好引導工作.
psac 目前離線  
送花文章: 3, 收花文章: 1631 篇, 收花: 3205 次