Cập nhật vùng động BIND được chia sẻ giữa các lượt xem bị trì hoãn

Đây là một cách nhanh chóng và bẩn thỉu: Trên BIND9 với một vùng động được chia sẻ giữa các lượt xem , thực hiện nsupdate, cập nhật / tạo / xóa một bản ghi sẽ hoạt động tốt nếu tôi truy vấn bản ghi đó từ một máy khách rơi vào cùng một chế độ xem tôi đã thực hiện nsupdate từ.

Truy vấn từ chế độ xem không giống với chế độ tôi đã sử dụng cho nsupdate sẽ ném NXDOMAIN (nếu thêm bản ghi mới) hoặc sẽ hiển thị thông tin bản ghi cũ trong trường hợp thay đổi / cập nhật cho đến một khoảng thời gian tùy ý (giả sử 15 phút) trôi qua, hoặc tôi buộc phải làm $ rndc freeze && rndc thaw. $ rndc syncDường như không làm bất cứ điều gì để giải quyết vấn đề - Tôi đã hy vọng nó chỉ là một tập tin tạp chí vì các tạp chí được ghi nhận để xả khoảng 15 phút.

Nếu điều đó không rõ ràng, đây là một số mã giả để giúp chúng tôi bắt đầu:

Lượt xem BIND

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";
};

Ví dụ dòng lệnh

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 ]

Ở những nơi khác, một máy chủ rơi vào cùng một góc nhìn với nsupdate

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

Ở những nơi khác, máy chủ rơi vào một cái nhìn khác với tư cách là 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 ]

Tại thời điểm này, nếu tôi kiên nhẫn, vấn đề cuối cùng sẽ tự giải quyết (có thể là 15 phút), nhưng tôi thường không có sự kiên nhẫn, vì vậy tôi buộc phải $ rndc freeze && rndc thawvào máy chủ tên để khắc phục sự cố.

Mặt trái

Về mặt hoàn toàn đảo ngược của mọi thứ, nếu tôi thực hiện nsupdate với máy chủ từ một địa chỉ rơi vào chế độ xem "cdn-redir", vấn đề sẽ tự đảo ngược. Các truy vấn tiếp theo từ các máy khách khớp với "cdn-redir" có được bản ghi chính xác ngay sau nsupdate mà không xử lý "rndc freeze / thaw", nhưng truy vấn từ các địa chỉ nằm ngoài chế độ xem "cdn-redir" hiện có độ trễ / rndc.

Câu hỏi cuối cùng của tôi

Nếu nó đơn giản như 42, tôi sẽ mở nó ra ...

Tôi muốn tránh phải "rndc đóng băng && rndc tan băng" vì sợ bỏ lỡ bản cập nhật động từ máy chủ DHCP. Có ai biết làm thế nào để các bản ghi được cập nhật được đồng bộ hóa giữa các chế độ xem hiệu quả / hiệu quả hơn hoặc có thể làm sáng tỏ nơi tôi có thể sai?

Chỉnh sửa: BIND 9.9.5 / Ubuntu 14.04 nhưng nó đã xảy ra trên các phiên bản trước của cả Ubuntu và BIND.

Cảm ơn tất cả!

Theo yêu cầu của Andrew B , đây là khu vực được tái cấu trúc (và một phần):

$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"

Các khung nhìn khác nhau hoạt động riêng biệt, về cơ bản, nó thuận tiện hơn so với việc chạy các trường hợp được đặt tên riêng. Nếu có các khu vực có cùng tên trong các chế độ xem khác nhau thì đây chỉ là sự trùng hợp ngẫu nhiên, chúng vẫn là các khu vực hoàn toàn riêng biệt, không liên quan nhiều hơn bất kỳ khu vực nào khác.

Việc có nhiều vùng riêng biệt sử dụng cùng một tệp vùng sẽ không hoạt động trong trường hợp liên kết tự cập nhật nội dung vùng (vùng nô lệ, vùng có cập nhật động, v.v.). Tôi không chắc liệu thậm chí có nguy cơ làm hỏng tập tin vùng hay không.

Bạn có thể thiết lập một cái gì đó giống như những gì bạn muốn làm bằng cách đặt vùng trong một chế độ làm nô lệ cho vùng có cùng tên trong chế độ xem khác. Đây rõ ràng sẽ là một cấu hình hơi phức tạp nhưng sử dụng các khóa TSIG cho ứng dụng khách phù hợp cũng như thông báo / chuyển giao tôi tin rằng nó có thể thực hiện được.

Chỉnh sửa: ISC đã xuất bản một bài viết KB cho kịch bản này, Làm cách nào để chia sẻ vùng động giữa nhiều chế độ xem? , đề xuất cùng loại cấu hình được đề cập ở trên.

Đây là ví dụ cấu hình của họ với định dạng được cải thiện phần nào:

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 { ... };
    };
};

Gặp vấn đề tương tự với quan điểm, tôi quyết định loại bỏ chúng và chuyển ủy quyền vào các khu vực thay thế.

Bạn có thể thay thế các chế độ xem trong các câu hỏi bằng cách đơn giản bao gồm cả hai tệp vùng, hãy để (các) vùng được chia sẻ hiện tại không bị ảnh hưởng và thêm truy vấn cho phép {} vào định nghĩa "Dynamic-zone.db" như:

    zone "dynamic.zone" {
            allow-query { 10.1.1.0/24; 10.1.2.0/24; };
            type master;
            file "/etc/bind/zones/master/dynamic.zone";
            update-policy { .... };
    };

bằng cách này, bạn đạt được mục tiêu giả định của mình để làm cho Dynamic.zone chỉ có thể truy cập được từ các mạng được chỉ định và để các khu vực khác được công khai.