Dua tapak, satu zon DNS persendirian: siapa memiliki rekodnya?

Anda menambah hos di tapak hijau, ia diselesaikan untuk pengguna hijau, dan pejabat kuning masih menerima NXDOMAIN. Ini bukan kegagalan VPN dan bukan penyelesai rosak; ini jurang pemilikan dalam zon persendirian. Dua senarai rekod yang disunting secara berasingan tidak menjadi satu zon hanya kerana tapak-tapak boleh mencapai satu sama lain. Penyelesaiannya ialah pelan penerbitan, bukan peraturan tembok api yang lain.

Gejala menamakan pemilik yang hilang

Setiap tapak mungkin mempunyai pengatasan tempatan, entri Pi-hole atau baris dnsmasq yang ditambah seseorang apabila nama diperlukan. Rekod hijau hanya wujud pada penyelesai hijau, jadi klien di kuning bertanya penyelesainya sendiri dan menerima "tiada nama sedemikian" yang benar. Jawapan basi kelihatan berbeza: hos berpindah, satu tapak mengemas kini salinannya, dan yang lain masih memulangkan alamat lama.

Tiada corak yang diperbaiki lama dengan mengosongkan cache. Cache penyelesai penghantar ialah salinan jawapan yang pernah diterimanya, bukan kuasa yang menerbitkan nama baharu, jadi cache yang berfungsi hari ini tidak memberitahu apa-apa tentang hos esok. Dokumentasi BIND menerangkan peranan primer, sekunder, rekursif dan penghantar secara berasingan tepat kerana sebab ini.

Jadi persoalan reka bentuk itu sempit dan boleh dijawab: siapa boleh mencipta rekod, dan bagaimana rekod itu sampai ke setiap penyelesai yang mesti menjawabnya?

Pilihan A: satu zon berwibawa dengan sekunder

Jalankan primer untuk internal.example.com dan biarkan sekunder yang disokong memperoleh zon di setiap tapak. Penyelesai rekursif setiap tapak bertanya sekunder tempatannya, jadi jawapan datang dari sumber berwibawa dan bukan cache, dan perubahan yang dibuat sekali dipindahkan dan bukannya ditaip semula.

Susunan itu memerlukan keputusan jelas yang mudah ditangguhkan dan mahal untuk dilangkau. Siapa boleh menyunting zon? Pelayan mana yang dibenarkan memindahkannya, dan melalui alamat mana? Apa yang patut dilihat klien semasa terowong antara tapak terputus? Sekunder terus menjawab daripada salinan terakhirnya, yang biasanya merupakan tingkah laku yang anda mahu, tetapi ia mesti menjadi pilihan yang diisytiharkan dan bukan kejutan semasa gangguan.

Hadkan pemindahan zon kepada sekunder yang diketahui mengikut alamat dan gunakan tandatangan transaksi di tempat pelaksanaan menyokongnya. Pemindahan terbuka ialah salinan ruang nama dalaman anda untuk sesiapa yang boleh mencapai port itu.

Kosnya ialah penyelarasan: satu laluan suntingan, satu semakan perubahan, dan persefahaman bersama tentang siapa yang bertugas apabila rekod salah.

Pilihan B: subdomain bagi setiap tapak

Wakilkan green.internal.example.com kepada tapak hijau dan yellow.internal.example.com kepada tapak kuning. Setiap tapak menjadi berwibawa bagi namanya sendiri, dan zon induk hanya membawa rekod pewakilan. Pertikaian atas satu fail hilang, dan pasukan tempatan boleh menambah hos tanpa menunggu perubahan pusat.

Pewakilan mesti wujud dalam zon induk, dengan rekod NS yang menunjuk ke pelayan berwibawa tapak. Penghantaran bersyarat untuk subdomain ialah alternatif sah apabila pewakilan penuh tidak praktikal, tetapi itu tetapan penyelesai dan bukan fakta yang diterbitkan, jadi setiap penyelesai memerlukan peraturan yang sama.

Kosnya berpindah dan bukan hilang: zon induk masih memerlukan pemilik, dan mencipta tapak baharu kini perubahan di dua tempat dan bukan satu.

Jadikan setiap penyelesai mengikut pilihan

Berikan penyelesai yang diluluskan dan domain carian kepada klien melalui konfigurasi yang disokong, dan pastikan penyelesai mempunyai laluan VPN yang dibenarkan ke mana-mana pelayan DNS jauh yang mesti ditanyainya. Aplikasi juga memerlukan laluan ke alamat persendirian yang dipulangkan oleh jawapan itu, kerana nama yang betul tanpa laluan masih sambungan yang terputus.

Jika Pi-hole menyediakan penyelesaian tempatan, catat rekod mana yang dimilikinya dan pertanyaan mana yang dihantarnya. Dua senarai Pi-hole yang disunting secara berasingan masih tidak mereplikasi. Dalam Pi-hole v6, baris dnsmasq tersuai ditetapkan melalui pilihan sebelah hos seperti TOML, CLI atau pemboleh ubah persekitaran dan tidak didedahkan melalui API; memuatkan fail /etc/dnsmasq.d/ ialah pilihan berasingan yang dimatikan secara lalai.

Kemudian uji dari kedua-dua belah dengan nama yang sepatutnya kelihatan di mana-mana:

$ dig +short newhost.green.internal.example.com @10.20.0.53
10.20.0.41
$ dig +short newhost.green.internal.example.com @10.30.0.53
10.20.0.41
$ dig SOA internal.example.com @10.30.0.53

Jawapan SOA memberitahu anda sama ada penyelesai kuning menganggap dirinya berwibawa, sedang bertanya sekunder, atau hanya menghantar. Itu reka bentuk berbeza dengan cara kegagalan berbeza, dan jawapannya biasanya mengenal pasti yang mana sebenarnya anda gunakan.

Akhiri dengan tiga kes penerimaan: satu nama dari setiap tapak, satu rekod diubah dalam masa sejam, dan pautan antara tapak tidak tersedia. Reka bentuk yang hanya lulus yang pertama mempunyai pelan penerbitan di atas kertas dan pengatasan tempatan dalam pengeluaran.