在很多人看來，DNS只是為外部提供DNS解析服務(wù)（我以前也是這么認(rèn)為的，直到膝蓋中了一箭），但作為互聯(lián)網(wǎng)的基礎(chǔ)設(shè)施，DNS遠(yuǎn)沒有想象的那么簡單。如果你沒有聽說過DNS查詢、反向解析、zone傳輸、動態(tài)更新、DNS安全，那你可以從本文中得到關(guān)于他們的最簡明的詮釋。

一、 DNS協(xié)議

　　DNS在53端口上監(jiān)聽請求并提供響應(yīng)的服務(wù)。出于性能的考慮，DNS查詢請求用UDP協(xié)議交互并且每個請求的大小小于512字節(jié)，但是如果返回的請求大小大于512字節(jié)，交互雙方會協(xié)商使用TCP協(xié)議。

二、 DNS查詢

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

DNS系統(tǒng)中有三類查詢：

　　1，遞歸查詢

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

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

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

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

　　2），一個標(biāo)示域或主機(jī)不存在的錯誤信息。需要注意的是這個錯誤信息也可能含有CNAME記錄。例如我要請求ftp.cobb.com，而我的域名服務(wù)器將ftp.cobb.com CNAME到了ljx.cobb.com，但是ljx.cobb.com這個主機(jī)不存在，這個時候就返回CNAME記錄和錯誤信息。

　　3），暫時性的錯誤信息。它主要是因為網(wǎng)絡(luò)不可達(dá)該主機(jī)，網(wǎng)絡(luò)不可達(dá)不一定表明該主機(jī)不存在。

  　2，迭代查詢

　　域名服務(wù)器在返回一些下一次查詢的指引或者主機(jī)IP地址，域名解析器在收到指引后會再次向這些指引發(fā)起查詢請求，直到收到主機(jī)IP地址。迭代解析的過程如下圖所示：

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

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

     2），標(biāo)示域或主機(jī)不存在的錯誤信息。

     3），暫時性錯誤?？赡芤驗榫W(wǎng)絡(luò)不可達(dá)。

     4），可以給出下一步域名解析的域名服務(wù)器（包括它的IP地址）的列表。告訴解析器再去哪里進(jìn)一步解析。

　 3，反向查詢

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

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

三、域維護(hù)

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

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

     1，全量傳輸AXFR

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

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

　　全量傳輸時在TCP的53端口上進(jìn)行。

　　2，增量傳輸(IXFR)

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

　　需要注意的是，不是所有的域名服務(wù)器都支持增量傳輸，當(dāng)不支持增量傳輸時，主從間就采用全量傳輸?shù)姆绞健?/p>

　　3，通告(NOTIFY)

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

　　所以在實現(xiàn)了通告消息的DNS集群中，DNS主服務(wù)器的zone文件發(fā)生改變后，它立即向從服務(wù)器發(fā)送一個NOTIFY消息，告訴從服務(wù)器我的zone文件發(fā)生改變了，接著從服務(wù)器馬上對比兩者的序列號，再采用上面介紹的全量傳輸或者增量傳輸?shù)姆椒ㄕ埱髗one文件。

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

　　4，動態(tài)更新

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

     一種是允許外部進(jìn)程在服務(wù)器運(yùn)行的時候更新zone文件；

　　另外一種是將zone中的資源記錄RR存儲在數(shù)據(jù)庫中，每次查找zone中記錄的時候動態(tài)讀?。?/p>

四、DNS安全

　　像其他的任何公共服務(wù)一樣，DNS也會受到各種各樣的安全威脅。這節(jié)看看DNS服務(wù)器會受到什么樣的安全威脅？聰明的人們又是怎么應(yīng)對這些威脅的。

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

　　上圖中的每個數(shù)據(jù)流都會受到響應(yīng)的安全威脅：

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

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

　　4）5）遠(yuǎn)程查詢受到的威脅可能有：cache污染（IP欺騙、數(shù)據(jù)攔截或錯誤的master主機(jī)地址）。cache污染是指cache中內(nèi)容可能將您的域名重定向到了一個錯誤的服務(wù)器。這種威脅通常的應(yīng)對方法是域名系統(tǒng)安全擴(kuò)展（DNSSEC, Domain Name System Security Extensions），它是為DNS客戶端（解析器）提供的的DNS數(shù)據(jù)來源，數(shù)據(jù)完整性驗證，但不提供或機(jī)密性和認(rèn)證的拒絕存在擴(kuò)展集。關(guān)于DNSSEC的資料見這里。關(guān)于這部分內(nèi)容，我會在后續(xù)的博客中專門介紹，請關(guān)注：www.cnblogs.com/cobbliu

五、參考文獻(xiàn)：

　　1，www.cnblogs.com/cobbliu

　　2，《Pro_DNS_and_BIND》

　　3，維基百科

聲明：您如果覺得這篇文章對您有幫助，可以任意引用，學(xué)習(xí)的樂趣在于分享！by -- @西涼元朔