DNS สาธารณะของ Google มี DoH API 2 รายการที่ต่างกันที่ปลายทางต่อไปนี้
หน้าภาพรวมการส่งที่มีความปลอดภัยมีตัวอย่างบรรทัดคําสั่ง curl สําหรับการใช้ทั้ง API และรายละเอียดของ TLS และฟีเจอร์อื่น ๆ ที่มักพบใน DNS ผ่าน TLS (DoT) และ DoH
นอกจากนี้ DoH ยังรองรับบริการ DNS64 สาธารณะของ Google สําหรับ IPv6 เท่านั้น
DNS สาธารณะของ Google ไม่รองรับ URL ที่ไม่ปลอดภัย http: สําหรับการเรียก API
เมธอด HTTP
- รับ
- การใช้เมธอด GET จะช่วยลดเวลาในการตอบสนองได้เนื่องจากมีการแคชได้อย่างมีประสิทธิภาพมากขึ้น
คําขอ RFC 8484 GET ต้องมีพารามิเตอร์การค้นหา
?dns=ที่มีข้อความ DNS ที่เข้ารหัสแบบ Base64Url เมธอด GET เป็นวิธีเดียวที่รองรับสําหรับ JSON API - โพสต์
- เมธอด POST รองรับเฉพาะ RFC 8484 API และใช้ข้อความ DNS แบบไบนารีที่มีแอปพลิเคชัน Content-Type/dns-message ในเนื้อหาคําขอและในการตอบสนอง HTTP ของ DoH
- หลัก
- HEAD ไม่ได้รับการสนับสนุนในขณะนี้ และส่งคืนข้อผิดพลาดคําขอ 400 อย่างไม่ถูกต้อง
วิธีอื่นๆ จะแสดงผลข้อผิดพลาด 501 ที่ไม่ได้ใช้
รหัสสถานะ HTTP
DNS สาธารณะของ Google จะแสดงรหัสสถานะ HTTP ต่อไปนี้
สำเร็จ
- 200 OK
- การแยกวิเคราะห์ HTTP และการสื่อสารด้วยรีโซลเวอร์ DNS สําเร็จ และเนื้อหาของการตอบกลับเป็นการตอบสนอง DNS ในการเข้ารหัสแบบไบนารีหรือการเข้ารหัส JSON ทั้งนี้ขึ้นอยู่กับปลายทางของการค้นหา ยอมรับส่วนหัว และพารามิเตอร์ GET
การเปลี่ยนเส้นทาง
- 301 ย้ายถาวร
- ไคลเอ็นต์ควรลองดําเนินการอีกครั้งตาม URL ที่ให้ไว้ในส่วนหัว
Location:หากการค้นหาเดิมเป็นคําขอ POST ไคลเอ็นต์ควรลองอีกครั้งโดยใช้ GET ก็ต่อเมื่อ URL ใหม่ระบุอาร์กิวเมนต์พารามิเตอร์ GET ของdnsมิเช่นนั้น ให้ลูกค้าควรลองใช้ POST อีกครั้ง
ส่วนโค้ดอื่นๆ เช่น 302 Found, 307 Redirect Redirector หรือ 308 Permanent Redirects อาจใช้ในอนาคต และไคลเอ็นต์ DoH ควรจัดการโค้ดทั้ง 4 รายการ
การตอบกลับที่มีรหัส 301 และ 308 ถาวรควรแคชไว้อย่างไม่มีกําหนด และ (หากทําได้) ผู้ใช้อาจได้รับแจ้งให้อัปเดตการกําหนดค่าเดิมโดยใช้ URL ใหม่
คําขอ POST ที่ตอบกลับแบบ 307 หรือ 308 ควรลองใช้ POST อีกครั้งเสมอ
ข้อผิดพลาด
การตอบกลับข้อผิดพลาดจะมีคําอธิบายสถานะ HTTP ในเนื้อความโดยใช้ HTML หรือข้อความธรรมดา
- 400 คําขอไม่ถูกต้อง
- ปัญหาในการแยกวิเคราะห์พารามิเตอร์ GET หรือข้อความคําขอ DNS ที่ไม่ถูกต้อง สําหรับพารามิเตอร์ GET ที่ไม่ถูกต้อง เนื้อความ HTTP ควรอธิบายถึงข้อผิดพลาด ข้อความ DNS ที่ไม่ถูกต้องส่วนใหญ่จะได้รับ 200 OK เมื่อใช้ FORMERR ส่วนข้อผิดพลาด HTTP จะแสดงผลสําหรับข้อความที่อ่านไม่รู้เรื่องโดยไม่มีส่วนคําถาม ธง QR ที่แสดงถึงการตอบกลับ หรือชุดค่าผสมที่มีการแจ้งว่าไม่เหมาะสมอื่นๆ พร้อมข้อผิดพลาดในการแยกวิเคราะห์ DNS ไบนารี
- 413 เพย์โหลดมีขนาดใหญ่เกินไป
- เนื้อหาคําขอ RFC 8484 POST เกินขนาดข้อความสูงสุด 512 ไบต์
- 414 URI ยาวเกินไป
- ส่วนหัวการค้นหา GET มีขนาดใหญ่เกินไป หรือพารามิเตอร์
dnsมีข้อความ DNS ที่เข้ารหัสแบบ Base64Url เกินขนาดข้อความสูงสุด 512 ไบต์ - 415 ประเภทสื่อที่ไม่รองรับ
- เนื้อหา POST ไม่มีส่วนหัวประเภทเนื้อหา
application/dns-message - 429 มีคําขอมากเกินไป
- ไคลเอ็นต์ส่งคําขอจํานวนมากเกินไปในระยะเวลาที่กําหนด ไคลเอ็นต์ควรหยุดส่งคําขอจนถึงเวลาที่ระบุในส่วนหัว "ลองอีกครั้งหลังจาก" (เวลาที่เกี่ยวข้องเป็นวินาที)
- 500 ข้อผิดพลาดภายในเซิร์ฟเวอร์
- ข้อผิดพลาด DoH ภายใน DNS สาธารณะของ Google
- 501 ไม่มีการติดตั้ง
- การใช้เมธอด GET และ POST เท่านั้น ทําให้วิธีอื่นๆ ได้รับข้อผิดพลาดนี้
- 502 เกตเวย์ไม่ถูกต้อง
- บริการ DoH ติดต่อกับรีโซลเวอร์ DNS สาธารณะของ Google ไม่ได้
ในกรณีของการตอบกลับรหัส 502 แม้ว่าการลองใช้ที่อยู่ DNS สาธารณะอื่นของ Google อาจช่วยได้ แต่การตอบสนองสํารองที่มีประสิทธิภาพมากกว่าคือการลองใช้บริการ DoH อื่น หรือเปลี่ยนไปใช้ UDP หรือ TCP DNS แบบดั้งเดิมที่ 8.8.8.8
ประโยชน์ของ DoH
การใช้ HTTPS ไม่ใช่แค่การเข้ารหัส TLS จะให้ประโยชน์ในทางปฏิบัติดังนี้
- HTTPS API ที่ใช้งานได้อย่างกว้างขวางและรองรับการใช้งานช่วยให้ติดตั้งใช้งานได้ง่ายขึ้นสําหรับ DNS สาธารณะของ Google เองและผู้มีโอกาสเป็นลูกค้า
- บริการ HTTPS ช่วยให้เว็บแอปมีสิทธิ์เข้าถึงระเบียน DNS ได้ทุกประเภท จึงหลีกเลี่ยงข้อจํากัดของเบราว์เซอร์และ OS DNS API ที่มีอยู่ ซึ่งโดยทั่วไปจะรองรับการค้นหาแบบโฮสต์ไปยังที่อยู่เท่านั้น
- ไคลเอ็นต์ที่ใช้การรองรับ HTTPS ที่ใช้ QUIC UDP สามารถหลีกเลี่ยงปัญหาต่างๆ เช่น การบล็อกบรรทัดล่วงหน้าที่อาจเกิดขึ้นเมื่อใช้การรับส่งข้อมูล TCP
แนวทางปฏิบัติแนะนําด้านความเป็นส่วนตัวสําหรับ DoH
นักพัฒนาแอปพลิเคชัน DoH ควรพิจารณาแนวทางปฏิบัติแนะนําด้านความเป็นส่วนตัวที่ระบุไว้ใน RFC 8484 และขยายด้านล่าง
จํากัดการใช้ส่วนหัว HTTP
ส่วนหัว HTTP แสดงข้อมูลเกี่ยวกับการใช้งาน DoH ของลูกค้า และใช้ในการลบข้อมูลระบุตัวบุคคลของไคลเอ็นต์ได้ ส่วนหัวอย่างเช่น คุกกี้, User-Agent และ Accept-Language ถือเป็นการกระทําผิดที่ร้ายแรงที่สุด แต่แม้แต่ชุดของส่วนหัวที่ส่งก็อาจเปิดเผยให้เห็นได้ เพื่อลดความเสี่ยงนี้ โปรดส่งเฉพาะส่วนหัว HTTP ที่จําเป็นสําหรับ DoH: Host, Content-Type (สําหรับ POST) และยอมรับหากจําเป็นต้องใช้ User-Agent ควรรวมอยู่ในเวอร์ชันพัฒนาหรือการทดสอบ
ใช้ตัวเลือกระยะห่างจากขอบของ EDNS
ทําตามคําแนะนําใน RFC 8467 สําหรับการใช้ตัวเลือกระยะห่างจากขอบของ EDNS เพื่อเสริมการค้นหา DoH ให้มีความยาวที่เหมาะสมเพียงไม่กี่ครั้งเพื่อป้องกันการวิเคราะห์การเข้าชม นอกจากนี้ยังสามารถใช้ระยะห่างจากขอบของ HTTP/2 ได้ด้วย แต่ต่างจากระยะห่างจากขอบของ EDNS จะไม่ทําให้เกิดระยะห่างจากขอบบริเวณตอบกลับจากเซิร์ฟเวอร์ DoH
ใช้ RFC 8484 POST สําหรับแอปพลิเคชันที่มีความละเอียดอ่อนด้านความเป็นส่วนตัวหรือโหมดเบราว์เซอร์เท่านั้น
การใช้คําสั่ง POST สําหรับ DoH จะลดแคชของคําตอบและเพิ่มเวลาในการตอบสนองของ DNS ได้ เราจึงไม่แนะนําให้ใช้ อย่างไรก็ตาม การลดการแคชน่าจะเหมาะสําหรับแอปพลิเคชันที่มีความละเอียดอ่อนด้านความเป็นส่วนตัว และอาจป้องกันการโจมตีแบบกําหนดเวลาจากเว็บแอปที่พยายามตรวจสอบว่าโดเมนใดที่ผู้ใช้เข้าชมเมื่อไม่นานมานี้
ปัญหา
หากต้องการรายงานข้อบกพร่องหรือขอฟีเจอร์ใหม่ โปรดเปิดปัญหาสําหรับ DoH