DNS(Domain Name System,域名系統),是目前互聯網上最不可或缺的服務器之一,我們在互聯網從訪問一個網站,到發送一封電子郵件,再到定位域中的域控制器,無時無刻不再使用著DNS為我們提供的服務,那為什么我們會需要這樣一個服務那?帶著這樣一個疑問讓我們先來認識一下什么是DNS吧
DNS最核心的工作就是域名解析,也就是把計算機名翻譯成IP地址,這樣我們就可以按照自己容易理解的方式來為一臺主機或者一個網站取一個名字,其他人也就可以通過這個名字來訪問我們的主機或者網站了,而不必去記住那些枯燥晦澀的IP地址,只有計算機才會才更容易理解那些地址,其實早在1969年互聯網就誕生了,雖然早期的互聯網的規模比較小,到70年代互聯網也只有幾百臺主機而已,這樣每臺主機之間相互訪問的就有一個比較簡單的辦法,就是每臺主機利用一個hosts文件就可以把互聯網上所有的主機都解析出來,hosts文件也計較簡單,就是每一行記錄一個主機對應的IP地址,在當時,這樣一個解決方案是可以滿足需要的,但是隨著互聯網規模的迅速膨脹,這樣一個僅僅靠hosts文件來識別網絡中主機的方案,顯然是不合適的,就按保守的算互聯網中有1億臺主機,什么的hosts文件能存放1億條記錄那?而且每時每刻這些記錄都有可能變化, 這也就是為什么現在會有需要的DNS服務的原因了。
早期互聯網利用host文件來定位其他主機位置的方法其實就是完全分散的解析方案,每臺主機都自己負責名稱解析,而DNS的出現就仿佛在告訴世人,域名解析這個事由我一個人來解決,你們只要給我發請求我就回答這個域名的地址是什么,我們都知道,如果真有這樣的一個DNS服務器的話,這個DNS服務器將會面臨多大的流量壓力,這個DNS服務器里面的解析條目會不會有極限,如何及時的更新這些解析條目,每一個問題都將使這臺DNS服務器的陷入絕境,那DNS的設計者們是怎么樣處理這些問題的那?
首先DNS采用的是分布式解決方案,具體是這樣的,互聯網管理委員會規定,域名的解釋權都歸根服務器所有,而根服務器通過委派,把com結尾的域名解析權委派給其他的DNS服務器,以后所有以com結尾的域名根服務器就都不負責解析了,而是由被委派的服務器負責解析,而且根服務器還把以net、org、edu、gov等等結尾的域名都一一進行進行了了委派,每個頂級域名都有預設的用途,例如com域名用于商業公司,edu域名用于教育機構,gov域名用于政府機關等等,這種頂級域名也被稱為頂級機構域名。根服務器還針對不同國家進行了域名委派,例如把所有以cn結尾的域名委派給中國互聯網管理中心,以jp結尾的域名委派給日本互聯網管理中心,cn、jp這些頂級域名被稱為頂級地理域名。 每個被委派的DNS服務器同樣使用委派的方式向下發展,例如新浪公司想申請使用sina.com域名,這時新浪公司就要向負責.com域名的DNS服務器提出申請,只要sina.com還沒有被其他公司或個人使用,而且申請者按時足額繳納了費用,負責.com域名的服務器就會把sina.com域名委派到新浪公司自己的DNS服務器,這時候你就知道一個域名對一家互聯網公司來講有多重要了吧,
讓我們來看下面這張圖,我想學過linux的同學就會覺得很熟悉,這不就是linux系統的目錄結構嗎,同時在公司待過一段時間的小伙伴也一樣會覺得很熟悉,這不就是一家現代公司的組織架構嗎,總經理就好比最上層的根,其他的部門經理就好比以com、net、org結尾的域名解析服務器一樣,根域名服務器和總經理一樣不負責任何一個具體的事務,只是把解析權授權給其他的域名服務器,
有了上面的認識以后,對于我們來了解一個域名具體的解析過程有著很大的幫助,一次DNS的工作過程是怎么樣的那,首先DNS的查詢類型分為遞歸查詢和迭代查詢;
遞歸查詢:一次查詢就得到最終的結果,通常是客戶端與本地DNS服務器之間會使用遞歸查詢。
迭代查詢:有可能發生多次請求,且每次得到的結果有可能只是參考答案,通常是DNS服務器直接會使用迭代查詢。
1)首先客戶端怎樣發起一個DNS查詢請求,例如此時你在瀏覽器地址欄輸入www.163.com敲回車之后,那么瀏覽器并沒有發起DNS請求,而是先查詢本機的DNS緩存中是否有該域名對應的地址,有的話直接訪問該地址,沒有的話查詢本機的hosts文件,如果剛好你本機的hosts文件中有該域名對應的地址,那么此刻客戶端是不會發起dns請求的,但是通常情況下本地的host文件是空的,所以就有了第二步
2)經歷是前面兩次本機內部的查詢之后發現并沒有該域名對應的IP地址,于是客戶端正式向本地的DNS服務器發起DNS查詢請求。
3)本地的DNS服務器收到這個查詢請求后,會查詢自己的緩存中以及自己的資源記錄中是否有該域名對應的IP地址,如果在自己的緩存中以及本機的資源記錄中依然找不到該對應的IP地址,此時本地DNS服務器會把請求發送給大名鼎鼎的13臺根服務器中的一臺,
4)其中一臺根服務器收到這個請求后,會發送一個回復說,.com的域名解析服務我已經委派給.com這臺域名服務器了,給你這個.com這臺域服務器的地址,你去哪里查詢吧,此時本地DNS服務器就進入了迭代查詢。
5)本地DNS服務器收到這個參考答案后,就會將它收到來自客戶端的DNS請求再次發往.com域名服務器。
6)負責.com域名解析服務器收到這個請求后,會回復說163.com的主區域服務器應該會知道答案,給你163.com主區域服務器的地址,你去它那里查詢吧。
7)本地DNS服務器收到這個參考答案后,就會將它收到來自客戶端的DNS請求再次發往163.com主區域服務器,當163.com這個主區域服務器收到這個DNS請求后,查詢自己的緩存以及自己的資源記錄,終于找到本區域內有一個www的主機。于是將www.163.com對應的ip地址回復給本地DNS服務器。
8)此時本地DNS服務器收到這個回復后,會將這條記錄回復給客戶端,同時將該記錄寫入到自己的緩存中,以便備查。
以上只是簡單的介紹了一個DNS請求的大致過程,當然實際的過程中要比這復雜的多,同時除了正向解析:FQDNàIP的解析之外,還包括反響解析:IPàFQDN。歡迎來一起討論,
從上面DNS請求的過程可以了解到,客戶端發送一個請求后,本地的DNS服務器就需要對不斷的迭代查詢客戶端發起的這個請求到底是哪個地址,直到找到這個域名所對應的IP地址是什么為止,那這臺DNS服務器具體是怎么工作的那?以及這臺DNS服務器都有哪些部分組成那?接下來,讓我們先來認識一下DNS服務器都有哪些類型,
1)主DNS服務器:維護所負責解析的域內解析庫服務器,有管理員維護
2)輔DNS服務器:從主DNS服務器或者其他DNS服務器哪里復制(也叫區域傳送)一份解析庫,從服務器通過每次檢測解析庫的版本號,沒到一次刷新時間間隔就會通過全局傳送或者區域傳送從主服務器上面更新解析庫。
3)緩存DNS服務器:通常就是用來存儲網絡上用戶需要的網頁和內容的網絡服務器。而DNS緩存服務器即是存在DNS信息,它可以將它收到的DNS信息存儲下來,并再將其提供給其它的用戶進行查詢,直到這些信息過期
4)轉發器:只做轉發
從上面DNS服務器的類型上可以看出,主DNS服務器承擔著重要的工作,那究竟我們的主DNS服務器如何工作的那?其實DNS服務器是通過由眾多資源記錄(Resource Record)這個區域解析庫來完成解析,任何一臺主DNS服務器都是如此,無論是windows平臺上面使用的域控制器,還是linux平臺的bind都是通過這些資源記錄來完成解析過程。以下就是這些資源記錄的類型以及語法格式,每條資源記錄的語法都遵循
name [TTL] IN rr_type value
SOA記錄:Start Of Authority,起始授權記錄;一個區域解析庫有且僅能有一個SOA記錄,而必須為解析庫的第一條記錄;
name: 當前區域的名字,例如“sina.com.”;
value: 有多部分組成
(1) 當前區域的主DNS服務器的FQDN,也可以使用當前區域的名字。
(2) 錄前區域管理員的郵箱地址;但地址中不能使用@符號,一般用“.”替換。
(3) 主從服務協調屬性的定義以及否定的答案的統一的TTL。
A記錄:internet Address,作用,FQDN(完全格式域名) –> IP
name: 某主機的FQDN(完全格式域名);
value: 主機名對應主機的IPv4地址;
AAAA記錄: FQDN(完全格式域名)–> IPv6
name: 某主機的FQDN(完全格式域名);
value: 主機名對應主機的IPv6地址;
PTR記錄: PoinTeR,IP –> FQDN(完全格式域名),用于反向解析
name: IP,有特定格式,把IP地址反過來寫,1.2.3.4,要寫作4.3.2.1;而有特定后綴
in-addr.arpa.,所以完整寫法為:4.3.2.1.in-addra.arpa.;
value: FQDN(完全格式域名);
NS記錄: Name Server,專用于標明當前區域的DNS服務器
name: 當前區域的名字;
value: 當前區域的某DNS服務器的名字;
注意:一個區域可以有多個NS記錄;
CNAME記錄:Canonical Name,別名記錄
name: 別名的FQDN(完全格式域名);
value: 正式名字的FQDN(完全格式域名);
MX:記錄 Mail exchanger,郵件交換器,用于定位該區域中的郵件服務器
name: 當前區域的名字;
value: 當前區域的某郵件服務器(smtp服務器)的主機名;
注意:一個區域內,MX記錄可有多個;但每個記錄的value之前應該有一個數字(0-99),表示此服務器的優先級;數字越小優先級越高;
以上的這些基礎認識,對于我們配置windows下的DNS服務器,還是linux平臺下bind都是必須要理解的,在下一篇博文中我會詳細介紹linux平臺下bind的正反向解析、主從同步、子域授權以及bind view,預知后事如何,且聽下回分解。
原創文章,作者:zhang,如若轉載,請注明出處:http://www.www58058.com/9994
圖非常精艷,文章少了樣式致使可讀性大打折扣
[…] 轉載請注明:linux運維部落 ? 淺談DNS基本原理以及實現方法(一) […]