詳解dns的常用記錄_第1頁
詳解dns的常用記錄_第2頁
詳解dns的常用記錄_第3頁
詳解dns的常用記錄_第4頁
詳解dns的常用記錄_第5頁
已閱讀5頁,還剩64頁未讀, 繼續(xù)免費閱讀

下載本文檔

版權說明:本文檔由用戶提供并上傳,收益歸屬內容提供方,若內容存在侵權,請進行舉報或認領

文檔簡介

DNS體系結構DNS是目前互聯(lián)網上最不可或缺的服務器之一,每天我們在互聯(lián)網上沖浪都需要DNS的幫助。DNS服務器能夠為我們解析域名,定位電子郵件服務器,找到域中的域控制器面對這么一個重要的服務器角色,我們有必要對它進行一番深入研究,本文嘗試探討一下DNS的體系結構,從而讓大家能更好地了解DNS的原理。在一個小規(guī)模的互聯(lián)網上,使用Hosts文件是一個非常簡單的解決方案,一般情況下,斯坦福大學的主機管理員每周更新一次Hosts文件,其他的主機管理員每周都定時下載更新的Hosts文件。但顯然這種解決方案在互聯(lián)網規(guī)模迅速膨脹時就不太適用了,就算現(xiàn)在的互聯(lián)網上有一億臺主機,想想看,如果每個人的計算機中都要有一個容納一億臺主機的Hosts文件!呵呵,是不是快要崩潰了!互聯(lián)網的管理者們及時為Hosts文件找到了繼任者DNS,DNS的設計要求使用分布式結構,既可以允許主機分散管理數(shù)據(jù),同時數(shù)據(jù)又可以被整個網絡所使用。管理的分散有利于緩解單一主機的瓶頸,緩解流量壓力,同時也讓數(shù)據(jù)更新變得簡單。DNS還被設計使用有層次結構的名稱空間為主機命名,以確保主機域名的唯一性。DNS的設計要求您已經看到了,下面我來具體解釋一下。DNS的前身Hosts文件是一個完全的分散解析方案,每臺主機都自己負責名稱解析,這種方法已經被我們否定了。那我們能否使用一個完全集中的解析方案呢?也就是全世界只有一個Hosts文件,互聯(lián)網用戶都利用這個文件進行名稱解析!這個方案咋一聽還是有可取之處的,至少大家都解脫出來了,不用每臺計算機都更新那個Hosts文件了,全世界只要把這個唯一的Hosts文件維護好就完事大吉了。實際上仔細考慮一下,有很多的問題,例如這臺存放Hosts文件的主機會成為性能瓶頸,面臨巨大的流量壓力,而且每個域名解析的結果都要通過這個文件進行更新,更新的速度可想而知不會太及時。因此,DNS也沒有采用這種完全集中的解析方案。目前DNS采用的是分布式的解析方案。具體是這樣的,互聯(lián)網管理委員會規(guī)定,域名空間的解析權都歸根服務器所有,也就是說,根服務器對互聯(lián)網上所有的域名都享有完全的解析權!且慢,有讀者要提問了,那這個根服務器不就相當于全世界唯一的Hosts文件了嗎?呵呵,不要著急,根服務器用了一個簡單的操作,就改變了這種結構。根服務器使用的是什么操作?委派!下圖就是根服務器委派的示意圖,如下圖所示,根服務器把com結尾的域名解析權委派給其他的DNS服務器,以后所有以com結尾的域名根服務器就都不負責解析了,而由被委派的服務器負責解析。而且根服務器還把以net,org,edu,gov等結尾的域名都一一進行了委派,這些被委派的域名被稱為頂級域名,每個頂級域名都有預設的用途,例如com域名用于商業(yè)公司,edu域名用于教育機構,gov域名用于政府機關等等,這種頂級域名也被稱為頂級機構域名。根服務器還針對不同國家進行了域名委派,例如把所有以CN結尾的域名委派給中國互聯(lián)網管理中心,以JP結尾的域名委派給日本互聯(lián)網管理中心,CN,JP這些頂級域名被稱為頂級地理域名。每個被委派的DNS服務器同樣使用委派的方式向下發(fā)展,例如和訊公司想申請使用域名,這時和訊就要向負責.com域名的DNS服務器提出申請,只要還沒有被其他公司或個人使用,而且申請者按時足額繳納了費用,負責.com域名的服務器就會把域名委派到和訊公司自己的DNS服務器。只要DNS服務器使用委派,域名空間就會逐步形成現(xiàn)有的分布式解析架構。這種架構把域名解析權下放到各公司自己的DNS服務器上,既有利于及時更新記錄,同時對平衡流量壓力也很有好處。以上介紹的域名解析過程我們可以通過一個實驗來加以說明,Berlin是一個DNS服務器,IP地址為00,其他IP參數(shù)如下圖所示。我們現(xiàn)在用Berlin來解析一個域名,我們用抓包工具ethereal追蹤一下域名解析的軌跡。在DNS服務器上查詢/url,如下圖所示,DNS服務器已經解析了這個域名,但到底解析的過程是什么樣的呢?向下看!打開抓包工具Ethereal,如下圖所示,我們看到第8條記錄顯示DNS服務器Berlin向發(fā)出了一個查詢請求,請求解析/url,何許人也,13個根服務器之一!接下來看第9條記錄,給Berlin一個回應,告訴了Berlin這個域名解析問題應該詢問負責com區(qū)域的DNS服務器,而且還給出了負責com區(qū)域服務器的域名和IP地址。接下來的第10條記錄顯示了Berlin向0發(fā)出了域名解析請求,從上圖可知,0就是負責com區(qū)域的域名服務器之一,這次查詢會有什么樣的回應呢?從下圖的第11條記錄可以看出,負責com區(qū)域的域名服務器告訴Berlin,以結尾的域名已經委派出去,現(xiàn)在有四個服務器負責,Berlin可以向這四個服務器中的任何一個提出查詢請求。從第12條記錄可以看出,Berlin這次向6提出了查詢請求,6就是上圖中提到的負責區(qū)域的四個服務器之一。這次查詢會有什么樣的結果呢?如下圖的第13條記錄所示,這次查詢終于有了結果,負責的6終于告訴Berlin,/url對應的IP是5。詳解DNS的常用記錄(上)在上篇,我們介紹了DNS服務器的體系結構,從中我們了解到如果我們希望注冊一個域名,那么必須經過頂級域名服務器或其下級的域名服務器為我們申請的域名進行委派,把解析權委派到我們的DNS服務器上,這樣我們才可以獲得對所申請域名的解析權。本文中我們將再進一步,假設我們已經為公司成功申請了一個域名,現(xiàn)在的解析權被委派到公司的DNS服務器,那我們在服務器上該進行什么樣的配置呢?一 安裝DNS服務器首先我們要在服務器上安裝DNS組件,服務器的TCP/IP配置如下圖所示。安裝DNS組件非常簡單,依次點擊 控制面板添加或刪除程序添加/刪除Windows組件網絡服務,如下圖所示,選擇“域名系統(tǒng)”即可。二 創(chuàng)建區(qū)域DNS服務器創(chuàng)建完畢之后,我們接下來就要創(chuàng)建DNS區(qū)域了,區(qū)域是DNS服務器所負責的名稱空間,DNS服務器有正向區(qū)域和反向區(qū)域,正向區(qū)域負責把域名解析為IP,而反向區(qū)域負責把IP解析為域名。DNS區(qū)域有三種類型,正向區(qū)域,反向區(qū)域和存根區(qū)域。要理解區(qū)域類型,先要明白DNS服務器有主服務器和輔助服務器的區(qū)別。一般情況下,企業(yè)申請域名時會考慮配備兩個DNS服務器,一個是主服務器,另一個是輔助服務器。一般的解析請求由主服務器負責,輔助服務器的數(shù)據(jù)是從主服務器復制而來的,輔助服務器的數(shù)據(jù)是只讀的,當主服務器出現(xiàn)故障或由于負載太重無法響應客戶機的解析請求時,輔助服務器會挺身而出擔負起域名解析的任務。現(xiàn)在我們回過頭來解釋一下什么是主要區(qū)域,主服務器使用的區(qū)域就是主要區(qū)域,同樣,輔助服務器使用的區(qū)域是輔助區(qū)域。存根區(qū)域可以看做是一個特殊的,簡化的輔助區(qū)域,具體區(qū)別我們在后續(xù)博文中會加以介紹。一般我們使用較多的是正向區(qū)域,而且從邏輯上考慮,必然是先創(chuàng)建主要區(qū)域,因為輔助區(qū)域和存根區(qū)域都需要從主要區(qū)域復制數(shù)據(jù),因此我們現(xiàn)在的任務是要為區(qū)域創(chuàng)建一個正向的主要區(qū)域。如下圖所示,我們在DNS服務器上選擇創(chuàng)建一個正向區(qū)域。出現(xiàn)新建區(qū)域向導,點擊下一步繼續(xù)。選擇創(chuàng)建一個主要區(qū)域。區(qū)域名稱和申請的域名是一樣的,。區(qū)域數(shù)據(jù)文件是.dns,區(qū)域內的所有記錄都存儲在這個文件里,注意,這個文件我們以后會用到的。向導詢問是否允許區(qū)域動態(tài)更新,一般來說,如果DNS區(qū)域在企業(yè)內網使用,我們會允許動態(tài)更新;如果用于Internet,那么一般不需要動態(tài)更新。如下圖所示,區(qū)域創(chuàng)建完畢。區(qū)域創(chuàng)建完畢之后,如下圖所示,區(qū)域中只有一個NS記錄和一個SOA記錄,我們接下來要做的工作就是在區(qū)域中創(chuàng)建適當?shù)腄NS記錄。三 創(chuàng)建記錄DNS記錄是DNS區(qū)域數(shù)據(jù)的具體表現(xiàn)形式,我們接下來為大家介紹幾種最常見的DNS記錄,大家掌握了這些記錄就可以基本掌握DNS的基本應用了。1、 A記錄A記錄也稱為主機記錄,是使用最廣泛的DNS記錄,A記錄的基本作用就是說明一個域名對應的IP是多少,例如,我們想通過A記錄說明一臺主機的域名是,IP是85,那么我們就可以進行下列操作。如下圖所示,我們在區(qū)域中選擇“新建主機”。如下圖所示,我們在A記錄中說明了域名對應的IP是85。其中提到了一個完全合格域名的概念,這里我們介紹一下。完全合格域名指的是點結尾的域名,例如.就是一個完全合格域名。在一般的網絡應用中,我們可以省略完全合格域名最右側的點,但DNS對這個點不能隨便省略。因為這個點代表了DNS的根,有了這個點,完全合格域名就可以表達為一個絕對路徑,例如.就可以表示為DNS根下的com子域下域中一個名為bbs的主機。如果DNS發(fā)現(xiàn)一個域名不是以點結尾的完全合格域名,就會把這個域名加上當前的區(qū)域名稱作為后綴,讓其滿足完全合格域名的形式需求。例如DNS會把域名bbs處理為.。因此,如果要求輸入完全合格域名,我們應該注意讓域名以點結尾。A記錄的基本用法是描述域名和IP的對應關系,其實A記錄還有一個高級用法,A記錄有負載平衡的作用。DNS經常被用作一個低成本的負載平衡解決方案,主要就是依靠A記錄來實現(xiàn)的。舉個例子加以說明,例如我們有四個Web服務器共同負責/url這個網站,四個Web服務器的IP地址分別為1,2,3和4,那么我們就應該創(chuàng)建如下的主機記錄。以上我們用四條A記錄分別描述了/url對應的四個IP,那么,到底如何利用這些IP來實現(xiàn)負載平衡呢?原理是這樣的,客戶機訪問Web服務器一般都使用域名,因此需要利用DNS服務器把域名解析為IP。第一個客戶機查詢/url時,DNS服務器會告訴客戶機這個域名對應的IP是1,第二個客戶機來查詢時DNS服務器就會把答案改為2,依此類推,DNS使用了“輪詢”的技術把不同的訪問用戶導向了四個不同的Web服務器,這樣就達到了一個簡易負載平衡的效果。我們可以通過一個簡單的實驗來驗證一下DNS輪詢的效果,如下圖所示,我們在客戶機上用ping /url的方式來查詢域名對應的IP,但奇怪的是,客戶機兩次查詢域名得到的是同一個結果,這時為什么呢?難道DNS輪詢不起作用了嗎?其實并非DNS輪詢出了問題,而是由于客戶機有DNS緩存機制,當客戶機第一次查詢DNS服務器獲得了域名對應的IP地址,客戶機會把查詢結果放入緩存,這樣下次查詢時就直接從緩存獲取結果而不用去問DNS服務器了。明白了這個道理,我們只要用IPCONFIG/FLUSHDNS清除客戶機的DNS緩存就可以繼續(xù)實驗了,實驗結果如下圖所示,我們可以看到DNS輪詢已經發(fā)揮了作用。2、 NS記錄NS記錄和SOA記錄是任何一個DNS區(qū)域都不可或缺的兩條記錄,NS記錄也叫名稱服務器記錄,用于說明這個區(qū)域有哪些DNS服務器負責解析,SOA記錄說明負責解析的DNS服務器中哪一個是主服務器。因此,任何一個DNS區(qū)域都不可能缺少這兩條記錄。假設區(qū)域有兩個DNS服務器負責解析,是主服務器,是輔助服務器,的ip是,的ip是。那么我們應該創(chuàng)建兩條NS記錄,當然,NS記錄依賴A記錄的解析,我們首先應該為和創(chuàng)建兩條A記錄,創(chuàng)建的A記錄如下圖所示。有了兩條主機記錄的支持,我們就可以編輯ns記錄了,如下圖所示,當前區(qū)域的ns記錄是創(chuàng)建區(qū)域時系統(tǒng)自動創(chuàng)建的。這條ns記錄并不能正常工作,因為nsserver并不是一個可以解析的完全合格域名,因此我們刪除這條記錄,重新再創(chuàng)建兩條NS記錄。如下圖所示,我們創(chuàng)建一條ns記錄,ns服務器的完全合格域名是.,解析出的IP是,這條記錄說明有一個服務器負責的域名解析。用同樣方法創(chuàng)建的ns記錄,創(chuàng)建完成的結果如下圖所示。3、 SOA記錄NS記錄說明了有兩個DNS服務器負責的域名解析,但哪個是主服務器呢?NS記錄并沒有說明,這個任務由SOA記錄來完成。SOA記錄也稱為起始授權機構記錄,SOA記錄中負責說明哪個DNS服務器是主服務器,以及主服務器和輔助服務器之間的一些關聯(lián)參數(shù)。如下圖所示就是的SOA記錄,我們逐一進行分析。首先我們要分析序列號,序列號反映了DNS服務器數(shù)據(jù)變化的次數(shù),DNS服務器的數(shù)據(jù)每更新一次,序列號就加大一位。但我們仔細想想,對管理員來說,了解這個參數(shù)意義不大,因為DNS服務器到底是更新了10000次還是9999次對管理員來說并沒有實質性的影響。實際上,這個參數(shù)是給輔助服務器使用的。我們前面提到,輔助服務器的數(shù)據(jù)都是從主服務器復制而來的,那么輔助服務器怎么判斷主服務器的數(shù)據(jù)有沒有進行更新呢?輔助服務器只要簡單地檢查一下主服務器的序列號就明白了,如果主服務器的序列號比輔助服務器的序列號大,那么輔助服務器就應該去主服務器進行增量更新了。主服務器這個參數(shù)的重要性不言而喻,目前的SOA記錄中主服務器參數(shù)是nsserver.,這并不是一個可以解析的完全合格域名,我們應該把主服務器改為.,如下圖所示,這才是正確的主服務器參數(shù)??赡艽蠹視幸蓡枺瑸槭裁碞S記錄和SOA記錄默認都是nsserver.,主要是因為nsserver.是這臺DNS服務器的NETBIOS名稱。從上圖可知,我們把SOA記錄中的負責人參數(shù)改為了.,看起來象個主機的完全合格域名,其實意思是,是一個郵箱地址。那么為什么負責人這個參數(shù)不直接寫成呢?畢竟這樣就好理解多了,這時因為符號在DNS中有特殊含義,在DNS中代表當前區(qū)域,也就是代表,因此我們被迫把郵件地址寫成了完全合格域名的格式。刷新間隔指的是輔助服務器每隔15分鐘聯(lián)系一下主服務器,查看主服務器有無數(shù)據(jù)更新。重試間隔10分鐘值的是如果輔助服務器和主服務器失去了聯(lián)系,那么輔助服務器每隔10分鐘聯(lián)系一下主服務器,在此期間由輔助服務器負責當前區(qū)域的域名解析。過期時間是1天指的是如果輔助服務器過了一天還沒有聯(lián)系上主服務器,輔助服務器就會認為主服務器永遠不會再回來了,自己的數(shù)據(jù)也沒有保存的意義了,因此會宣布數(shù)據(jù)過期,并拒絕為用戶繼續(xù)提供解析服務。TTL一個小時指的是記錄在DNS緩存中的生存時間是一個小時。詳解DNS常用記錄(下)在上文中我們介紹了DNS服務器中幾種不可或缺的記錄,包括A記錄,NS記錄和SOA記錄。本文中我們將繼續(xù)為大家介紹DNS的另外幾種常用記錄,希望能對大家了解DNS有所幫助。四 MX記錄MX記錄也被稱為郵件交換器記錄,MX記錄用于說明哪臺服務器是當前區(qū)域的郵件服務器,例如在區(qū)域中,是郵件服務器,而且IP地址是25。那么我們就可以在DNS服務器中進行下列處理:1、 為郵件服務器創(chuàng)建A記錄如下圖所示,我們首先為郵件服務器創(chuàng)建一條A記錄,這時因為MX記錄中描述郵件服務器時不能使用IP地址,只能使用完全合格域名。2、 創(chuàng)建MX記錄如下圖所示,在DNS服務器中選擇創(chuàng)建MX記錄。MX記錄如下圖所示,這條MX記錄說明是的郵件服務器,而且優(yōu)先級是10。注意,如果區(qū)域有多個MX記錄,而且優(yōu)先級不同,那么其他郵局給發(fā)郵件時會首先把郵件發(fā)給優(yōu)先級最高的郵件服務器,代表優(yōu)先級的數(shù)字越低則優(yōu)先級越高,優(yōu)先級最高為0。MX記錄對郵件服務器來說是不可或缺的,兩個互聯(lián)網郵局系統(tǒng)在相互通訊時必須依賴DNS的MX記錄才能定位出對方的郵件服務器位置。例如163.net郵局給263.net郵局發(fā)一封電子郵件,那163郵局的SMTP服務器就需要向DNS服務器發(fā)出一個查詢請求,請DNS服務器查詢263.net的MX記錄,這樣163郵局的SMTP服務器就可以定位263.net的SMTP服務器,然后就可以把郵件發(fā)送到263郵局。我們通過一個例子來具體說明一下MX記錄的用途,我們在09上搭建了一個郵件服務器,我們利用這個郵件服務器給發(fā)送一封電子郵件,當郵件服務器給郵局發(fā)送郵件時,我們用抓包工具ethereal記錄抓包過程。如下圖所示,我們可以看出郵件服務器09在發(fā)送郵件時首先向DNS服務器發(fā)出一個查詢請求,請求查詢的MX記錄,DNS服務器告訴查詢者郵局的郵件服務器是,這樣09才知道應該把郵件發(fā)送到。五 Cname記錄Cname記錄也被稱為別名記錄,其實就是讓一個服務器有多個域名,大致相當于給一個人起個外號。為什么需要Cname記錄呢?一方面是照顧用戶的使用習慣,例如我們習慣把郵件服務器命名為mail,把ftp服務器命名為ftp,那如果只有一臺服務器,同時提供郵件服務和FTP服務,那我們究竟該怎么命名呢?我們可以把服務器命名為,然后再創(chuàng)建一個Cname記錄叫就可以兩者兼顧了。另外使用Cname記錄也有安全方面的考慮因素,例如我們不希望別人知道某個網站的真實域名,那我們可以讓用戶訪問網站的別名,例如我們訪問的百度網站的真實域名就是/url,我們使用的/url只是/url的別名而已。好,下面我們舉個創(chuàng)建Cname記錄的例子,假設我們要為創(chuàng)建一個別名,那我們就可以進行下列操作。如下圖所示,我們選擇在DNS服務器中創(chuàng)建Cname記錄。記錄內容如下圖所示,我們?yōu)閯?chuàng)建了一個別名記錄,別名是。對進行解析,結果如下圖所示,DNS服務器告訴我們就是。六 SRV記錄SRV記錄是服務器資源記錄的縮寫,SRV記錄是DNS記錄中的新鮮面孔,在RFC2052中才對SRV記錄進行了定義,因此很多老版本的DNS服務器并不支持SRV記錄。那么SRV記錄有什么用呢?SRV記錄的作用是說明一個服務器能夠提供什么樣的服務!SRV記錄在微軟的Active Directory中有著重要地位,大家知道在NT4時代域和DNS并沒有太多關系。但從Win2000開始,域就離不開DNS的幫助了,為什么呢?因為域內的計算機要依賴DNS的SRV記錄來定位域控制器!微軟的即時通訊服務器Live Communications Server也可以依靠SRV記錄定位即時通訊服務器,有鑒于SRV記錄可以定位特定服務器的位置,我們可以預計,在微軟將來的服務器產品中SRV記錄將發(fā)揮越來越多的作用。下面我們舉個例子說明SRV記錄的作用,假設在域中是一個Web服務器,在80端口提供網站服務,那么我們如何用SRV記錄說明這些信息呢?如下圖所示,我們在DNS服務器中選擇新建“其他新紀錄”。記錄類型我們選擇SRV。下圖是我們創(chuàng)建的SRV記錄,這條記錄的意思是服務器在域中提供HTTP服務,此服務基于TCP協(xié)議,守護在80端口。七 PTR記錄PTR記錄也被稱為指針記錄,PTR記錄是A記錄的逆向記錄,作用是把IP地址解析為域名。由于我們在前面提到過,DNS的反向區(qū)域負責從IP到域名的解析,因此如果要創(chuàng)建PTR記錄,必須在反向區(qū)域中創(chuàng)建。下面我們舉例說明如何創(chuàng)建反向區(qū)域以及PTR記錄。如下圖所示,我們在DNS服務器的反向區(qū)域中選擇“新建區(qū)域”。出現(xiàn)新建區(qū)域向導,選擇下一步繼續(xù)。區(qū)域類型選擇“主要區(qū)域”。向導要求輸入當前的網絡號,網絡號是IP地址和子網掩碼進行與運算后的結果,反向區(qū)域的名稱不能隨便設置,必須是顛倒的網絡號再加上后綴。例如當前的網絡號是202.99.16,那反向區(qū)域的名稱就應該是16.99.202.。設置反向區(qū)域的數(shù)據(jù)文件,使用默認值即可。這個區(qū)域也不需要動態(tài)更新。如下圖所示,反向區(qū)域創(chuàng)建完成。創(chuàng)建了反向區(qū)域之后,我們就可以在反向區(qū)域中創(chuàng)建PTR記錄了,如下圖所示,我們選擇在反向區(qū)域中創(chuàng)建PTR記錄。如下圖所示,我們創(chuàng)建的PTR記錄把解析為域名。創(chuàng)建了PTR記錄后,我們就可以把IP解析為域名了,下圖是我們用nslookup工具測試的結果,我們看到IP地址已經被正確地解析為域名了。其實當我們運行nslookup后,nslookup所做的第一件事就是把DNS服務器的IP地址進行反向解析。配置DNS輔助服務器在前文中,我們介紹了如何在DNS服務器中創(chuàng)建常用的DNS記錄,本文中我們要為大家介紹如何配置DNS的輔助服務器,同時也要介紹一下和輔助區(qū)域類似的存根區(qū)域。DNS輔助服務器是一種容錯設計,考慮的是一旦DNS主服務器出現(xiàn)故障或因負載太重無法及時響應客戶機請求,輔助服務器將挺身而出為主服務器排憂解難。輔助服務器的區(qū)域數(shù)據(jù)都是從主服務器復制而來,因此輔助服務器的數(shù)據(jù)都是只讀的,當然,如果有必要,我們可以很輕松地把輔助服務器升級為主服務器。我們通過下面的一個實驗為大家介紹如何配置DNS輔助服務器,如下圖所示,是的主服務器,是的輔助服務器。一 權限設置如果我們想把配置為的輔助服務器,首先我們要在主服務器上進行權限設置。出于安全原因,主服務器并不允許任意的DNS服務器從自己的區(qū)域中復制數(shù)據(jù),默認情況下,只有這個區(qū)域的DNS服務器才被允許成為輔助DNS服務器。如下圖所示,在區(qū)域的屬性中切換到“區(qū)域復制”標簽,我們發(fā)現(xiàn)默認設置是允許區(qū)域復制的,只是被允許的都是的域名服務器。切換到“名稱服務器”標簽,如下圖所示,區(qū)域有兩個名稱服務器,和,是主服務器,那么顯然就是獲得區(qū)域復制授權的輔助服務器了。二 創(chuàng)建輔助區(qū)域N獲得授權成為的輔助DNS服務器之后,我們就可以在上創(chuàng)建輔助區(qū)域了。如下圖所示,我們在輔助DNS服務器上選擇“新建區(qū)域”。如下圖所示,出現(xiàn)新建區(qū)域向導,點擊下一步繼續(xù)。區(qū)域類型選擇“輔助區(qū)域”,這是輔助服務器使用的區(qū)域類型。區(qū)域名稱是。區(qū)域的主服務器是,輔助服務器將從主服務器復制區(qū)域數(shù)據(jù)。如下圖所示,DNS輔助區(qū)域創(chuàng)建完畢。三 區(qū)域數(shù)據(jù)傳輸在上創(chuàng)建了DNS輔助區(qū)域后,我們發(fā)現(xiàn)輔助服務器不能從主服務器復制數(shù)據(jù),錯誤信息如下圖所示。出現(xiàn)上述故障不用擔心,DNS區(qū)域復制經常會遇到這種故障,基本都是由于新創(chuàng)建的DNS輔助區(qū)域沒有來得及和主服務器同步。我們稍微等上幾分鐘,然后刷新一下區(qū)域就正常了,如下圖所示,輔助服務器已經從主服務器復制了所有的區(qū)域數(shù)據(jù)。以后輔助服務器就會向SOA記錄中描述的那樣,每隔15分鐘檢查一下主服務器有沒有更新。一旦發(fā)現(xiàn)主服務器有新記錄,輔助服務器會立刻使用增量復制把主服務器的新記錄復制過來。四 存根區(qū)域Windows Server 2003在DNS中新推出了一種存根區(qū)域,相比以往的輔助區(qū)域,DNS管理員們又多了一種選擇。存根區(qū)域和輔助區(qū)域有類似之處,都要從區(qū)域的主服務器復制數(shù)據(jù)。不同之處在于,輔助區(qū)域復制區(qū)域中的所有記錄,但存根區(qū)域只復制區(qū)域的SOA記錄,NS記錄以及解析NS記錄的A記錄(也稱粘連記錄)。也就是說,存根區(qū)域并不需要在自己的區(qū)域中保存所有的DNS記錄,存根區(qū)域只要知道利用哪個DNS服務器可以對DNS記錄進行解析就可以了。下面我們在上刪除剛創(chuàng)建的輔助區(qū)域,重新創(chuàng)建一個存根區(qū)域,大家可以來比較一下存根區(qū)域和輔助區(qū)域有哪些區(qū)別。如下圖所示,我們在上選擇“新建區(qū)域”。區(qū)域類型選擇“存根區(qū)域”,如下圖所示,創(chuàng)建向導中已經對存根區(qū)域的工作性質進行了說明。存根區(qū)域的名稱是。區(qū)域數(shù)據(jù)的名稱是.dns。存根區(qū)域也需要從主服務器復制數(shù)據(jù),如下圖所示,的主服務器是。如下圖所示,存根區(qū)域創(chuàng)建完成。查看一下新創(chuàng)建的存根區(qū)域內容,如下圖所示,我們發(fā)現(xiàn)存根區(qū)域中只有SOA記錄,NS記錄以及與NS記錄相關聯(lián)的A記錄。也就是說,這個存根區(qū)域并沒有保存的所有DNS記錄,但它知道上擁有的全部記錄,如果需要解析記錄,可以向發(fā)起查詢請求。DNS的輔助服務器配置起來很簡單,只要注意好設置區(qū)域復制的權限即可,輔助服務器既可以幫助主服務器進行負載平衡,也是一個容錯設計,因此被DNS管理員普遍使用揭秘DNS后臺文件在前文中我們介紹了DNS的體系結構,常用記錄,還介紹了輔助服務器的配置,今天我們來介紹一下DNS服務器背后的幾個文件。其實DNS服務器的工作完全依靠這幾個文件,了解了DNS的后臺文件后,有利于更好地理解DNS服務器,也可以讓大家明白為什么有高手聲稱配置DNS最好的工具就是記事本。 DNS服務器所使用的文件并不復雜,一個是Boot文件,負責存儲DNS服務器的啟動信息;一個是Cache.dns,負責存儲根服務器的域名和IP地址;還有一個最重要的文件就是區(qū)域數(shù)據(jù)文件,負責存儲區(qū)域內的所有DNS記錄。這些文件都在WindowsSystem32DNS目錄下,我們找到負責解析區(qū)域的DNS服務器,來分析一下這個DNS服務器所使用的上述文件。一 Boot文件首先來看看Boot文件,奇怪的是,在DNS服務器C:WindowsSystem32DNS目錄下,我們并沒有發(fā)現(xiàn)Boot文件,具體如下圖所示,這時為什么呢?這時因為DNS的引導信息可以有三種保存的途徑,一是可以保存在Boot文件,二是可以保存在注冊表,三是可以保存在Active Directory。微軟可能是怕用戶誤刪除了Boot文件,因此默認情況下把引導信息用另外兩種方式保存。如果我們想查看Boot文件的內容,首先要修改DNS服務器引導信息的保存方式。如下圖所示,在DNS管理器中選擇查看DNS服務器的屬性。在DNS服務器屬性中切換到“高級”標簽,如下圖所示,選擇從文件加載區(qū)域數(shù)據(jù),這樣DNS服務器就會把啟動信息寫到Boot文件中。如下圖所示,Boot文件終于出現(xiàn)了!用記事本打開boot文件查看一下,其實內容很簡單,Primay代表DNS服務器是當前區(qū)域的主服務器,從Boot文件可以看到,當前的DNS服務器是區(qū)域的主服務器,同時也是16.99.202.區(qū)域的主服務器。但并不是根域的DNS服務器,要想解析根域,需要依靠cache.dns,chache.dns中記錄了13個根服務器的域名和IP地址。是的輔助服務器,我們看看它的Boot文件內容是什么。如下圖所示,secondary表示是當前區(qū)域的輔助服務器,主服務器是,根域的解析也是要依靠cache.dns中的13個根服務器??偨Y:看了兩個例子,我們發(fā)現(xiàn)DNS服務器中的Boot文件其實很簡單,就是描述了當前的DNS服務器負責哪些區(qū)域,是區(qū)域的主服務器還是輔助服務器,區(qū)域數(shù)據(jù)文件放在哪里等問題。我們完全可以利用Boot文件控制DNS啟動時加載的區(qū)域數(shù)據(jù),也可以改變DNS服務器的角色,例如從輔助服務器改為主服務器。二 Cache.dns以前我們介紹DNS體系結構時曾經描述過域名解析的過程:DNS服務器發(fā)現(xiàn)一個域名自己不能解析,就會把這個查詢提交給根服務器,根服務器通過迭代方式可以讓DNS服務器最終找到答案。這個過程中有個關鍵問題,DNS服務器怎么知道誰是互聯(lián)網上的根服務器呢?答案現(xiàn)在就可以揭曉了,Cache.dns中存儲了13個根服務器的域名和IP地址!這13個根服務器除了在東京,倫敦,斯德哥爾摩各有一臺,其余都在美國。如下圖所示,Cache.dns中描述了13臺服務器的完全合格域名以及IP地址,其中是個縮寫,代表當前區(qū)域,也就是根域。每個服務器用兩條記錄描述,一條記錄是NS記錄類型,一條是A記錄類型。NS記錄說明誰是根域的DNS服務器,A記錄說明這臺DNS服務器的IP地址是多少。Cache.dns的內容也可以通過DNS服務器屬性中的“根提示”來查看,如下圖所示,我們查看DNS服務器的屬性,在屬性中切換到“根提示”標簽,所看到的內容就是cache.dns中所描述的13個根服務器??偨Y:Cache.dns中記錄了互聯(lián)網上13個根服務器的域名和IP,我們有很多地方需要利用Cache.dns,例如北京新增加了一個DNS根服務器,但Win2003并不知道這個變化,這時我們就需要通過修改Cache.dns來完成這個工作。或者是假設一個大企業(yè)使用了私有根,自己做了一個根服務器,這時也要修改Cache.dns才能讓DNS服務器知道這個私有根的存在。三 區(qū)域數(shù)據(jù)文件接下來我們要介紹的就是

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯(lián)系上傳者。文件的所有權益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網頁內容里面會有圖紙預覽,若沒有圖紙預覽就沒有圖紙。
  • 4. 未經權益所有人同意不得將文件中的內容挪作商業(yè)或盈利用途。
  • 5. 人人文庫網僅提供信息存儲空間,僅對用戶上傳內容的表現(xiàn)方式做保護處理,對用戶上傳分享的文檔內容本身不做任何修改或編輯,并不能對任何下載內容負責。
  • 6. 下載文件中如有侵權或不適當內容,請與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準確性、安全性和完整性, 同時也不承擔用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

評論

0/150

提交評論