DNS melalui HTTPS: apakah itu dan bagaimana ia melindungi pertanyaan anda

Panduan Alfa » Pengkomputeran » DNS melalui HTTPS: apakah itu dan bagaimana ia melindungi pertanyaan anda

Apabila anda menaip alamat web, terdapat komponen yang berfungsi di sebalik tabir untuk memastikan anda sampai ke tapak yang betul: Sistem Nama Domain (DNS). DNS menterjemahkan nama yang mudah diingati kepada alamat IP yang boleh difahami oleh komputer. Ya, ia mudah, tetapi selama bertahun-tahun ia beroperasi dengan kerentanan yang ketara: pertanyaan ini dilayari tanpa disulitkan. Inilah sebabnya mengapa DNS melalui HTTPS, juga dikenali sebagai DoH, telah menjadi begitu ketara—lapisan perlindungan tambahan yang menyukarkan penyedia perkhidmatan internet anda untuk menjejaki domain yang anda lawati.

Penting untuk menjelaskan satu perkara dari awal: DoH meningkatkan privasi pertanyaan DNS, tetapi ia bukan VPN, dan juga tidak mengubah keseluruhan sambungan anda menjadi terowong rahsia . Sepanjang artikel ini, kami akan meneroka dengan tepat apa itu VPN, mengapa ia menjadi popular, cara mengaktifkannya dalam Chrome, Edge dan Firefox, kelebihan dan kekurangannya, bagaimana ia berbeza daripada DNS berbanding TLS dan VPN, dan sejauh mana batasan teknikal dan praktikalnya.

Apakah DNS dan mengapa sistem tradisional gagal?

Pelayan DNS merupakan salah satu komponen yang hampir tidak dipandang oleh sesiapa pun, namun ia menjadi asas sebahagian besar pelayaran dalam talian. Tugas mereka adalah untuk memautkan nama domain ke alamat IP pelayan yang sepadan . Apabila anda melayari laman web, komputer anda tidak memahami huruf: ia memerlukan alamat IP untuk mengetahui mesin yang hendak disambungkan. Banyak penghala didatangkan dengan pelayan DNS yang telah dikonfigurasikan oleh penyedia perkhidmatan internet, yang menjadikan prosesnya mudah, walaupun ia juga meninggalkan jejak yang boleh dilihat oleh sesiapa sahaja yang mengawal infrastruktur tersebut.

Masalah yang mendasarinya ialah pertanyaan DNS tradisional dibuat dalam teks biasa dan tanpa perlindungan . Ini membuka pintu kepada pengintipan, serangan orang tengah dan manipulasi respons. Penyedia perkhidmatan internet boleh mengetahui domain mana yang anda tanyakan dan bila; penyerang pada rangkaian kongsi boleh cuba memintas permintaan dan mengembalikan respons palsu. Teknik ini dikenali sebagai rampasan DNS dan akhirnya boleh membawa anda ke halaman palsu, pengiklanan yang tidak diingini atau tapak yang direka untuk mencuri data. Kerajaan dan penyedia perkhidmatan internet juga secara sejarahnya telah mengeksploitasi kelemahan ini untuk melaksanakan penapisan, menyekat domain atau memaparkan pengiklanan tambahan.

• Mendengar secara pasif: Seseorang memerhatikan pertanyaan dan membuat kesimpulan tentang perkhidmatan atau laman web yang anda kerap lawati.
• Lelaki di tengah: Komunikasi dipintas dan respons diubah suai untuk menyamar sebagai pelayan.
• Menyekat dan menapis: Ia menghalang resolusi domain tertentu untuk mengawal akses kepada kandungan.

DNS melalui HTTPS: Sulitkan pertanyaan supaya ia tidak kelihatan kepada semua orang.

DNS melalui HTTPS, atau DoH, ialah penyelesaian yang memanfaatkan protokol HTTPS untuk menghantar pertanyaan dan respons DNS dalam bentuk yang disulitkan . Peranti ini merangkumnya dalam sambungan selamat, biasanya menggunakan port 443, port yang sama yang digunakan oleh laman web selamat, sekali gus menghalang pemerhati luaran daripada membacanya dengan mudah.

Agar ini berfungsi, pelayan DNS yang sedang ditanya juga mesti menyokong DNS berasaskan Domain (DoH ). Hanya mendayakan pilihan dalam pelayar tidak mencukupi: penyelesai yang dipilih mesti mematuhi piawaian ini. Spesifikasi ini telah berkembang dan masih dianggap sebagai teknologi yang sedang membangun, walaupun sejak 2018 syarikat seperti Google dan Yayasan Mozilla telah menguji dan mengintegrasikannya. Selain privasi yang dipertingkatkan, ujian menunjukkan bahawa DoH boleh mengurangkan kependaman dan membuat pertanyaan lebih pantas, kerana tidak selalunya perlu untuk menyelesaikan keseluruhan domain, tetapi hanya bahagian minimum yang diperlukan.

Kelebihan DoH: lebih banyak privasi, kurang manipulasi dan prestasi yang lebih baik

Kelebihan yang paling ketara ialah keselamatan. Oleh kerana ia bergerak dalam mod yang disulitkan, pertanyaan DNS jauh lebih sukar untuk diintip atau diubah suai . Ini merumitkan serangan orang tengah, mengurangkan pendedahan pada rangkaian Wi-Fi awam dan menghalang pengendali tempatan daripada melihat dengan jelas domain yang anda minta. Memandangkan trafik DoH menggunakan port 443, ia sebati dengan sambungan HTTPS lain dan sukar dibezakan daripada lawatan web biasa.

Terdapat juga sebab prestasi. DoH boleh mengurangkan kependaman dan mempercepatkan komunikasi DNS hasil daripada perubahan dalam cara nama diselesaikan dan penggunaan cache yang lebih baik. Contohnya, kaedah GET bagi sesetengah API direka bentuk untuk disimpan dalam cache dengan lebih cekap. Dalam praktiknya, ini boleh diterjemahkan kepada pelayaran yang sedikit lebih pantas, walaupun ia bukan penyelesaian ajaib dan penambahbaikan tidak selalu ketara. Tambahan pula, memandangkan ia dilaksanakan dalam pelayar, pengguna tidak perlu menunggu penyedia perkhidmatan internet mereka mengaktifkannya.

Kelemahan dan perdebatan: apabila penyulitan merumitkan kehidupan

Bukan semua orang memandang baik Penyulitan berasaskan Domain (DoH). Penyulitan yang sama yang melindungi pengguna juga menyukarkan pemantauan rangkaian . Banyak program kawalan ibu bapa bergantung pada pemeriksaan pertanyaan DNS untuk menentukan laman web mana yang cuba diakses oleh kanak-kanak; dengan DoH, tugas ini menjadi jauh lebih rumit dan mungkin mustahil. Situasi yang sama wujud untuk pentadbir rangkaian korporat, yang kehilangan keterlihatan ke dalam domain yang sedang dipersoalkan dan tidak dapat menguatkuasakan peraturan tertentu dengan mudah.

Penyedia internet juga kehilangan keupayaan untuk memantau akses dan menyekat domain tertentu atas permintaan sesebuah institusi. Ini menimbulkan perdebatan yang sah: sesetengah melihatnya sebagai kemenangan untuk privasi, sementara yang lain menganggapnya sebagai masalah kawalan dan pengurusan . Dalam kes DoT, ia juga dikritik kerana menggunakan portnya sendiri yang boleh dikenali, yang membolehkan pengenalpastian pertanyaan DNS walaupun tanpa mengetahui dengan tepat apa yang diminta. DoH mengelakkan isyarat jelas ini dengan menyamar sebagai sebahagian daripada trafik HTTPS, tetapi sebagai balasannya, pentadbir rangkaian dibiarkan dengan lebih sedikit alat untuk mengurus komunikasi mereka.

Cara mendayakan DoH dalam Chrome, Edge dan Firefox

Mengaktifkan Sistem Nama Domain (DNS) dalam pelayar moden biasanya mudah, terutamanya jika ia berasaskan Chromium atau Firefox. Pilihan ini wujud, walaupun dalam beberapa kes ia tersembunyi dalam menu tetapan lanjutan . Sebelum mengubah apa-apa, adalah penting untuk memahami bahawa pelayar hanya melindungi pertanyaannya sendiri: aplikasi lain pada peranti mungkin terus menggunakan sistem DNS yang berbeza jika ia tidak dikonfigurasikan pada peringkat sistem.

Google Chrome

Dalam Chrome, cara terpantas adalah dengan menaip chrome://flags/#dns-over-https di bar alamat. Itu akan membawa anda terus ke Bendera Chrome atau ciri eksperimen.Anda akan melihat pilihan yang dipanggil Carian DNS selamat dipilih; klik pada menu lungsur turun yang menyatakan Lalai dan pilih Diaktifkan. Kemudian anda perlu memulakan semula pelayar anda agar perubahan tersebut berkuat kuasa.

Microsoft Edge

Dalam Edge berasaskan Chromium, prosesnya hampir sama. Buka pelayar anda dan taip edge://flags/#dns-over-https di bar carianAnda akan memasukkan Bendera Edge dan pilihan carian DNS Selamat yang sama akan muncul. Tukar Lalai kepada Diaktifkan dan mulakan semula pelayar apabila digesa.

Mozilla Firefox

Dalam Firefox, anda tidak perlu pergi ke Bendera. Klik butang menu di penjuru kanan sebelah atas dan pilih Pilihan . Dalam bahagian Umum, tatal ke bawah dan klik Tetapan Rangkaian. Dalam tetingkap yang terbuka, tandakan kotak di sebelah Dayakan DNS melalui HTTPS. Anda kemudian boleh memilih daripada pembekal seperti Cloudflare dan NextDNS untuk melakukan penyulitan melalui HTTPS.

DNS melalui TLS (DoT): laluan yang disulitkan yang lain

DNS melalui TLS, atau DoT, merupakan satu lagi cara untuk melindungi pertanyaan DNS. Daripada menggunakan HTTPS, ia menggunakan TLS melalui sambungan TCP dan port piawai, 853. TLS ialah asas keselamatan yang sama seperti HTTPS, jadi ideanya adalah serupa: untuk mencipta terowong yang disulitkan di mana hanya dua peserta boleh menyahsulit dan memproses maklumat. Ini menjadikan serangan orang tengah lebih sukar dan menghalang pihak ketiga daripada membaca atau memanipulasi pertanyaan.

DotT mempunyai kelebihannya, terutamanya berbanding DNS tradisional, yang tidak menawarkan langkah keselamatan. Penyulitan menghalang penjenayah siber daripada memintas permintaan dan juga menghalang langkah penapisan tertentu . Walau bagaimanapun, ia memerlukan keserasian daripada klien dan pelayan. Beberapa pembekal menawarkan pelayan yang serasi, tetapi menggunakannya pada desktop atau komputer riba biasanya memerlukan pemasangan perisian tambahan; pada Android moden, sekurang-kurangnya sejak Android 9, ia sudah disepadukan. Penyelesaian wujud untuk Windows dan Linux, walaupun ia tidak selalunya setelus yang diinginkan.

Antara kelemahannya, ramai pakar perlindungan data mengkritik DoT kerana menggunakan satu port yang boleh dikenali. Walaupun mustahil untuk mengetahui laman web mana yang sedang diakses, trafik DNS boleh dikesan . Bagi sesetengah pentadbir rangkaian, ini berguna kerana ia membolehkan mereka mengekalkan gambaran keseluruhan tentang apa yang berlaku; bagi yang lain, ia adalah isyarat yang mereka lebih suka sembunyikan. Tambahan pula, DoT belum lagi meluas seperti DNS tradisional, dan penggunaannya di bahagian pelayan adalah terhad. Terdapat kebimbangan bahawa beberapa syarikat akan semakin menumpukan pertanyaan DNS, yang berpotensi mewujudkan sejenis monopoli antarabangsa.

DoH vs. DoT: Dua cara untuk melindungi perkara yang sama

Perbezaan utama antara DoH dan DoT terletak pada port dan bagaimana trafik disamarkan. DoT menggunakan portnya sendiri, 853, manakala DoH menggunakan 443 dan sebati dengan sambungan HTTPS biasa . Perbezaan yang nampaknya kecil ini telah mencetuskan perdebatan yang besar. Dari perspektif privasi, ketidakbolehbezaan pertanyaan DNS daripada trafik lain adalah satu kelebihan: jika ia tidak dikenali, ia tidak boleh dimanipulasi dengan mudah. ​​Walau bagaimanapun, dari perspektif pengurusan rangkaian, kawalan hilang, dan menjadi lebih sukar untuk melaksanakan dasar keselamatan atau penapisan.

Pada terasnya, terdapat dua visi. IETF, konsortium yang membangunkan banyak piawaian internet, berada di belakang DoT , manakala Google dan Yayasan Mozilla telah mempromosikan DoH dengan kuat. Ini bukanlah teknologi yang bertentangan, tetapi ia mewakili cara yang berbeza untuk memahami privasi, keterlihatan rangkaian dan peranan perantara. Pilihan antara satu dan yang lain bergantung pada apa yang perlu dilindungi dan siapa yang perlu mengurus rangkaian.

DoH vs. VPN: Ia melindungi soalan, bukan keseluruhan perjalanan

DoH dan VPN sering muncul dalam perbualan yang sama tentang privasi, tetapi ia tidak melakukan perkara yang sama. DoH melindungi pertanyaan nama; VPN melindungi laluan data anda . Cara paling mudah untuk memahami perkara ini adalah dengan memikirkan DoH meletakkan soalan sensitif dalam sampul surat yang tertutup rapat, manakala VPN menjadikan keseluruhan perjalanan melalui terowong peribadi sebelum kembali ke jalan awam. Kedua-duanya boleh meningkatkan privasi, tetapi hanya satu yang direka bentuk untuk meliputi trafik telefon, tablet dan komputer secara komprehensif.

Apakah yang dilakukan oleh DNS sebelum laman web dimuatkan?

Sebelum pelayar anda boleh memuatkan laman web, peranti anda perlu mengetahui lokasinya. DNS berfungsi seperti buku telefon, menterjemahkan nama laman web kepada alamat IP . Ini berlaku secara berterusan: apabila anda membuka halaman, melancarkan aplikasi, mengemas kini e-mel anda atau memainkan video. Kebanyakan masa ia berlaku secara senyap dan anda tidak menyedarinya, yang bagus untuk kemudahan, tetapi ia juga memudahkan untuk diabaikan sebagai isu privasi. Pertanyaan DNS tradisional tidak disulitkan, jadi penyedia perkhidmatan internet anda, majikan anda, sekolah anda, Wi-Fi kedai kopi atau rangkaian hotel boleh melihat domain yang cuba dicapai oleh peranti anda. Mereka tidak melihat kandungan penuh halaman HTTPS, tetapi mereka mendapat garis besar aktiviti anda yang agak mendedahkan.

Pertanyaan DNS tidak mendedahkan setiap halaman yang telah anda lihat atau semua yang anda taip ke dalam borang, tetapi senarai domain boleh mendedahkan tabiat, minat, alat kerja, penyelidikan kesihatan atau perkhidmatan kewangan . Itulah sebabnya DNS yang disulitkan telah menjadi ciri privasi yang berguna. Ia tidak mendedahkan semuanya, tetapi ia mendedahkan lebih daripada yang disedari oleh ramai orang.

Apa yang disembunyikan oleh DoH dan apa yang didedahkannya?

DoH menghantar pertanyaan DNS melalui HTTPS, protokol yang disulitkan sama yang digunakan oleh laman web selamat. Permintaan tersebut akan menyulitkan peranti anda dan sampai ke penyelesai yang menyokong standard tersebut . Pada Wi-Fi awam, ini boleh menyukarkan pengendali rangkaian untuk membaca pertanyaan anda secara tidak sengaja. Jika pembekal internet anda mengurus DNS, bertukar kepada penyelesai DoH boleh menghalang mereka daripada melihat pertanyaan ini dengan cara biasa. Tambahan pula, jika rangkaian memanipulasi hasil resolusi nama, DNS yang disulitkan boleh mengurangkan beberapa bentuk manipulasi.

Kini, DoH menyembunyikan pertanyaan, bukan keseluruhan perbualan. Ia mungkin menghalang sesetengah pemerhati daripada melihat carian domain dengan jelas, tetapi ia tidak menjadikan keseluruhan sambungan internet anda sebagai terowong yang disulitkan . Sebaik sahaja peranti mengetahui alamat IP, sambungan yang lain akan mengikuti laluan biasa, melainkan alat privasi lain mengubah laluan tersebut. DoH tidak menyembunyikan alamat IP sebenar anda daripada laman web, aplikasi atau perkhidmatan yang anda sambungkan, dan juga tidak membuatkan anda kelihatan berada di bandar atau negara yang berbeza. Jika anda log masuk ke akaun, perkhidmatan tersebut tahu itu anda. Jika pelayar mempunyai kuki, sesi yang disimpan, pengecam pengiklanan atau cap jari yang boleh dikenali, DoH tidak memadamkan isyarat tersebut.

Ia juga tidak melindungi setiap aplikasi melainkan ia dikonfigurasikan pada peringkat sistem dan aplikasi tersebut mematuhi tetapan tersebut. Satu pelayar mungkin menggunakan DNS selamat manakala aplikasi lain pada peranti yang sama menggunakan laluan DNS yang berbeza . Sesetengah aplikasi mengurus rangkaian mereka sendiri dan tidak selalunya sejajar dengan tetapan sistem atau pelayar. Oleh itu, DoH boleh mewujudkan rasa perlindungan lengkap yang palsu: ia meningkatkan privasi pertanyaan DNS, tetapi ia tidak melindungi pemindahan fail, trafik pesanan, panggilan video, sambungan permainan, penyegerakan latar belakang atau aplikasi penstriman seperti yang dilakukan oleh VPN.

Apakah yang dilindungi oleh VPN dan apa yang tidak boleh disembunyikannya?

VPN melindungi bahagian perjalanan anda yang berbeza. Ia mewujudkan terowong yang disulitkan antara peranti anda dan pelayan VPN, yang menghalakan trafik internet anda melalui pelayan tersebut . Penyedia perkhidmatan internet atau rangkaian Wi-Fi tempatan anda melihat sambungan yang disulitkan ke pelayan VPN, bukan pandangan yang jelas bagi setiap tapak dan perkhidmatan yang anda sambungkan. Selain itu, VPN mengubah alamat IP awam yang dilihat oleh laman web dan aplikasi: destinasi melihat alamat IP pelayan VPN dan bukannya alamat IP rumah atau pembawa mudah alih anda. Ini boleh mengurangkan penjejakan berasaskan lokasi, membantu anda memintas beberapa profil ISP dan menjadikan penggunaan Wi-Fi awam lebih selamat.

VPN yang komprehensif boleh melindungi pelayar, aplikasi penstriman, klien e-mel, alat sandaran awan, aplikasi pemesejan, permainan dan perkhidmatan latar belakang. Ia juga boleh menghalakan permintaan DNS melalui terowong yang disulitkan apabila dikonfigurasikan dengan betul , oleh itu adalah idea yang baik untuk menjalankan ujian kebocoran DNS. Walau bagaimanapun, VPN bukanlah sihir. Jika anda log masuk ke rangkaian sosial, akaun e-mel, perkhidmatan penstriman atau kedai dalam talian, perkhidmatan tersebut masih mengetahui siapa anda. Ia boleh menyembunyikan alamat IP asal anda, tetapi ia tidak menjadikan log masuk anda tanpa nama. Perkara yang sama berlaku untuk apa sahaja yang anda hantar secara langsung: nama, alamat e-mel, butiran pembayaran, alamat penghantaran, foto atau mesej anda.

Kuki dan cap jari pelayar masih penting. Aplikasi boleh menimbulkan masalah yang serupa melalui pengecam pengiklanan, kebenaran, akses lokasi, pengimbasan Bluetooth, nama Wi-Fi berdekatan dan alat pengimbasan. Perisian hasad merupakan satu lagi halangan sukar kerana ia boleh menangkap data sebelum ia sampai ke terowong VPN . Pendek kata, VPN menyembunyikan dan menyulitkan banyak aktiviti, tetapi ia tidak menyembunyikan setiap cap jari digital.

DoH dan VPN boleh digunakan serentak

Ya, ia boleh digabungkan, tetapi persediaan yang ideal bergantung pada cara peranti, pelayar dan aplikasi VPN mengendalikan DNS. Dalam kebanyakan kes, penyelesaian paling mudah adalah membiarkan VPN mengendalikan DNS . Aplikasi yang baik harus menghantar pertanyaan DNS melalui terowong yang disulitkan supaya ISP anda tidak menerimanya secara langsung. Dengan cara ini, anda mendapat privasi DNS sebagai sebahagian daripada sambungan VPN tanpa perlu melaraskan tetapan pelayar anda secara berasingan.

Masalah timbul apabila pelayar menggunakan konfigurasi Domain Authority (DoH) sendiri semasa VPN cuba mengurus DNS pada peringkat sistem. Tiada apa yang mungkin rosak, tetapi kekeliruan memang berlaku : anda mungkin fikir semua pertanyaan melalui VPN, tetapi pada hakikatnya, pelayar menghantar sebahagiannya sendiri ke penyelesai yang berbeza. Di sinilah ujian kebocoran DNS berguna. Jika, selepas menyambung ke VPN, anda melihat pelayan DNS ISP anda, sesuatu tidak berfungsi seperti yang dijangkakan; jika anda melihat pelayan yang berkaitan dengan VPN, konfigurasi tersebut berkemungkinan besar berfungsi dengan betul.

Bilakah DoH mencukupi dan bilakah VPN digalakkan?

DoH boleh mencukupi apabila kebimbangan utama anda adalah privasi asas pertanyaan DNS dalam pelayar anda. Pada rangkaian rumah yang dipercayai, mendayakan DNS Selamat mengurangkan pendedahan teks biasa tanpa memerlukan anda menukar lokasi anda atau mengamankan semua aplikasi anda . Ia juga berguna pada rangkaian yang mana penapisan atau manipulasi DNS menjadi kebimbangan, kerana perjalanan melalui HTTPS menjadikannya lebih sukar untuk diperiksa atau diubah suai dengan mudah. ​​Ini tidak bermakna ia memintas semua sekatan atau kalis penapisan, tetapi ia merupakan peningkatan yang ketara berbanding DNS yang tidak disulitkan. Tambahan pula, ia ringan: anda tidak perlu memilih pelayan VPN atau mengubah penghalaan anda dengan ketara, dan anda biasanya tidak akan melihat kesan yang ketara terhadap kelajuan.

VPN paling sesuai apabila anda mahukan perlindungan seluruh peranti, bukan sekadar carian DNS. Ini termasuk lapangan terbang, hotel, sekolah, ruang kerja bersama, kafe dan penginapan sewa . Pada rangkaian kongsi, anda tidak tahu siapa yang mengawal penghala, siapa lagi yang disambungkan atau sama ada seseorang cuba memintas trafik. VPN juga membantu apabila anda tidak mahu ISP anda membina profil corak penyemakan imbas anda: walaupun HTTPS melindungi kandungan halaman, metadata rangkaian masih boleh mendedahkan corak yang berguna. Melancong adalah satu lagi contoh yang jelas: VPN boleh menjadikan sambungan anda lebih konsisten, melindungi anda pada rangkaian yang tidak dikenali dan menjadikan laman web melihat lokasi pelayan VPN dan bukannya sambungan tempatan sementara anda.

Butiran teknikal API DoH DNS Awam Google

Google Public DNS menawarkan dua API DoH yang berbeza. Satu direka bentuk untuk RFC 8484 dan menerima permintaan GET dan POST di https://dns.google/dns-query; yang satu lagi ialah API JSON yang hanya menyokong permintaan GET di https://dns.google/resolve . Terdapat juga antara muka web di https://dns.google/ yang memaparkan hasil JSON dalam pelayar, tetapi ia tidak melaksanakan API penuh. Antara muka ini tidak boleh dikelirukan dengan URL API atau dengan https://dns.google/query. Perkhidmatan ini tidak menyokong URL HTTP yang tidak selamat dan DoH juga disokong oleh perkhidmatan DNS64 awam Google, walaupun dalam kes itu, hanya IPv6 yang disokong. Dokumentasi pengangkutan selamat Google termasuk contoh curl dan butiran tentang TLS, DoT dan DoH.

Kaedah HTTP yang tersedia

Kaedah GET boleh mengurangkan kependaman kerana ia menyimpan cache dengan lebih berkesan. Permintaan GET RFC 8484 mesti memasukkan parameter `?dns=` dengan mesej DNS yang dikodkan Base64Url , dan ia merupakan satu-satunya kaedah yang disokong oleh API JSON. Kaedah POST juga hanya tersedia dalam RFC 8484 dan menggunakan mesej DNS binari dengan `application/dns-message` dalam kedua-dua badan permintaan dan respons. Kaedah HEAD pada masa ini tidak disokong dan mengembalikan ralat Permintaan Buruk 400. Kaedah lain mengembalikan ralat 501 Tidak Dilaksanakan.

Kod status dan ralat

API mengembalikan beberapa kod HTTP yang perlu diketahui. OK 200 menunjukkan bahawa penghuraian HTTP dan komunikasi dengan penyelesai DNS berjaya ; badan respons boleh menjadi respons DNS binari atau JSON bergantung pada titik akhir, pengepala Terima dan parameter GET. Nota: ralat HTTP juga boleh menjadi kegagalan DNS, jadi adalah dinasihatkan untuk menyemak kod respons DNS, contohnya, medan "Status" JSON, untuk ralat seperti SERVFAIL, FORMERR, REFUSED atau NOTIMP.

• 301 Dipindahkan Secara Tetap: Klien mesti mencuba semula permintaan pada URL yang dinyatakan dalam Lokasi. Jika permintaan asal ialah POST, ia hanya perlu mencuba semula dengan GET jika URL baharu menentukan parameter DNS; jika tidak, ia mesti diulang dengan POST. Kod status 302, 307 dan 308 juga mungkin muncul dan klien DoH mesti mengendalikan keempat-empatnya. Kod status 301 dan 308 kekal boleh disimpan dalam cache selama-lamanya. Permintaan POST yang menerima kod status 307 atau 308 mesti sentiasa dicuba semula dengan POST.
• Permintaan Buruk 400: Masalah menghuraikan parameter GET atau mesej permintaan DNS yang tidak sah. Kebanyakan mesej DNS yang tidak sah menerima OK 200 dengan FORMERR, tetapi ralat HTTP berlaku untuk mesej yang tidak boleh dibaca tanpa bahagian Soalan, dengan kod QR yang menunjukkan respons atau dengan kombinasi kod yang tidak masuk akal.
• 413 Muatan Terlalu Besar: Isi kandungan permintaan POST RFC 8484 melebihi saiz mesej maksimum iaitu 512 bait.
• 414 URI Terlalu Panjang: Pengepala pertanyaan GET terlalu besar atau parameter dns melebihi 512 bait.
• 415 Jenis Media Tidak Disokong: Badan POST tidak mempunyai pengepala jenis kandungan application/dns-message.
• 429 Terlalu Banyak Permintaan: Terlalu banyak permintaan telah dihantar dalam tempoh tertentu. Klien mesti menunggu sehingga masa yang dinyatakan dalam pengepala Cuba Semula-Selepas.
• Ralat Pelayan Dalaman 500: Ralat dalaman dalam perkhidmatan DoH.
• 501 Tidak Dilaksanakan: Hanya GET dan POST dilaksanakan; selebihnya mengembalikan ralat ini.
• 502 Gerbang Buruk: Perkhidmatan DoH tidak dapat berkomunikasi dengan penyelesai DNS Awam Google. Mencuba alamat lain mungkin berkesan, tetapi pelan sandaran yang lebih berkesan adalah dengan mencuba perkhidmatan DoH lain atau bertukar kepada DNS tradisional menggunakan UDP atau TCP di 8.8.8.8.

Amalan terbaik untuk privasi dan prestasi

Pembangun aplikasi DoH harus mengehadkan pengepala HTTP. Pengepala seperti Cookie, User-Agent dan Accept-Language boleh mendedahkan maklumat tentang pelaksanaan klien dan menyumbang kepada penyahanoniman . Adalah disyorkan untuk menghantar hanya pengepala yang diperlukan untuk DoH: Host, Content-Type (untuk permintaan POST) dan, jika perlu, Accept. Pengepala User-Agent harus disertakan dalam versi pembangunan atau ujian. Adalah juga dinasihatkan untuk menggunakan pilihan padding EDNS untuk memendekkan pertanyaan kepada panjang biasa dan menjadikan analisis trafik lebih sukar. Padding HTTP/2 adalah mungkin, tetapi tidak seperti padding EDNS, ia tidak menjana padding dalam respons pelayan DoH.

Kaedah POST dalam RFC 8484 hanya boleh digunakan dalam aplikasi sensitif privasi atau mod pelayar. Menggunakan POST mengurangkan kapasiti cache dan boleh meningkatkan kependaman, jadi ia secara amnya tidak digalakkan . Walau bagaimanapun, mengurangkan saiz cache mungkin dinasihatkan untuk aplikasi yang ingin mencegah serangan penyegerakan aplikasi web yang bertujuan untuk menemui domain yang baru-baru ini dilawati pengguna. Pendekatan HTTPS juga mempunyai kelebihan praktikal: API HTTPS tersedia dan disokong secara meluas, memudahkan pelaksanaan; perkhidmatan HTTPS memberikan aplikasi web akses kepada semua jenis rekod DNS, mengelakkan batasan API pelayar atau sistem pengendalian yang biasanya terhad kepada carian hos-ke-alamat; dan klien yang melaksanakan HTTPS melalui UDP dengan QUIC boleh mengelakkan isu seperti penyekatan kepala baris yang berlaku dengan TCP. Jika anda menghadapi pepijat atau ingin meminta ciri baharu, anda harus melaporkan isu berkaitan DoH melalui saluran biasa.

Soalan lazim tentang DoH dan VPN

Salah satu soalan yang paling kerap ditanya ialah sama ada masuk akal untuk menggunakan DoH apabila sudah menggunakan VPN. Ia mungkin, tetapi pendekatan yang paling praktikal biasanya adalah membiarkan VPN mengendalikan DNS dan mengesahkan dengan ujian kebocoran bahawa pertanyaan melalui saluran yang betul. Jika pelayar menghantar pertanyaannya sendiri ke satu arah dan VPN ke arah yang lain, anda mungkin akan mendapat kejutan yang tidak menyenangkan.

Satu lagi soalan biasa ialah sama ada DoH menghalang pembekal internet anda daripada melihat laman web yang anda lawati. DoH menyembunyikan pertanyaan DNS daripada ramai pemerhati, tetapi ia tidak mengalih keluar semua metadata atau menyembunyikan alamat IP anda : ISP anda masih boleh melihat alamat IP yang anda sambungkan dan maklumat rangkaian lain. Untuk perlindungan yang lebih luas, anda memerlukan VPN atau gabungan berbilang lapisan privasi.

Perlu juga ditanya sama ada DomainHost (DoH) mencukupi pada Wi-Fi awam. Ia boleh membantu menghalang pengendali rangkaian daripada membaca pertanyaan DNS anda dengan mudah, tetapi ia tidak melindungi keseluruhan sambungan atau trafik semua aplikasi . Di lapangan terbang, hotel dan kafe, penggunaan VPN biasanya lebih komprehensif, terutamanya jika anda tidak tahu siapa yang mengawal penghala atau jika orang lain disambungkan.

Sistem Nama Domain (DoH) dan VPN bukanlah pesaing langsung, tetapi sebaliknya alat dengan keupayaan yang berbeza. DoH menyulitkan carian domain dan mengurangkan pendedahan bahagian proses tersebut; VPN menyulitkan laluan antara peranti anda dan pelayan dan mengubah alamat IP yang dilihat oleh destinasi . Kedua-duanya tidak menjadikan anda halimunan: akaun, kuki, cap jari pelayar, kebenaran aplikasi, perisian hasad dan sebarang data yang anda kongsikan secara langsung masih boleh mengenal pasti anda. Tetapi itu tidak menjadikannya tidak berguna. Ia hanya bermakna setiap satu mempunyai peranannya. DoH melindungi carian alamat; VPN melindungi lebih banyak laluan yang diambil oleh data anda.