Mengikuti perusahaan Google tentang niat untuk melakukan percobaan untuk menguji implementasi “DNS over HTTPS” (DoH, DNS over HTTPS) yang sedang dikembangkan untuk browser Chrome. Chrome 78, yang dijadwalkan pada 22 Oktober, akan memiliki beberapa kategori pengguna secara default untuk menggunakan DoH. Hanya pengguna yang pengaturan sistemnya saat ini menentukan penyedia DNS tertentu yang diakui kompatibel dengan DoH yang akan mengambil bagian dalam eksperimen untuk mengaktifkan DoH.
Daftar putih penyedia DNS termasuk Google (8.8.8.8, 8.8.4.4), Cloudflare (1.1.1.1, 1.0.0.1), OpenDNS (208.67.222.222, 208.67.220.220), Quad9 (9.9.9.9, 149.112.112.112), Penjelajahan Bersih (185.228.168.168. 185.228.169.168, 185.222.222.222) dan DNS.SB (185.184.222.222, XNUMX). Jika pengaturan DNS pengguna menentukan salah satu server DNS yang disebutkan di atas, DoH di Chrome akan diaktifkan secara default. Bagi mereka yang menggunakan server DNS yang disediakan oleh penyedia Internet lokal mereka, semuanya tidak akan berubah dan pemecah masalah sistem akan terus digunakan untuk permintaan DNS.
Perbedaan penting dari penerapan DoH di Firefox, yang secara bertahap mengaktifkan DoH secara default sudah pada akhir bulan September, adalah kurangnya pengikatan pada satu layanan DoH. Jika di Firefox secara default Server DNS CloudFlare, maka Chrome hanya akan memperbarui metode bekerja dengan DNS ke layanan yang setara, tanpa mengubah penyedia DNS. Misalnya, jika pengguna memiliki DNS 8.8.8.8 yang ditentukan dalam pengaturan sistem, maka Chrome akan melakukannya Layanan Google DoH (“https://dns.google.com/dns-query”), jika DNSnya 1.1.1.1, maka layanan Cloudflare DoH (“https://cloudflare-dns.com/dns-query”) Dan
Jika diinginkan, pengguna dapat mengaktifkan atau menonaktifkan DoH menggunakan pengaturan “chrome://flags/#dns-over-https”. Tiga mode pengoperasian didukung: aman, otomatis, dan mati. Dalam mode “aman”, host ditentukan hanya berdasarkan nilai aman yang di-cache sebelumnya (diterima melalui koneksi aman) dan permintaan melalui DoH; penggantian ke DNS biasa tidak diterapkan. Dalam mode “otomatis”, jika DoH dan cache aman tidak tersedia, data dapat diambil dari cache yang tidak aman dan diakses melalui DNS tradisional. Dalam mode “mati”, cache bersama diperiksa terlebih dahulu dan jika tidak ada data, permintaan dikirim melalui DNS sistem. Mode diatur melalui kDnsOverHttpsMode , dan templat pemetaan server melalui kDnsOverHttpsTemplates.
Eksperimen untuk mengaktifkan DoH akan dilakukan pada semua platform yang didukung di Chrome, dengan pengecualian Linux dan iOS karena sifat penguraian pengaturan penyelesai yang tidak sepele dan membatasi akses ke pengaturan DNS sistem. Jika, setelah mengaktifkan DoH, ada masalah saat mengirimkan permintaan ke server DoH (misalnya, karena pemblokiran, konektivitas jaringan, atau kegagalan), browser akan secara otomatis mengembalikan pengaturan DNS sistem.
Tujuan dari percobaan ini adalah untuk menguji akhir penerapan DoH dan mempelajari dampak penggunaan DoH terhadap kinerja. Perlu dicatat bahwa sebenarnya ada dukungan dari DoH ke dalam basis kode Chrome pada bulan Februari, tetapi untuk mengonfigurasi dan mengaktifkan DoH meluncurkan Chrome dengan tanda khusus dan serangkaian opsi yang tidak jelas.
Ingatlah bahwa DoH dapat berguna untuk mencegah kebocoran informasi tentang nama host yang diminta melalui server DNS penyedia, melawan serangan MITM dan spoofing lalu lintas DNS (misalnya, saat menyambung ke Wi-Fi publik), melawan pemblokiran di DNS level (DoH tidak dapat menggantikan VPN di area bypass pemblokiran yang diterapkan pada level DPI) atau untuk mengatur pekerjaan jika tidak mungkin mengakses server DNS secara langsung (misalnya, saat bekerja melalui proxy). Jika dalam situasi normal permintaan DNS langsung dikirim ke server DNS yang ditentukan dalam konfigurasi sistem, maka dalam kasus DoH, permintaan untuk menentukan alamat IP host dienkapsulasi dalam lalu lintas HTTPS dan dikirim ke server HTTP, tempat penyelesai memproses permintaan melalui Web API. Standar DNSSEC yang ada menggunakan enkripsi hanya untuk mengautentikasi klien dan server, tetapi tidak melindungi lalu lintas dari intersepsi dan tidak menjamin kerahasiaan permintaan.
Sumber: opennet.ru