Soalan dan bila ia terpakai
Soalan ini kerap ditanya dalam temuduga rangkaian, keselamatan, backend, SRE, dan kejuruteraan jualan. Jawapan yang mantap menganggap DNS over HTTPS (DoH) sebagai satu sempadan protokol, bukannya sekadar "DNS dengan sijil". DoH membawa pertanyaan dan respons DNS di dalam pertukaran HTTPS. Pengangkutan ini menyembunyikan pertanyaan daripada pemerhati laluan biasa (on-path observer) antara klien dan penyelesai (resolver) DoH, tetapi resolver masih menerimanya dan boleh merekodkan log atau menapisnya. Pilihan ini bergantung pada siapa yang perlu melihat DNS, kawalan dasar yang diperlukan, dan sama ada klien boleh mencapai resolver dengan andal.
Perkara yang dinilai oleh penemuduga
- Sama ada anda boleh memisahkan semantik mesej DNS daripada status HTTP dan tingkah laku pengangkutan.
- Sama ada anda menyatakan sempadan privasi: penyulitan ke resolver yang dipilih bukanlah kerahsiaan tanpa nama (anonymity).
- Sama ada anda memahami GET berbanding POST, jenis kandungan, tingkah laku cache, dan bootstrap.
- Sama ada anda membandingkan DoH, DoT, dan DNS biasa mengikut pemilik pelaksanaan, kebolehlihatan (observability), pendaman (latency), dan dasar.
- Sama ada anda mentakrifkan sandaran (fallback) dan ujian dan bukannya mendakwa bahawa penyulitan secara automatik menambah baik setiap hasil.
Soalan untuk dijelaskan terlebih dahulu
Tanya siapa yang mengawal klien dan resolver, sama ada dasar penapisan atau audit korporat mesti kekal dikuatkuasakan, sama ada rangkaian menyekat HTTPS keluar atau DNS UDP/TCP, dan sama ada matlamatnya adalah kerahsiaan daripada rangkaian tempatan, akses API peringkat aplikasi, atau daya tahan terhadap pengubahan data. Jelaskan sama ada pelayar web, resolver sistem pengendalian, atau ejen terurus yang akan mengeluarkan pertanyaan. Tanya juga tentang bajet pendaman, portal tawanan (captive portals), nama split-horizon, pengesahan DNSSEC, pengekalan log, dan fallback yang boleh diterima apabila resolver yang dipilih tidak dapat dicapai. Jawapan ini boleh menentukan kesesuaian antara resolver terurus perusahaan, klien DoH aplikasi, DoT, atau DNS biasa.
Rangka jawapan 30 saat
DoH memetakan setiap pasangan pertanyaan-respons DNS kepada permintaan dan respons HTTPS, biasanya menggunakan format wayar DNS dengan jenis media application/dns-message. Ia menyulitkan lompatan (hop) klien-ke-resolver dan boleh merentasi rangkaian yang membenarkan HTTPS, namun resolver masih melihat pertanyaan tersebut dan dasar mungkin memerlukan titik akhir yang diluluskan. GET boleh memudahkan cache; POST mengelakkan meletakkan pertanyaan yang dikodkan dalam URL dan lebih diutamakan untuk permintaan sensitif. Saya akan memilih DoH untuk keperluan privasi atau API yang jelas, membandingkannya dengan DoT apabila resolver terurus dan pemisahan pengangkutan yang jelas diutamakan, serta mentakrifkan bootstrap, caching, tingkah laku split-DNS, fallback, peminimuman telemetri, dan ujian sebelum pelaksanaan.
Analisis mendalam langkah demi langkah
1. Memetakan lapisan protokol
Pertanyaan DNS tetap merupakan mesej DNS. RFC 8484 memetakan satu pasangan pertanyaan-respons kepada satu pertukaran HTTP dan mentakrifkan application/dns-message untuk perwakilan binari. HTTPS membekalkan kerahsiaan dan integriti TLS untuk sambungan, manakala HTTP membekalkan kaedah, kod status, penggunaan semula sambungan, dan kawalan cache. NXDOMAIN atau SERVFAIL DNS masih merupakan kod respons DNS; ia boleh tiba di dalam respons HTTP 2xx. HTTP 4xx atau 5xx bermakna pertukaran HTTP gagal dan tidak mengandungi jawapan DNS yang asal, jadi klien mesti mengendalikan kegagalan HTTP secara berasingan.
2. Memilih GET, POST, dan caching secara wajar
RFC 8484 memerlukan pelayan DoH menyokong kedua-dua GET dan POST untuk jenis media RFC. GET meletakkan mesej DNS yang dikodkan dengan Base64URL dalam parameter pertanyaan dns, yang boleh meningkatkan penggunaan semula cache HTTP biasa tetapi juga menjadikan pertanyaan kelihatan pada log URL, perantara, dan sejarah pelayar melainkan permukaan tersebut dikawal. POST membawa mesej binari dalam badan permintaan bersama jenis kandungan. Untuk nama sensitif, utamakan POST atau laluan GET yang dikawal rapi, minimumkan pengepala, dan pastikan cache tidak menghasilkan kesegaran palsu yang bercanggah dengan dasar TTL DNS. Google menyediakan titik akhir RFC 8484 dan titik akhir JSON yang berasingan; kedua-duanya adalah kontrak API yang berbeza.
3. Mentakrifkan sempadan privasi dan dasar
DoH menghalang pemerhati tempatan daripada membaca paket DNS teks biasa pada hop yang dilindungi, tetapi resolver masih boleh melihat pertanyaan, metadata klien, pemasaan, dan konteks dasar yang dipilih. HTTPS tidak mengesahkan jawapan DNS itu sendiri; tingkah laku DNSSEC resolver dan model kepercayaan klien kekal relevan. Perusahaan terurus mungkin memerlukan resolver yang diluluskan, penapisan kategori, zon split-horizon, kawalan pengekalan, dan bukti audit. Membenarkan setiap aplikasi memilih resolver awam sewenang-wenangnya boleh memintas kawalan tersebut, walaupun lalu lintas disulitkan.
4. Mengendalikan bootstrap, kegagalan, dan fallback
Klien mesti menemui alamat pelayan DoH sebelum ia boleh menyelesaikan pelayan tersebut melalui perkhidmatan yang sama. Bootstrap boleh menggunakan IP yang dikonfigurasikan, resolver yang dipercayai, atau saluran penyediaan lain; setiap laluan memerlukan pengesahan dan giliran sijil. Anggap ralat HTTP, ralat respons DNS, tamat masa, pemintasan captive portal, dan penafian dasar sebagai hasil yang berbeza. Gangguan resolver boleh beralih kepada pengangkutan yang diluluskan, tetapi fallback senyap ke resolver yang tidak dipercayai boleh melanggar privasi atau dasar perusahaan. Rekodkan resolver dan pengangkutan mana yang menjawab tanpa mengekalkan kandungan pertanyaan penuh secara lalai.
5. Membandingkan pilihan pelaksanaan dan mengesahkannya
DNS tradisional adalah mudah dan boleh dilihat oleh pengendali rangkaian, tetapi pengangkutan teks biasa mendedahkan pertanyaan sepanjang laluan. DoT menyulitkan DNS dalam perkhidmatan TLS khusus dan sering kali mudah untuk resolver sistem pengendalian. DoH menggabungkan DNS ke dalam HTTPS dan boleh menggunakan infrastruktur HTTP sedia ada, API pelayar, dan kebolehcapaian port 443, dengan kos dasar lapisan HTTP dan kerumitan kebolehlihatan yang lebih tinggi. Sahkan pilihan tersebut dengan tangkapan paket daripada ujian terkawal, log status DNS dan HTTP di pihak resolver, tingkah laku hit cache dan TTL, kes split-DNS, kegagalan DNSSEC, captive portal, gangguan resolver, giliran sijil, dan dasar fallback. Ukur carian p50/p95/p99, kelas kegagalan, dan kebocoran pertanyaan dan bukannya sekadar pendaman purata.
Contoh jawapan yang mantap
DoH ialah protokol yang meletakkan pertanyaan dan respons DNS di dalam pertukaran HTTPS. Mesej DNS mengekalkan maksud biasanya; HTTPS melindungi hop antara klien ke resolver yang dipilih, dan HTTP membekalkan kaedah, kod status, penggunaan semula sambungan, dan tingkah laku cache. Oleh itu, NXDOMAIN DNS boleh dibawa dalam respons HTTP 2xx, manakala HTTP 5xx ialah kegagalan pengangkutan atau perkhidmatan tanpa jawapan DNS. Saya akan menggunakan DoH apabila saya memerlukan akses peringkat aplikasi atau kerahsiaan daripada rangkaian tempatan dan boleh menetapkan resolver yang diluluskan. Saya lebih suka POST untuk nama sensitif, meminimumkan pengepala, dan memastikan dasar resolver, pengendalian DNSSEC, zon split-horizon, dan pengekalan kekal eksplisit. Bootstrap mesti berlaku melalui penyelesaian yang dikonfigurasikan atau dipercayai, dan fallback mesti kekal dalam dasar yang diluluskan. Sebelum pelancaran, saya akan menguji semantik cache dan TTL, pendedahan log URL untuk GET, captive portal, giliran sijil, gangguan resolver, ralat DNSSEC, dan sama ada paket atau log mendedahkan pertanyaan di luar resolver yang dimaksudkan.
Kesilapan biasa
- Mengatakan "HTTPS menjadikan DNS tanpa nama" → resolver yang dipilih masih melihat pertanyaan dan metadata → nyatakan hop terlindung yang tepat dan sempadan kepercayaan resolver.
- Menganggap
NXDOMAINDNS sebagai ralat HTTP → kod respons DNS boleh berada di dalam HTTP 2xx → huraikan lapisan status HTTP dan DNS secara berasingan. - Memilih GET untuk rahsia tanpa membincangkan log URL → pertanyaan yang dikodkan boleh memasuki sejarah atau log perantara → gunakan POST atau dasar cache dan pengelogan yang terkawal.
- Mendakwa DoH sentiasa mengatasi DoT → pemilik pelaksanaan, dasar, kebolehcapaian, dan kebolehlihatan berbeza → bandingkan persekitaran konkrit terlebih dahulu.
- Membuat bootstrap nama hos DoH melalui resolver yang sama yang belum diselesaikan → klien mengalami kebergantungan pekeliling (circular dependency) → sediakan alamat IP atau laluan bootstrap yang dipercayai.
- Beralih ke mana-mana resolver awam selepas tamat masa → kerahsiaan dan penapisan perusahaan mungkin dipintas → hadkan fallback kepada pengangkutan dan titik akhir yang diluluskan sahaja.
- Mengukur purata pendaman sahaja → gangguan, terlepas cache (cache misses), dan kebocoran kekal tersembunyi → pecahkan p95/p99, kelas kegagalan, tingkah laku TTL, dan identiti resolver.
Soalan susulan dan jawapan
Adakah DoH mengesahkan bahawa jawapan DNS adalah sahih?
Tidak. TLS mengesahkan pelayan HTTPS yang dipilih oleh klien. Kesahihan jawapan DNS bergantung pada tingkah laku pengesahan resolver dan kepercayaan klien terhadap resolver tersebut; DNSSEC dan HTTPS adalah perkara yang berasingan. Reka bentuk sistem harus merekodkan sama ada pengesahan diperlukan dan bagaimana kegagalan pengesahan dipaparkan.
Mengapakah HTTP 200 boleh mengandungi carian DNS yang gagal?
Pertukaran HTTP telah berjaya dan membawa mesej DNS yang sah. Mesej DNS tersebut mungkin membawa NXDOMAIN, SERVFAIL, atau kod respons DNS yang lain. Klien mesti menghuraikan kedua-dua lapisan dan mengelak daripada mencuba semula jawapan negatif DNS yang sah seolah-olah permintaan HTTP itu gagal.
Bilakah DoT merupakan pilihan yang lebih baik?
DoT adalah pilihan yang sangat sesuai apabila sistem pengendalian atau resolver perusahaan mengawal pengangkutan, mahukan port DNS khusus serta dasar rangkaian yang ringkas, dan tidak memerlukan API HTTP untuk pelayar web. DoH lebih diutamakan apabila kebolehcapaian HTTPS sedia ada atau API aplikasi menjadi keperluan utama. Keputusan bergantung pada pemilikan dan dasar, bukannya peraturan umum bahawa "tersulit sentiasa lebih baik".
Apakah yang patut berlaku apabila resolver DoH tidak dapat dicapai pada captive portal?
Kesan portal atau kegagalan TLS/HTTP yang berulang, hentikan amplifikasi percubaan semula, dan ikuti dasar yang dikonfigurasikan: gunakan fallback yang diluluskan, jedakan resolusi dengan laluan pemulihan yang dapat dilihat oleh pengguna, atau gunakan DNS yang disediakan oleh rangkaian secara sementara hanya jika dasar membenarkannya. Uji perkara ini sebelum pelaksanaan kerana fallback tanpa kawalan boleh membocorkan setiap pertanyaan.