一起學DNS系列(十)圖、例詳解DNS遞歸和迭代查詢原理及過程 (1)

上節中提到了一些有關遞歸查詢的內容,但說的很少,也很籠統,本節將會從原理和實例兩方面入手分析DNS的遞歸以及迭代查詢。
  在此之前,我們需要了解一些背景知識,以便於更好的理解今天的主題內容。
  在互聯網中,一個域名的順利解析離不開兩類域名服務器,只有由這兩類域名服務器可以提供“權威性”的域名解析。
  第一類就是國際域名管理機構,也就InterNIC,主要負責國際域名的註冊和解析,第二類就是國內域名註冊管理機構,在中國就是CNNIC了,主要負責國內域名註冊和解析,當然,儘管分爲國際和國內,但兩者一主一輔,相互同步信息,畢竟最終的目的是在全球任何一個有網絡的地方都可以順利訪問任何一個有效合法的域名,其間的聯繫就可見一斑了。
    有的朋友可能會有這個疑問,域名服務器不是有很多嗎?爲什麼說只有2類呢?是的,ISP何其多?當我們輸入某一網址(或域名),系統將這個域名發送至需要將其當前已配置的DNS服務器,以便轉換爲IP地址進行訪問,通常會是當地的公共DNS服務器(內網環境可能直接提交到防火牆或路由器上做進一步轉發處理)。公網DNS服務器收到此請求後,並非立刻處理,比如轉發至上一級的DNS服務器(在第一節講過DNS有着很嚴格的邏輯層次關係),而是首先會查看自己的DNS緩存,如果有這個域名對應的IP,則直接返回給用戶,系統收到這個IP後交給瀏覽器做進一步處理。在這個輪迴的過程中,客戶端所得到的DNS的回覆就是“非權威的性”的,也就是說這個結果並不是來自這個域名所直接授權的DNS服務器,而是該記錄的副本。簡單的說,“非權威性”的應答是從別的DNS服務器上覆制過來的,與之對應的,就是“權威性”應答則是由域名所在的服務器作出的應答,聽起來似乎不易理解,我們來看一個例子。
   我所在地是深圳,這裏的公共DNS服務器是202.96.134.133,我們來檢測一下。
如下圖:
這裏用到了nslookup命令,用來查詢當前本機解析域名所依賴的DNS服務器,從上圖中文名可以得知當前默認的DNS解析服務器是ns.szptt.net.cn,對應的IP地址爲202.96.134.133,也就是說在這臺機子上運行的網絡程序,如果需要用到DNS域名解析的,都會將請求到這個服務器上,尋求解析。
   當然,如果你是在內網,或是其他類型的局域網,在解析時候可能無法順利得到上圖的結果,多半是代理或防火牆的緣故。建議ADSL用戶可以自測一下,加深印象。現在,我們來解析一個網站的別名記錄,以此來了解一下何爲“非授權記錄”
以網易爲例吧。如下圖:
依照上圖步驟就完成了一次CNAME記錄的查詢,通過這次小測試,希望大家注意一下幾點:
1、查詢的命令不僅這一種,我們還可以用命令nslookup -qt=cname www.163.com ,返回的結果是一樣的。
2、查詢的對象需要是一個完整的URL地址,而並非域名,如果想查詢對象寫出163.com,則默認值返回163.com這個域的ns記錄。
如下圖:
163.com的子域名還有很多,不同的子域名可能對應不用的NS服務器,這樣做的目的是可以更快的相應客戶請求,這就用到的服務器的均衡負載技術了。所以網易的NS服務器也肯定不只這一個。可以用命令來證實,如下圖:
從上圖可知,網易的NS服務器至少有2臺。
以上所有的信息都是“非權威性”的迴應,換句話說,這些記錄都保存在深圳的這臺DNS服務器上,剛纔查詢的所有結果均來源於此,自然都是副本信息。
    那如何才能找到最原始的解析記錄呢?要想揭開這個疑難,我們需要對DNS的查詢原理有一定的認識。下面是是DNS查詢的大致步驟:
1> 首先,客戶端提出域名解析請求(無論以何種形式或方法),並將該請求發或轉發給本地的DNS服務器。 
2> 接着,本地DNS服務器收到請求後就去查詢自己的緩存,如果有該條記錄,則會將查詢的結果返回給客戶端。(也就是我們看到的““非權威性”的應答”)。
  請注意,下面就開始遞歸查詢了: 
  反之,如果DNS服務器本地沒有搜索到相應的記錄,則會把請求轉發到根DNS(13臺根DNS服務器的IP信息默認均存儲在DNS服務器中,當需要時就會去有選擇性的連接)。 
3> 然後,根DNS服務器收到請求後會判斷這個域名是誰來授權管理,並會返回一個負責該域名子域的DNS服務器地址。比如,查詢ent.163.com的IP,根DNS服務器就會在負責.com頂級域名的DNS服務器中選一個(並非隨機,而是根據空間、地址、管轄區域等條件進行篩選),返回給本地DNS服務器。可以說根域對頂級域名有絕對管理權,自然也知道他們的全部信息,因爲在DNS系統中,上一級對下一級有管理權限,毫無疑問,根DNS是最高一級了。
4> 本地DNS服務器收到這個地址後,就開始聯繫對方並將此請求發給他。負責.com域名的某臺服務器收到此請求後,如果自己無法解析,就會返回一個管理.com的下一級的DNS服務器地址給本地DNS服務器,也就是負責管理163.com的DNS。
5> 當本地DNS服務器收到這個地址後,就會重複上面的動作,繼續往下聯繫。
6> 不斷重複這樣的輪迴過程,直到有一臺DNS服務器可以順利解析出這個地址爲止。在這個過程中,客戶端一直處理等待狀態,他不需要做任何事,也做不了什麼。
7> 直到本地DNS服務器獲得IP時,纔會把這個IP返回給客戶端,到此在本地的DNS服務器取得IP地址後,遞歸查詢就算完成了。本地DNS服務器同時會將這條記錄寫入自己的緩存,以備後用。
   到此,整個解析過程完成。
   客戶端拿到這個地址後,就可以順利往下進行了。但假設客戶端請求的域名根本不存在,解析自然不成功,DNS服務器會返回此域名不可達,在客戶端的體現就是網頁無法瀏覽或網絡程序無法連接等等。
   下節中,我將以圖解的方式將這個過程體現出來,便於大家形象化的理解遞歸查詢的過程,謝謝。
   敬請期待!
本文出自 “許一君的原創技術博客” 博客,請務必保留此出處http://jeffyyko.blog.51cto.com/28563/215293
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章