在視圖之間共享的 BIND 動態區域的更新延遲

這是快速而骯髒的：在具有在視圖之間共享的動態區域的 BIND9 上，如果我從屬於我執行 nsupdate 的同一視圖的客戶端查詢該記錄，則執行 nsupdate、更新/創建/刪除記錄將正常工作從。

從與我使用 nsupdate 的視圖不同的視圖進行查詢將拋出 NXDOMAIN（如果添加新記錄）或在更改/更新時顯示舊記錄資訊，直到任意時間長度（例如 15分鐘）過去了，或者我強行過去了$ rndc freeze && rndc thaw。 $ rndc sync似乎根本沒有做任何事情來解決這個問題——我希望這只是一個日誌文件的事情，因為日誌刷新記錄在 15 分鐘左右刷新。

如果不清楚，這裡有一些虛擬碼可以幫助我們開始：

綁定視圖

view "cdn-redir" {
  match-clients { 10.1.1.0/24; 10.1.2.0/24; };
  include "cdn-zone.db";
  include "dynamic-zone.db";
};

view "default" {
  match-clients { any; };
  include "dynamic-zone.db";
};

範例命令行

user@ns:~$ nsupdate -k rndc.key
> server localhost
> zone example.com.
> update add foohost.example.com. 600 A 10.5.6.7
> send
> quit

user@ns:~$ dig foohost.example.com (resolv.conf points to 127.0.0.1)
 [ responds with correct answer 10.5.6.7 ]

在其他地方，主機落入與 nsupdate 相同的視圖

user@10.11.12.50:~$ foohost.example.com (resolv.conf points to above nameserver)
 [ responds with correct answer 10.5.6.7 ]

在其他地方，主機落入與 nsupdate不同的視圖

user@10.1.1.50:~$ dig foohost.example.com (resolv.conf points to above nameserver)
 [ responds with NXDOMAIN even though I'm asking the same server ]

此時，如果我有耐心，問題最終會自行解決（可能需要 15 分鐘），但我經常沒有耐心，所以我不得不$ rndc freeze && rndc thaw在名稱伺服器上強行解決問題。

另一方面

在完全相反的方面，如果我從屬於“cdn-redir”視圖的地址對伺服器執行 nsupdate，問題就會自行逆轉。來自匹配“cdn-redir”的客戶端的後續查詢在 nsupdate 之後立即獲得正確的記錄，而無需擺弄“rndc freeze/thaw”，但是從“cdn-redir”視圖之外的地址查詢現在有延遲/rndc 愚蠢。

我的終極問題

如果它像42那麼簡單，我會張開雙臂接受它……

我想避免不得不“rndc freeze && rndc thaw”，因為害怕錯過來自 DHCP 伺服器的動態更新。有誰知道如何更有效/更有效地在視圖之間同步更新記錄，或者可以闡明我可能出錯的地方？

編輯：BIND 9.9.5/Ubuntu 14.04 但它發生在 Ubuntu 和 BIND 的早期版本上。

謝謝大家！

根據Andrew B的要求，這裡是編輯（和部分）區域：

$ORIGIN .
$TTL 3600
example.com     IN SOA ns1.example.com. HOSTMASTER.example.com. (
                      2009025039 ; serial
                      900 ; refresh 15
                      600 ; retry 10
                      86400 ; expire 1 day
                      900 ; minimum 15 min
               )
               NS     ns1.example.com.
$ORIGIN example.com.
$TTL 30
AEGIS           A   10.2.1.60
               TXT "31bdb9b3dec929e051f778dda5abd0dfc7"
$TTL 86400
ts-router       A 10.1.1.1 
               A 10.1.2.1
               A 10.1.3.1
               A 10.1.4.1
               A 10.1.5.1
               A 10.1.6.1
               A 10.1.7.1
               A 10.1.8.1
               A 10.2.1.1
               A 10.2.2.1
               A 10.2.3.1
ts-server       A 10.2.1.20
ts-squid0       A 10.2.2.20
ts-squid1       A 10.2.2.21
$TTL 600
tssw4           A 10.2.3.4
tssw5           A 10.2.3.5
tssw6           A 10.2.3.6
tssw7           A 10.2.3.7
; wash rinse repeat for more hosts
$TTL 30
wintermute      A     10.2.1.61
               TXT   "003f141e5bcd3fc86954ac559e8a55700"

不同的視圖分別執行，它本質上比執行命名的單獨實例更方便。如果在不同的視圖中有同名的區域，這只是巧合，它們仍然是完全獨立的區域，與任何其他區域沒有更多的相關性。

讓多個單獨的區域使用相同的區域文件在 bind 自行更新區域內容的情況下不起作用（從屬區域、具有動態更新的區域等）。我不確定是否有損壞區域文件本身的風險。

您可以通過使一個視圖中的區域成為另一個視圖中具有相同名稱的區域的從屬來設置您想要執行的操作。這顯然是一個有點複雜的配置，但我相信它應該是可行的，但使用匹配客戶端的 TSIG 密鑰以及通知/傳輸。

編輯：ISC 已針對此場景發布了一篇知識庫文章，如何在多個視圖之間共享動態區域？，建議使用上述相同類型的配置。

這是他們的配置範例，格式有所改進：

key "external" {
   algorithm hmac-md5;
   secret "xxxxxxxx";
};

key "mykey" {
   algorithm hmac-md5;
   secret "yyyyyyyy";
};

view "internal" {
   match-clients { !key external; 10.0.1/24; };

   server 10.0.1.1 {
       /* Deliver notify messages to external view. */
       keys { external; };
   };

   zone "example.com" {
       type master;
       file "internal/example.db";
       allow-update { key mykey; };
       also-notify { 10.0.1.1; };
   };
};

view "external" {
   match-clients { key external; any; };

   zone "example.com" {
       type slave;
       file "external/example.db";
       masters { 10.0.1.1; };
       transfer-source { 10.0.1.1; };
       // allow-update-forwarding { any; };
       // allow-notify { ... };
   };
};

引用自：https://serverfault.com/questions/592492