DNS terenkripsi tanpa VPN menyembunyikan kueri, bukan alamat Anda

Uji kebocoran DNS yang menampilkan jaringan rumah Anda bukan bukti bahwa DNS terenkripsi gagal, dan juga bukan bukti bahwa ada yang berhasil. Uji itu menjawab satu pertanyaan: resolver mana yang menerima kueri ini dari jaringan ini. Apakah itu masalah bergantung pada apa yang Anda lindungi dan dari siapa.

Tuliskan tujuan sebelum menjalankan uji apa pun.

Langkah 1: sebutkan perlindungan yang benar-benar Anda inginkan

Tiga tujuan tercampur. Anda mungkin ingin pengamat di jalur berhenti membaca kueri. Anda mungkin ingin resolver tertentu berhenti menerimanya. Anda mungkin ingin situs web yang Anda kunjungi berhenti melihat alamat rumah Anda. DNS terenkripsi melayani yang pertama, mengubah siapa yang memenuhi yang kedua, dan tidak melakukan apa pun untuk yang ketiga.

VPN melayani yang ketiga dan, tergantung penyedia, yang pertama. Tidak ada alat yang menjadi superset alat lainnya.

Langkah 2: pilih resolver dan verifikasi identitasnya

DNS over TLS membungkus kueri dalam sesi TLS dengan resolver, dan DNS over HTTPS membungkusnya dalam permintaan HTTP; RFC 7858 dan RFC 8484 menjelaskan keduanya, dan tidak satu pun membutuhkan terowongan. Yang penting secara operasional adalah sertifikat diverifikasi terhadap nama yang Anda konfigurasi, karena sesi terenkripsi dengan pihak yang salah lebih buruk daripada teks biasa dengan pihak yang benar. Itu berarti mode ketat di tempat platform menawarkannya, bukan mode oportunistik yang mundur saat verifikasi gagal. Periksa sesi secara langsung sebelum memercayai pengaturan: openssl s_client -connect 9.9.9.9:853 -servername dns.quad9.net -brief.

Jabat tangan harus menyebut resolver yang Anda konfigurasi dan mengembalikan rantai yang dapat Anda verifikasi.

Langkah 3: tentukan perilaku saat gagal

Setiap implementasi punya kebijakan untuk resolver terenkripsi yang tak terjangkau, dan kebijakan itulah keputusan privasi. Mode ketat membuat pencarian gagal, yang terlihat dan menjengkelkan. Mode oportunistik mencoba lagi dengan teks biasa, yang tak terlihat dan menggagalkan tujuan justru pada hari ketika itu penting. Pilih dengan sadar, lalu catat pilihan itu di samping persyaratan.

Pada systemd-resolved itu berarti DNSOverTLS=yes bukan opportunistic; pada Android itu berarti mode nama host Private DNS alih-alih otomatis.

Periksa apa yang benar-benar berlaku dengan resolvectl status | grep -i -A1 "dns over tls", karena file drop-in yang tidak pernah dimuat ulang tidak mengubah apa pun.

Langkah 4: periksa apakah aplikasi mengikuti resolver sistem

Peramban dengan pengaturan DNS aman sendiri melewati konfigurasi sistem sepenuhnya, begitu juga runtime kontainer dengan resolver tertanam atau runtime bahasa yang membaca daftar yang dikodekan keras. Entah buat mereka mengikuti sistem atau konfigurasikan secara eksplisit dan catat. Lalu lihat perilaku mundur masing-masing, karena tidak semuanya gagal tertutup. Daftarnya dalam praktik singkat: peramban, runtime kontainer, dan klien VPN apa pun yang juga Anda jalankan.

Nama organisasi privat tetap pada resolver internal yang disetujui. Mengirimnya ke layanan publik agar uji terlihat rapi dengan sengaja menciptakan masalah lain.

Langkah 5: baca uji kebocoran terhadap persyaratan

Uji yang melaporkan resolver tak terduga adalah petunjuk, bukan putusan. Mungkin ia mengamati resolver terenkripsi yang Anda maksud, pengaturan khusus aplikasi, atau fallback teks biasa yang tidak Anda ketahui. Bandingkan resolver yang dilaporkan dengan yang dikonfigurasi langkah 2, dan bandingkan hasilnya dengan tujuan dari langkah 1.

Jika tujuannya menjauhkan kueri dari jaringan lokal, uji yang menampilkan resolver biasa Anda adalah temuan nyata. Jika tujuannya anonimitas saat menjelajah, tidak ada pengaturan DNS yang akan memberikannya.

Tuliskan baris penerimaan dalam bahasa tujuan: pencarian ini menggunakan resolver terverifikasi ini dalam kondisi ini. Apa pun yang lebih luas adalah klaim yang tidak dapat Anda uji.