<P 
      align=justify>標準查詢指定一個目標域名（QNAME），查詢類型（QTYPE）和查詢類（QCLASS），然后尋找相應的RR，這類的查詢占了DNS查詢的絕大部分，如果未有特殊說明，一般都指這種查詢。</P>
      <P align=justify>QTYPE和QCLASS域為16位，是定義的type和class的超集。QTYPE域可以包括：</P>
      <BLOCKQUOTE>
        <UL>
          <LI>
          <P align=justify>&lt;any type&gt;：和相應類型相匹配的RR matches just that type. 
          (e.g., A, PTR).</P>
          <LI>
          <P align=justify>AXFR：由QTYPE指定的特定區</P>
          <LI>
          <P align=justify>MAILB：和RR相關的所有郵箱</P>
          <LI>
          <P align=justify>*：所有RR類型</P></LI></UL></BLOCKQUOTE>
      <P align=justify>QCLASS域可以包括：</P>
      <BLOCKQUOTE>
        <UL>
          <LI>
          <P align=justify>&lt;any class&gt;：和相應類相匹配的RR</P>
          <LI>
          <P align=justify>*：所有的RR類</P></LI></UL></BLOCKQUOTE>
      <P 
      align=justify>使用查詢域名，QTYPE和QCLASS，名字服務器就會檢查相應的RR，服務器可以返回一個可能包括相應RR的服務器名。例如：希望向Mockapetris@ISI.EDU發郵件，應用程序會向resolver要求了解關于ISI.EDU的信息，會產生下面的查詢：QNAME=ISI.EDU，QTYPE=MX，QCLASS=IN，可能產生響應的區可能是：</P>
      <P align=justify>ISI.EDU. MX 10 VENERA.ISI.EDU.</P>
      <P align=justify>MX 10 VAXA.ISI.EDU.</P>
      <P align=justify>隨此以外還有：</P>
      <P align=justify>VAXA.ISI.EDU. A 10.2.0.27</P>
      <P align=justify>A 128.9.0.33</P>
      <P align=justify>VENERA.ISI.EDU. A 10.1.0.52</P>
      <P align=justify>A 128.9.0.32</P>
      <P 
      align=justify>服務器假設如果請求者希望得到郵件交換（exchange）信息，它會馬上請求交換服務器的地址，所以找到兩個。這里需要注意QCLASS=*類型的查詢，因為服務器不可能知道了解域名系統中所有類的可用信息，它也不是所有類的認證權威，因此這類查詢不能得到認證。</P>
      <P align=justify>2.7.2. 反向查詢（可選）</P>
      <P align=justify>名字服務器可以反映資源和域名之間的映射關系。標準查詢可以對將域名映射到SOA RR，相應的反向查詢則映射SOA 
      RR到域名。</P>
      <P 
      align=justify>對于名字服務器來說這種實現是可選的，但是所有的名字服務器必須至少能夠理解反向查詢消息，不能說發來的消息當不知道。域名系統不保證反向查詢的完全和唯一性，因為系統是按照域名而非主機地址或其它資源類型安排的。反向查詢主要用于調試，以及和數據庫支持相關的活動中。反向查詢可以不返回正確的TTL，也不標明RR是某個集合中的一員，我們不知道它是不是唯一的，因此反向查詢的結果不緩沖。反向查詢對于映射主機地址到主機名是不合適的，此時要用IN-ADDR.ARPA域。</P>
      <P align=justify>2.8. 狀態查詢（實驗中）</P>
      <P align=justify>沒有定義</P>
      <P align=justify>2.9. 完整查詢（過時的）</P>
      <P align=justify>這里就不說了，以后可能會支持重設計（redegsign）服務。</P>
      <P align=justify>3. 名字服務器</P>
      <P align=justify>3.1. 介紹</P>
      <P 
      align=justify>名字服務器保存了許多信息，這些信息組成了域數據庫。數據庫被分為區，這些區在不同的服務器上保存。服務器可以有不同的可選函數和數據源，它最基本的工作是響應查詢，它的響應是是一種簡單的形式進行的，響應可以僅根據本地數據作出，也可以根據其它相關服務器而做出。一個給定的區可以根據不同的服務器來保證其有效性，通過管理命令，用戶可以查詢由至少兩臺服務器保存的一個區上的數據，多臺服務器保存信息保證了適當的冗余。</P>
      <P 
      align=justify>給定的名字服務器通常支持一個或多個區，但只充當域樹一小部分的認證權威。它有一些緩沖的非認證信息，這些信息是域樹其它部分的，在響應查詢時名字服務器會給出什么時它認證的，什么是它緩沖的。</P>
      <P align=justify>3.2. 數據庫如何被劃分為區</P>
      <P 
      align=justify>劃分數據庫有兩種方法，一種是根據class，另一種是在名字空間的結點間進行分隔，而產生，我們稱這種分隔為cut。class（以下我們稱為類）分隔比較簡單，在傳統上，名字空間和所有類是一回事，分隔的類可被認為是一系列平行的名字空間樹。創建新類的通常理由是要為已有的類型創建新的數據格式，或是為了對已有的名字空間進行分隔管理。在一個類中可在兩個相鄰的結點進行cut（以下我們稱為切分），在所有的切分完成后，相連空間的每個組就是一個獨立的區。此區是在相連區域內所有數據的認證權威。</P>
      <P 
      align=justify>這種方法意味著所有的區至少有一個結點，域名和所有特定區內的結點是相連的。給定的樹型結構一定有一個點更加靠近根，我們用這個點標記這個區。雖然可能沒什么用，也可以將每個域名分在不同的區中，也可以讓所有的結點在一個區中。另外，數據庫也可根據不同企業對名字的控制進行劃分，有些企業可能希望自己管理某一部分域名子樹，這時這個企業就可以對域名進行相應的增加或刪除操作，可以自己加入自己的下一級域名。當然，這個企業也可以對自己管理的名字空間進行進一步劃分。</P>
      <P align=justify>3.2.1. 技術問題</P>
      <P align=justify>描述一個區的數據有四部分：</P>
      <BLOCKQUOTE>
        <OL>
          <LI>
          <P align=justify>區中所有結點的認證數據</P>
          <LI>
          <P align=justify>定義區內頂結點的數據（此數據可被認為是認證數據的一部分）</P>
          <LI>
          <P align=justify>描述代表子區的數據</P>
          <LI>
          <P align=justify>訪問服務器子區的數據（我們也稱為“相關”（glue）數據）</P></LI></OL></BLOCKQUOTE>
      <P 
      align=justify>所有這些數據以RR的形式表示，所有區可以被RR集的形式描述。通過傳輸RR，可以傳輸整個區，具體的方法可以是通過FTP傳輸相應的文本文件，或是通過網絡消息的形式傳輸。一個區的認證數據是所有的RR，這些RR和樹中所有的結點是關聯的，要么就是切分后的結點關聯。描述頂結點的RR對于區的管理特別重要，這些RR有兩種類型，名字服務器RR，它描述了區中的服務器列表；另一種是SOA 
      RR，它描述的區的管理參數。</P>
      <P align=justify>描述切分的RR是NS 
      RR，因為切分是在結點間進行的，所有RR不是區認證數據的一部分，它應該和相應的在子區內的頂結點一致。因為名字服務器通常和區邊界相關，NS 
      RR只在一些區的頂結點上有。在組成一個區的數據中，NS RR在頂層結點和在邊界底的切分處出現，不在其它地方。</P>
      <P 
      align=justify>區結構所要實現的一個目標是任何區都有足夠的數據可以和任何子區建立通信。也就是說，父區有足夠的信息可以訪問子區中的任何一臺名字服務器。NS 
      RR命名了子區服務器，它不足以完成上面的要求，因此有了名字但仍然不知道地址。特別地，如果名字服務器的名字在子區內是它自己，我們就無法知道通過它的任何信息了。為了解決這一問題，區中包括了一個關聯RR，它不是認證權威數據的一部分，但它表示了服務器的地址。如果名字服務器名在切分下，就需要這些RR了。</P>
      <P align=justify>3.2.2. 管理問題</P>
      <P 
      align=justify>當有些組織希望掌握自己的域時，第一步是標記合適的父區，然后取得父區中管理結點的許可來管理。管理的時候沒有什么具體的技術問題，可是還是有一些規則的，對中型的區可以沒有這些規定，但是小型的就不行了。本文不具體討論這一問題了，有興趣可參閱相關的資料。</P>
      <P 
      align=justify>一旦選擇了子區的名字，此區的新管理結點要冗余的名字服務器來支持。注意：沒有要求一個區的服務器必須在此域中有名字的主機上。在許多種情況下，一個區要想被更容易地訪問到最好把內容放得分散一點，不要集中在一起?，F在許多國家的名字服務器是放置在別國的，這樣在取得名字解析的時候不用把請求千里迢迢送到遠程主機上去了。作為配置的最后一步，就是要選擇NS 
      RR和關聯RR。</P>
      <P align=justify>3.3. 深入名字服務器</P>
      <P align=justify>3.3.1. 查詢和響應</P>
      <P 
      align=justify>名字服務器的主要內容就是響應標準查詢。查詢和響應有專用的格式，查詢包括QTYPE，QCLASS和QNAME，它描述了需要數據的類型，類（class）和名字。服務器的響應取決于它支持不支持循環查詢：</P>
      <UL>
        <LI>
        <P 
        align=justify>最簡單的是不支持循環查詢，它返回的要么是本地信息，要么是一個錯誤碼，告訴用戶你要的信息這里沒有，然后再返回一個鄰近服務器的地址，讓用戶到那里去查一查。</P>
        <LI>
        <P 
        align=justify>如果支持循環查詢，那名字服務器如果未能在本地找到相應的信息，就代替用戶向其它服務器進行查詢，這時它是代替用戶扮演了resolver的角色，直到最后把結果找到（也可能根本沒有結果，那就返回錯誤），并返回給用戶為止。</P></LI></UL>
      <P align=justify>使用循環查詢要客戶和服務器雙方都支持才行。這個信息通過查詢和響應中的兩位來交換：</P>
      <UL>
        <LI>
        <P align=justify>如果允許循環查詢則設置RA位，服務器方可以不管客戶是否進行請求而直接設置此位</P>
        <LI>
        <P 
      align=justify>查詢中如果請求循環查詢則設置RD位，客戶只有在知道服務器方支持循環查詢后才能夠進行循環查詢請求</P></LI></UL>
      <P 
      align=justify>客戶可以在響應中同時設置RA和RD位來確認是否支持循環查詢請求。請注意：服務器在客戶未指明RD位時不會自己進行循環查詢。</P>
      <P align=justify>如果請求了循環查詢，同時也支持循環查詢，對查詢的響應會是以下之一：</P>
      <BLOCKQUOTE>
        <UL>
          <LI>
          <P align=justify>查詢指定的CNAME RR有多個別名</P>
          <LI>
          <P align=justify>指定的名字服務器不存在</P>
          <LI>
          <P align=justify>臨時錯誤</P></LI></UL></BLOCKQUOTE>
      <P align=justify>如果未請求循環查詢或不支持循環查詢，則響應可以可能是：</P>
      <P align=justify>- 認證權威服務器指出名字不存在</P>
      <P align=justify>- 臨時錯誤</P>
      <P 
      align=justify>另外還會提供一些信息，指出所查詢的RR是否從一個區來，或者是不是被緩存；另一種信息指明名字服務器指出還有一個服務器擁有相同的記錄，這個服務器更靠近要查詢的名字的祖先。</P>
      <P align=justify>3.3.2. 算法</P>
      <P 
      align=justify>名字服務器使用的算法和本地操作系統和數據結構相關，下面的算法假設RR以幾個樹型結構組織，一個樹就是區，有一個樹是用于緩沖的：</P>
      <BLOCKQUOTE>
        <OL>
          <LI>
          <P align=justify>是不是支持循環查詢要看服務器，如果支持，而且需要循環查詢，轉到第5步；</P>
          <LI>
          <P align=justify>查詢最靠近QNAME祖先的結點所在的區，如果未找到這個區，轉第4步；</P>
          <LI>
          <P align=justify>開始在區內從上到下進行匹配，匹配過程的結束條件有以下幾個：</P></LI></OL>
        <BLOCKQUOTE>
          <UL>
            <LI>
            <P 
            align=justify>如果整個QNAME匹配了，我們就找到了。如果數據所在結果是CNAME，QTYPE不匹配CNAME，復制CNAME 
            RR到響應的應答區，將QNAME改變為CNAME 
            RR中的標準形式后返回第1步；否則復制所有匹配QTYPE的RR到響應的應答區，然后轉第6步；</P>
            <LI>
            <P align=justify>如果匹配的結果使我們離開了認證權威，我們就獲得一個參照（referral），我們這時會碰到一個帶有NS 
            RR的結點，復制NS 
            RR到響應的認證區內，在其它區域隨便放上什么地址，如果從認證數據或緩沖內沒有獲得地址，可以使用關聯RR。然后轉到第4步；</P>
            <LI>
            <P 
            align=justify>如果在一些標記上不可能有匹配，看看是不是有"*"標記存在，如果"*"標記不存在，檢查我們要查找的名字是不是QNAME，如果名字就是原來的QNAME，在響應中設置錯誤，否則退出。如果"*"存在，以RR和QTYPE匹配，如果匹配成功，將它們復制到響應中，但設置RR的擁有者（owner）為QNAME，不是帶有"*"的結點，然后轉到第6步；</P></LI></UL></BLOCKQUOTE>
        <OL start=4>
          <LI>
          <P