DNS-over-HTTPS (DoH)

Google Public DNS menyediakan dua DoH API yang berbeda di endpoint berikut:

  • https://dns.google/dns-query – RFC 8484 (GET dan POST)
  • https://dns.google/resolve? – JSON API (GET)

Halaman Secure Transports Overview memiliki contoh command line curl untuk menggunakan API serta detail TLS dan fitur lain yang umum digunakan untuk DNS melalui TLS (DoT) dan DoH.

DoH juga didukung untuk layanan Google Public DNS64 khusus IPv6.

Google Public DNS tidak mendukung URL http: yang tidak aman untuk panggilan API.

Metode HTTP

GET
Menggunakan metode GET dapat mengurangi latensi, karena metode tersebut di-cache secara lebih efektif. Permintaan GET RFC 8484 harus memiliki parameter kueri ?dns= dengan pesan DNS berenkode Base64Url. Metode GET adalah satu-satunya metode yang didukung untuk JSON API.
POST
Metode POST hanya didukung untuk RFC 8484 API dan menggunakan pesan DNS biner dengan aplikasi/dns-message Content-Type dalam isi permintaan dan dalam respons HTTP DoH.
HEAD
HEAD saat ini tidak didukung dan menampilkan error 400 Bad Request.

Metode lain menampilkan error 501 Not Implemented.

Kode status HTTP

Google Public DNS DoH menampilkan kode status HTTP berikut:

Berhasil

200 OK
Penguraian HTTP dan komunikasi dengan resolver DNS berhasil, dan konten isi respons adalah respons DNS dalam encoding biner atau JSON, bergantung pada endpoint kuerinya, serta parameter GET dan header Accept.

Pengalihan

301 Dipindahkan Secara Permanen
Klien harus mencoba lagi di URL yang diberikan di header Location:. Jika kueri asli adalah permintaan POST, klien hanya boleh mencoba lagi dengan GET jika URL baru menentukan argumen parameter GET dns; jika tidak, klien harus mencoba lagi dengan POST.

Kode lain seperti 302 Found, 307 Temporary Redirect, atau Pengalihan Permanen 308 dapat digunakan di masa mendatang, dan klien DoH harus menangani keempat kode tersebut.

Respons dengan kode 301 dan 308 permanen harus di-cache tanpa batas waktu, dan jika memungkinkan, pengguna mungkin diminta untuk memperbarui konfigurasi awal mereka menggunakan URL baru.

Permintaan POST yang mendapatkan respons 307 atau 308 harus selalu dicoba lagi dengan POST.

Error

Respons error akan memiliki penjelasan tentang status HTTP di bagian isi, menggunakan HTML atau teks biasa.

400 Permintaan Buruk
Masalah saat menguraikan parameter GET, atau pesan permintaan DNS yang tidak valid. Untuk parameter GET yang buruk, isi HTTP harus menjelaskan error. Sebagian besar pesan DNS yang tidak valid mendapatkan 200 OK dengan FORMERR; error HTTP ditampilkan untuk pesan yang kacau balau tanpa bagian Pertanyaan, flag QR yang menunjukkan balasan, atau kombinasi flag tidak masuk akal lainnya dengan error penguraian DNS biner.
Payload 413 Terlalu Besar
Isi permintaan POST RFC 8484 melampaui ukuran pesan maksimum 512 byte.
URI 414 Terlalu Panjang
Header kueri GET terlalu besar atau parameter dns memiliki pesan DNS yang dienkode Base64Url yang melebihi ukuran pesan maksimum 512 byte.
Jenis Media 415 Tidak Didukung
Isi POST tidak memiliki header Content-Type application/dns-message.
429 Terlalu Banyak Permintaan
Klien telah mengirim terlalu banyak permintaan dalam jangka waktu tertentu. Klien harus berhenti mengirim permintaan hingga waktu yang ditentukan di header Retry-After (waktu relatif dalam detik).
500 Error Server Internal
Error DoH internal Google Public DNS.
501 Tidak Diterapkan
Hanya metode GET dan POST yang diterapkan, metode lain mendapatkan error ini.
502 Gateway Buruk
Layanan DoH tidak dapat menghubungi resolver Google Public DNS.

Dalam kasus respons 502, meskipun mencoba ulang alamat DNS Publik Google alternatif mungkin dapat membantu, respons penggantian yang lebih efektif adalah mencoba layanan DoH lain, atau beralih ke DNS UDP atau TCP tradisional di 8.8.8.8.

Manfaat DoH

Menggunakan HTTPS, bukan hanya enkripsi TLS, memiliki beberapa manfaat praktis:

  • API HTTPS yang tersedia secara luas dan didukung dengan baik akan menyederhanakan implementasi untuk Google Public DNS itu sendiri dan calon klien.
  • Layanan HTTPS memberi aplikasi web akses ke semua jenis data DNS, sehingga menghindari batasan API DNS OS dan browser yang ada, yang umumnya hanya mendukung pencarian host-ke-alamat.
  • Klien yang menerapkan dukungan HTTPS berbasis QUIC UDP dapat menghindari masalah seperti pemblokiran head-of-line yang dapat terjadi saat menggunakan transpor TCP.

Praktik Terbaik Privasi untuk Departemen Kesehatan

Developer aplikasi DoH harus mempertimbangkan praktik terbaik privasi yang diuraikan dalam RFC 8484 dan diperluas di bawah:

  • Membatasi penggunaan Header HTTP

    Header HTTP mengungkapkan informasi tentang implementasi DoH klien dan dapat digunakan untuk mendeanonimisasi klien. Header seperti Cookie, Agen Pengguna, dan Accept-Language adalah pelanggar terburuk, tetapi bahkan kumpulan header yang dikirim dapat terungkap. Untuk meminimalkan risiko ini, hanya kirim header HTTP yang diperlukan untuk DoH: Host, Content-Type (untuk POST), dan jika perlu, Accept. Agen Pengguna harus disertakan dalam setiap versi pengembangan atau pengujian.

  • Menggunakan opsi padding EDNS

    Ikuti panduan di RFC 8467 untuk penggunaan opsi padding EDNS guna menambahkan kueri DoH ke beberapa panjang umum untuk melindungi dari analisis traffic. Penggunaan padding HTTP/2 juga dapat dilakukan, tetapi tidak seperti padding EDNS, tidak akan menimbulkan padding pada respons dari server DoH.

  • Gunakan RFC 8484 POST hanya untuk aplikasi atau mode browser yang sensitif terhadap privasi

    Menggunakan kueri POST untuk DoH akan mengurangi kemampuan cache respons dan dapat meningkatkan latensi DNS, sehingga umumnya tidak direkomendasikan. Namun, mengurangi cache mungkin diinginkan untuk aplikasi yang sensitif terhadap privasi, dan dapat melindungi dari serangan waktu dari aplikasi web yang mencoba menentukan domain yang telah dikunjungi pengguna akhir-akhir ini.

Masalah

Untuk melaporkan bug atau meminta fitur baru, buka masalah untuk DoH.