DNS1034中文版
域名的概念與機制1. 介紹本文主要介紹域名（DNS ）的一些機制及實現(xiàn)方法，下面我們就具體看一下它的情況。1.1. 域名的歷史產(chǎn)生域名的的根本動機在于管理方便，原來的主機名與IP 地址映射是保存在NI
域名的概念與機制
1. 介紹
本文主要介紹域名（DNS ）的一些機制及實現(xiàn)方法，下面我們就具體看一下它的情況。
1.1. 域名的歷史
產(chǎn)生域名的的根本動機在于管理方便，原來的主機名與IP 地址映射是保存在NIC 的hosts .txt 文件中的，當時因為主機數(shù)量少，這個文件也不經(jīng)常變化，因此其它主機幾天一次 從NIC 的主機上下載這個文件進行主機名和IP 地址映射就可以了。但隨著網(wǎng)絡的發(fā)展，這 種方法變得無法使用，因為經(jīng)常會有主機要求下載，對NIC 的主機造成巨大的壓力，而且 也不能保證服務的質(zhì)量。許多局域網(wǎng)用戶希望自己管理自己的主機名，而不希望等NIC 許 多天把自己的主機名加在hosts.txt 文件中，有些組織也希望有自己的名字空間配置。是 需要一個能夠簡單管理的方法了。最后決定使用層次式的名字空間組織方案，以. 為分隔 標準不同的層次。整個名字空間以分布式數(shù)據(jù)庫管理。請看閱讀前不要把平常的域名和 這里的域名系統(tǒng)混在一起。最好的方法就是把原來的觀念忘記了，看現(xiàn)在的新東西。
1.2. DNS設計目標
DNS 的設置目標影響了它的結(jié)構(gòu)，主要目標是對資源有一個一致的名字空間，為了避免不 同編碼帶來的問題，需要包括網(wǎng)絡標記，地址，路由或其它信息作為名字的一部分。出 于對實驗數(shù)據(jù)的分析，看來分布式的存儲條件是必須的。要在獲取數(shù)據(jù)的代價和數(shù)據(jù)準 確性之間有一個平衡。需要對名字所代表的資源類型有一個標記。要支持多協(xié)議訪問。 名字服務器操作獨立于通信系統(tǒng)。應該能夠使用不同的機器都能夠使用這一系統(tǒng)，使用 的方法可能不同，但是都要能夠使用。
1.3. 基于使用的一些假設
設計系統(tǒng)時是基于下面假設進行的：數(shù)據(jù)庫的初始大小和使用系統(tǒng)的主機成正比，但最 后數(shù)據(jù)庫的大小會和用戶的數(shù)目成正比，這一過程會發(fā)生在一些資源（如郵箱和其它一 些要加入到域名系統(tǒng)中的信息）進入系統(tǒng)開始；大部分的數(shù)據(jù)改變比較慢，但系統(tǒng)能夠 對改變有一些快速的適應。由相應的組織負責分布式數(shù)據(jù)庫的維護。域名系統(tǒng)的用戶可 以選擇自己喜歡的主機。因為其中的數(shù)據(jù)十分敏感而且重要，因此一定要保證正確性， 如果因為主機或網(wǎng)絡失敗而造成無法為用戶服務，用戶要以原來的數(shù)據(jù)為準，不要自己 胡亂想一個數(shù)據(jù)就用。在查詢的時候要避免循環(huán)查詢，一種方法是將未找到這一信息返 回給用戶，讓用戶再找新的主機尋找相應的地址，一種是由主機找別的主機尋找相應的 地址，找到后由相應的主機返回地址給用戶，這兩個方法各有好處。域名系統(tǒng)假設所有 的數(shù)據(jù)是在一個主文件中保存，這個主文件的內(nèi)容分布存儲于系統(tǒng)中的各臺主機上。用 戶通過標準的查詢程序resolover 查詢。主文件的標準形式使得它可以在不同主機間進行 傳輸（利用FTP ，電子郵件等方式）。本地可以使用文本編輯器進行管理，然后將這個文 件傳輸?shù)矫址掌髂抢铮缓笸ㄖ址掌鞯墓芾韱T加載這個文件就是了。對于re solver 來說，配置好的名字服務器是地址信息的主要來源。域名系統(tǒng)定義了訪問數(shù)據(jù)的 過程和訪問其它名字服務器的方法，它還定義了緩沖的大小和更新緩沖的時間等配置信 息。
系統(tǒng)管理員需要提供：
區(qū)域（zone ）邊界定義
主文件數(shù)據(jù)
主文件的更新
更新策略描述
域名系統(tǒng)需要提供：
,源數(shù)據(jù)的標準格式
查詢數(shù)據(jù)庫的標準方法
多其它名字服務器上更新數(shù)據(jù)的標準方法
1.4. DNS組成
DNS 由下面三個部分組成：
域名空間和資源記錄，域名空間是一個樹狀結(jié)構(gòu)，資源記錄是與名字相關的一些數(shù)據(jù)。 從概念上說，每個結(jié)點和域名空間樹的葉子結(jié)點都有一定的信息，而查詢是要查詢出一 些與之相關的特定信息。
名字服務器是服務器程序，它保留域名樹結(jié)構(gòu)和相應的信息，它可以緩沖各種數(shù)據(jù)，保 存域名樹中的任何部分，但是通常它保存域名空間的一個子集，如果需要查詢其它信息 可以通過指向其它名字服務器的地址尋找。這個名字服務器是這一部分的認證權(quán)威，所 有的認證信息組成一個單元稱為區(qū)，這些區(qū)可以分布于不同的服務器上以保證數(shù)據(jù)的冗 余。
resolver 是向名字服務器提出查詢請求并將結(jié)果返回給客戶的程序，它必須可以訪問至 少一個名字服務器，并將結(jié)果直接返回給用戶或向別的名字服務器查詢。它通常是用戶 可以訪問的系統(tǒng)方法，在resolver 和用戶程序之間不需要協(xié)議。
下面我們通過三個不同的角度來看看它們的相互關系：
從用戶的角度，域名系統(tǒng)可以通過簡單的過程或操作系統(tǒng)調(diào)用來調(diào)用本地resolver 進行 查詢。域名空間包括一個單獨的樹，用戶可以從樹中的任何一個部分查詢信息。
從resolver 的角度，域名系統(tǒng)由一些名字服務器組成，每個服務器有域樹的整個或部分 數(shù)據(jù)，resolver 將這些數(shù)據(jù)庫視為基本是靜態(tài)的。
從名字服務器的角度，域名系統(tǒng)由稱為區(qū)（zone ）的本地數(shù)據(jù)集組成，名字服務器必須 定期從主備份上更新自己區(qū)內(nèi)的數(shù)據(jù)，它還必須處理從resovler 傳送來的查詢請求。
2. 域名空間和資源記錄
2.1. 定義和名詞
域名空間是樹狀結(jié)構(gòu)，每個結(jié)點和資源集相對應（這個資源集可能為空），域名系統(tǒng)不 區(qū)別樹內(nèi)結(jié)點和葉子結(jié)點，統(tǒng)稱為結(jié)點。每個結(jié)點有一個標記，這個標記的長度為0到6 3個字節(jié)。不同的結(jié)點可以使用相同的標記。0長度的標記（空標記）為根記錄保留。結(jié) 點的域名是從結(jié)點到根的標記組成的。這些標記對大小寫不敏感，這就是說，A 和a 對域 名是等效的。但是你在收到域名時最好保留它的大小寫狀態(tài)以便以后的服務擴展便于使 用。
用戶需要輸入域名時，每個節(jié)點的標記長度不管多長，總要以點分隔。絕對域名的最后 總以點結(jié)束，例如"poneria.ISI.EDU." ，而相對域名則不這樣，它由本地域指明位置即 可。相對域名相對于一個公認的域名或相對于用作搜索列的一串域名。相對名通常在用 戶接口出現(xiàn)，在用戶接口，表示方法因?qū)崿F(xiàn)不同而不同，相對域名也出現(xiàn)在主文件中， 主文件相對于一個源域名而設立。為了簡化實現(xiàn)，整個域名的長度不得大于255個字節(jié)。 域由域名標記，它由其下的域組成。如果一個域包括在另一域中，則稱它為這個域的子 域。我們可能通過表示很直觀的看出。如A.B.C.D 是B.C.D ，C.D ，D 和" "的子域。
2.2. 管理規(guī)范
作為策略，DNS 技術(shù)說明未說明一個特定的樹結(jié)構(gòu)或什么規(guī)則來選擇標記，此說明希望達 到的目的是越簡單越好。應用程序的開發(fā)可以不管名字空間的邊界和名字服務器的存在 。這不是說沒有規(guī)矩地亂來，而是把規(guī)則制定得開放以便于處理問題，樹的不同部分可 以有不同的規(guī)則。例如IN-ADDR.ARPA 分布在網(wǎng)絡各處，用于將網(wǎng)絡或主機號轉(zhuǎn)換為主機 名，而NetBIOS 域是平面式的，原因很簡單，這樣便于應用。但是，對于名字空間的通常
,部分，我們還是有規(guī)定的，目的是為了應用起來比較方便。低層域名最終被分為多個區(qū) ，這樣的域應該在頂層域上提供一個標記使最終的解析可能不必重名字就可以完成。在 管理的時候，老的軟件可能不支持結(jié)點標記中的數(shù)字，特殊字符。
2.3. 技術(shù)規(guī)范
在DNS 能夠被用來為某些種類的結(jié)點保存名字信息前，必須滿足下面兩個條件： 要有在對象名和域之間映射的規(guī)則，這個規(guī)則描述了關于對象的信息如何被訪問 需要有描述對象的RR 類型和數(shù)據(jù)格式
這些規(guī)則可煩可簡，規(guī)則者要考慮到對現(xiàn)在格式和以后格式的兼容問題。多映射或映射 分層是必須的。對于主機，映射取決于主機名的現(xiàn)有格式，它是通常文本表示域名的子 集，加上描述主機地址的RR 格式。因為我們需要從地址到主機的可靠映射，所以定義了 將地址映射到IN-ADDR.ARPA 域的方法。
對了郵箱，映射會復雜一些。通常的郵件地址
域名解析方法進行解析，這兩部分組合形成一個域名。因此郵件地址HOSTMASTER@SRI-N IC.ARPA ，會變?yōu)镠OSTMASTER.SRI-NIC.ARPA 。通常的用戶不關心這些定義的規(guī)則，但用
戶應該理解它們使用的是一種的許多要求的綜合產(chǎn)物，有要求兼容老產(chǎn)品的，有要求添 加新功能的。
2.4. 例子
下圖是現(xiàn)在域名系統(tǒng)的一個部分，它在本文中還會經(jīng)常被用到。請注意，這個樹只是實 際樹的一個小小的子樹。
|
--------------------- ------------------
| | |
MIL EDU ARPA
| | |
----- ----- | ------ ----- -----
| | | | | | |
BRL NOSC DARPA | IN-ADDR SRI-NIC ACC
|
-------- ------------------ --------------- --------
| | | | |
UCI MIT | UDEL YALE
| ISI
| |
--- --- |
| | |
LCS ACHILLES -- ----- ----- --------
| | | | | |
XX A C VAXA VENERA Mockapetris
在此例中，根域有三個子域：MIL ，EDU 和ARPA ，而LCS.MIT.EDU 域有一個子域XX.LCS.MI T.EDU ，其它的節(jié)點也是域。
2.5. 命名規(guī)則
DNS 的命名規(guī)則是為了使對域名的命名比較統(tǒng)一。也就是要將任何現(xiàn)存的對象都可以在最
,小改動的情況下變?yōu)橛蛎Ｖ斏鞯氖褂谜邥x擇域名適合域名系統(tǒng)和應用程序。例如在 命名郵件域名時，使用者會同時遵守相應的郵件協(xié)議。這就使對老軟件的兼容性提高了 。下面的規(guī)則是一個較少引起問題的規(guī)則:
請注意：域名內(nèi)不分大小寫。標記必須遵守ARPANET 主機名規(guī)則，它要求主機名必須以字 母開始，以字母或數(shù)字結(jié)束，中間的可以是數(shù)字字母或連字符，長度沒有限制。但標記 必須少于63個字符。下面的字符串就表示了APARNET 中的主機：
A.ISI.EDU XX.LCS.MIT.EDU SRI-NIC.ARPA
2.6. 資源記錄
域名標記結(jié)點，每個結(jié)點都有資源信息集，些集可以為空。資源信息集和由分離資源集 （RR ）的特殊名字相關聯(lián)。在集中的RR 順序沒有關系，標記有這東西就是了，它不用由 名字服務器，resovler 或DNS 的其它部分保存，只在這兒有。特定的RR 我們認為有以下幾 個：
owner
RR 能夠被找到的域名
它是一個16位值，指定RR 內(nèi)的資源類型，它指一個抽象資源，具體的標記有以下幾個： A
主機地址
CNAME
一個擬名的統(tǒng)一命名
HINFO
標記由主機使用折CPU 和OS
MX
標記用于域的郵件交換資源
NS
此域的權(quán)威認證名字服務器
PTR
指向其它域名空間的指針
SOA
標記區(qū)認證權(quán)威的開始
class
它是一個16位值，標記協(xié)議族或某一個協(xié)議實例，本文中使用IN 代表internet 系統(tǒng)，C H 代表Chaos 系統(tǒng)
TTL
它是RR 的生存時間，它是32位整數(shù)，單位是秒，它主要用于resolver 緩存RR 多長時間 它是一種類型，有時是依賴于數(shù)據(jù)的類，它描述了以下資源：
A
,對于class 是IN 的，它是一個32位IP 地址，對于CH ，它是后面跟一個16位八進制Chaos 地
址的域名
CNAME
域名
MX
作為一個域的郵件服務資源的主機名，主機名后有一個16位的配置值
NS
主機名
PTR
域名
SOA
一些域
擁有資源的名字通常是隱式的，不構(gòu)成RR 的一部分。TTL 時間只影響緩沖內(nèi)的數(shù)據(jù)，不影 響區(qū)內(nèi)的已經(jīng)保存的認證數(shù)據(jù)。TTL 通常由管理員設置，TTL=0表示禁止緩沖。RDATA 內(nèi)的
數(shù)據(jù)是二進制串和域名的混合。域名通常使用指針指向DNS 內(nèi)的其它數(shù)據(jù)。
2.6.1. RR的文本表示
RR 在DNS 中是以二進制形式表示的，而在名字服務器或resolver 中保存的時是經(jīng)過壓縮編 碼處理的。本文中我們采用相同于主文件中表示的表示方法，也就是不壓縮的方法，以 便顯示RR 的內(nèi)容。行開始時給出誰擁有RR ，如果這一位置空出，就表示本行RR 的擁有者
和上面RR 的擁有者是一個。其后是TTL ，type 和RR 的class 。RR 的RDATA 部分是在當前數(shù)據(jù)
的表示類型的基礎上得到的。下面是一些RR 的例子：
ISI.EDU. MX 10 VENERA.ISI.EDU.
MX 10 VAXA.ISI.EDU.
VENERA.ISI.EDU. A 128.9.0.32
A 10.1.0.52
V AXA.ISI.EDU. A 10.2.0.27
A 128.9.0.33
其中我們注意到MX 那一部分，它的RDA TA 部分有是一個16位數(shù)后面跟一個域名組成。其它
的也就不說了。本例子顯示了6個RR ，第三個域名有兩個RR 。下面是一個例子，它顯示在 不同的class 下如何表示：
XX.LCS.MIT.EDU. IN A 10.0.0.44
CH A MIT.EDU. 2420
2.6.2. 別名和統(tǒng)一命名
現(xiàn)存的系統(tǒng)中有時會對相同的資源有不同的命名，不但主機是這樣，郵箱也是這樣，不 同的名字指向的是同一個位置。大部分系統(tǒng)都能夠?qū)Χ鄠€名字指定一個是統(tǒng)一命名的結(jié) 果，另外的是別名。域名系統(tǒng)提供使用統(tǒng)一命名的機制（CNAME RR ），CNAME RR 標記它
的owner 名為別名，并指出在RDA TA 部分的相應統(tǒng)一命名。如果一個結(jié)點存在CNAME RR， 不應該有其它的數(shù)據(jù)，這保證了統(tǒng)一命名和它的別名不能不同。這也使得緩沖的CNAME
,可
以不用檢索認證權(quán)威服務器就可以提供服務。在有CNAME RR時，DNS 軟件如果查詢不到與
域名相關的資源，它會檢查資源集中是不是有一個有匹配class 的CNAME ，如果有，名字 服務器返回的應答中包括這個CNAME 記錄，并根據(jù)在CNAME 中指定的數(shù)據(jù)開始新的查詢。
下面我們看一個例子，假設名字服務器處理對USC-ISIC.ARPA 的查詢，它要求查詢A 信息 ，下面是RR 的內(nèi)容：
USC-ISIC.ARPA IN CNAME C.ISI.EDU
C.ISI.EDU IN A 10.0.0.52
這兩個RR 都作為響應返回，而只查詢CNAME 的*查詢則只返回CNAME 。
RR 中指向其它名字的域名應該指向主名而不是別名，這就避免了查詢中過多的轉(zhuǎn)向查詢 。例如，對于上面的RR ，它的IN-ADDR.ARPA 記錄應該是：
52.0.0.10.IN-ADDR.ARPA IN PTR C.ISI.EDU
最后指向的是C.ISI.EDU ，而不是USC-ISIC.ARPA ，當然一個健壯的域名軟件不會因為提 供了循環(huán)的CNAME 而失敗。
2.7. 查詢
查詢就是發(fā)向名字服務器要求響應的一個請求。在Internet 上，這種請求以UDP 或TCP 傳 輸，名字服務器的響應可以是查詢結(jié)果，或是另一個名字名字器地址，要么就是一個錯 誤信息。通常用戶并不直接發(fā)送請求，而是向resolver 發(fā)送請求，由resolver 依次將一 個或多個請求發(fā)向名字服務器，并負責處理錯誤情況。請求和響應有標準格式，它們包 括一個頭和數(shù)個固定的域，然后是包括查詢參數(shù)和RR 的四個部分。頭中最重要的域是稱 為操作符的東西，它指出要進行什么操作。在所有可能的16個值中，標準查詢是必須的 ，反向查詢和狀態(tài)查詢是可選的，有一個完全查詢已經(jīng)過時，其它的還未指定。而上面 的提到的四個部分如下：
Question
包括查詢名和其它參數(shù)
Answer
包括查詢結(jié)果的RR
Authority
包括一個RR ，但這個RR 包括的是另一個名字服務器
Additional
包括了一個些在其它部分中使用RR 時會有用的信息
請注意：因頭中操作符（碼）的不同，這些部分的內(nèi)容可能不同，但格式可是一樣的。
2.7.1. 標準查詢
標準查詢指定一個目標域名（QNAME ），查詢類型（QTYPE ）和查詢類（QCLASS ），然后 尋找相應的RR ，這類的查詢占了DNS 查詢的絕大部分，如果未有特殊說明，一般都指這種
查詢。
QTYPE 和QCLASS 域為16位，是定義的type 和class 的超集。QTYPE 域可以包括：
AXFR ：由QTYPE 指定的特定區(qū)
MAILB ：和RR 相關的所有郵箱
*：所有RR 類型
,QCLASS 域可以包括：
*：所有的RR 類
使用查詢域名，QTYPE 和QCLASS ，名字服務器就會檢查相應的RR ，服務器可以返回一個可
能包括相應RR 的服務器名。例如：希望向Mockapetris@ISI.EDU發(fā)郵件，應用程序會向r esolver 要求了解關于ISI.EDU 的信息，會產(chǎn)生下面的查詢：QNAME=ISI.EDU，QTYPE=MX， QCLASS=IN，可能產(chǎn)生響應的區(qū)可能是：
ISI.EDU. MX 10 VENERA.ISI.EDU.
MX 10 VAXA.ISI.EDU.
隨此以外還有：
V AXA.ISI.EDU. A 10.2.0.27
A 128.9.0.33
VENERA.ISI.EDU. A 10.1.0.52
A 128.9.0.32
服務器假設如果請求者希望得到郵件交換（exchange ）信息，它會馬上請求交換服務器 的地址，所以找到兩個。這里需要注意QCLASS=*類型的查詢，因為服務器不可能知道了 解域名系統(tǒng)中所有類的可用信息，它也不是所有類的認證權(quán)威，因此這類查詢不能得到 認證。
2.7.2. 反向查詢（可選）
名字服務器可以反映資源和域名之間的映射關系。標準查詢可以對將域名映射到SOA RR ，相應的反向查詢則映射SOA RR到域名。
對于名字服務器來說這種實現(xiàn)是可選的，但是所有的名字服務器必須至少能夠理解反向 查詢消息，不能說發(fā)來的消息當不知道。域名系統(tǒng)不保證反向查詢的完全和唯一性，因 為系統(tǒng)是按照域名而非主機地址或其它資源類型安排的。反向查詢主要用于調(diào)試，以及 和數(shù)據(jù)庫支持相關的活動中。反向查詢可以不返回正確的TTL ，也不標明RR 是某個集合中 的一員，我們不知道它是不是唯一的，因此反向查詢的結(jié)果不緩沖。反向查詢對于映射 主機地址到主機名是不合適的，此時要用IN-ADDR.ARPA 域。
2.8. 狀態(tài)查詢（實驗中）
沒有定義
2.9. 完整查詢（過時的）
這里就不說了，以后可能會支持重設計（redegsign ）服務。
3. 名字服務器
3.1. 介紹
名字服務器保存了許多信息，這些信息組成了域數(shù)據(jù)庫。數(shù)據(jù)庫被分為區(qū)，這些區(qū)在不 同的服務器上保存。服務器可以有不同的可選函數(shù)和數(shù)據(jù)源，它最基本的工作是響應查 詢，它的響應是是一種簡單的形式進行的，響應可以僅根據(jù)本地數(shù)據(jù)作出，也可以根據(jù) 其它相關服務器而做出。一個給定的區(qū)可以根據(jù)不同的服務器來保證其有效性，通過管 理命令，用戶可以查詢由至少兩臺服務器保存的一個區(qū)上的數(shù)據(jù)，多臺服務器保存信息 保證了適當?shù)娜哂唷?/p>
給定的名字服務器通常支持一個或多個區(qū)，但只充當域樹一小部分的認證權(quán)威。它有一 些緩沖的非認證信息，這些信息是域樹其它部分的，在響應查詢時名字服務器會給出什 么時它認證的，什么是它緩沖的。
3.2. 數(shù)據(jù)庫如何被劃分為區(qū)
,劃分數(shù)據(jù)庫有兩種方法，一種是根據(jù)class ，另一種是在名字空間的結(jié)點間進行分隔，而 產(chǎn)生，我們稱這種分隔為cut 。class （以下我們稱為類）分隔比較簡單，在傳統(tǒng)上，名 字空間和所有類是一回事，分隔的類可被認為是一系列平行的名字空間樹。創(chuàng)建新類的 通常理由是要為已有的類型創(chuàng)建新的數(shù)據(jù)格式，或是為了對已有的名字空間進行分隔管 理。在一個類中可在兩個相鄰的結(jié)點進行cut （以下我們稱為切分），在所有的切分完成 后，相連空間的每個組就是一個獨立的區(qū)。此區(qū)是在相連區(qū)域內(nèi)所有數(shù)據(jù)的認證權(quán)威。 這種方法意味著所有的區(qū)至少有一個結(jié)點，域名和所有特定區(qū)內(nèi)的結(jié)點是相連的。給定 的樹型結(jié)構(gòu)一定有一個點更加靠近根，我們用這個點標記這個區(qū)。雖然可能沒什么用， 也可以將每個域名分在不同的區(qū)中，也可以讓所有的結(jié)點在一個區(qū)中。另外，數(shù)據(jù)庫也 可根據(jù)不同企業(yè)對名字的控制進行劃分，有些企業(yè)可能希望自己管理某一部分域名子樹 ，這時這個企業(yè)就可以對域名進行相應的增加或刪除操作，可以自己加入自己的下一級 域名。當然，這個企業(yè)也可以對自己管理的名字空間進行進一步劃分。
3.2.1. 技術(shù)問題
描述一個區(qū)的數(shù)據(jù)有四部分：
區(qū)中所有結(jié)點的認證數(shù)據(jù)
定義區(qū)內(nèi)頂結(jié)點的數(shù)據(jù)（此數(shù)據(jù)可被認為是認證數(shù)據(jù)的一部分）
描述代表子區(qū)的數(shù)據(jù)
訪問服務器子區(qū)的數(shù)據(jù)（我們也稱為“相關”（glue ）數(shù)據(jù)）
所有這些數(shù)據(jù)以RR 的形式表示，所有區(qū)可以被RR 集的形式描述。通過傳輸RR ，可以傳輸
整個區(qū)，具體的方法可以是通過FTP 傳輸相應的文本文件，或是通過網(wǎng)絡消息的形式傳輸 。一個區(qū)的認證數(shù)據(jù)是所有的RR ，這些RR 和樹中所有的結(jié)點是關聯(lián)的，要么就是切分后 的結(jié)點關聯(lián)。描述頂結(jié)點的RR 對于區(qū)的管理特別重要，這些RR 有兩種類型，名字服務器 RR ，它描述了區(qū)中的服務器列表；另一種是SOA RR，它描述的區(qū)的管理參數(shù)。
描述切分的RR 是NS RR，因為切分是在結(jié)點間進行的，所有RR 不是區(qū)認證數(shù)據(jù)的一部分， 它應該和相應的在子區(qū)內(nèi)的頂結(jié)點一致。因為名字服務器通常和區(qū)邊界相關，NS RR只在 一些區(qū)的頂結(jié)點上有。在組成一個區(qū)的數(shù)據(jù)中，NS RR在頂層結(jié)點和在邊界底的切分處出 現(xiàn)，不在其它地方。
區(qū)結(jié)構(gòu)所要實現(xiàn)的一個目標是任何區(qū)都有足夠的數(shù)據(jù)可以和任何子區(qū)建立通信。也就是 說，父區(qū)有足夠的信息可以訪問子區(qū)中的任何一臺名字服務器。NS RR命名了子區(qū)服務器 ，它不足以完成上面的要求，因此有了名字但仍然不知道地址。特別地，如果名字服務 器的名字在子區(qū)內(nèi)是它自己，我們就無法知道通過它的任何信息了。為了解決這一問題 ，區(qū)中包括了一個關聯(lián)RR ，它不是認證權(quán)威數(shù)據(jù)的一部分，但它表示了服務器的地址。 如果名字服務器名在切分下，就需要這些RR 了。
3.2.2. 管理問題
當有些組織希望掌握自己的域時，第一步是標記合適的父區(qū)，然后取得父區(qū)中管理結(jié)點 的許可來管理。管理的時候沒有什么具體的技術(shù)問題，可是還是有一些規(guī)則的，對中型 的區(qū)可以沒有這些規(guī)定，但是小型的就不行了。本文不具體討論這一問題了，有興趣可 參閱相關的資料。
一旦選擇了子區(qū)的名字，此區(qū)的新管理結(jié)點要冗余的名字服務器來支持。注意：沒有要 求一個區(qū)的服務器必須在此域中有名字的主機上。在許多種情況下，一個區(qū)要想被更容 易地訪問到最好把內(nèi)容放得分散一點，不要集中在一起?，F(xiàn)在許多國家的名字服務器是 放置在別國的，這樣在取得名字解析的時候不用把請求千里迢迢送到遠程主機上去了。 作為配置的最后一步，就是要選擇NS RR和關聯(lián)RR 。
,3.3. 深入名字服務器
3.3.1. 查詢和響應
名字服務器的主要內(nèi)容就是響應標準查詢。查詢和響應有專用的格式，查詢包括QTYPE ， QCLASS 和QNAME ，它描述了需要數(shù)據(jù)的類型，類（class ）和名字。服務器的響應取決于 它支持不支持循環(huán)查詢：
最簡單的是不支持循環(huán)查詢，它返回的要么是本地信息，要么是一個錯誤碼，告訴用戶 你要的信息這里沒有，然后再返回一個鄰近服務器的地址，讓用戶到那里去查一查。 如果支持循環(huán)查詢，那名字服務器如果未能在本地找到相應的信息，就代替用戶向其它 服務器進行查詢，這時它是代替用戶扮演了resolver 的角色，直到最后把結(jié)果找到（也 可能根本沒有結(jié)果，那就返回錯誤），并返回給用戶為止。
使用循環(huán)查詢要客戶和服務器雙方都支持才行。這個信息通過查詢和響應中的兩位來交 換：
如果允許循環(huán)查詢則設置RA 位，服務器方可以不管客戶是否進行請求而直接設置此位 查詢中如果請求循環(huán)查詢則設置RD 位，客戶只有在知道服務器方支持循環(huán)查詢后才能夠 進行循環(huán)查詢請求
客戶可以在響應中同時設置RA 和RD 位來確認是否支持循環(huán)查詢請求。請注意：服務器在 客戶未指明RD 位時不會自己進行循環(huán)查詢。
如果請求了循環(huán)查詢，同時也支持循環(huán)查詢，對查詢的響應會是以下之一：
查詢指定的CNAME RR有多個別名
指定的名字服務器不存在
臨時錯誤
如果未請求循環(huán)查詢或不支持循環(huán)查詢，則響應可以可能是：
- 認證權(quán)威服務器指出名字不存在
- 臨時錯誤
另外還會提供一些信息，指出所查詢的RR 是否從一個區(qū)來，或者是不是被緩存；另一種 信息指明名字服務器指出還有一個服務器擁有相同的記錄，這個服務器更靠近要查詢的 名字的祖先。
3.3.2. 算法
名字服務器使用的算法和本地操作系統(tǒng)和數(shù)據(jù)結(jié)構(gòu)相關，下面的算法假設RR 以幾個樹型 結(jié)構(gòu)組織，一個樹就是區(qū)，有一個樹是用于緩沖的：
是不是支持循環(huán)查詢要看服務器，如果支持，而且需要循環(huán)查詢，轉(zhuǎn)到第5步；
查詢最靠近QNAME 祖先的結(jié)點所在的區(qū)，如果未找到這個區(qū)，轉(zhuǎn)第4步；
開始在區(qū)內(nèi)從上到下進行匹配，匹配過程的結(jié)束條件有以下幾個：
如果整個QNAME 匹配了，我們就找到了。如果數(shù)據(jù)所在結(jié)果是CNAME ，QTYPE 不匹配CNAME
，復制CNAME RR到響應的應答區(qū)，將QNAME 改變?yōu)镃NAME RR中的標準形式后返回第1步；
否則復制所有匹配QTYPE 的RR 到響應的應答區(qū)，然后轉(zhuǎn)第6步；
如果匹配的結(jié)果使我們離開了認證權(quán)威，我們就獲得一個參照（referral ），我們這時
會碰到一個帶有NS RR的結(jié)點，復制NS RR到響應的認證區(qū)內(nèi)，在其它區(qū)域隨便放上什么 地址，如果從認證數(shù)據(jù)或緩沖內(nèi)沒有獲得地址，可以使用關聯(lián)RR 。然后轉(zhuǎn)到第4步； 如果在一些標記上不可能有匹配，看看是不是有"*"標記存在，如果"*"標記不存在，檢 查我們要查找的名字是不是QNAME ，如果名字就是原來的QNAME ，在響應中設置錯誤，否
,則退出。如果"*"存在，以RR 和QTYPE 匹配，如果匹配成功，將它們復制到響應中，但設 置RR 的擁有者（owner ）為QNAME ，不是帶有"*"的結(jié)點，然后轉(zhuǎn)到第6步；
在緩沖中進行匹配，如果在緩沖中找到QNAME ，將所有和它關聯(lián)的而且匹配QTYPE 的RR 復
制到響應區(qū)，如果沒有從認證權(quán)威來的授權(quán)，可以在緩沖中尋找最好的一個，將它放在 認證區(qū)內(nèi)，然后轉(zhuǎn)到第6步；
使用本地resolver 響應請求。保存包括中間CNAME 在內(nèi)的結(jié)果到應答中。
僅使用本地數(shù)據(jù)，試著加入其它有用的RR 到查詢的附加部分。然后退出。
3.3.3. Wildcard
在前面的算法中，我們對其擁有者以*開始的RR 進行了特殊處理，這類的RR 稱為wildcar ds 。Wildcard RR 可以看成合成RR 的指令，在有合適的條件時，服務器創(chuàng)建RR ，這個RR 的
擁有者名和查詢名相同，而內(nèi)容是從wildcard RR獲得的。這種機制經(jīng)常用于創(chuàng)建一個區(qū) ，這個區(qū)可用于在網(wǎng)絡上從一個郵件系統(tǒng)向另一個郵件系統(tǒng)轉(zhuǎn)發(fā)郵件。這種情況下，通 常的假設是區(qū)中的所有名字都存在，只要沒有說不存在，都認為有。
wildcard RR的內(nèi)容遵守通常RR 的格式，區(qū)中的wildcard 有一個擁有者名，它控制者可以 進行匹配的查詢名。wildcard RR的擁有者名是以下的形式："*.
如果區(qū)中已經(jīng)存在了它所代表的某個域。例如，如果wildcard RR有"*.X"，區(qū)中包括了
B.X ，那么wildcard 就不代表B.X ，A.B.X 或X ，而只能代表Z.X 了。
在查詢名中的*沒有什么特殊作用，它只用于在認證權(quán)威區(qū)中檢測wildcard ，這樣的查詢 是唯一可以在響應中獲得包括擁有者名中包含*的查詢請求，其它請求的響應都不能包含 *。這樣查詢的結(jié)果不能緩沖。在合成RR 時，wildcard RR的內(nèi)容不應該被改變。
下面是一個例子，我們假設一個大公司有一個大型的非TCP/IP網(wǎng)絡，它要創(chuàng)建一個郵件 網(wǎng)關。如果公司是X.COM ，而TCP/IP網(wǎng)關為A.X.COM ，下面的RR 可能會在COM 區(qū)中： X.COM
MX
10
A.X.COM
*.X.COM
MX
10
A.X.COM
A.X.COM
A
1.2.3.4
A.X.COM
MX
10
A.X.COM
*.A.X.COM
MX