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

一、 DNS協(xié)議

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

二、 DNS查詢

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

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

　　1，遞歸查詢

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

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

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

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

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

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

  　2，迭代查詢

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

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

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

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

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

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

　 3，反向查詢

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

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

三、域維護(hù)

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

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

     1，全量傳輸AXFR

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

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

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

　　2，增量傳輸(IXFR)

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

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

　　3，通告(NOTIFY)

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

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

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

　　4，動(dòng)態(tài)更新

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

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

　　另外一種是將zone中的資源記錄RR存儲(chǔ)在數(shù)據(jù)庫(kù)中，每次查找zone中記錄的時(shí)候動(dòng)態(tài)讀取；

四、DNS安全

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

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

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

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

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

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

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

　　1，www.cnblogs.com/cobbliu

　　2，《Pro_DNS_and_BIND》

　　3，維基百科

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