BIND di atas VPN: forward bersyarat atau zona stub?

Tiga cara menyelesaikan satu zona privat melalui VPN, dan kapan masing-masing cocok: forward, stub, atau secondary, plus pemeriksaan alamat sumber yang menentukan.

Resolver kantor Anda menjawab semuanya kecuali satu ruang nama korporat, dan server DNS korporat yang mengetahuinya berada di balik VPN. BIND dapat menyerahkan satu zona itu ke upstream dengan tiga cara berbeda, dan masing-masing gagal dengan cara berbeda. Forward bersyarat adalah komitmen terkecil, zona stub menyimpan data delegasi, dan secondary menyimpan salinan lengkap. Pilih berdasarkan apa yang akan diizinkan upstream dan apa yang Anda ingin resolver pegang, bukan berdasarkan cuplikan mana yang Anda temukan lebih dulu.

Tiga susunan untuk satu ruang nama

TypeWhat your resolver keepsUpstream mustFails when
forwarda forwarder listanswer queries from your source addressupstream is down and forward only is set
stubthe zone's NS records and addressesanswer NS queries for the zonedelegation data goes stale after an NS change
secondarya full copy of the zonepermit AXFR or IXFR from your sourcetransfer is blocked by ACL or firewall

Forward bersyarat: komitmen terkecil

Misalkan resolver kantor di 192.168.10.53 dan server korporat di 10.40.0.53 yang dapat dijangkau melalui terowongan yang disetujui. Deklarasinya tiga baris, dan yang menarik adalah forward only, karena mengubah perilaku kegagalan, bukan jalurnya.

zone "corp.example" {
    type forward;
    forward only;
    forwarders { 10.40.0.53; };
};

Dengan forward only, upstream yang tidak terjangkau menghasilkan SERVFAIL untuk zona ini alih-alih kembali ke resolusi iteratif. Biasanya itulah yang Anda inginkan untuk ruang nama privat, karena fallback akan mengirim nama privat ke resolver publik dan mengembalikan jawaban yang tidak berguna dari internet. Referensi BIND mendokumentasikan kedua kebijakan, dan perbedaannya lebih penting daripada yang disiratkan cuplikan. Gabungkan zona ke konfigurasi yang ada alih-alih mengganti zona yang sudah ada untuk nama yang sama.

Stub atau secondary: saat delegasi penting

Zona stub meminta server korporat untuk catatan NS zona lalu menanyakan server otoritatif secara langsung. Pilih ini ketika wilayah upstream besar atau terbagi dan Anda ingin resolver mengikuti delegasi alih-alih memakukan semuanya ke satu alamat. Biayanya adalah ketergantungan pada data NS yang mutakhir, dan pada setiap server nama yang terdaftar dapat dijangkau dari alamat sumber resolver Anda.

zone "corp.example" {
    type stub;
    masters { 10.40.0.53; };
};

zone "corp.example" {
    type secondary;
    primaries { 10.40.0.53; };
    file "corp.example.db";
};

Secondary menjawab dari data lokal dan bertahan saat upstream mati, dan itulah alasan menerima ketergantungan transfer. Ini juga berarti resolver Anda kini menyimpan salinan zona yang bukan miliknya, jadi jalur berkas, ACL transfer pada primer, dan timer penyegaran semuanya menjadi bagian dari permukaan operasional Anda.

Pemeriksaan yang menentukan di antara keduanya

BIND membuat kueri keluarnya sendiri, jadi pertanyaannya bukan apakah laptop dapat menjangkau 10.40.0.53, melainkan apakah host resolver dapat, dari alamat sumber yang akan dilihat server korporat. Tanyakan ke kernel, lalu ke server, dalam urutan itu.

ip route get 10.40.0.53
named-checkconf
rndc reload corp.example
dig @10.40.0.53 corp.example NS +norecurse
dig @192.168.10.53 portal.corp.example

Izinkan UDP dan TCP di jalur: jawaban terpotong memaksa TCP, dan kebijakan yang hanya mengizinkan UDP menghasilkan kegagalan berkala yang tampak seperti kehilangan paket. Sisi korporat memerlukan aturan terima untuk sumber resolver Anda dan rute balik ke sana; sumber itu bisa berupa alamat terutek resolver atau alamat yang diterjemahkan secara eksplisit, dan jarang berupa alamat kumpulan klien. Jika kueri NS gagal, zona stub tidak dapat bekerja, apa pun perilaku zona forward.

Verifikasi jawabannya, bukan terowongannya

Kueri melalui resolver kantor untuk nama yang belum pernah Anda minta, dan periksa bagian authority jawaban untuk melihat apakah berasal dari zona korporat. Jawaban dalam cache tidak membuktikan apa pun tentang jalur saat ini, dan kueri langsung yang berhasil ke upstream tidak membuktikan resolver Anda memilih zona itu. Ulangi kueri yang sama melalui TCP untuk memastikan jalur bertahan saat pemotongan.

Arahkan klien ke resolver kantor, dan biarkan validasi DNSSEC tetap aktif. Peramban yang dikonfigurasi dengan resolver terenkripsi independen melewati susunan ini sepenuhnya, dan mematikan validasi agar jawaban tak terduga tampak benar menukar kegagalan yang terlihat dengan yang tak terlihat.

Catat jenis mana dari ketiganya yang Anda pilih dan mengapa. Orang berikutnya yang melihat zona gagal akan membutuhkan kalimat itu lebih dari berkas konfigurasi.

Artikel terkait