DNS基本操作詳解
2016-04-10 23:46
Loull
閱讀(996)
評論(0)
編輯
收藏
舉報
在很多人看來，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記錄。例如我要請求ftp.cobb.com，而我的域名伺服器将ftp.cobb.com CNAME到了ljx.cobb.com，但是ljx.cobb.com這個主機不存在，這個時候就傳回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
五、參考文獻：
1，www.cnblogs.com/cobbliu
2，《Pro_DNS_and_BIND》
3，維基百科
- 分類 DNS