Pembaruan ke zona dinamis BIND yang dibagi antara tampilan yang tertunda

Inilah yang cepat dan kotor: Pada BIND9 dengan zona dinamis yang dibagi antara tampilan , melakukan nsupdate, memperbarui / membuat / menghapus catatan akan berfungsi dengan baik jika saya meminta catatan itu dari klien yang masuk ke tampilan yang sama dengan yang saya lakukan pada nsupdate dari.

Meminta dari tampilan yang tidak sama dengan yang saya gunakan untuk nsupdate akan melempar NXDOMAIN (jika menambahkan catatan baru) atau akan menampilkan informasi catatan lama jika terjadi perubahan / pembaruan hingga jangka waktu yang sewenang-wenang (misalnya 15 menit) berlalu, atau saya lakukan secara paksa $ rndc freeze && rndc thaw. $ rndc synctampaknya tidak melakukan apa-apa untuk menyelesaikan masalah - saya berharap itu hanya file jurnal karena flush jurnal didokumentasikan untuk flush sekitar 15 menit.

Jika itu tidak jelas, inilah beberapa kode semu untuk memulai:

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

Contoh baris perintah

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 ]

Di tempat lain, sebuah host jatuh ke tampilan yang sama dengan nsupdate

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

Di tempat lain, host jatuh ke tampilan yang berbeda sebagai 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 ]

Pada titik ini, jika saya sabar, masalahnya pada akhirnya akan teratasi dengan sendirinya (mungkin 15 menit), tetapi saya sering tidak memiliki kemewahan kesabaran, jadi saya terpaksa $ rndc freeze && rndc thawmenggunakan server nama untuk memperbaiki masalah secara paksa.

Di sisi lain

Di sisi hal-hal yang terbalik sempurna, jika saya melakukan nsupdate terhadap server dari alamat yang jatuh ke tampilan "cdn-redir", masalahnya terbalik dengan sendirinya. Pertanyaan selanjutnya dari klien yang cocok dengan "cdn-redir" mendapatkan catatan yang benar segera setelah nsupdate tanpa mengutak-atik "rndc freeze / thaw", tetapi permintaan dari alamat yang berada di luar tampilan "cdn-redir" sekarang memiliki penundaan / kekonyolan rndc.

Pertanyaan pamungkas saya

Jika sesederhana 42, saya akan menerimanya dengan tangan terbuka ...

Saya ingin menghindari "rndc freeze && rndc thaw" karena takut tidak ada pembaruan dinamis dari server DHCP. Adakah yang tahu cara membuat catatan yang diperbarui disinkronkan antara tampilan dengan lebih efektif / efisien, atau dapat menjelaskan di mana saya mungkin salah?

Sunting: BIND 9.9.5 / Ubuntu 14.04 tetapi itu terjadi pada versi Ubuntu dan BIND sebelumnya.

Terima kasih semuanya!

Seperti yang diminta oleh Andrew B , inilah zona redacted (dan sebagian):

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

Pandangan berbeda bertindak secara terpisah, itu pada dasarnya kenyamanan saat menjalankan contoh nama yang terpisah. Jika ada zona dengan nama yang sama dalam tampilan yang berbeda, ini hanya kebetulan, mereka masih merupakan zona yang sepenuhnya terpisah, tidak lebih terkait daripada zona lainnya.

Memiliki beberapa zona terpisah menggunakan file zona yang sama tidak berfungsi dalam situasi di mana bind memperbarui konten zona sendiri (zona slave, zona dengan pembaruan dinamis, dll). Saya tidak yakin apakah ada risiko merusak file zona itu sendiri.

Anda mungkin dapat mengatur sesuatu seperti apa yang ingin Anda lakukan dengan membuat zona di satu tampilan menjadi budak untuk zona dengan nama yang sama di tampilan lain. Ini jelas akan menjadi konfigurasi yang agak rumit tetapi menggunakan kunci TSIG untuk pertandingan-klien serta pemberitahuan / transfer saya percaya itu harus bisa dilakukan.

Sunting: ISC telah menerbitkan artikel KB untuk skenario ini, Bagaimana cara saya berbagi zona dinamis antara banyak tampilan? , menyarankan jenis konfigurasi yang sama yang disebutkan di atas.

Ini adalah contoh konfigurasi mereka dengan pemformatan yang agak ditingkatkan:

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

Memiliki masalah serupa dengan tampilan, saya memutuskan untuk menyingkirkannya dan memindahkan otorisasi ke zona.

Anda dapat mengganti tampilan dalam pertanyaan dengan memasukkan kedua file zona dengan mudah, biarkan zona yang saat ini dibagikan tidak tersentuh dan tambahkan izin-bolehkan {} ke definisi "dynamic-zone.db" seperti:

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

dengan ini Anda mencapai tujuan yang Anda duga untuk membuat dynamic.zone dapat diakses hanya dari jaringan yang ditentukan dan memiliki zona lain untuk publik.