align=justify>在緩沖中進行匹配，如果在緩沖中找到QNAME，將所有和它關聯的而且匹配QTYPE的RR復制到響應區，如果沒有從認證權威來的授權，可以在緩沖中尋找最好的一個，將它放在認證區內，然后轉到第6步；</P>
          <LI>
          <P align=justify>使用本地resolver響應請求。保存包括中間CNAME在內的結果到應答中。</P>
          <LI>
          <P 
      align=justify>僅使用本地數據，試著加入其它有用的RR到查詢的附加部分。然后退出。</P></LI></OL></BLOCKQUOTE>
      <P align=justify>3.3.3. Wildcard</P>
      <P align=justify>在前面的算法中，我們對其擁有者以*開始的RR進行了特殊處理，這類的RR稱為wildcards。Wildcard 
      RR可以看成合成RR的指令，在有合適的條件時，服務器創建RR，這個RR的擁有者名和查詢名相同，而內容是從wildcard 
      RR獲得的。這種機制經常用于創建一個區，這個區可用于在網絡上從一個郵件系統向另一個郵件系統轉發郵件。這種情況下，通常的假設是區中的所有名字都存在，只要沒有說不存在，都認為有。</P>
      <P align=justify>wildcard 
      RR的內容遵守通常RR的格式，區中的wildcard有一個擁有者名，它控制者可以進行匹配的查詢名。wildcard 
      RR的擁有者名是以下的形式："*.&lt;anydomain&gt;"，其中&lt;anydomain&gt;是任何域名，&lt;anydomain&gt;不應該再包括其它*標記，而且它應該在區的認證數據之中。我們可以把wildcard看成是通配符的作用。wildcard 
      RR在以下情況中不適用：</P>
      <UL>
        <LI>
        <P align=justify>查詢在應該在別的區中；</P>
        <LI>
        <P align=justify>如果區中已經存在了它所代表的某個域。例如，如果wildcard 
        RR有"*.X"，區中包括了B.X，那么wildcard就不代表B.X，A.B.X或X，而只能代表Z.X了。</P></LI></UL>
      <P 
      align=justify>在查詢名中的*沒有什么特殊作用，它只用于在認證權威區中檢測wildcard，這樣的查詢是唯一可以在響應中獲得包括擁有者名中包含*的查詢請求，其它請求的響應都不能包含*。這樣查詢的結果不能緩沖。在合成RR時，wildcard 
      RR的內容不應該被改變。</P>
      <P 
      align=justify>下面是一個例子，我們假設一個大公司有一個大型的非TCP/IP網絡，它要創建一個郵件網關。如果公司是X.COM，而TCP/IP網關為A.X.COM，下面的RR可能會在COM區中：</FONT></P>
      <TABLE cellSpacing=1 cellPadding=7 width="100%" border=1>
        <TBODY>
        <TR>
          <TD vAlign=top width="19%"><FONT face=宋體 size=3>
            <P align=justify>X.COM</FONT></P></TD>
          <TD vAlign=top width="12%">
            <BLOCKQUOTE><FONT face=宋體 size=3>
              <P align=justify>MX</FONT></P></BLOCKQUOTE></TD>
          <TD vAlign=top width="16%">
            <BLOCKQUOTE><FONT face=宋體 size=3>
              <P align=justify>10</FONT></P></BLOCKQUOTE></TD>
          <TD vAlign=top width="54%"><FONT face=宋體 size=3>
            <P align=justify>A.X.COM</FONT></P></TD></TR>
        <TR>
          <TD vAlign=top width="19%"><FONT face=宋體 size=3>
            <P align=justify>*.X.COM</FONT></P></TD>
          <TD vAlign=top width="12%">
            <BLOCKQUOTE><FONT face=宋體 size=3>
              <P align=justify>MX</FONT></P></BLOCKQUOTE></TD>
          <TD vAlign=top width="16%">
            <BLOCKQUOTE><FONT face=宋體 size=3>
              <P align=justify>10</FONT></P></BLOCKQUOTE></TD>
          <TD vAlign=top width="54%"><FONT face=宋體 size=3>
            <P align=justify>A.X.COM</FONT></P></TD></TR>
        <TR>
          <TD vAlign=top width="19%"><FONT face=宋體 size=3>
            <P align=justify>A.X.COM</FONT></P></TD>
          <TD vAlign=top width="12%">
            <BLOCKQUOTE><FONT face=宋體 size=3>
              <P align=justify>A</FONT></P></BLOCKQUOTE></TD>
          <TD vAlign=top width="16%">
            <BLOCKQUOTE><FONT face=宋體 size=3>
              <P align=justify>1.2.3.4</FONT></P></BLOCKQUOTE></TD>
          <TD vAlign=top width="54%">　</TD></TR>
        <TR>
          <TD vAlign=top width="19%"><FONT face=宋體 size=3>
            <P align=justify>A.X.COM</FONT></P></TD>
          <TD vAlign=top width="12%">
            <BLOCKQUOTE><FONT face=宋體 size=3>
              <P align=justify>MX</FONT></P></BLOCKQUOTE></TD>
          <TD vAlign=top width="16%">
            <BLOCKQUOTE><FONT face=宋體 size=3>
              <P align=justify>10</FONT></P></BLOCKQUOTE></TD>
          <TD vAlign=top width="54%"><FONT face=宋體 size=3>
            <P align=justify>A.X.COM</FONT></P></TD></TR>
        <TR>
          <TD vAlign=top width="19%"><FONT face=宋體 size=3>
            <P align=justify>*.A.X.COM</FONT></P></TD>
          <TD vAlign=top width="12%">
            <BLOCKQUOTE><FONT face=宋體 size=3>
              <P align=justify>MX</FONT></P></BLOCKQUOTE></TD>
          <TD vAlign=top width="16%">
            <BLOCKQUOTE><FONT face=宋體 size=3>
              <P align=justify>10</FONT></P></BLOCKQUOTE></TD>
          <TD vAlign=top width="54%"><FONT face=宋體 size=3>
            <P align=justify>A.X.COM</FONT></P></TD></TR></TBODY></TABLE><FONT face=宋體 
      size=3>
      <P align=justify>對于所有X.COM中的MX查詢，都會得到A.X.COM。存在兩個wildcard 
      RR是必須的，因為有A.X.COM，就必須要有*.A.X.COM，否則W.A.X.COM就查詢不出來，原因請在本節中的wildcard 
      RR不適用的情況中尋找。</P>
      <P align=justify>3.3.4. 否定響應緩沖（可選）</P>
      <P 
      align=justify>DNS可以允許服務器提供一種否定響應緩沖服務，在這種服務下服務器返回一個否定響應和一個TTL，resolver可以認為在TTL的時間之內相同的查詢都會獲得否定響應。同樣的，resolver可以進行一個配置多個類型的查詢，并緩沖不存在的類型。</P>
      <P align=justify>實現的方法是當數據是被認證時服務器加入一個SOA 
      RR到響應的附加區域，SOA必須是那個區的，而且這個區必須中響應中數據的認證權威區，SOA的MINIMUM域控制緩沖否定響應的時間。在有些情況下，響應數據可能包括多個擁有者名，這時SOA機制應該用于匹配QNAME的數據上，它才是唯一被認證了的數據。服務器和resovler不應該試圖添加SOA到非認證響應的附加區域，也不應該進行任何推測。</P>
      <P align=justify>這個功能是可選的，雖然現在它越來越有可能成為標準，但是服務器并非非要加SOA 
      RR到所有的認證響應中去，resolver也不一定非要緩沖否定結果。所有的resolver和支持循環查詢的服務器都應該可以忽略SOA RR。</P>
      <P align=justify>3.3.5. 區的維護與傳輸</P>
      <P 
      align=justify>區管理員的部分工作是維護所有服務器上的區數據。當必須要進行修改時，修改必須讓所有的名字服務器知道。這一過程可以通過FTP或其它什么過程完成，而推薦的方法是DNS協議的區傳輸部分所指出的方法。通常的自動更新模式是一個服務器是區的主服務器，管理員對區內的域名文件（master 
      file）進行修改，修改后管理員通知主服務器裝載新的數據，其它的非主服務器定期和主服務器進行同步。</P>
      <P 
      align=justify>為了知道是否發生了修改，非主服務器必須檢查SOA的SERIAL域，只要有改變，SERIAL域就會改變，這種改變可能是加一，也可能是其它的什么算法，反正變了就行。因為我們改變的域大小是有范圍的，因此理論上必須有一個修改的時間間隔，基本上，老的復本必須在序列號（就是那個域）用完其空間一半時消失。實際上只要保證比較操作的正確性就可以了。</P>
      <P align=justify>非主服務器的定期同步由區內SOA 
      RR的參數REFRESH，RETRY和EXPIRE決定。當非主服務器裝入新區時，它會在REFRESH秒后向主服務器查詢新序列號，如果查詢未能完成，它會每隔RETRY秒重新進行一次。如果查詢得到的序列號和原來的序列號一樣，則不需要進行改變。在REFRESH時間間隔后重新開始。如果非主服務器在EXPIRE間隔后不能進行查詢，它必須拋棄現有的區數據。</P>
      <P 
      align=justify>當查詢后知道區內的數據已經改變，非主服務器必須通過AXFR請求請求主服務器傳送區數據。AXFR可能會被拒絕而產生錯誤，但是通常情況下會得到一系列響應信息。第一個和最后一個信息必須包括區內頂認證結點的數據。中間的信息包括區內其它RR的信息，包括認證的和非認證的。這些數據使非主服務器得到區數據的復本，因為必須保證數據的準確，我們必須使用基于連接的協議。以上的查詢操作不但可以在主服務器非主服務器之間進行，而且可以在非主服務器之間進行。這可以提高整體的運行效率。</P>
      <P align=justify>4. RESOLVERS</P>
      <P align=justify>4.1. 介紹</P>
      <P 
      align=justify>Resolver是用戶程序和域名服務器之間的接口，最簡單的情況下，resolver接收從用戶來的請求，返回符合本地數據格式的查詢結果。resolver和請求DNS服務的程序在同一臺機器上，但DNS服務器則在其它機器上，因為resolver可能要查詢多個名字服務器，所有它需要有一個本地緩沖，而查詢的時間則可能因具體查詢不同而差別很大。resolver的一個重要作用是就是它有一個多個程序可以共享的緩沖區，這里保存著一些查詢結果，使用這些結果可以減少對服務器反復的查詢。</P>
      <P align=justify>4.2. 客戶-resolver接口</P>
      <P align=justify>4.2.1. 典型函數</P>
      <P align=justify>這個接口因主機不同而不同，但有三個函數是大家必須都有的：</P>
      <BLOCKQUOTE>
        <OL>
          <LI>
          <P 
          align=justify>主機名到主機地址轉換，此函數通常定義用來模擬原來基于HOSTS.TXT的函數。給定一個字符串，返回一個32位IP地址，在DNS下，它轉換為請求類型A的RR請求。因為DNS不保存RR的順序，函數會進行排序將返回的許多地址中的一個返回給用戶。請注意：最好是返回多個地址，但單個地址是模擬原來基于HOSTS.TXT服務的。</P>
          <LI>
          <P 
          align=justify>主機地址到主機名轉換，給定32位IP地址，返回字符串。查詢時采用PRT查詢，主機名加上"IN-ADDR.ARPA"后綴進行查詢，如IP地址為1.2.3.4，則PTR 
          RR查詢域名"4.3.2.1.IN-ADDR.ARPA"。</P>
          <LI>
          <P 
          align=justify>通用查詢函數，調用者提供QNAME，QTYPE和QCLASS，希望所有匹配的RR，函數會使用DNS格式而非本機格式返回查詢結果，結果中包括所有RR的內容。</P></LI></OL></BLOCKQUOTE>
      <P align=justify>在resolver執行上面的函數時，會返回以下的結果給客戶：</P>
      <BLOCKQUOTE>
        <UL>
          <LI>
          <P align=justify>給定請求數據的一個或多個RR，此時resovler以合適的格式返回結果</P>
          <LI>
          <P align=justify>名字錯誤(NE)，在查詢的名字不存在是會返回NE</P>
          <LI>
          <P 
          align=justify>未找到數據錯誤，查詢的名字存在，但合適類型的數據不存在時產生這種錯誤，如把主機地址用于郵箱地址時會返回錯誤</P></LI></UL></BLOCKQUOTE>
      <P 
      align=justify>需要注意的是，有時某些函數會在查詢時名字錯誤和數據未找到錯誤會被合并為另一種類型的錯誤，但通常函數不會。一個原因是程序通常先查詢一個名字（包括類型信息），然后是同一個名字的另外類型，如果兩個錯誤合起來，反面會減慢查詢速度。</P>
      <P align=justify>4.2.2. 別名</P>
      <P 
      align=justify>當試圖解析一個特殊的名字查詢時，resolver可能發現這是一個別名，如果可能這種情況會返回給客戶。但是經常，當resolver碰到一個CNAME時，它會重新開始一個查詢。然而，在執行通常函數而且CNAME 
      RR配置查詢類型時，resolver不應該要別名。在有別名的時候有幾種特殊情況。多級別名應該避免，因為太缺乏效率，但這也不應該被做為錯誤返回給客戶。對于別名循環和別名指向不存在的名字時應該將錯誤返回給客戶。</P>
      <P align=justify>4.2.3. 臨時錯誤</P>
      <P 
      align=justify>有時候因為網絡等原因，resolver可能不能完成某個請求，這時不應該返回沒有名字或未查詢到這類錯誤。這類錯誤對人類用戶來說可是件煩心的事。在某些時候可以阻塞請求，但這并不是個好的解決之道，特別是服務器就等它完成以轉向其它任務的時候。推薦的方法是返回錯誤指示現在出現臨時錯誤。</P>
      <P align=justify>4.3. Resolver內部</P>