Tangkapan Split-DNS: sebutkan di mana setiap pengamatan diambil

Dua orang menelusuri masalah Split-DNS yang sama dan mendapatkan alamat resolver yang berbeda. Satu memakai alat pencarian, satu menangkap paket di adaptor, dan yang ketiga membaca diagnostik klien itu sendiri. Tidak ada yang berbohong, dan tidak ada yang menggambarkan tahap yang sama. Menamai titik pengamatan mengubah pertentangan menjadi peta.

Satu pencarian, beberapa titik pengamatan

Untuk satu nama internal, ada setidaknya lima tempat untuk dilihat: aplikasi dan API resolver yang dipanggilnya, kebijakan domain yang berlaku di klien, tangkapan di adaptor atau filter, batas gateway yang terkendali, dan resolver yang benar-benar menerima kueri.

Masing-masing menjawab pertanyaan berbeda, dan tidak satu pun sendiri membuktikan ke mana kueri pergi.

Tangkapan di adaptor menunjukkan paket, bukan niat. Itu tidak memberi tahu resolver mana yang dipilih klien, dan tangkapan kosong bisa berarti jawaban tersimpan di cache atau API resolver lain, bukan paket yang dibuang. Perlakukan setiap pengamatan sebagai bukti tentang satu tahap. Lalu susun tahap-tahap itu menjadi jalur.

Filter klien berada di antara aplikasi dan kabel

Klien VPN dengan Split-DNS menerapkan pencocokan domain sebelum paket meninggalkan mesin. Nama dalam sufiks terowongan pergi ke resolver internal; sisanya pergi ke resolver lokal. Filter adalah kebijakan, dan kebijakan bisa berbeda menurut platform dan versi klien.

Panduan Split-DNS Secure Client dari Cisco mencakup pencocokan domain dan filter Windows, dan memisahkan apa yang dilihat aplikasi saat memakai API resolver asli dari apa yang dilihat alat seperti nslookup. Perbedaan itulah intinya.

Mulai dari profil yang berlaku dan satu pencarian aplikasi biasa. Setiap uji yang menyebut server eksplisit adalah pengelakan yang disengaja; jelaskan dengan diagnostik klien itu sendiri, dan jangan biarkan itu menjadi kriteria penerimaan.

nslookup menempuh jalur berbeda dari aplikasi

nslookup membangun kueri DNS-nya sendiri dan dapat melewati kebijakan resolver sistem operasi. Itu membuatnya berguna untuk menanyakan pertanyaan tertentu ke server tertentu, dan menyesatkan untuk menguji apa yang akan dialami aplikasi.

Di Windows, tabel kebijakan resolusi nama menentukan sufiks mana memakai server mana. Membacanya menunjukkan kebijakan yang akan diikuti aplikasi, dan itulah bagian yang sering hilang.

Baca kebijakan itu lalu ajukan pertanyaan yang sama melalui resolver normal:

Get-DnsClientNrptPolicy
Resolve-DnsName intranet.hq.example

Resolver terenkripsi menyembunyikan kueri, bukan koneksinya

Peramban dengan resolver DNS-over-HTTPS sendiri adalah kasus yang sama sekali lain. Kueri keluar di dalam TLS, sehingga tangkapan paket menunjukkan koneksi ke alamat resolver tetapi bukan nama yang ditanyakan.

Cari tahu dulu kebijakan terkelola peramban, lalu bandingkan dengan pencarian sistem operasi. Peramban yang diizinkan memilih resolver sendiri mungkin tidak pernah melihat kebijakan Split-DNS sama sekali.

Kehati-hatian yang sama berlaku untuk setiap klien yang membawa resolver sendiri. Tangkapan yang mengenali koneksi jarak jauh bukan bukti tentang nama kueri. Jika Anda perlu namanya, ambil dari log resolver itu sendiri atau dari diagnostik aplikasi, dengan aturan privasi yang berlaku.

Bandingkan dengan uji berlabel

Pilih nama internal yang disetujui untuk pengujian, ditambah nama publik yang tidak membawa makna sensitif. Untuk masing-masing, catat waktu, tipe rekaman, jawaban, dan kebijakan yang Anda harapkan.

Di tempat yang diizinkan, bandingkan penerimaan resolver dengan satu pengamatan sempit dari klien atau gateway:

nslookup intranet.hq.example 10.55.0.53
Get-DnsClientNrptPolicy | Format-List

Jangan pernah mengirim nama pribadi ke resolver publik yang tidak terkait hanya untuk membuat perbandingan, dan sunting semua yang Anda bagikan. Terakhir, pisahkan jawaban DNS yang benar dari koneksi layanan yang menyusul: alamat pribadi yang sudah diresolusi masih membutuhkan rute dan otorisasi aplikasi.