Dua situs, satu zona DNS privat: siapa yang memiliki catatannya?

Anda menambahkan host di situs hijau, host itu ter-resolve untuk pengguna hijau, dan kantor kuning tetap menerima NXDOMAIN. Ini bukan kegagalan VPN dan bukan resolver rusak; ini celah kepemilikan di dalam zona privat. Dua daftar catatan yang diedit secara terpisah tidak menjadi satu zona hanya karena situs-situsnya dapat saling menjangkau. Solusinya adalah rencana penerbitan, bukan aturan firewall lain.

Gejalanya menyebut pemilik yang hilang

Setiap situs mungkin punya penimpaan lokal, entri Pi-hole, atau baris dnsmasq yang ditambahkan seseorang saat sebuah nama dibutuhkan. Catatan hijau hanya ada di resolver hijau, jadi klien di situs kuning bertanya ke resolver-nya sendiri dan menerima "tidak ada nama seperti itu" yang jujur. Jawaban basi terlihat berbeda: host berpindah, satu situs memperbarui salinannya, dan yang lain masih mengembalikan alamat lama.

Tidak ada pola yang teratasi lama oleh pengosongan cache. Cache resolver penerus adalah salinan jawaban yang pernah diterimanya, bukan otoritas yang menerbitkan nama baru, jadi cache yang bekerja hari ini tidak memberi tahu apa pun tentang host besok. Dokumentasi BIND menjelaskan peran primer, sekunder, rekursif, dan penerusan secara terpisah justru karena alasan ini.

Jadi pertanyaan desainnya sempit dan dapat dijawab: siapa yang boleh membuat catatan, dan bagaimana catatan itu mencapai setiap resolver yang harus menjawabnya?

Opsi A: satu zona otoritatif dengan sekunder

Jalankan primer untuk internal.example.com dan biarkan sekunder yang didukung memperoleh zona di setiap situs. Resolver rekursif tiap situs menanyakan sekunder lokalnya, jadi jawaban datang dari sumber otoritatif, bukan cache, dan perubahan yang dilakukan sekali ditransfer alih-alih diketik ulang.

Susunan itu memerlukan keputusan eksplisit yang mudah ditunda dan mahal untuk dilewati. Siapa yang boleh mengedit zona? Server mana yang boleh mentransfernya, dan melalui alamat mana? Apa yang harus dilihat klien saat terowongan antar situs mati? Sekunder terus menjawab dari salinan terakhirnya, yang biasanya merupakan perilaku yang Anda inginkan, tetapi itu harus menjadi pilihan yang dinyatakan, bukan kejutan saat gangguan.

Batasi transfer zona ke sekunder yang dikenal berdasarkan alamat dan gunakan tanda tangan transaksi di tempat implementasi mendukungnya. Transfer terbuka adalah salinan ruang nama internal Anda bagi siapa pun yang dapat mencapai port.

Biayanya adalah koordinasi: satu jalur penyuntingan, satu tinjauan perubahan, dan pemahaman bersama tentang siapa yang berjaga saat catatan salah.

Opsi B: subdomain per situs

Delegasikan green.internal.example.com ke situs hijau dan yellow.internal.example.com ke situs kuning. Setiap situs menjadi otoritatif untuk namanya sendiri, dan zona induk hanya membawa catatan delegasi. Perselisihan atas satu berkas hilang, dan tim lokal dapat menambahkan host tanpa menunggu perubahan pusat.

Delegasi harus ada di zona induk, dengan catatan NS yang menunjuk ke server otoritatif situs. Penerusan bersyarat untuk subdomain adalah alternatif yang sah ketika delegasi penuh tidak praktis, tetapi itu pengaturan resolver, bukan fakta yang diterbitkan, jadi setiap resolver memerlukan aturan yang sama.

Biayanya berpindah alih-alih hilang: zona induk tetap memerlukan pemilik, dan membuat situs baru kini menjadi perubahan di dua tempat, bukan satu.

Buat setiap resolver mengikuti pilihan

Berikan resolver yang disetujui dan domain pencarian kepada klien melalui konfigurasi yang didukung, dan pastikan bahwa resolver memiliki rute VPN yang diizinkan ke setiap server DNS jarak jauh yang harus ditanyakannya. Aplikasi juga memerlukan rute ke alamat privat yang dikembalikan jawaban itu, karena nama yang benar tanpa jalur tetap koneksi yang rusak.

Jika Pi-hole menyediakan resolusi lokal, catat catatan mana yang dimilikinya dan kueri mana yang diteruskannya. Dua daftar Pi-hole yang diedit secara terpisah tetap tidak mereplikasi. Di Pi-hole v6, baris dnsmasq khusus diatur melalui opsi sisi host seperti TOML, CLI, atau variabel lingkungan dan tidak diekspos melalui API; memuat berkas /etc/dnsmasq.d/ adalah opsi terpisah yang mati secara default.

Kemudian uji dari kedua sisi dengan nama yang seharusnya terlihat 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

Jawaban SOA memberi tahu Anda apakah resolver kuning menganggap dirinya otoritatif, sedang menanyakan sekunder, atau hanya meneruskan. Itu desain berbeda dengan mode kegagalan berbeda, dan jawabannya biasanya mengidentifikasi mana yang benar-benar Anda terapkan.

Akhiri dengan tiga kasus penerimaan: satu nama dari setiap situs, satu catatan yang diubah dalam satu jam, dan tautan antar situs tidak tersedia. Desain yang hanya lolos yang pertama memiliki rencana penerbitan di atas kertas dan penimpaan lokal di produksi.