DNS ก่อน HTTPS (DoH)

จัดทุกอย่างให้เป็นระเบียบอยู่เสมอด้วยคอลเล็กชัน บันทึกและจัดหมวดหมู่เนื้อหาตามค่ากำหนดของคุณ

DNS สาธารณะของ Google มี DoH API 2 รายการที่ต่างกันที่ปลายทางต่อไปนี้

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

หน้าภาพรวมการส่งที่มีความปลอดภัยมีตัวอย่างบรรทัดคําสั่ง 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