Sokongan percubaan untuk DNS-over-HTTPS telah ditambahkan pada pelayan DNS BIND

Pembangun pelayan DNS BIND mengumumkan penambahan sokongan pelayan untuk DNS melalui HTTPS (DoH, DNS over HTTPS) dan teknologi DNS over TLS (DoT, DNS over TLS), serta mekanisme XFR-over-TLS untuk selamat. memindahkan kandungan zon DNS antara pelayan. DoH tersedia untuk ujian dalam keluaran 9.17 dan sokongan DoT telah hadir sejak keluaran 9.17.10. Selepas penstabilan, sokongan DoT dan DoH akan disandarkan ke cawangan 9.17.7 yang stabil.

Pelaksanaan protokol HTTP/2 yang digunakan dalam DoH adalah berdasarkan penggunaan pustaka nghttp2, yang termasuk antara kebergantungan pemasangan (pada masa hadapan, perpustakaan itu dirancang untuk dipindahkan ke bilangan kebergantungan pilihan). Kedua-dua sambungan yang disulitkan (TLS) dan HTTP/2 tidak disulitkan disokong. Dengan tetapan yang sesuai, satu proses bernama kini boleh melayani bukan sahaja pertanyaan DNS tradisional, tetapi juga pertanyaan yang dihantar menggunakan DoH (DNS-over-HTTPS) dan DoT (DNS-over-TLS). Sokongan HTTPS pada bahagian klien (gali) belum dilaksanakan. Sokongan XFR-over-TLS tersedia untuk permintaan masuk dan keluar.

Pemprosesan permintaan menggunakan DoH dan DoT didayakan dengan menambahkan pilihan http dan tls pada arahan dengar. Untuk menyokong DNS-over-HTTP yang tidak disulitkan, anda harus menentukan "tls none" dalam tetapan. Kekunci ditakrifkan dalam bahagian "tls". Port rangkaian lalai 853 untuk DoT, 443 untuk DoH dan 80 untuk DNS-over-HTTP boleh ditindih melalui parameter tls-port, https-port dan http-port. Contohnya: tls local-tls { key-file "/path/to/priv_key.pem"; fail-sijil "/path/to/cert_chain.pem"; }; http local-http-server { endpoints { "/dns-query"; }; }; pilihan { https-port 443; listen-on port 443 tls local-tls http myserver {mana-mana;}; }

Antara ciri pelaksanaan DoH dalam BIND, integrasi diperhatikan sebagai pengangkutan umum, yang boleh digunakan bukan sahaja untuk memproses permintaan pelanggan kepada penyelesai, tetapi juga apabila bertukar-tukar data antara pelayan, apabila memindahkan zon oleh pelayan DNS yang berwibawa, dan apabila memproses sebarang permintaan yang disokong oleh pengangkutan DNS lain .

Ciri lain ialah keupayaan untuk mengalihkan operasi penyulitan untuk TLS ke pelayan lain, yang mungkin diperlukan dalam keadaan di mana sijil TLS disimpan pada sistem lain (contohnya, dalam infrastruktur dengan pelayan web) dan diselenggara oleh kakitangan lain. Sokongan untuk DNS-over-HTTP yang tidak disulitkan dilaksanakan untuk memudahkan penyahpepijatan dan sebagai lapisan untuk pemajuan dalam rangkaian dalaman, berdasarkan penyulitan yang boleh diatur pada pelayan lain. Pada pelayan jauh, nginx boleh digunakan untuk menjana trafik TLS, sama seperti cara pengikatan HTTPS diatur untuk tapak web.

Mari kita ingat bahawa DNS-over-HTTPS boleh berguna untuk mencegah kebocoran maklumat tentang nama hos yang diminta melalui pelayan DNS penyedia, memerangi serangan MITM dan penipuan trafik DNS (contohnya, apabila menyambung ke Wi-Fi awam), melawan menyekat pada peringkat DNS (DNS-over-HTTPS tidak boleh menggantikan VPN dalam memintas penyekatan yang dilaksanakan pada peringkat DPI) atau untuk mengatur kerja apabila mustahil untuk mengakses pelayan DNS secara langsung (contohnya, apabila bekerja melalui proksi). Jika dalam keadaan biasa permintaan DNS dihantar terus ke pelayan DNS yang ditakrifkan dalam konfigurasi sistem, maka dalam kes DNS-over-HTTPS permintaan untuk menentukan alamat IP hos dirangkumkan dalam trafik HTTPS dan dihantar ke pelayan HTTP, di mana penyelesai memproses permintaan melalui API Web.

"DNS melalui TLS" berbeza daripada "DNS melalui HTTPS" dalam penggunaan protokol DNS standard (port rangkaian 853 biasanya digunakan), dibungkus dalam saluran komunikasi yang disulitkan yang dianjurkan menggunakan protokol TLS dengan semakan kesahihan hos melalui sijil TLS/SSL yang diperakui oleh pihak berkuasa pensijilan. Standard DNSSEC sedia ada menggunakan penyulitan hanya untuk mengesahkan klien dan pelayan, tetapi tidak melindungi trafik daripada pemintasan dan tidak menjamin kerahsiaan permintaan.

Sumber: opennet.ru

Tambah komen