Apakah VPN Anda mengenkripsi DNS, atau hanya hop berikutnya?

Mengaktifkan DNS terenkripsi di server VPN sering digambarkan sebagai menutup kebocoran, dan deskripsi itu menyembunyikan koneksi mana yang berubah. Hop dari klien ke resolver dan hop dari resolver ke hulu adalah koneksi terpisah dengan pemilik terpisah. Mengenkripsi salah satunya membiarkan yang lain persis seperti sebelumnya.

Catat siapa yang menerima kueri di setiap tahap sebelum Anda menyentuh berkas konfigurasi.

Dua tatanan terlihat sama di halaman pengaturan

Pada tatanan pertama perangkat menjalankan DNS over TLS sendiri, dan terowongan hanya membawa koneksi itu ke resolver yang Anda pilih. Sesi TLS berakhir di resolver, yang berarti resolver melihat kueri dan jalan keluar VPN melihat teks sandi yang tidak dapat dibacanya. Pada tatanan kedua perangkat mengirim DNS biasa melalui terowongan ke penerus di host VPN, dan penerus itu membuka koneksi terenkripsinya sendiri ke resolver hulu. Keduanya tampak seperti "DNS terenkripsi dengan VPN" dalam daftar fitur, dan menempatkan kueri yang dapat dibaca di gedung yang berbeda.

Perbedaannya terukur, bukan filosofis. Cari sesi TLS di klien atau di server, dan Anda tahu tatanan mana yang sebenarnya Anda miliki.

Petakan rantai resolver sebelum Anda mengubahnya

Hitung resolver di jalur dan sebutkan peran masing-masing. Komponen penerus menyerahkan permintaan ke resolver lain, sedangkan resolver rekursif melakukan pekerjaan menemukan jawaban dan dapat berbicara langsung dengan server otoritatif. Peran itu didefinisikan terpisah justru karena alasan ini, dan definisi resolver dalam RFC 9076 layak dibaca sebelum Anda menganggap hanya ada satu tujuan hulu. Host yang menjalankan resolver rekursifnya sendiri tidak punya satu "hulu" untuk dienkripsi, yang membuat seluruh rencana tidak berlaku.

Lalu tanyakan komponen mana yang dikonfigurasi untuk digunakan klien. Alamat DNS yang didorong profil VPN memberi tahu Anda ke mana kueri pergi, bukan proses mana yang menjawabnya.

Perhatikan juga perilaku saat gagal. Jika hulu terenkripsi menjadi tak terjangkau, apakah penerus gagal tertutup, kembali ke teks biasa, atau beralih ke resolver lain? Keputusan itu harus masuk catatan, karena mengubah jaminan privasi pada saat terowongan paling tidak sehat.

Verifikasi hop mana yang terenkripsi

Mulai dari klien dan pastikan apakah ia memegang sesi TLS ke porta 853. Kueri yang berhasil diselesaikan melalui porta 53 tidak membuktikan apa pun tentang enkripsi.

resolvectl status | grep -E "DNS Servers|DNS over TLS"
kdig +tls +tls-ca +tls-hostname=dns.example.net @198.51.100.53 example.com A

Lalu pindah ke host VPN dan cari koneksi terenkripsi keluar yang dibuka penerus. Tabel soket memberi tahu Anda apakah ada sesi TLS hulu, dan proses mana yang memilikinya:

ss -tunp '( dport = :853 )'
dig @127.0.0.1 example.com A +short

Jika klien menunjukkan sesi TLS dan server tidak, Anda berada di tatanan pertama dan server tidak dapat membaca kueri yang diteruskannya di lapisan IP. Jika server menunjukkan sesi TLS dan klien menunjukkan lalu lintas porta 53 biasa di dalam terowongan, Anda berada di tatanan kedua: hop berikutnya terlindungi, dan penerus tetap membaca setiap nama yang diminta perangkat. Hasil kedua itu bukan kegagalan, tetapi menyebutnya enkripsi ujung ke ujung itu keliru.

Catat pemilik dan perilaku saat gagal

Kepemilikan menentukan apa yang boleh Anda janjikan. Pemilik perangkat mengendalikan koneksi terenkripsi di sisi klien, sedangkan administrator VPN mengendalikan koneksi berikutnya yang dibuat penerusnya. Siapa pun yang tidak menjalankan keduanya hanya dapat menggambarkan jalurnya.

Sebelum mengaktifkan apa pun, periksa penamaan internal. Mengirim nama organisasi ke resolver publik bukan rancangan yang setara, dan zona split-horizon yang hanya ada di dalam jaringan tidak akan diselesaikan sama sekali di hulu. Uji satu nama internal dan satu nama publik setelah perubahan, dan simpan hasilnya bersama perubahan konfigurasi. Jika jalur terenkripsi merusak resolusi host internal, perbaikannya adalah aturan resolver dengan cakupan terbatas, bukan terowongan yang lebih lebar.

Akhiri dengan menulis satu kalimat per hop: komponen mana yang menerima kueri, apakah hop itu terenkripsi, dan siapa yang dapat membaca nama itu. Ketika kalimat untuk host VPN masih menyatakan bahwa ia dapat membaca kueri, dokumentasi harus mengatakannya, karena diagram yang mengklaim sebaliknya akan dipercaya oleh orang yang tidak pernah menjalankan perintahnya.