本節書摘來自異步社群《dns與bind（第5版）》一書中的第10章，第10.4節,作者： 【美】joseph davies 更多章節内容可以通路雲栖社群“異步社群”公衆号檢視。
有了動态更新和notify功能，就可以随着網絡狀态的改變而更新區域資料，并且這些變動可以迅速傳送至區域的所有權威名稱伺服器。看起來很完美，不是嗎？
其實不盡然。在一個大型區域中，動态更新的頻率是非常驚人的。不難想象：存在這樣一個大型區域，其中包含上千個用戶端，可是某天管理者突然決定使用active directory和dhcp。現在每個用戶端都要更新自己在區域中的位址記錄，并且域控制器（domain controllers）也會更新一些記錄以便通知用戶端它們提供了哪些服務。（第17章會對active directory做進一步介紹。）
每當primary名稱伺服器接收一條更新并增加區域的序号時，便會向它的slave發送notify通告。每當接收到notify通告時，這些slave就會向其master伺服器查詢區域的序号，并且有可能進行區域資料傳輸。如果該區域很大，則傳輸會花些時間；在此期間，可能又接收到一條更新。slave可能永遠都在進行區域資料傳輸！另外，即便區域的變動可能非常小（例如，增加一條用戶端位址記錄），名稱伺服器卻仍要浪費許多時間來傳輸整個區域的資料。
增量區域傳輸（incremental zone transfer，ixfr）可以解決該問題。slave名稱伺服器可以告訴它們的master伺服器，自己目前所持有的區域資料是哪個版本，而隻要求發送該版本和目前版本之間有變動的部分即可。這樣就可以大幅降低區域資料傳輸的大小和時間。
增量區域傳輸請求所使用的查詢類型是ixfr而非axfr（這個查詢類型會啟動整個區域資料的傳輸），并且消息的authority字段包含slave目前的區域soa記錄。當master名稱伺服器接收到增量區域傳輸請求時，它會查找slave和master所持有的區域資料版本之間發生改變的記錄。如果該記錄丢失，則master會發送完整的區域資料。否則，它隻發送區域資料版本之間有差異的部分。
10.4.1 ixfr的局限性
聽起來不錯，不是嗎？但是ixfr也存在一些局限性。首先，ixfr不能很好地運作在bind 之前的版本上。不過所有bind 9名稱伺服器都支援ixfr并且運作得很好，同時還可以跟bind 8.2.3進行互動操作。
其次，ixfr适合工作在使用動态更新來修改區域資料的情況下，而不适用于手動更新。動态更新會記錄下對區域資料及序号所作的變更，而這正是master名稱伺服器要向請求ixfr的slave發送的資訊。但是重載整個區域資料檔案的名稱伺服器，必須找出該區域和上個區域之間的差别，例如，對這兩個版本執行diff。這意味着，如果想最大程度地發揮ixfr的作用，那麼隻能使用動态更新來修改區域資料，而絕不能手動編輯區域資料檔案。
10.4.2 從差異中确定ixfr
bind 開始支援通過比較區域資料檔案和其在記憶體中的版本差别，來确定ixfr應答。這意味着現在（又）可以手動編輯區域資料檔案了。然而必須采取預防措施，確定所編輯的區域資料檔案是最新版本，并且在編輯期間拒絕動态更新。（動态更新會改變記憶體中的區域資料，進而導緻區域資料檔案不能反映實際狀态。）
要開啟這項功能，可以在options或zone語句中使用ixfr-from-differences子語句。下面的配置會對所有區域開啟此項功能：
要強制名稱伺服器儲存新版本的區域資料檔案并且暫時停止該區域的動态更新，可以使用rndc的新指令freeze：
要通知名稱伺服器重載區域資料檔案并且恢複區域的動态更新，可以使用rndc的thaw指令：
https://yqfile.alicdn.com/15b6c6366e2a4035032073ef5723ffa54c4cbfc1.png" >
不應該長時間當機區域資料的更新，尤其是在可能漏掉重要的更新時。
**
10.4.3 ixfr相關檔案**
除了動态更新日志檔案，bind 8名稱伺服器還會維護ixfr日志，用以記錄對區域資料的改變。如同動态更新日志檔案，名稱伺服器每收到一條更新，就會更新ixfr日志檔案。和動态更新日志檔案不同的是，ixfr日志檔案永遠不會被删除，不過可以配置名稱伺服器對超出指定大小的日志檔案進行削減（trim）。bind 8的ixfr日志檔案名，預設由區域資料檔案名加上.ixfr組成。
bind 9名稱伺服器使用動态更新日志檔案（logfile或稱為journal file），來收集ixfr應答并維護區域資料的完整性。由于primary名稱伺服器根本不知道何時會用到這條區域變更記錄，是以該日志檔案不會被删除。bind 9的slave會儲存日志檔案，即便它接收到的是區域的axfr，因為它還可能是一個或多個slave的master名稱伺服器。
10.4.4 bind 8的ixfr配置
在bind 8中，配置ixfr相當簡單。首先，在master名稱伺服器上，需要使用名為maintain-ixfr-base的options子語句，以便讓其維護整個區域的ixfr日志檔案，甚至包括以該名稱伺服器為slave的區域，因為這些區域可能有slave需要ixfr服務：
其次，需要告知slaves去向它們的master名稱伺服器請求ixfr服務。方法是使用一條新的server子語句support-ixfr：
https://yqfile.alicdn.com/e50ba71de1a7fc2370bb94797c78aa630269f43f.png" >
這樣就完成了，除非想重命名master上的ixfr日志檔案。這要使用一條新的zone子語句ixfr-base：
https://yqfile.alicdn.com/375d79d4c3082494feea7493f403758283dab464.png" >
還可以在名稱伺服器上配置，當ixfr日志檔案超出指定大小時進行削減1：
一旦ixfr日志檔案超過指定值100kb，名稱伺服器就會将其削減到指定大小。這100kb的彈性空間用來避免當日志檔案達到極限值時，接下來的每條更新都會導緻其被削減回指定大小。
使用many-answers區域傳輸格式可以使區域資料的傳輸更有效率。有關many-answers區域傳輸本章稍後會加以說明。
10.4.5 bind 9的ixfr配置
在bind 9的master名稱伺服器中，配置ixfr甚至更簡單，因為不必做任何事情：該功能是預設開啟的。如果想針對特定的slave伺服器關閉該功能（應該不會想這麼做，因為slave必定會請求進行增量資料傳輸），可以使用server的子語句provide-ixfr，其預設值是yes：
還可以将provide-ixfr作為options的子語句，在此所做的配置會應用到所有的slave（隻要該slave沒有在自己的server語句中明确配置provide-ixfr子語句）。
因為bind 9的master名稱伺服器預設采用many-answers區域傳輸格式，是以不必專門配置transfer-format。
比較有用的是request-ixfr子語句，它可以被用在options或server語句中。如果混合使用了支援ixfr（ixfr-capable）和不支援ixfr（ixfr-impaired）的master，可以将slave的區域傳輸請求改為發送給支援ixfr的master：
從bind 開始，bind 9名稱伺服器支援使用options的子語句max-journal-size配置日志檔案（journal file）的最大尺寸。