網域名稱的概念與機制(3)

來源:互聯網
上載者:User

  3.3.2. 演算法

  名字伺服器使用的演算法和本地作業系統和資料結構相關,下面的演算法假設RR以幾個樹型結構組織,一個樹就是區,有一個樹是用於緩衝的:

  1.   是不是支援迴圈查詢要看伺服器,如果支援,而且需要迴圈查詢,轉到第5步;

  2.   查詢最靠近QNAME祖先的結點所在的區,如果未找到這個區,轉第4步;

  3.   開始在區內從上到下進行匹配,匹配過程的結束條件有以下幾個:

  •   如果整個QNAME匹配了,我們就找到了。如果資料所在結果是CNAME,QTYPE不匹配CNAME,複製CNAME RR到響應的應答區,將QNAME改變為CNAME RR中的標準形式後返回第1步;否則複製所有匹配QTYPE的RR到響應的應答區,然後轉第6步;

  •   如果匹配的結果使我們離開了認證權威,我們就獲得一個參照(referral),我們這時會碰到一個帶有NS RR的結點,複製NS RR到響應的認證區內,在其它地區隨便放上什麼地址,如果從認證資料或緩衝內沒有獲得地址,可以使用關聯RR。然後轉到第4步;

  •   如果在一些標記上不可能有匹配,看看是不是有"*"標記存在,如果"*"標記不存在,檢查我們要尋找的名字是不是QNAME,如果名字就是原來的QNAME,在響應中設定錯誤,否則退出。如果"*"存在,以RR和QTYPE匹配,如果匹配成功,將它們複製到響應中,但設定RR的擁有者(owner)為QNAME,不是帶有"*"的結點,然後轉到第6步;

  1.   在緩衝中進行匹配,如果在緩衝中找到QNAME,將所有和它關聯的而且匹配QTYPE的RR複製到響應區,如果沒有從認證權威來的授權,可以在緩衝中尋找最好的一個,將它放在認證區內,然後轉到第6步;

  2.   使用本地resolver響應請求。儲存包括中間CNAME在內的結果到應答中。

  3.   僅使用本機資料,試著加入其它有用的RR到查詢的附加部分。然後退出。

  3.3.3. Wildcard

  在前面的演算法中,我們對其擁有者以*開始的RR進行了特殊處理,這類的RR稱為wildcards。Wildcard RR可以看成合成RR的指令,在有合適的條件時,伺服器建立RR,這個RR的擁有者名和查詢名相同,而內容是從wildcard RR獲得的。這種機制經常用於建立一個區,這個區可用於在網路上從一個郵件系統向另一個郵件系統轉寄郵件。這種情況下,通常的假設是區中的所有名字都存在,只要沒有說不存在,都認為有。

  wildcard RR的內容遵守通常RR的格式,區中的wildcard有一個擁有者名,它控制者可以進行匹配的查詢名。wildcard RR的擁有者名是以下的形式:"*.",其中是任何網域名稱,不應該再包括其它*標記,而且它應該在區的認證資料之中。我們可以把wildcard看成是萬用字元的作用。wildcard RR在以下情況中不適用:

  •   查詢在應該在別的區中;

  •   如果區中已經存在了它所代表的某個域。例如,如果wildcard RR有"*.X",區中包括了B.X,那麼wildcard就不代表B.X,A.B.X或X,而只能代表Z.X了。

  在查詢名中的*沒有什麼特殊作用,它只用於在認證權威區中檢測wildcard,這樣的查詢是唯一可以在響應中獲得包括擁有者名中包含*的查詢請求,其它請求的響應都不能包含*。這樣查詢的結果不能緩衝。在合成RR時,wildcard RR的內容不應該被改變。

  下面是一個例子,我們假設一個大公司有一個大型的非TCP/IP網路,它要建立一個郵件網關。如果公司是X.COM,而TCP/IP網關為A.X.COM,下面的RR可能會在COM區中:

  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

  10

  A.X.COM

  對於所有X.COM中的MX查詢,都會得到A.X.COM。存在兩個wildcard RR是必須的,因為有A.X.COM,就必須要有*.A.X.COM,否則W.A.X.COM就查詢不出來,原因請在本節中的wildcard RR不適用的情況中尋找。

  3.3.4. 否定響應緩衝(可選)

  DNS可以允許伺服器提供一種否定響應緩衝服務,在這種服務下伺服器返回一個否定響應和一個TTL,resolver可以認為在TTL的時間之內相同的查詢都會獲得否定響應。同樣的,resolver可以進行一個配置多個類型的查詢,並緩衝不存在的類型。

  實現的方法是當資料是被認證時伺服器加入一個SOA RR到響應的附加地區,SOA必須是那個區的,而且這個區必須中響應中資料的認證權威區,SOA的MINIMUM域控制緩衝否定響應的時間。在有些情況下,響應資料可能包括多個擁有者名,這時SOA機制應該用於匹配QNAME的資料上,它才是唯一被認證了的資料。伺服器和resovler不應該試圖添加SOA到非認證響應的附加地區,也不應該進行任何推測。

  這個功能是可選的,雖然現在它越來越有可能成為標準,但是伺服器並非非要加SOA RR到所有的認證響應中去,resolver也不一定非要緩衝否定結果。所有的resolver和支援迴圈查詢的伺服器都應該可以忽略SOA RR。

  3.3.5. 區的維護與傳輸

  區管理員的部分工作是維護所有伺服器上的區資料。當必須要進行修改時,修改必須讓所有的名字伺服器知道。這一過程可以通過FTP或其它什麼過程完成,而推薦的方法是DNS協議的區傳輸部分所指出的方法。通常的自動更新模式是一個伺服器是區的主伺服器,管理員對區內的網域名稱檔案(master file)進行修改,修改後管理員通知主伺服器裝載新的資料,其它的非主伺服器定期和主伺服器進行同步。

  為了知道是否發生了修改,非主伺服器必須檢查SOA的SERIAL域,只要有改變,SERIAL域就會改變,這種改變可能是加一,也可能是其它的什麼演算法,反正變了就行。因為我們改變的域大小是有範圍的,因此理論上必須有一個修改的時間間隔,基本上,老的複本必須在序號(就是那個域)用完其空間一半時消失。實際上只要保證比較操作的正確性就可以了。

  非主伺服器的定期同步由區內SOA RR的參數REFRESH,RETRY和EXPIRE決定。當非主伺服器裝入新區時,它會在REFRESH秒後向主伺服器查詢新序號,如果查詢未能完成,它會每隔RETRY秒重新進行一次。如果查詢得到的序號和原來的序號一樣,則不需要進行改變。在REFRESH時間間隔後重新開始。如果非主伺服器在EXPIRE間隔後不能進行查詢,它必須拋棄現有的區資料。

  當查詢後知道區內的資料已經改變,非主伺服器必須通過AXFR請求請求主伺服器傳送區資料。AXFR可能會被拒絕而產生錯誤,但是通常情況下會得到一系列響應資訊。第一個和最後一個資訊必須包括區內頂認證結點的資料。中間的資訊包括區內其它RR的資訊,包括認證的和非認證的。這些資料使非主伺服器得到區資料的複本,因為必須保證資料的準確,我們必須使用基於串連的協議。以上的查詢操作不但可以在主伺服器非主伺服器之間進行,而且可以在非主伺服器之間進行。這可以提高整體的運行效率。

  4. RESOLVERS

  4.1. 介紹

  Resolver是使用者程式和網域名稱伺服器之間的介面,最簡單的情況下,resolver接收從使用者來的請求,返回符合本機資料格式的查詢結果。resolver和請求DNS服務的程式在同一台機器上,但DNS伺服器則在其它機器上,因為resolver可能要查詢多個名字伺服器,所有它需要有一個本地緩衝,而查詢的時間則可能因具體查詢不同而差別很大。resolver的一個重要作用是就是它有一個多個程式可以共用的緩衝區,這裡儲存著一些查詢結果,使用這些結果可以減少對伺服器反覆的查詢。

  4.2. 客戶-resolver介面

  4.2.1. 典型函數

  這個介面因主機不同而不同,但有三個函數是大家必須都有的:

  1.   主機名稱到主機地址轉換,此函數通常定義用來類比原來基於HOSTS.TXT的函數。給定一個字串,返回一個32位IP地址,在DNS下,它轉換為請求類型A的RR請求。因為DNS不儲存RR的順序,函數會進行排序將返回的許多地址中的一個返回給使用者。請注意:最好是返回多個地址,但單個地址是類比原來基於HOSTS.TXT服務的。

  2.   主機地址到主機名稱轉換,給定32位IP地址,返回字串。查詢時採用PRT查詢,主機名稱加上"IN-ADDR.ARPA"尾碼進行查詢,如IP地址為1.2.3.4,則PTR RR查詢網域名稱"4.3.2.1.IN-ADDR.ARPA"。

  3.   通用查詢函數,調用者提供QNAME,QTYPE和QCLASS,希望所有匹配的RR,函數會使用DNS格式而非原生格式返回查詢結果,結果中包括所有RR的內容。

  在resolver執行上面的函數時,會返回以下的結果給客戶:

  •   給定請求資料的一個或多個RR,此時resovler以合適的格式返回結果

  •   名字錯誤(NE),在查詢的名字不存在是會返回NE

  •   未找到資料錯誤,查詢的名字存在,但合適類型的資料不存在時產生這種錯誤,如把主機地址用於郵箱地址時會返回錯誤

  需要注意的是,有時某些函數會在查詢時名字錯誤和資料未找到錯誤會被合并為另一種類型的錯誤,但通常函數不會。一個原因是程式通常先查詢一個名字(包括類型資訊),然後是同一個名字的另外類型,如果兩個錯誤合起來,反面會減慢查詢速度。

  4.2.2. 別名

  當試圖解析一個特殊的名字查詢時,resolver可能發現這是一個別名,如果可能這種情況會返回給客戶。但是經常,當resolver碰到一個CNAME時,它會重新開始一個查詢。然而,在執行通常函數而且CNAME RR配置查詢類型時,resolver不應該要別名。在有別名的時候有幾種特殊情況。多層級名應該避免,因為太缺乏效率,但這也不應該被做為錯誤返回給客戶。對於別名迴圈和別名指向不存在的名字時應該將錯誤返回給客戶。

  4.2.3. 臨時錯誤

  有時候因為網路等原因,resolver可能不能完成某個請求,這時不應該返回沒有名字或未查詢到這類錯誤。這類錯誤對人類使用者來說可是件煩心的事。在某些時候可以阻塞請求,但這並不是個好的解決之道,特別是伺服器就等它完成以轉向其它任務的時候。推薦的方法是返回錯誤指示現在出現臨時錯誤。

  4.3. Resolver內部

  每個resolver的實現都不相同,會有複雜的邏輯處理各種錯誤,而本文只討論一個綱領。

  4.3.1. 根(Stub)resolvers

  一種實現resolver的方法就是在支援迴圈查詢的伺服器上實現,這樣可以節省PC機上的資源,也可以對查詢結果緩衝進行集中管理。其它的事情就是要一個支援迴圈查詢服務器地址的檔案在PC機上,PC機上資源有限,支援一個網域名稱資料庫可能不太現實。使用者必須確定所列的名字伺服器支援迴圈查詢,伺服器可以拒絕進行任何客戶的迴圈查詢請求,因此使用者必須向管理員核對。這種類型的服務有一些不足,因為迴圈查詢較費時,根對UDP重發時間的選擇比較難以確定,伺服器會因為根的反覆重發而崩潰。使用TCP或許會好,但這樣會嚴重佔用主機時間,使用TCP相當於實現一個即時的查詢系統。

  4.3.2. 資源

  除了自己的資源外,resolver可以訪問本機伺服器儲存的區資料。這會使resolver的速度加快,但是也可以讓緩衝資料衝掉區資料。本文中指的本地資訊是說緩衝和共用區資料,在有認證資料和緩衝資料時應該優先使用認證資料。下面的演算法假設所有函數被轉換為一個通常的查詢函數,使用下面的資料結構代表進行中的請求的狀態:

  SNAME

  要查詢的網域名稱

  STYPE

  查詢請求的QTYPE

  SCLASS

  查詢請求的QCLASS

  SLIST

  表示正在查詢的名字伺服器和區,它儲存resolver的預測,預測希望查詢的資料在什麼地方,通過接收的資料,此結構內的資料會發生變化。它包括伺服器位址,區內已知的伺服器,記錄,以及表示查詢距離目標還有多遠的標記(查詢從樹頂開始向下,直到目標)。

  SBELT

  在resolver無法從本地資訊知道應該查詢哪個伺服器時,它就派上用場了。

  CACHE

  儲存前一次響應的結果,因為resolver會拋棄達到TTL時間的RR,所有大部分resolver實現將接收到RR的時間轉換為絕對時間,然後儲存在緩衝中,resolver可以在查詢時順便將到期RR拋棄,也可定期進行維護。



相關文章

Alibaba Cloud 10 Year Anniversary

With You, We are Shaping a Digital World, 2009-2019

Learn more >

Apsara Conference 2019

The Rise of Data Intelligence, September 25th - 27th, Hangzhou, China

Learn more >

Alibaba Cloud Free Trial

Learn and experience the power of Alibaba Cloud with a free trial worth $300-1200 USD

Learn more >

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。