VPN Anda mendorong tiga server DNS: mana yang menjawab?

Buka halaman pengaturan setelah terhubung dan tiga alamat DNS terdaftar; pertanyaan auditnya adalah mana yang menangani kueri terakhir Anda. Jumlahnya saja tidak menjawab apa pun, karena dorongan klien, antarmuka fisik, dan kebijakan per domain semuanya menulis ke tampilan yang sama. Entri-entri itu membawa cakupan berbeda, dan cakupan, bukan posisi, yang menentukan siapa menjawab. Mulailah dengan memisahkan sumbernya, lalu uji sumber yang memiliki nama yang Anda pedulikan.

Mengapa daftarnya lebih panjang dari profil Anda

Klien VPN mendorong alamat resolver untuk tautan terowongan, dan sistem operasi menyimpannya di samping apa pun yang sudah dimiliki antarmuka fisik. Router, sewa DHCP korporat, VPN kedua, dan kebijakan per domain masing-masing menyumbang entrinya sendiri. Tiga alamat di halaman bisa berarti tiga cakupan, bukan tiga kandidat untuk satu tugas. Membaca jumlahnya sebagai bukti kebocoran adalah kesalahan pertama dalam audit ini.

Di dalam satu antarmuka, klien memang mencoba servernya secara berurutan, jadi daftar terurut bukan tanpa makna. Yang bukan antrean adalah tampilan gabungan, tempat entri dari profil, tautan fisik, dan aturan per domain duduk berdampingan tanpa satu peringkat. Perbedaan itulah yang menentukan apa yang Anda uji: urutan menjelaskan perilaku di dalam satu cakupan, dan cakupan menjelaskan semua hal lain.

DNS terenkripsi mematahkan gambaran dari dalam aplikasi. Peramban atau klien obrolan dengan resolver DNS-over-HTTPS sendiri mengirim kueri sepenuhnya melewati daftar sistem operasi, sehingga alamat di halaman pengaturan menggambarkan lalu lintas yang tidak pernah dihasilkan aplikasi. Periksa pengaturan resolver aplikasi itu sendiri sebelum menyalahkan profil atas nama yang keluar salah.

Apa yang dikatakan tiap pemeriksaan dari ketiganya

Setiap sumber meninggalkan jejaknya di tempat berbeda, dan tidak ada satu perintah pun yang menunjukkan semuanya. Inilah pemetaan yang layak disimpan di samping halaman pengaturan:

Pada sistem yang memakai systemd-resolved, resolvectl status adalah acuan, karena melaporkan DNS per tautan bersama domain perutean. macOS menjawab melalui scutil --dns, yang mendaftar resolver bercakupan sesuai urutan percobaannya. Windows membagi dua bagian: Get-DnsClientServerAddress untuk server per antarmuka dan Get-DnsClientNrptPolicy untuk aturan sufiks. Jalankan perintah yang sesuai dengan resolver yang benar-benar dipakai, karena mesin dengan runtime kontainer dan resolver desktop bisa memiliki lebih dari satu yang terpasang.

Resolver cadangan yang tidak bisa menjawab zona Anda

Entri kedua biasanya ada untuk ketersediaan, dan ketersediaan hanya bekerja jika cadangan mengetahui namanya. Tanyakan nama host internal ke resolver publik dan ia mengembalikan NXDOMAIN, atau jawaban wildcard dari domain pencarian yang tidak ada hubungannya dengan Anda. Failover yang tidak pernah diperiksa lalu menghasilkan gangguan tepat pada saat dibutuhkan.

Split DNS ada untuk mencegahnya: sufiks perusahaan pergi ke resolver yang memegang zona, dan nama publik tetap di jalur default. Rancangannya sehat, dan bergantung pada kelengkapan daftar sufiks. Microsoft mendokumentasikan kebijakan resolver per sufiks yang menggerakkan ini di Windows, dan gagasan yang sama muncul sebagai domain perutean di systemd-resolved dan sebagai resolver bercakupan di macOS.

Bandingkan zona yang boleh dijawab cadangan dengan sufiks yang ada dalam kebijakan. Perbandingan itu menemukan celahnya sebelum pengguna melaporkan bahwa satu situs internal berhenti ter-resolve setelah perubahan terowongan.

Kueri melalui resolver sistem operasi, bukan di sekitarnya

Kueri melalui resolver sistem operasi, karena kueri langsung ke server melewati kebijakan dan hanya melaporkan apa yang akan dikatakan server itu. Selisih antara kedua jawaban itulah intinya:

resolvectl query intranet.example.com
dig +short intranet.example.com @198.51.100.53

Jika kueri sistem mengembalikan alamat privat sementara kueri langsung mengembalikan NXDOMAIN, kebijakan bekerja dan cadangan adalah titik lemahnya. Jika keduanya mengembalikan jawaban publik yang sama, nama itu di-resolve di luar cakupan yang Anda maksud, dan daftar sufiks adalah tempat mencarinya. Simpan kedua keluaran, karena perdebatan resolver lebih cepat selesai dengan dua baris daripada dengan tangkapan layar halaman pengaturan.

Lalu latih jalur kegagalan, karena cadangan yang belum diuji siapa pun hanyalah asumsi. Jadikan resolver pilihan sebagai lubang hitam untuk satu kueri dan lihat alamat mana yang kembali:

ip route add blackhole 198.51.100.53/32
resolvectl query intranet.example.com
ip route del blackhole 198.51.100.53/32

Hapus rute itu segera setelah kueri selesai, atau orang berikutnya mewarisi misteri. Jika nama internal masih ter-resolve di jendela itu, sesuatu di luar cakupan yang dimaksud menjawabnya. Jika sebaliknya waktu habis, cadangannya tidak ada atau tercakup dengan benar, dan log resolver sendiri memberi tahu Anda mana dari keduanya.

Putuskan: pertahankan, batasi, atau hapus

Pertahankan resolver kedua bila ia menjawab ruang nama yang Anda butuhkan dan tetap terjangkau di bawah profil. Batasi bila ia seharusnya hanya melihat satu sufiks dan tidak yang lain, dan hapus bila ia tidak punya cakupan maupun tujuan terdokumentasi. Entri tanpa tugas adalah kebocoran masa depan tanpa manfaat, dan nilai bawaan vendor bukanlah tujuan.

Catat hasilnya sebagai empat kolom: sufiks, resolver, antarmuka, dan pemilik. Baris itu menjawab pertanyaan audit berikutnya lebih cepat daripada tangkapan layar mana pun, dan bertahan terhadap pembaruan klien yang diam-diam menyusun ulang daftar.