From：http://blog.csdn.net/yipiankongbai/article/details/25031461
一、域名系統
1、域名系統概述
? ? ? ? 域名系統DNS(Domain Name System)是因特網使用的命名系統，用來把便于人們使用的機器名字轉換成為IP地址。域名系統其實就是名字系統。為什么不叫“名字”而叫“域名”呢？這是因為在這種因特網的命名系統中使用了許多的“域(domain)”，因此就出現了“域名”這個名詞。“域名系統”明確地指明這種系統是應用在因特網中。
? ? ? ? 我們都知道，IP地址是由32位的二進制數字組成的。用戶與因特網上某臺主機通信時，顯然不愿意使用很難記憶的長達32位的二進制主機地址。即使是點分十進制IP地址也并不太容易記憶。相反，大家愿意使用比較容易記憶的主機名字。但是，機器在處理IP數據報時，并不是使用域名而是使用IP地址。這是因為IP地址長度固定，而域名的長度不固定，機器處理起來比較困難。
? ? ? ? 因為因特網規模很大，所以整個因特網只使用一個域名服務器是不可行的。因此，早在1983年因特網開始采用層次樹狀結構的命名方法，并使用分布式的域名系統DNS。并采用客戶服務器方式。DNS使大多數名字都在本地解析(resolve)，僅有少量解析需要在因特網上通信，因此DNS系統的效率很高。由于DNS是分布式系統，即使單個計算機除了故障，也不會妨礙整個DNS系統的正常運行。
? ? ? ? 域名到IP地址的解析是由分布在因特網上的許多域名服務器程序共同完成的。域名服務器程序在專設的結點上運行，而人們也常把運行域名服務器程序的機器稱為域名服務器。
? ? ? ? 域名到IP地址的解析過程的要點如下：當某一個應用需要把主機名解析為IP地址時，該應用進程就調用解析程序，并稱為DNS的一個客戶，把待解析的域名放在DNS請求報文中，以UDP用戶數據報方式發給本地域名服務器。本地域名服務器在查找域名后，把對應的IP地址放在回答報文中返回。應用程序獲得目的主機的IP地址后即可進行通信。
? ? ? ? 若本地域名服務器不能回答該請求，則此域名服務器就暫時稱為DNS的另一個客戶，并向其他域名服務器發出查詢請求。這種過程直至找到能夠回答該請求的域名服務器為止。此過程在后面作進一步討論。
2、因特網的域名結構
? ? ? ? 由于因特網的用戶數量較多，所以因特網在命名時采用的是層次樹狀結構的命名方法。任何一個連接在因特網上的主機或路由器，都有一個唯一的層次結構的名字，即域名(domain name)。這里，“域”(domain)是名字空間中一個可被管理的劃分。
? ? ? ? 從語法上講，每一個域名都是有標號(label)序列組成，而各標號之間用點(小數點)隔開。
? ? ? ? 如下例子所示：
? ? ? ? 這是中央電視臺用于手法電子郵件的計算機的域名，它由三個標號組成，其中標號com是頂級域名，標號cctv是二級域名，標號mail是三級域名。
? ? ? ? DNS規定，域名中的標號都有英文和數字組成，每一個標號不超過63個字符(為了記憶方便，一般不會超過12個字符)，也不區分大小寫字母。標號中除連字符(-)外不能使用其他的標點符號。級別最低的域名寫在最左邊，而級別最高的字符寫在最右邊。由多個標號組成的完整域名總共不超過255個字符。DNS既不規定一個域名需要包含多少個下級域名，也不規定每一級域名代表什么意思。各級域名由其上一級的域名管理機構管理，而最高的頂級域名則由ICANN進行管理。用這種方法可使每一個域名在整個互聯網范圍內是唯一的，并且也容易設計出一種查找域名的機制。
? ? ? ? 域名只是邏輯概念，并不代表計算機所在的物理地點。據2006年12月統計，現在頂級域名TLD(Top Level Domain)已有265個，分為三大類：
? ? ? ? (1)國家頂級域名nTLD：采用ISO3166的規定。如：cn代表中國，us代表美國，uk代表英國，等等。國家域名又常記為ccTLD(cc表示國家代碼contry-code)。
? ? ? ? (2)通用頂級域名gTLD：最常見的通用頂級域名有7個，即：com(公司企業)，net(網絡服務機構)，org(非營利組織)，int(國際組織)，gov(美國的政府部門)，mil(美國的軍事部門)。
? ? ? ? (3)基礎結構域名(infrastructure domain)：這種頂級域名只有一個，即arpa，用于反向域名解析，因此稱為反向域名。
3、域名服務器
? ? ? ? 如果采用上述的樹狀結構，每一個節點都采用一個域名服務器，這樣會使得域名服務器的數量太多，使域名服務器系統的運行效率降低。所以在DNS中，采用劃分區的方法來解決。
? ? ? ? 一個服務器所負責管轄(或有權限)的范圍叫做區(zone)。各單位根據具體情況來劃分自己管轄范圍的區。但在一個區中的所有節點必須是能夠連通的。每一個區設置相應的權限域名服務器，用來保存該區中的所有主機到域名IP地址的映射。總之，DNS服務器的管轄范圍不是以“域”為單位，而是以“區”為單位。區是DNS服務器實際管轄的范圍。區 <= 域。
? ? ? ? 下圖是區的不同劃分方法的舉例。假定abc公司有下屬部門x和y，部門x下面有分三個分布們u,v,w，而y下面還有下屬部門t。圖a表示abc公司只設一個區abc.com。這是，區abc.com和域abc.com指的是同一件事。但圖b表示abc公司劃分為兩個區：abc.com和y.abc.com。這兩個區都隸屬于域abc.com，都各設置了相應的權限域名服務器。不難看出，區是域的子集。
? ? ? ? 下圖是以上圖b中abc公司劃分的兩個區為例，給出了DNS域名服務器樹狀結構圖。這種DNS域名服務器樹狀結構圖可以更準確地反映出DNS的分布式結構。圖中的每一個域名服務器都能夠部分域名到IP地址的解析。當某個DNS服務器不能進行域名到IP地址的轉換時，它就會設法找因特網上別的域名服務器進行解析。
? ? ? ? 從下圖可以看出，因特網上的DNS服務器也是按照層次安排的。每一個域名服務器只對域名體系中的一部分進行管轄。根據域名服務器所起的作用，可以把域名服務器劃分為下面四種不同的類型。
根域名服務器：最高層次的域名服務器，也是最重要的域名服務器。所有的根域名服務器都知道所有的頂級域名服務器的域名和IP地址。不管是哪一個本地域名服務器，若要對因特網上任何一個域名進行解析，只要自己無法解析，就首先求助根域名服務器。所以根域名服務器是最重要的域名服務器。假定所有的根域名服務器都癱瘓了，那么整個DNS系統就無法工作。需要注意的是，在很多情況下，根域名服務器并不直接把待查詢的域名直接解析出IP地址，而是告訴本地域名服務器下一步應當找哪一個頂級域名服務器進行查詢。
頂級域名服務器：負責管理在該頂級域名服務器注冊的二級域名。
權限域名服務器：負責一個“區”的域名服務器。
本地域名服務器：本地服務器不屬于下圖的域名服務器的層次結構，但是它對域名系統非常重要。當一個主機發出DNS查詢請求時，這個查詢請求報文就發送給本地域名服務器。
4、域名的解析過程
注意：
? ? ? ? 一、主機向本地域名服務器的查詢一般都是采用遞歸查詢。所謂遞歸查詢就是：如果主機所詢問的本地域名服務器不知道被查詢的域名的IP地址，那么本地域名服務器就以DNS客戶的身份，向其它根域名服務器繼續發出查詢請求報文(即替主機繼續查詢)，而不是讓主機自己進行下一步查詢。因此，遞歸查詢返回的查詢結果或者是所要查詢的IP地址，或者是報錯，表示無法查詢到所需的IP地址。
? ? ? ?二、本地域名服務器向根域名服務器的查詢的迭代查詢。迭代查詢的特點：當根域名服務器收到本地域名服務器發出的迭代查詢請求報文時，要么給出所要查詢的IP地址，要么告訴本地服務器：“你下一步應當向哪一個域名服務器進行查詢”。然后讓本地服務器進行后續的查詢。根域名服務器通常是把自己知道的頂級域名服務器的IP地址告訴本地域名服務器，讓本地域名服務器再向頂級域名服務器查詢。頂級域名服務器在收到本地域名服務器的查詢請求后，要么給出所要查詢的IP地址，要么告訴本地服務器下一步應當向哪一個權限域名服務器進行查詢。最后，知道了所要解析的IP地址或報錯，然后把這個結果返回給發起查詢的主機。
? ? ? ? 下圖給出了這兩種查詢的差別
? ? ? ? 下面舉一個例子演示整個查詢過程：
? ? ? ? 假定域名為m.xyz.com的主機想知道另一個主機y.abc.com的IP地址。例如，主機m.xyz.com打算發送郵件給y.abc.com。這時就必須知道主機y.abc.com的IP地址。下面是上圖a的幾個查詢步驟：
? ? ? ? 1、主機m.abc.com先向本地服務器dns.xyz.com進行遞歸查詢。
? ? ? ? 2、本地服務器采用迭代查詢。它先向一個根域名服務器查詢。
? ? ? ? 3、根域名服務器告訴本地服務器，下一次應查詢的頂級域名服務器dns.com的IP地址。
? ? ? ? 4、本地域名服務器向頂級域名服務器dns.com進行查詢。
? ? ? ? 5、頂級域名服務器dns.com告訴本地域名服務器，下一步應查詢的權限服務器dns.abc.com的IP地址。
? ? ? ? 6、本地域名服務器向權限域名服務器dns.abc.com進行查詢。
? ? ? ? 7、權限域名服務器dns.abc.com告訴本地域名服務器，所查詢的主機的IP地址。
? ? ? ? 8、本地域名服務器最后把查詢結果告訴m.xyz.com。
? ? ? ? 整個查詢過程共用到了8個UDP報文。
? ? ? ? 為了提高DNS查詢效率，并減輕服務器的負荷和減少因特網上的DNS查詢報文數量，在域名服務器中廣泛使用了高速緩存，用來存放最近查詢過的域名以及從何處獲得域名映射信息的記錄。
? ? ? ? 例如，在上面的查詢過程中，如果在m.xyz.com的主機上不久前已經有用戶查詢過y.abc.com的IP地址，那么本地域名服務器就不必向根域名服務器重新查詢y.abc.com的IP地址，而是直接把告訴緩存中存放的上次查詢結果(即y.abc.com的IP地址)告訴用戶。
? ? ? ? 由于名字到地址的綁定并不經常改變，為保持告訴緩存中的內容正確，域名服務器應為每項內容設置計時器并處理超過合理時間的項(例如每個項目兩天)。當域名服務器已從緩存中刪去某項信息后又被請求查詢該項信息，就必須重新到授權管理該項的域名服務器綁定信息。當權限服務器回答一個查詢請求時，在響應中都指明綁定有效存在的時間值。增加此時間值可減少網絡開銷，而減少此時間值可提高域名解析的正確性。
不僅在本地域名服務器中需要高速緩存，在主機中也需要。許多主機在啟動時從本地服務器下載名字和地址的全部數據庫，維護存放自己最近使用的域名的高速緩存，并且只在從緩存中找不到名字時才使用域名服務器。維護本地域名服務器數據庫的主機應當定期地檢查域名服務器以獲取新的映射信息，而且主機必須從緩存中刪除無效的項。由于域名改動并不頻繁，大多數網點不需花精力就能維護數據庫的一致性。
From：http://blog.chinaunix.net/uid-28216282-id-3757849.html
DNS的幾個基本概念：
就是所謂的“.”，其實我們的網址www.baidu.com在配置當中應該是www.baidu.com.（最后有一點），一般我們在瀏覽器里輸入時會省略后面的點，而這也已經成為了習慣。
根域服務器我們知道有13臺，但是這是錯誤的觀點。
根域服務器只是具有13個IP地址，但機器數量卻不是13臺，因為這些IP地址借助了任播的技術，所以我們可以在全球設立這些IP的鏡像站點，你訪問到的這個IP并不是唯一的那臺主機。
具體的鏡像分布可以參考維基百科。這些主機的內容都是一樣的
根域下來就是頂級域或者叫一級域，
有兩種劃分方式，一種互聯網剛興起時的按照行業性質劃分的com.，net.等，一種是按國家劃分的如cn.，jp.，等。
具體多少你可以自己去查，我們這里不關心。
每個域都會有域名服務器，也叫權威域名服務器。
Baidu.com就是一個頂級域名，而www.baidu.com卻不是頂級域名，他是在baidu.com 這個域里的一叫做www的主機。
一級域之后還有二級域，三級域，只要我買了一個頂級域，并且我搭建了自己BIND服務器（或者其他軟件搭建的）注冊到互聯網中，那么我就可以隨意在前面多加幾個域了（當然長度是有限制的）。
比如a.www.baidu.com，在這個網址中，www.baidu.com變成了一個二級域而不是一臺主機，主機名是a。
能提供域名解析的服務器，上面的記錄類型可以是A(address)記錄，NS記錄（name server），MX（mail），CNAME等。
（詳解參見博客：域名解析中A記錄、CNAME、MX記錄、NS記錄的區別和聯系）
A記錄是什么意思呢，就是記錄一個IP地址和一個主機名字，比如我這個域名服務器所在的域test.baidu.com，我們知道這是一個二級的域名，然后我在里面有一條A記錄,記錄了主機為a的IP，查到了就返回給你了。
如果我現在要想baidu.com這個域名服務器查詢a.test.baidu.com，那么這個頂級域名服務器就會發現你請求的這個網址在test.baidu.com這個域中，我這里記錄了這個二級域的域名服務器test.baidu.com的NS的IP。我返回給你這個地址你再去查主機為a的主機把。
這些域內的域名服務器都稱為權威服務器，直接提供DNS查詢服務。（這些服務器可不會做遞歸哦）
那么我們的DNS是怎么解析一個域名的呢？
1.現在我有一臺計算機，通過ISP接入了互聯網，那么ISP就會給我分配一個DNS服務器，這個DNS服務器不是權威服務器，而是相當于一個代理的dns解析服務器，他會幫你迭代權威服務器返回的應答，然后把最終查到IP返回給你。
2.現在的我計算機要向這臺ISPDNS發起請求查詢www.baidu.com這個域名了，(經網友提醒：這里其實準確來說不是ISPDNS，而應該是用戶自己電腦網絡設置里的DNS，并不一定是ISPDNS。比如也有可能你手工設置了8.8.8.8)
3.ISPDNS拿到請求后，先檢查一下自己的緩存中有沒有這個地址，有的話就直接返回。這個時候拿到的ip地址，會被標記為非權威服務器的應答。
4.如果緩存中沒有的話，ISPDNS會從配置文件里面讀取13個根域名服務器的地址（這些地址是不變的，直接在BIND的配置文件中），
5.然后像其中一臺發起請求。
6.根服務器拿到這個請求后，知道他是com.這個頂級域名下的，所以就會返回com域中的NS記錄，一般來說是13臺主機名和IP。
7.然后ISPDNS向其中一臺再次發起請求，com域的服務器發現你這請求是baidu.com這個域的，我一查發現了這個域的NS，那我就返回給你，你再去查。
（目前百度有4臺baidu.com的頂級域名服務器）。
8.ISPDNS不厭其煩的再次向baidu.com這個域的權威服務器發起請求，baidu.com收到之后，查了下有www的這臺主機，就把這個IP返回給你了，
9.然后ISPDNS拿到了之后，將其返回給了客戶端，并且把這個保存在高速緩存中。
下面我們來用 nslookup 這個工具詳細來說一下解析步驟：
從上圖我們可以看到:
????????? 第一行Server是：DNS服務器的主機名--210.32.32.1
????????? 第二行Address是： 它的IP地址--210.32.32.1#53
????????? 下面的Name是：解析的URL--??? www.jsjzx.com
????????? Address是：解析出來的IP--112.121.162.168
但是也有像百度這樣的DNS比較復雜的解析:
你會發現百度有一個cname = www.a.shifen.com? 的別名。
這是怎么一個過程呢？
我們用dig工具來跟蹤一下把（linux系統自帶有）
-----------------------------------------------------------------------------------------------------------------------------------------------
Dig工具會在本地計算機做迭代，然后記錄查詢的過程。
第一步是向我這臺機器的ISPDNS獲取到根域服務區的13個IP和主機名[b-j].root-servers.net.。
第二步是向其中的一臺根域服務器（Servername就是末行小括號里面的）發送www.baidu.com的查詢請求，他返回了com.頂級域的服務器IP（未顯示）和名稱，
第三步，便向com.域的一臺服務器192.33.4.12請求,www.baidu.com，他返回了baidu.com域的服務器IP（未顯示）和名稱，百度有四臺頂級域的服務器
???? 【此處可以用dig @192.33.4.12 www.baidu.com查看返回的百度頂級域名服務器IP地址】。
第四步呢，向百度的頂級域服務器（202.108.22.220）請求www.baidu.com，他發現這個www有個別名，而不是一臺主機，別名是www.a.shifen.com。
----------------------------------------------------------------------------------------------------------------------------------------------------
按照一般的邏輯，當dns請求到別名的時候，查詢會終止，而是重新發起查詢別名的請求，所以此處應該返回的是www.a.shifen.com而已。
但是為什么返回a.shifen.com的這個域的NS呢？
我們可以嘗試下面的這個命令：dig +trace? shifen.com 看看有什么結果。。。。。。。。
你會發現第三步時shifen.com這個頂級域的域名服務器和baidu.com這個域的域名服務器是同一臺主機（即：dns.baidu.com）！
當我拿到www.baidu.com的別名www.a.shifen.com的時候，我本來需要重新到com域查找shifen.com域的NS，但是因為這兩個域在同一臺NS上，所以直接向本機發起了，
shifen.com域發現請求的www.a.shifen.com是屬于a.shifen.com這個域的，
于是就把a.shifen.com的這個NS和IP返回，讓我到a.shifen.com這個域的域名服務器上查詢www.a.shifen.com。
于是我便從ns X .a.shifen.com中一臺拿到了一條A記錄，最終的最終也便是www.baidu.com的IP地址了.【此處也可以用dig +trace www.a.shifen.com】跟蹤一下
用一個圖來說明一下(圖中第三步的全世界只有13臺是錯誤的)
以下內容為在虛擬機中搭建local dns服務器得到的實驗數據，糾正上述結論
在上面的分析中，我們用dig工具進行了追蹤，但是dig沒有繼續追蹤當我們從baidu.com拿到cname和ns2.a.shifen.com的IP之后的事情。
我們就所以然的下結論認為local dns會向ns2.a.shifen.com請求www.a.shifenc.om。
其實這個想法是錯誤，在自己的本地搭建一個local dns，抓取整個解析過程中是所有包，看看就明白拉。
實際的結果是雖然dns.baidu.com返回了a.shifen.com域的服務器地址和IP，
但是local dns并不是直接向上述返回的IP請求www.a.shifen.com，而是再一次去請求com域，得到shifen.com域的服務器（也就是baidu.com的那四臺），
然后又請求www.a.shifen.com，返回a.shifen.com的域的服務器，最后才是去請求www.a.shifen.com，
雖然上面已經返回了IP，但是實驗的結果就是再走一遍shifen.com域的查詢。
上圖就是localdns在解析www.baidu.com的抓包全過程。藍色那條就是在收到cname和響應的a.shifen.com的域名服務器IP地址之后，繼續向com域請求shifen.com。
這個圖充分說明了返回cname的同時也返回了ns2.a.shifen.com的IP。
因此總結一下便是
???????? ①本機向local dns請求www.baidu.com
???????? ②local dns向根域請求www.baidu.com，根域返回com.域的服務器IP
???????? ③向com.域請求www.baidu.com，com.域返回baidu.com域的服務器IP
???????? ④向baidu.com請求www.baidu.com，返回cname www.a.shifen.com和a.shifen.com域的服務器IP
???????? ⑤向root域請求www.a.shifen.com
???????? ⑥向com.域請求www.a.shife.com
???????? ⑦向shifen.com請求
???????? ⑧向a.shifen.com域請求
???????? ⑨拿到www.a.shifen.com的IP
???????? ⑩localdns返回本機www.baidu.com cname www.a.shifen.com 以及 www.a.shifen.com的IP
From:http://www.cnblogs.com/cobbliu/archive/2013/03/24/2979521.html
在很多人看來，DNS只是為外部提供DNS解析服務（我以前也是這么認為的，直到膝蓋中了一箭），但作為互聯網的基礎設施，DNS遠沒有想象的那么簡單。如果你沒有聽說過DNS查詢、反向解析、zone傳輸、動態更新、DNS安全，那你可以從本文中得到關于他們的最簡明的詮釋。
DNS在53端口上監聽請求并提供響應的服務。出于性能的考慮，DNS查詢請求用UDP協議交互并且每個請求的大小小于512字節，但是如果返回的請求大小大于512字節，交互雙方會協商使用TCP協議。
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.comCNAME到 ljx.cobb.com，然后返回ljx.cobb.com的A記錄。
2），一個標示域或主機不存在的錯誤信息。需要注意的是這個錯誤信息也可能含有CNAME記錄。例如我要請求ftp.cobb.com，而我的域名服務器將ftp.cobb.comCNAME到了ljx.cobb.com，但是ljx.cobb.com這個主機不存在，這個時候就返回CNAME記錄和錯誤信息。
3），暫時性的錯誤信息。它主要是因為網絡不可達該主機，網絡不可達不一定表明該主機不存在。
域名服務器在返回一些下一次查詢的指引或者主機IP地址，域名解析器在收到指引后會再次向這些指引發起查詢請求，直到收到主機IP地址。迭代解析的過程如下圖所示：
一般情況下，遞歸查詢的時候會收到以下三種可能的返回結果：
???? 1），A記錄或者帶有CNAME鏈的A記錄。
???? 2），標示域或主機不存在的錯誤信息。
???? 3），暫時性錯誤。可能因為網絡不可達。
???? 4），可以給出下一步域名解析的域名服務器（包括它的IP地址）的列表。告訴解析器再去哪里進一步解析。
反向查詢是根據一個資源記錄查詢域名。這個資源記錄可能是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的正常數據流。如下圖所示：
上圖中的每個數據流都會受到響應的安全威脅：
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
DNS，就是Domain Name System的縮寫，翻譯過來就是域名系統，是互聯網上作為域名和IP地址相互映射的一個分布式數據庫。DNS能夠使用戶更方便的訪問互聯網，而不用去記住能夠被機器直接讀取的IP數串。通過域名，最終得到該域名對應的IP地址的過程叫做域名解析（或主機名解析）。
下面這張圖，詳細說明了一個DNS域名解析的全過程：
下面來詳細解釋DNS域名解析的過程：
網絡客戶端就是我們平常使用的電腦，打開瀏覽器，輸入一個域名。比如輸入www.163.com，這時，你使用的電腦會發出一個DNS請求到本地DNS服務器。本地DNS服務器一般都是你的網絡接入服務器商提供，比如中國電信，中國移動。
查詢www.163.com的DNS請求到達本地DNS服務器之后，本地DNS服務器會首先查詢它的緩存記錄，如果緩存中有此條記錄，就可以直接返回結果。如果沒有，本地DNS服務器還要向DNS根服務器進行查詢。
根DNS服務器沒有記錄具體的域名和IP地址的對應關系，而是告訴本地DNS服務器，你可以到域服務器上去繼續查詢，并給出域服務器的地址。
本地DNS服務器繼續向域服務器發出請求，在這個例子中，請求的對象是.com域服務器。.com域服務器收到請求之后，也不會直接返回域名和IP地址的對應關系，而是告訴本地DNS服務器，你的域名的解析服務器的地址。
最后，本地DNS服務器向域名的解析服務器發出請求，這時就能收到一個域名和IP地址對應關系，本地DNS服務器不僅要把IP地址返回給用戶電腦，還要把這個對應關系保存在緩存中，以備下次別的用戶查詢時，可以直接返回結果，加快網絡訪問。
關于DNS解析的TTL參數：
我們在配置DNS解析的時候，有一個參數常常容易忽略，就是DNS解析的TTL參數，Time To Live。TTL這個參數告訴本地DNS服務器，域名緩存的最長時間。用阿里云解析來舉例，阿里云解析默認的TTL是10分鐘，10分鐘的含義是，本地DNS服務器對于域名的緩存時間是10分鐘，10分鐘之后，本地DNS服務器就會刪除這條記錄，刪除之后，如果有用戶訪問這個域名，就要重復一遍上述復雜的流程。
其實，如果網站已經進入穩定發展的狀態，不會輕易更換IP地址，我們完全可以將TTL設置到協議最大值，即24小時。帶來的好處是，讓域名解析記錄能夠更長時間的存放在本地DNS服務器中，以加快所有用戶的訪問。設置成24小時，其實，還解決了Googlebot在全球部署的服務器抓取網站可能帶來的問題，這個問題麥新杰專門有一篇博文，請參考：“Googlebot無法訪問您的站點”問題理解和處理方法
阿里云之所以只將TTL設置成10分鐘，是為了讓域名解析更快生效而已。因為之前的解析會在最長10分鐘之后失效（本地DNS服務器將對應的解析條目刪除），然后新的解析生效。如果是24小時，這個生效的時間最長就是24小時，甚至更長（本地DNS服務器要有用戶請求，才會發起查詢）。
相關內容：https://study.163.com/course/courseMain.htm?courseId=1210406206&share=2&shareId=480000002227524
