技術支持
DNS協定區中所有結點的認證數據
定義區內頂結點的數據（此數據可被認為是認證數據的一部分）
訪問伺服器子區的數據（我們也稱為?#30456;關?#65288;glue）數據）
所有這些數據以RR的形式表示，所有區可以被RR集的形式描述。通過傳輸RR，可以傳輸整個區，具體的方法可以是通過FTP傳輸相應的文本檔案，或是通過網路訊息的形式傳輸。一個區的認證數據是所有的RR，這些RR和樹中所有的結點是關聯的，要么就是切分後的結點關聯。描述頂結點的RR對於區的管理特別重要，這些RR有兩種類型，名字伺服器RR，它描述了區中的伺服器列表；另一種是SOARR，它描述的區的管理參數。
描述切分的RR是NSRR，因為切分是在結點間進行的，所有RR不是區認證數據的一部分，它應該和相應的在子區內的頂結點一致。因為名字伺服器通常和區邊界相關，NSRR只在一些區的頂結點上有。在組成一個區的數據中，NSRR在頂層結點和在邊界底的切分處出現，不在其它地方。
區結構所要實現的一個目標是任何區都有足夠的數據可以和任何子區建立通信。也就是說，父區有足夠的信息可以訪問子區中的任何一台名字伺服器。NSRR命名了子區伺服器，它不足以完成上面的要求，因此有了名字但仍然不知道地址。特別地，如果名字伺服器的名字在子區內是它自己，我們就無法知道通過它的任何信息了。為了解決這一問題，區中包括了一個關聯RR，它不是認證權威數據的一部分，但它表示了伺服器的地址。如果名字伺服器名在切分下，就需要這些RR了。
管理問題
當有些組織希望掌握自己的域時，第一步是標記合適的父區，然後取得父區中管理結點的許可來管理。管理的時候沒有什麼具體的技術問題，可是還是有一些規則的，對中型的區可以沒有這些規定，但是小型的就不行了。本文不具體討論這一問題了，有興趣可參閱相關的資料。
一旦選擇了子區的名字，此區的新管理結點要冗餘的名字伺服器來支持。注意：沒有要求一個區的伺服器必須在此域中有名字的主機上。在許多種情況下，一個區要想被更容易地訪問到最好把內容放得分散一點，不要集中在一起。現在許多國家的名字伺服器是放置在別國的，這樣在取得名字解析的時候不用把請求千里迢迢送到遠程主機上去了。作為配置的最後一步，就是要選擇NSRR和關聯RR。
查詢和回響
名字伺服器的主要內容就是回響標準查詢。查詢和回響有專用的格式，查詢包括QTYPE，QCLASS和QNAME，它描述了需要數據的類型，類（class）和名字。伺服器的回響取決於它支持不支持循環查詢：
最簡單的是不支持循環查詢，它返回的要么是本地信息，要么是一個錯誤碼，告訴用戶你要的信息這裡沒有，然後再返回一個鄰近伺服器的地址，讓用戶到那裡去查一查。
如果支持循環查詢，那名字伺服器如果未能在本地找到相應的信息，就代替用戶向其它伺服器進行查詢，這時它是代替用戶扮演了resolver的角色，直到最後把結果找到（也可能根本沒有結果，那就返回錯誤），並返回給用戶為止。
使用循環查詢要客戶和伺服器雙方都支持才行。這個信息通過查詢和回響中的兩位來交換：
如果允許循環查詢則設定RA位，伺服器方可以不管客戶是否進行請求而直接設定此位
查詢中如果請求循環查詢則設定RD位，客戶只有在知道伺服器方支持循環查詢後才能夠進行循環查詢請求
客戶可以在回響中同時設定RA和RD位來確認是否支持循環查詢請求。請注意：伺服器在客戶未指明RD位時不會自己進行循環查詢。
如果請求了循環查詢，同時也支持循環查詢，對查詢的回響會是以下之一：
查詢指定的CNAMERR有多個別名
指定的名字伺服器不存在
臨時錯誤
如果未請求循環查詢或不支持循環查詢，則回響可以可能是：
-認證權威伺服器指出名字不存在
-臨時錯誤
另外還會提供一些信息，指出所查詢的RR是否從一個區來，或者是不是被快取；另一種信息指明名字伺服器指出還有一個伺服器擁有相同的記錄，這個伺服器更靠近要查詢的名字的祖先。
算法
名字伺服器使用的算法和本地作業系統和數據結構相關，下面的算法假設RR以幾個樹型結構組織，一個樹就是區。
使用協定格式
DNS在進行區域傳輸的時候使用TCP協定，其它時候則使用UDP協定；
DNS的規範規定了2種類型的DNS伺服器，一個叫主DNS伺服器，一個叫輔助DNS伺服器。在一個區中主DNS伺服器從自己本機的數據檔案中讀取該區的DNS數據信息，而輔助DNS伺服器則從區的主DNS伺服器中讀取該區的DNS數據信息。當一個輔助DNS伺服器啟動時，它需要與主DNS伺服器通信，並載入數據信息，這就叫做區傳送（zonetransfer）。
為什麼既使用TCP又使用UDP？
首先了解一下TCP與UDP傳送位元組的長度限制：
UDP報文的最大長度為512位元組，而TCP則允許報文長度超過512位元組。當DNS查詢超過512位元組時，協定的TC標誌出現刪除標誌，這時則使用TCP傳送。通常傳統的UDP報文一般不會大於512位元組。
