DNS基本概念及操作詳解

目錄：

1.DNS協議

2.DNS查詢

2.1遞歸查詢

2.2跌代查詢

2.3反向查詢

3.域維護

3.1全量AXFR傳輸

3.2增量IXFR傳輸

3.3通過NOTIFY

3.4動態更新

4.DNS安全

在很多人看來，DNS只是為外部提供DNS解析服務（我以前也是這麽認為的，直到膝蓋中了一箭），但作為互聯網的基礎設施，DNS遠沒有想象的那麽簡單。如果你沒有聽說過DNS查詢、反向解析、zone傳輸、動態更新、DNS安全，那你可以從本文中得到關於他們的最簡明的詮釋。

一、 DNS協議

DNS在53端口上監聽請求並提供響應的服務。出於性能的考慮，DNS查詢請求用UDP協議交互並且每個請求的大小小於512字節，但是如果返回的請求大小大於512字節，交互雙方會協商使用TCP協議。

二、 DNS查詢

DNS中的域名服務器最主要的功能就是響應域名解析器的查詢請求（這個域名解析器可能是PC端的解析器，也可能是具有解析功能的另一臺域名服務器）。域名解析器是安裝在PC端的軟件，它負責向本地DNS（local DNS）發起域名解析請求。

DNS系統中有三類查詢：

　　1，遞歸查詢

　　域名服務器將代替請求的客戶機（下級DNS服務器）進行域名查詢，如果域名服務器不能直接回答，則域名服務器會在域各樹種的各個分支的上下進行遞歸查詢，最終將查詢結果返回給客戶機，在域名查詢期間，客戶機始終處於等待狀態。遞歸解析的過程如下圖所示：

上圖中需要註意的是，許多授權域名服務器都不會提供遞歸查詢的功能（為什麽？），比如根域名服務器.和二級域名服務器.com都不提供遞歸查詢的功能，所以真正意義上的遞歸查詢是由Local DNS來完成的。

　　一般情況下，遞歸查詢的時候會收到以下三種可能的返回結果：

　　1），一個或若幹個A記錄，或者帶有CNAME鏈的A記錄。A記錄即要請求的域名的IP地址，帶有CNAME鏈的A記錄就像上一篇博客“DNS開源服務器BIND最小配置詳解”裏面請求ftp.cobb.com時會先將ftp.cobb.com CNAME到 ljx.cobb.com，然後返回ljx.cobb.com的A記錄。

　　2），一個標示域或主機不存在的錯誤信息。需要註意的是這個錯誤信息也可能含有CNAME記錄。例如我要請求

　　3），暫時性的錯誤信息。它主要是因為網絡不可達該主機，網絡不可達不一定表明該主機不存在。

2，叠代查詢

　域名服務器在返回一些下一次查詢的指引或者主機IP地址，域名解析器在收到指引後會再次向這些指引發起查詢請求，直到收到主機IP地址。叠代解析的過程如下圖所示：

一般情況下，遞歸查詢的時候會收到以下三種可能的返回結果：

1），A記錄或者帶有CNAME鏈的A記錄。

2），標示域或主機不存在的錯誤信息。

3），暫時性錯誤。可能因為網絡不可達。

4），可以給出下一步域名解析的域名服務器（包括它的IP地址）的列表。告訴解析器再去哪裏進一步解析。

3，反向查詢

　　反向查詢是根據一個資源記錄查詢域名。這個資源記錄可能是A記錄，CNAME記錄或者MX記錄（見“DNS開源服務器BIND最小配置詳解”）。

　　為了實現反向查詢，DNS中有一個特殊的域名IN-ADDR.ARPA來專門作反向查詢定義。詳情見RFC3425。

三、域維護

　　域維護是指通過DNS協議來在主域名服務器和從域名服務器之間維護同一個zone文件。

　　DNS中有兩種域維護手段，一種是全量傳輸AXFR(full zone transfer)，另一種是增量傳輸IXFR(incremental zone transfer)。

1，全量傳輸AXFR

　　全量傳輸時，從域名服務器從主域名服務器上請求zone文件，poll的時間間隔由SOA記錄中的refresh標簽定義。請求zone文件的過程是從域名服務器向主域名服務器發送查詢來實現，如果主域名服務器中SOA記錄中的序列號(serial number標簽定義)大於從域名服務器SOA記錄的序列號，從域名服務器就會向主域名服務器發送全量傳輸請求。所以主域名服務器一旦改變了zone文件，則需要增加它該zone中的序列號。整個SOA記錄的完整格式見下圖：

通常情況下，序列號sn遵循“年+月+日+編號”的格式，如圖中的2003080803表示該zone是2003年8月8日的第三次更新。

　　全量傳輸時在TCP的53端口上進行。

　　2，增量傳輸(IXFR)

　　傳遞非常大的zone文件是非常耗資源的（時間、帶寬等），尤其是只有zone中的一個記錄改變的時候，沒有必要傳遞整個zone文件，增量傳輸是允許主域名服務器和從域名服務器之間只傳輸那些改變的記錄。

　　需要註意的是，不是所有的域名服務器都支持增量傳輸，當不支持增量傳輸時，主從間就采用全量傳輸的方式。

　　3，通告(NOTIFY)

　　從上面的分析中可以看出，從服務器每隔refresh時間向主服務器發送請求，只有主服務器的SOA中的序列號大於從服務器的序列號才傳輸，但是如果這個時間間隔比較大的話（比如12個小時），快速變化的網絡環境可能不允許有如此大時間的差異。

　　所以在實現了通告消息的DNS集群中，DNS主服務器的zone文件發生改變後，它立即向從服務器發送一個NOTIFY消息，告訴從服務器我的zone文件發生改變了，接著從服務器馬上對比兩者的序列號，再采用上面介紹的全量傳輸或者增量傳輸的方法請求zone文件。

　　BIND本身支持通告，通告的配置是在named.conf中的zone中的option中配置，配置指令是notify, also-notify和notify-source，具體見這裏。

　　4，動態更新

　　每次需要更新zone文件的時候都需要停止域名服務器並重啟，這樣當zone文件很多的時候域名服務器重啟時加載zone文件需要很多的時間。所以需要有一種不停止查詢服務而且快速更新zone文件地方機制，這種機制主要有兩種：

一種是允許外部進程在服務器運行的時候更新zone文件；

　　另外一種是將zone中的資源記錄RR存儲在數據庫中，每次查找zone中記錄的時候動態讀取；

四、DNS安全

　　像其他的任何公共服務一樣，DNS也會受到各種各樣的安全威脅。這節看看DNS服務器會受到什麽樣的安全威脅？聰明的人們又是怎麽應對這些威脅的。

　　為了了解DNS受到的安全威脅和響應的應對措施，首先需要了解一下DNS的正常數據流。如下圖所示：

上圖中的每個數據流都會受到響應的安全威脅：

　　1）zone文件受到的威脅可能有：文件被無意或有意篡改或刪除。這種威脅是較好應對的，最主要的方法是制定很好的系統管理策略，zone文件和其他的配置文件需要嚴格而安全的讀寫權限。

　　2）3）動態更新和域傳輸受到的威脅可能有：未授權的更新、zone文件在傳輸過程中被篡改（經常是把域名篡改為別的IP）。這種威脅通常的應對方法是TSIG(Transaction SIGnature)策略（這個策略定義在RFC2845中）。TSIG策略中會計算出一個key，這個key是通過單向散列(能輕松地從輸入得出值，但很難通過值猜出輸入)計算出來的，然後傳輸zone文件的雙方在傳輸過程中都帶上這個key，如果key不對就拒絕傳輸。

　　4）5）遠程查詢受到的威脅可能有：cache汙染（IP欺騙、數據攔截或錯誤的master主機地址）。cache汙染是指cache中內容可能將您的域名重定向到了一個錯誤的服務器。這種威脅通常的應對方法是域名系統安全擴展（DNSSEC, Domain Name System Security Extensions），它是為DNS客戶端（解析器）提供的的DNS數據來源，數據完整性驗證，但不提供或機密性和認證的拒絕存在擴展集。

關於DNSSEC的資料見這裏。關於這部分內容，我會在後續的博客中專門介紹，請關註：www.cnblogs.com/cobbliu

本文出自 “每天進步一點點，自律” 博客，請務必保留此出處http://wbxue.blog.51cto.com/11831715/1966975

DNS基本概念及操作詳解----------------轉載