Google Public DNS cung cấp hai DoH API riêng biệt tại các điểm cuối sau:
Trang Tổng quan về phương thức truyền tải an toàn có curl ví dụ về dòng lệnh để sử dụng cả API cũng như thông tin chi tiết về TLS và các tính năng khác phổ biến cho cả DNS qua TLS (DoT) và DoH.
DoH cũng được hỗ trợ cho dịch vụ Google Public DNS64 chỉ dành cho IPv6.
Google Public DNS không hỗ trợ các URL http: không an toàn cho các lệnh gọi API.
Các phương thức HTTP
- GET
- Phương thức GET có thể giảm độ trễ vì phương thức này được lưu vào bộ nhớ đệm hiệu quả hơn.
Các yêu cầu GET RFC 8484 phải có tham số truy vấn
?dns=với thông báo DNS được mã hoá Base64Url. Phương thức GET là phương thức duy nhất được hỗ trợ cho API JSON. - POST
- Phương thức POST chỉ được hỗ trợ cho API RFC 8484 và sử dụng thông báo DNS nhị phân có chứa ứng dụng Content-Type/thông báo dns- trong nội dung yêu cầu và trong phản hồi HTTP DoH.
- HEAD
- HEAD hiện không được hỗ trợ và trả về lỗi 400 Bad Request.
Các phương thức khác trả về lỗi 501 Not Implementationed (Chưa triển khai).
Mã trạng thái HTTP
Google Public DNS DoH trả về mã trạng thái HTTP sau đây:
Thành công
- 200 OK
- Phân tích cú pháp và giao tiếp HTTP với trình phân giải DNS đã thành công. Nội dung nội dung phản hồi là một phản hồi DNS ở dạng mã hoá nhị phân hoặc JSON, tuỳ thuộc vào điểm cuối truy vấn, tiêu đề Chấp nhận và tham số GET.
Chuyển hướng
- 301 Đã di chuyển vĩnh viễn
- Ứng dụng nên thử lại tại URL được cung cấp trong tiêu đề
Location:. Nếu truy vấn ban đầu là yêu cầu POST, thì ứng dụng chỉ nên thử lại bằng GET nếu URL mới chỉ định đối số tham số GETdns; nếu không thì ứng dụng nên thử lại bằng yêu cầu POST.
Trong tương lai, có thể sử dụng các mã khác như 302 Found, 307 Temporary Redirect hoặc 308 Permanent Redirect và ứng dụng DoH sẽ xử lý cả 4 mã.
Các phản hồi có mã 301 và 308 cố định phải được lưu vào bộ nhớ đệm vô thời hạn và nếu thích hợp, người dùng có thể được nhắc cập nhật cấu hình ban đầu bằng URL mới.
Đối với những yêu cầu POST và nhận được phản hồi 307 hoặc 308, bạn nên thử lại bằng phương thức POST.
Lỗi
Phản hồi lỗi sẽ có phần giải thích về trạng thái HTTP trong phần nội dung, bằng cách sử dụng HTML hoặc văn bản thuần tuý.
- 400 Yêu cầu không hợp lệ
- Sự cố khi phân tích cú pháp các tham số GET hoặc thông báo yêu cầu DNS không hợp lệ. Đối với các tham số GET không hợp lệ, phần nội dung HTTP sẽ giải thích lỗi. Hầu hết thông báo DNS không hợp lệ đều nhận được giá trị 200 OK với FORMERR; lỗi HTTP được trả về đối với các thông báo bị cắt xén không có phần Câu hỏi, một cờ QR biểu thị câu trả lời hoặc các cách kết hợp cờ vô nghĩa khác mắc lỗi phân tích cú pháp DNS nhị phân.
- 413 Tải trọng quá lớn
- Nội dung yêu cầu POST RFC 8484 vượt quá kích thước thư tối đa 512 byte.
- URI 414 quá dài
- Tiêu đề truy vấn GET quá lớn hoặc tham số
dnscó thông báo DNS được mã hoá Base64Url vượt quá kích thước thông báo tối đa 512 byte. - 415 Loại nội dung nghe nhìn không được hỗ trợ
- Nội dung POST không có tiêu đề Content-Type
application/dns-message. - 429 Quá nhiều yêu cầu
- Khách hàng đã gửi quá nhiều yêu cầu trong một khoảng thời gian nhất định. Ứng dụng sẽ ngừng gửi yêu cầu cho đến thời điểm đã chỉ định trong tiêu đề Retry-After (thời gian tương đối tính bằng giây).
- Lỗi máy chủ nội bộ 500
- Lỗi DoH nội bộ của DNS Google Public.
- 501 Chưa được triển khai
- Chỉ triển khai phương thức GET và POST, các phương thức khác sẽ gặp lỗi này.
- 502 Cổng vào không hợp lệ
- Dịch vụ DoH không thể liên hệ với trình phân giải DNS của Google Public.
Trong trường hợp phản hồi 502, mặc dù việc thử lại địa chỉ DNS Google Public thay thế có thể hữu ích, nhưng phản hồi dự phòng hiệu quả hơn sẽ là thử một dịch vụ DoH khác hoặc chuyển sang UDP hoặc TCP DNS truyền thống tại 8.8.8.8.
Lợi ích của DoH
Việc sử dụng HTTPS không chỉ mã hoá TLS mang lại một số lợi ích thiết thực:
- Các API HTTPS được cung cấp rộng rãi và được hỗ trợ tốt giúp đơn giản hoá quá trình triển khai cho cả DNS Google Public và ứng dụng tiềm năng.
- Dịch vụ HTTPS cung cấp cho các ứng dụng web quyền truy cập vào tất cả các loại bản ghi DNS, tránh các hạn chế của API DNS của trình duyệt và hệ điều hành hiện có, thường chỉ hỗ trợ hoạt động tra cứu máy chủ lưu trữ với địa chỉ.
- Các ứng dụng triển khai hỗ trợ HTTPS dựa trên UDP theo QUIC có thể tránh được các sự cố như chặn đầu dòng có thể xảy ra khi sử dụng truyền tải TCP.
Các phương pháp hay nhất về quyền riêng tư dành cho DoH
Nhà phát triển ứng dụng DoH nên cân nhắc các phương pháp hay nhất về quyền riêng tư được nêu trong RFC 8484 và mở rộng bên dưới:
Hạn chế sử dụng tiêu đề HTTP
Các tiêu đề HTTP tiết lộ thông tin về việc triển khai DoH của ứng dụng và có thể được dùng để huỷ ẩn danh ứng dụng. Các tiêu đề như Cookie, Tác nhân người dùng và Accept-Language là những mục vi phạm nghiêm trọng nhất, nhưng ngay cả tập hợp tiêu đề đã gửi cũng có thể bị lộ. Để giảm thiểu rủi ro này, hãy chỉ gửi các tiêu đề HTTP cần thiết cho DoH: Host (Lưu trữ), Content-Type (đối với POST) và Accept (Chấp nhận). Phải đưa tác nhân người dùng vào mọi phiên bản phát triển hoặc thử nghiệm.
Sử dụng các lựa chọn khoảng đệm EDNS
Làm theo hướng dẫn trong RFC 8467 để sử dụng các tuỳ chọn khoảng đệm EDNS nhằm truyền truy vấn DoH theo một vài độ dài phổ biến nhằm ngăn chặn việc phân tích lưu lượng truy cập. Bạn cũng có thể sử dụng khoảng đệm HTTP/2, nhưng không giống như khoảng đệm EDNS, sẽ không tạo ra khoảng đệm trên phản hồi từ máy chủ DoH.
Chỉ sử dụng RFC 8484 POST cho các ứng dụng có nhạy cảm về quyền riêng tư hoặc chế độ trình duyệt
Việc sử dụng POST cho các truy vấn DoH làm giảm khả năng lưu vào bộ nhớ đệm của phản hồi và có thể làm tăng độ trễ của DNS. Vì vậy, bạn không nên thực hiện việc này. Tuy nhiên, việc giảm khả năng lưu vào bộ nhớ đệm có thể là cần thiết đối với các ứng dụng nhạy cảm về quyền riêng tư và có thể giúp chống lại các cuộc tấn công về thời gian của các ứng dụng web cố gắng xác định những miền mà người dùng đã truy cập gần đây.
Vấn đề
Để báo cáo lỗi hoặc yêu cầu tính năng mới, vui lòng mở một vấn đề của DoH.