Pertanyaan dan kapan ini berlaku
Pertanyaan ini muncul dalam wawancara jaringan, keamanan, backend, SRE, dan sales-engineering. Jawaban yang kuat memperlakukan DNS over HTTPS (DoH) sebagai batas protokol, bukan sekadar "DNS dengan sertifikat". DoH membawa kueri dan respons DNS di dalam pertukaran HTTPS. Transport ini menyembunyikan kueri dari pengamat jalur biasa (on-path observer) antara klien dan resolver DoH, tetapi resolver tetap menerimanya serta dapat mencatat (log) atau memfilternya. Pilihan ini bergantung pada siapa yang harus melihat DNS, kontrol kebijakan apa yang diperlukan, dan apakah klien dapat menjangkau resolver dengan andal.
Apa yang dievaluasi oleh pewawancara
- Apakah Anda dapat memisahkan semantik pesan DNS dari status HTTP dan perilaku transport.
- Apakah Anda menyatakan batasan privasi: enkripsi ke resolver yang dipilih bukanlah anonimitas.
- Apakah Anda memahami GET versus POST, tipe konten, perilaku cache, dan bootstrap.
- Apakah Anda membandingkan DoH, DoT, dan DNS biasa berdasarkan pemilik penerapan, observabilitas, latensi, dan kebijakan.
- Apakah Anda menentukan mekanisme fallback dan pengujian alih-alih mengklaim bahwa enkripsi secara otomatis meningkatkan setiap hasil.
Pertanyaan untuk diklarifikasi terlebih dahulu
Tanyakan siapa yang mengontrol klien dan resolver, apakah kebijakan pemfilteran atau audit perusahaan harus tetap dapat ditegakkan, apakah jaringan memblokir HTTPS keluar atau DNS UDP/TCP, dan apakah tujuannya adalah kerahasiaan dari jaringan lokal, akses API tingkat aplikasi, atau ketahanan terhadap manipulasi. Klarifikasi apakah browser, resolver sistem operasi, atau agen terkelola yang akan mengeluarkan kueri. Tanyakan juga tentang anggaran latensi, captive portal, nama split-horizon, validasi DNSSEC, retensi pencatatan log, dan fallback yang dapat diterima saat resolver yang dipilih tidak dapat dijangkau. Jawaban-jawaban ini dapat menentukan apakah lebih baik menggunakan resolver yang dikelola enterprise, klien DoH aplikasi, DoT, atau DNS biasa.
Kerangka jawaban 30 detik
DoH memetakan setiap pasangan kueri-respons DNS ke permintaan dan respons HTTPS, biasanya menggunakan format wire DNS dengan tipe media application/dns-message. Protokol ini mengenkripsi lompatan (hop) klien-ke-resolver dan dapat melintasi jaringan yang mengizinkan HTTPS, tetapi resolver tetap melihat kueri dan kebijakan mungkin memerlukan endpoint yang disetujui. GET ramah terhadap cache; POST menghindari penempatan kueri yang dienkode dalam URL dan lebih disukai untuk permintaan sensitif. Saya akan memilih DoH untuk kebutuhan privasi atau API yang eksplisit, membandingkannya dengan DoT ketika resolver terkelola dan pemisahan transport yang jelas diperlukan, serta menentukan bootstrap, caching, perilaku split-DNS, fallback, minimalisasi telemetri, dan pengujian sebelum peluncuran.
Pembahasan mendalam langkah demi langkah
1. Memetakan lapisan protokol
Pertanyaan DNS tetap berupa pesan DNS. RFC 8484 memetakan satu pasangan kueri-respons ke satu pertukaran HTTP dan menetapkan application/dns-message untuk representasi binernya. HTTPS menyediakan kerahasiaan dan integritas TLS untuk koneksi, sedangkan HTTP menyediakan metode, kode status, penggunaan ulang koneksi, dan kontrol cache. NXDOMAIN atau SERVFAIL DNS tetap merupakan kode respons DNS; kode tersebut dapat tiba di dalam respons HTTP 2xx. HTTP 4xx atau 5xx berarti pertukaran HTTP gagal dan tidak berisi jawaban DNS asli, sehingga klien harus menerapkan penanganan kegagalan HTTP secara terpisah.
2. Memilih GET, POST, dan caching secara cermat
RFC 8484 mewajibkan server DoH untuk mendukung GET dan POST untuk tipe media RFC tersebut. GET menempatkan pesan DNS yang dienkode dengan Base64URL dalam parameter kueri dns, yang dapat meningkatkan penggunaan ulang cache HTTP biasa tetapi juga membuat kueri terlihat pada log URL, perantara, dan riwayat browser kecuali area tersebut dikontrol. POST membawa pesan biner di dalam body beserta tipe kontennya. Untuk nama-nama sensitif, prioritaskan POST atau jalur GET yang dikelola dengan hati-hati, minimalkan header, dan pastikan cache tidak membuat masa berlaku (freshness) baru yang bertentangan dengan kebijakan TTL DNS. Google menyediakan endpoint RFC 8484 dan endpoint JSON terpisah; keduanya merupakan kontrak API yang berbeda.
3. Menentukan batasan privasi dan kebijakan
DoH mencegah pengamat lokal membaca paket DNS plaintext pada hop yang dilindungi, tetapi resolver masih dapat melihat kueri, metadata klien, waktu, dan konteks kebijakan yang dipilih. HTTPS tidak memvalidasi jawaban DNS itu sendiri; perilaku DNSSEC pada resolver dan model kepercayaan klien tetap relevan. Enterprise yang terkelola mungkin memerlukan resolver yang disetujui, pemfilteran kategori, zona split-horizon, kontrol retensi, dan bukti audit. Mengizinkan setiap aplikasi memilih resolver publik sembarangan dapat melewati kontrol tersebut, meskipun lalu lintasnya dienkripsi.
4. Menangani bootstrap, kegagalan, dan fallback
Klien harus menemukan alamat server DoH sebelum dapat meresolusi server tersebut melalui layanan yang sama. Bootstrap dapat menggunakan IP yang dikonfigurasi, resolver tepercaya, atau saluran provisi lainnya; setiap jalur memerlukan validasi dan rotasi sertifikat. Perlakukan kesalahan HTTP, kesalahan respons DNS, batas waktu habis (timeout), intersepsi captive portal, dan penolakan kebijakan sebagai hasil yang berbeda. Pemadaman resolver dapat dialihkan (fallback) ke transport yang disetujui, tetapi fallback diam-diam ke resolver yang tidak tepercaya dapat melanggar privasi atau kebijakan enterprise. Catat resolver dan transport mana yang merespons tanpa menyimpan konten kueri lengkap secara default.
5. Membandingkan pilihan penerapan dan memverifikasinya
DNS tradisional sederhana dan terlihat oleh operator jaringan, tetapi transport plaintext mengekspos kueri di sepanjang jalur. DoT mengenkripsi DNS dalam layanan TLS khusus dan sering kali mudah diterapkan untuk resolver sistem operasi. DoH menggabungkan DNS ke dalam HTTPS dan dapat memanfaatkan infrastruktur HTTP yang ada, API browser, serta keterjangkauan port 443, dengan konsekuensi kompleksitas kebijakan lapisan HTTP dan observabilitas yang lebih tinggi. Verifikasi pilihan tersebut dengan tangkapan paket dari pengujian terkontrol, log status DNS dan HTTP di sisi resolver, perilaku cache hit dan TTL, kasus split-DNS, kegagalan DNSSEC, captive portal, pemadaman resolver, rotasi sertifikat, dan kebijakan fallback. Ukur lookup p50/p95/p99, klasifikasi kegagalan, dan kebocoran kueri, bukan hanya latensi rata-rata.
Contoh jawaban yang kuat
DoH adalah protokol yang menempatkan kueri dan respons DNS di dalam pertukaran HTTPS. Pesan DNS mempertahankan makna normalnya; HTTPS melindungi hop dari klien ke resolver yang dipilih, dan HTTP menyediakan metode, kode status, penggunaan ulang koneksi, serta perilaku cache. Oleh karena itu, NXDOMAIN DNS dapat dibawa dalam respons HTTP 2xx, sedangkan HTTP 5xx adalah kegagalan transport atau layanan tanpa jawaban DNS. Saya akan menggunakan DoH ketika saya membutuhkan akses tingkat aplikasi atau kerahasiaan dari jaringan lokal dan dapat menentukan resolver yang disetujui. Saya akan memilih POST untuk nama-nama sensitif, meminimalkan header, dan menjaga agar kebijakan resolver, penanganan DNSSEC, zona split-horizon, dan retensi tetap eksplisit. Bootstrap harus terjadi melalui resolusi yang dikonfigurasi atau tepercaya, dan fallback harus tetap berada dalam kebijakan yang disetujui. Sebelum peluncuran, saya akan menguji semantik cache dan TTL, paparan pencatatan log URL untuk GET, captive portal, rotasi sertifikat, pemadaman resolver, kesalahan DNSSEC, dan apakah paket atau log mengungkap kueri di luar resolver yang dimaksudkan.
Kesalahan umum
- Mengatakan "HTTPS membuat DNS menjadi anonim" → resolver yang dipilih tetap melihat kueri dan metadata → sebutkan batas perlindungan hop dan batas kepercayaan resolver secara tepat.
- Memperlakukan
NXDOMAINDNS sebagai kesalahan HTTP → kode respons DNS dapat berada di dalam HTTP 2xx → parsing lapisan status HTTP dan DNS secara terpisah. - Memilih GET untuk data rahasia tanpa membahas log URL → kueri yang dienkode dapat masuk ke riwayat atau log perantara → gunakan POST atau kebijakan cache dan logging yang terkontrol.
- Mengklaim bahwa DoH selalu lebih baik daripada DoT → pemilik penerapan, kebijakan, keterjangkauan, dan observabilitas berbeda → bandingkan lingkungan konkretnya terlebih dahulu.
- Melakukan bootstrap hostname DoH melalui resolver yang sama yang belum teresolusi → klien mengalami dependensi sirkular → sediakan alamat IP langsung atau jalur bootstrap tepercaya.
- Beralih ke resolver publik mana pun setelah timeout → kerahasiaan dan pemfilteran enterprise dapat terlewati → batasi fallback hanya ke transport dan endpoint yang disetujui.
- Hanya mengukur latensi rata-rata → pemadaman, cache miss, dan kebocoran tetap tersembunyi → lakukan segmentasi p95/p99, kelas kegagalan, perilaku TTL, dan identitas resolver.
Pertanyaan lanjutan dan jawaban
Apakah DoH memvalidasi bahwa jawaban DNS itu autentik?
Tidak. TLS mengautentikasi server HTTPS yang dipilih oleh klien. Keaslian jawaban DNS bergantung pada perilaku validasi resolver dan model kepercayaan klien terhadap resolver tersebut; DNSSEC dan HTTPS adalah dua hal yang terpisah. Rancangan arsitektur harus mencatat apakah validasi diperlukan dan bagaimana kegagalan validasi dimunculkan ke permukaan.
Mengapa HTTP 200 dapat berisi pencarian DNS yang gagal?
Pertukaran HTTP berhasil dan mengangkut pesan DNS yang valid. Pesan DNS tersebut mungkin membawa NXDOMAIN, SERVFAIL, atau kode respons DNS lainnya. Klien harus mengurai kedua lapisan dan menghindari mencoba ulang (retry) respons negatif DNS yang valid seolah-olah permintaan HTTP tersebut gagal.
Kapan DoT menjadi pilihan yang lebih baik?
DoT sangat cocok ketika sistem operasi atau resolver enterprise mengontrol transport, menginginkan port DNS khusus dan kebijakan jaringan yang sederhana, serta tidak memerlukan API HTTP yang menghadap browser. DoH lebih disukai ketika keterjangkauan HTTPS yang ada atau API aplikasi menjadi persyaratan utama. Keputusan ini mengikuti kepemilikan dan kebijakan, bukan aturan umum bahwa "terenkripsi selalu lebih baik".
Apa yang harus terjadi jika resolver DoH tidak dapat dijangkau pada captive portal?
Deteksi portal atau kegagalan TLS/HTTP yang berulang, hentikan amplifikasi percobaan ulang, dan ikuti kebijakan yang dikonfigurasi: gunakan fallback yang disetujui, jeda resolusi dengan jalur pemulihan yang terlihat oleh pengguna, atau gunakan sementara DNS yang disediakan jaringan hanya jika kebijakan mengizinkannya. Uji hal ini sebelum peluncuran karena fallback tanpa kendali dapat membocorkan setiap kueri.