Google Public DNS diam-diam telah mengaktifkan dukungan DNS over TLS

Tiba-tiba, tanpa pengumuman awal, DNS over TLS mulai bekerja pada 8.8.8.8 . Sebelumnya, Google mengumumkan hanya dukungan untuk DNS melalui HTTPS.

Penyelesai publik CloudFlare dengan alamat IP 1.1.1.1 telah mendukung DNS over TLS sejak proyek dimulai.

Mengapa itu perlu?

Menggunakan skema DNS klasik, penyedia dapat menyodok cakarnya yang kotor ke dalam paket DNS Anda, menelusuri domain mana yang Anda minta, dan spoof jawaban sesuka Anda. Scammers melakukan hal yang sama, mengganti resolver pada router yang diretas untuk mengarahkan pengguna ke server palsu.

Dengan DNS over TLS / HTTPS, permintaan dikirim di dalam terowongan terenkripsi sehingga penyedia tidak dapat mengganti atau melihat permintaan.

Dan dengan munculnya enkripsi nama domain dalam sertifikat X.509 ( ESNI ), akan menjadi mustahil untuk memblokir melalui DPI melalui SNI (Server Name Indication, bidang khusus di mana nama domain ditransmisikan dalam paket TLS pertama), yang sekarang digunakan oleh beberapa penyedia besar.

Bagaimana cara kerjanya

Sambungan TLS dibuat ke port TCP: 853, dan sertifikat resolver diverifikasi menggunakan sertifikat root sistem, seperti HTTPS di browser. Ini menghilangkan kebutuhan untuk menambahkan kunci apa saja secara manual. Di dalam terowongan, permintaan DNS reguler dilakukan. Ini menciptakan lebih sedikit overhead daripada DNS melalui HTTPS, yang menambahkan header HTTP ke permintaan dan respons.

Sayangnya, saat ini hanya di Android 9 (Pie) dukungan untuk DNS over TLS dibangun ke dalam resolver sistem. Petunjuk Penyiapan untuk Android 9 .

Untuk sistem lain, diusulkan untuk menggunakan daemon pihak ketiga, dan mengirim penyelesai sistem ke localhost (127.0.0.1).

Pengaturan pada macOS

Mari kita menganalisis DNS lebih dari TLS pada versi terbaru dari macOS, menggunakan simpul penyelesaian sebagai contoh

Instalasi

brew install knot-resolver 

Secara default, simpul akan bekerja seperti resolver rekursif biasa, seperti dnsmasq.

Mengedit konfigurasi

 nano /usr/local/etc/kresd/config 

Dan tambahkan ke akhir file:

 policy.add( policy.all( policy.TLS_FORWARD({ {'8.8.8.8', hostname='8.8.8.8'}, {'8.8.4.4', hostname='8.8.4.4'} }))) 

Akibatnya, konfigurasi saya terlihat seperti ini:

Peluncuran daemon

 sudo brew services start knot-resolver 

Anda dapat memeriksa apakah daemon berhasil dimulai dengan menggunakan perintah:

 sudo lsof -i -P -n | grep kresd 

Proses kresd harus mendengarkan pada port 53 di localhost.

Jika ada kesalahan, lihat log kesalahan:

 cat /usr/local/var/log/kresd.log 

Memeriksa operasi penyelesai

 dig @127.0.0.1 habr.com 

Pastikan resolver lokal merespons dengan benar.

Instalasi sebagai pemecah masalah sistem

Jika semuanya berfungsi dengan benar, Anda dapat menetapkan resolver sistem di properti adapter jaringan:



UPD

Apa perbedaan antara DNSCrypt, DNSSEC, DNS over TLS / HTTPS.

DNSCrypt dapat bekerja pada UDP dan TCP. Koneksi ke port 443. Untuk enkripsi, protokolnya sendiri digunakan, yang berbeda dari HTTPS. Itu dapat dengan mudah disorot menggunakan DPI. Ini lebih merupakan konsep, yang diuji sebelum pengenalan DNS melalui TLS / HTTPS, karena tidak memiliki RFC, yaitu, itu bukan standar Internet resmi. Kemungkinan besar, segera, itu akan sepenuhnya digantikan oleh yang terakhir.

DNS over TLS (DoT) - Koneksi TCP terjadi pada port 853, permintaan DNS reguler dikirimkan di dalam terowongan. Penyedia melihat bahwa ini adalah permintaan DNS tetapi tidak dapat mengganggu itu. Hal lain dianggap sama, dalam DNS lebih dari TLS harus ada sedikit overhead untuk setiap permintaan daripada di atas HTTPS.

DNS over HTTP (DoH) - Koneksi TCP ke port 443, mirip dengan HTTPS biasa. Di dalamnya ada format permintaan yang berbeda, dengan tajuk HTTP. Namun, untuk penyedia, permintaan seperti itu akan dilihat sebagai koneksi HTTPS normal. Saya kira protokol ini ditemukan jika DNS query ke server asing diblokir untuk menutupi lalu lintas web normal. Dan juga, agar browser dapat menyelesaikan domain sendiri dan tidak menciptakan lalu lintas yang tidak normal.

Faktanya, DNS over HTTPS dan over TLS adalah hal yang sama, dengan format permintaan yang sedikit berbeda. Kedua protokol ini diterima sebagai standar dan memiliki RFC. Kemungkinan besar, dalam waktu dekat kita akan melihat distribusi massa keduanya.

DNSSEC adalah protokol untuk menandatangani catatan DNS secara digital. Ini tidak terkait dengan enkripsi, karena semua permintaan dikirim dalam teks yang jelas. Ia dapat bekerja baik melalui protokol DNS klasik lama, mis. UDP / TCP pada port 53, dan di dalam DNS melalui TLS / HTTPS. Tujuan DNSSEC adalah untuk mengotentikasi catatan DNS. Pemilik domain dapat menambahkan kunci publik ke server root dari zona domainnya dan menandatangani semua entri pada wizard server NS. Bahkan, untuk setiap catatan DNS, misalnya, A-record atau MX-record, ditambahkan catatan lain dari tipe RRSIG yang berisi tanda tangan. Prosedur validasi DNSSEC pada resolver rekursif memungkinkan Anda menentukan apakah catatan ini benar-benar dibuat oleh pemilik domain.

Perbandingan yang lebih rinci dari semua protokol dnscrypt.info/faq (paragraf Protokol lain)