DNS-over-HTTPS (DoH)

Google Public DNS มี DoH API 2 แบบที่แตกต่างกันที่ปลายทางเหล่านี้

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

หน้าภาพรวมของการส่งที่มีความปลอดภัยมีตัวอย่างบรรทัดคำสั่ง curl สำหรับการใช้ API ทั้ง 2 อย่าง รวมถึงรายละเอียดของ TLS และฟีเจอร์อื่นๆ ที่ใช้กับทั้ง DNS ผ่าน TLS (DoT) และ DoH

นอกจากนี้ DoH ยังรองรับบริการ Google Public DNS64 แบบ IPv6 เท่านั้นด้วย

DNS สาธารณะของ Google ไม่รองรับ URL http: ที่ไม่ปลอดภัยสำหรับการเรียก API

เมธอด HTTP

GET

การใช้เมธอด GET จะช่วยลดเวลาในการตอบสนองได้ เนื่องจากวิธีการดังกล่าวมีการแคชไว้อย่างมีประสิทธิภาพมากกว่า คำขอ RFC 8484 GET ต้องมีพารามิเตอร์การค้นหา ?dns= ที่มีข้อความ DNS ที่เข้ารหัส Base64Url เมธอด GET เป็นวิธีเดียวที่รองรับสำหรับ JSON API

POST

เมธอด POST จะรองรับเฉพาะ RFC 8484 API เท่านั้น และใช้ข้อความ DNS แบบไบนารีที่มีแอปพลิเคชัน Content-Type/dns-message ในเนื้อหาคำขอและในการตอบกลับ HTTP ของ DoH

HEAD

ไม่รองรับ HEAD ในขณะนี้ และแสดงข้อผิดพลาด 400 Bad Request

วิธีการอื่นๆ จะแสดงข้อผิดพลาด 501 Not Implemented

รหัสสถานะ HTTP

Google Public DNS DoH แสดงรหัสสถานะ HTTP ต่อไปนี้

Success

200 OK

การแยกวิเคราะห์และการติดต่อสื่อสาร HTTP กับรีโซลเวอร์ DNS สำเร็จแล้ว และเนื้อหาการตอบสนองเป็นการตอบสนอง DNS ในการเข้ารหัสแบบไบนารีหรือ JSON ขึ้นอยู่กับปลายทางการค้นหา ยอมรับส่วนหัว และพารามิเตอร์ GET

การเปลี่ยนเส้นทาง

301 ย้ายถาวร

ไคลเอ็นต์ควรลองอีกครั้งที่ URL ที่ให้ไว้ในส่วนหัว Location: หากการค้นหาเดิมเป็นคำขอ POST ไคลเอ็นต์ควรลองอีกครั้งโดยใช้ GET ต่อเมื่อ URL ใหม่ระบุอาร์กิวเมนต์พารามิเตอร์ dns GET หรือไม่เช่นนั้น ไคลเอ็นต์ควรลองใช้ POST อีกครั้ง

ในอนาคตอาจมีการใช้รหัสอื่นๆ เช่น 302 Found, 307 Temporary Redirect หรือ 308 Permanent Redirect และลูกค้า DoH ควรจัดการโค้ดทั้ง 4 รหัส

คุณควรแคชการตอบกลับด้วยรหัส 301 และ 308 แบบถาวรไว้อย่างไม่มีกำหนด และหากทำได้ ผู้ใช้อาจได้รับแจ้งให้อัปเดตการกำหนดค่าเดิมโดยใช้ URL ใหม่

คำขอ POST ที่ได้รับการตอบกลับแบบ 307 หรือ 308 ควรดำเนินการซ้ำด้วย POST เสมอ

ข้อผิดพลาด

การตอบกลับข้อผิดพลาดจะมีคำอธิบายสถานะ HTTP อยู่ในเนื้อหาโดยใช้ HTML หรือข้อความธรรมดา

400 คำขอไม่ถูกต้อง

เกิดปัญหาในการแยกวิเคราะห์พารามิเตอร์ GET หรือข้อความคำขอ DNS ที่ไม่ถูกต้อง สำหรับพารามิเตอร์ GET ที่ไม่ถูกต้อง เนื้อหา HTTP ควรอธิบายข้อผิดพลาดดังกล่าว ข้อความ DNS ที่ไม่ถูกต้องส่วนใหญ่จะได้รับค่า 200 OK ที่มี FORMERR โดยระบบจะแสดงผลข้อผิดพลาด HTTP สำหรับข้อความที่อ่านไม่ออกที่ไม่มีส่วนคำถาม แฟล็กคิวอาร์ที่ระบุการตอบกลับ หรือการผสมแฟล็กอื่นๆ ที่ไม่มีความหมายและมีข้อผิดพลาดการแยกวิเคราะห์ DNS แบบไบนารี

413 เพย์โหลดมีขนาดใหญ่เกินไป

เนื้อหาของคำขอ RFC 8484 POST เกินขนาดสูงสุด 512 ไบต์

414 URI ยาวเกินไป

ส่วนหัวของการค้นหา GET มีขนาดใหญ่เกินไปหรือพารามิเตอร์ dns มีข้อความ DNS ที่เข้ารหัสแบบ Base64Url ซึ่งเกินขนาดข้อความสูงสุด 512 ไบต์

415 ไม่รองรับประเภทสื่อ

เนื้อหา POST ไม่มีส่วนหัว Content-Type application/dns-message

429 มีคำขอมากเกินไป

ลูกค้าส่งคำขอมากเกินไปภายในระยะเวลาที่กำหนด ไคลเอ็นต์ควรหยุดส่งคำขอจนกว่าจะถึงเวลาที่ระบุไว้ในส่วนหัว Retry-After (เวลาสัมพัทธ์เป็นวินาที)

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 ของไคลเอ็นต์ และสามารถใช้เพื่อลบข้อมูลระบุตัวบุคคลของไคลเอ็นต์ ส่วนหัว เช่น Cookie, User-Agent และ Receive-Language เป็นผู้กระทำผิดที่ร้ายแรงที่สุด แต่แม้แต่ชุดส่วนหัวที่ส่ง ก็อาจเปิดเผยได้ เพื่อลดความเสี่ยงนี้ ให้ส่งเฉพาะส่วนหัว HTTP ที่จำเป็นสำหรับ DoH: Host, Content-Type (สำหรับ POST) และส่งให้ "อยู่ในกลุ่ม" หากจำเป็น ควรรวม User-Agent ไว้ในเวอร์ชันพัฒนาหรือการทดสอบ

• ใช้ตัวเลือกระยะห่างจากขอบของ EDNS

  ทำตามคำแนะนำใน RFC 8467 สำหรับการใช้ตัวเลือกการเว้นระยะห่างของ EDNS เพื่อเพิ่มการค้นหา DoH ตามความยาวทั่วไปสัก 2-3 ช่วงเพื่อป้องกันการวิเคราะห์การเข้าชม การใช้ระยะห่างจากขอบของ HTTP/2 ก็สามารถทำได้เช่นกัน แต่ต่างจากระยะห่างจากขอบของ EDNS ตรงที่จะไม่ทำให้เกิดระยะห่างจากขอบในการตอบสนองจากเซิร์ฟเวอร์ DoH

• ใช้ RFC 8484 POST เฉพาะสำหรับแอปพลิเคชันหรือโหมดเบราว์เซอร์ที่มีความละเอียดอ่อนด้านความเป็นส่วนตัวเท่านั้น

  การใช้ POST สำหรับการค้นหา DoH จะลดความสามารถในการแคชของคำตอบและเพิ่มเวลาในการตอบสนองของ DNS จึงไม่แนะนำโดยทั่วไป อย่างไรก็ตาม การลดการแคชอาจเหมาะสำหรับแอปพลิเคชันที่คำนึงถึงความเป็นส่วนตัว และอาจป้องกันการโจมตีจากเวลาของเว็บแอปที่พยายามระบุโดเมนที่ผู้ใช้เข้าชมเมื่อเร็วๆ นี้

ปัญหา

หากต้องการรายงานข้อบกพร่องหรือขอฟีเจอร์ใหม่ โปรดเปิดปัญหาสำหรับ DoH