นักพัฒนาไฟร์ฟอกซ์ เกี่ยวกับการเปิดใช้งานโหมด DNS ผ่าน HTTPS (DoH, DNS ผ่าน HTTPS) เป็นค่าเริ่มต้นสำหรับผู้ใช้ในสหรัฐอเมริกา การเข้ารหัสการรับส่งข้อมูล DNS ถือเป็นปัจจัยพื้นฐานที่สำคัญในการปกป้องผู้ใช้ ตั้งแต่วันนี้เป็นต้นไป การติดตั้งใหม่ทั้งหมดโดยผู้ใช้ในสหรัฐฯ จะเปิดใช้งาน DoH เป็นค่าเริ่มต้น ผู้ใช้ปัจจุบันในสหรัฐฯ มีกำหนดจะเปลี่ยนไปใช้ DoH ภายในไม่กี่สัปดาห์ ในสหภาพยุโรปและประเทศอื่นๆ ให้เปิดใช้งาน DoH ตามค่าเริ่มต้นในตอนนี้ .
หลังจากเปิดใช้งาน DoH ผู้ใช้จะแสดงคำเตือนซึ่งอนุญาตให้ปฏิเสธที่จะติดต่อเซิร์ฟเวอร์ DoH DNS แบบรวมศูนย์และกลับสู่รูปแบบเดิมในการส่งข้อความค้นหาที่ไม่ได้เข้ารหัสไปยังเซิร์ฟเวอร์ DNS ของผู้ให้บริการ แทนที่จะใช้โครงสร้างพื้นฐานแบบกระจายของตัวแก้ไข DNS DoH ใช้การเชื่อมโยงกับบริการ DoH เฉพาะ ซึ่งถือได้ว่าเป็นจุดเดียวของความล้มเหลว ปัจจุบันมีการเสนองานผ่านผู้ให้บริการ DNS สองราย - CloudFlare (ค่าเริ่มต้น) และ .
เปลี่ยนผู้ให้บริการหรือปิดการใช้งาน DoH ในการตั้งค่าการเชื่อมต่อเครือข่าย ตัวอย่างเช่น คุณสามารถระบุเซิร์ฟเวอร์ DoH สำรอง “https://dns.google/dns-query” เพื่อเข้าถึงเซิร์ฟเวอร์ Google “https://dns.quad9.net/dns-query” - Quad9 และ “https:/ /doh .opendns.com/dns-query" - OpenDNS เกี่ยวกับ:config ยังมีการตั้งค่า network.trr.mode ซึ่งคุณสามารถเปลี่ยนโหมดการทำงานของ DoH ได้: ค่า 0 จะปิดใช้งาน DoH โดยสิ้นเชิง 1 - ใช้ DNS หรือ DoH แล้วแต่ว่าอันไหนจะเร็วกว่า 2 - DoH ถูกใช้เป็นค่าเริ่มต้น และใช้ DNS เป็นตัวเลือกสำรอง 3 - ใช้เฉพาะ DoH เท่านั้น 4 - โหมดมิเรอร์ที่ใช้ DoH และ DNS พร้อมกัน
จำได้ว่า DoH มีประโยชน์ในการป้องกันการรั่วไหลของข้อมูลเกี่ยวกับชื่อโฮสต์ที่ร้องขอผ่านเซิร์ฟเวอร์ DNS ของผู้ให้บริการ ต่อสู้กับการโจมตี MITM และการปลอมแปลงทราฟฟิก DNS (เช่น เมื่อเชื่อมต่อกับ Wi-Fi สาธารณะ) ตอบโต้การบล็อกที่ระดับ DNS (DoH ไม่สามารถแทนที่ VPN ในพื้นที่ของการข้ามการบล็อกที่ดำเนินการในระดับ DPI) หรือสำหรับการจัดระเบียบงานในกรณีที่ไม่สามารถเข้าถึงเซิร์ฟเวอร์ DNS ได้โดยตรง (เช่น เมื่อทำงานผ่านพร็อกซี) ในสถานการณ์ปกติ คำขอ DNS จะถูกส่งโดยตรงไปยังเซิร์ฟเวอร์ DNS ที่กำหนดไว้ในการกำหนดค่าระบบ ในกรณีของ DoH คำขอเพื่อตรวจสอบที่อยู่ IP ของโฮสต์จะถูกห่อหุ้มไว้ในทราฟฟิก HTTPS และส่งไปยังเซิร์ฟเวอร์ HTTP ซึ่งรีโซลเวอร์ ประมวลผลคำขอผ่าน Web API มาตรฐาน DNSSEC ปัจจุบันใช้การเข้ารหัสเพื่อรับรองความถูกต้องของไคลเอนต์และเซิร์ฟเวอร์เท่านั้น แต่ไม่ได้ป้องกันการรับส่งข้อมูลจากการสกัดกั้นและไม่รับประกันการรักษาความลับของคำขอ
ในการเลือกผู้ให้บริการ DoH ที่นำเสนอใน Firefox ไปยังตัวแก้ไข DNS ที่น่าเชื่อถือ ซึ่งผู้ให้บริการ DNS สามารถใช้ข้อมูลที่ได้รับเพื่อแก้ไขเฉพาะเพื่อให้มั่นใจในการทำงานของบริการเท่านั้น ต้องไม่จัดเก็บบันทึกนานกว่า 24 ชั่วโมง ไม่สามารถถ่ายโอนข้อมูลไปยังบุคคลที่สาม และจำเป็นต้องเปิดเผยข้อมูล เกี่ยวกับวิธีการประมวลผลข้อมูล บริการจะต้องไม่เซ็นเซอร์ กรอง แทรกแซง หรือปิดกั้นการรับส่งข้อมูล DNS ยกเว้นตามที่กฎหมายกำหนด
ควรใช้ DoH ด้วยความระมัดระวัง ตัวอย่างเช่น ในสหพันธรัฐรัสเซีย ที่อยู่ IP 104.16.248.249 และ 104.16.249.249 เชื่อมโยงกับเซิร์ฟเวอร์ DoH เริ่มต้น mozilla.cloudflare-dns.com ที่นำเสนอใน Firefox в ตามคำร้องขอของศาล Stavropol ลงวันที่ 10.06.2013 มิถุนายน XNUMX
DoH ยังอาจทำให้เกิดปัญหาในด้านต่างๆ เช่น ระบบควบคุมโดยผู้ปกครอง การเข้าถึงเนมสเปซภายในในระบบองค์กร การเลือกเส้นทางในระบบเพิ่มประสิทธิภาพการจัดส่งเนื้อหา และการปฏิบัติตามคำสั่งศาลในด้านการต่อสู้กับการเผยแพร่เนื้อหาที่ผิดกฎหมายและการแสวงหาผลประโยชน์จาก ผู้เยาว์ เพื่อหลีกเลี่ยงปัญหาดังกล่าว จึงมีการใช้และทดสอบระบบตรวจสอบที่จะปิดการใช้งาน DoH โดยอัตโนมัติภายใต้เงื่อนไขบางประการ
ในการระบุตัวแก้ไขระดับองค์กร จะมีการตรวจสอบโดเมนระดับแรก (TLD) ที่ไม่ปกติ และผู้แก้ไขระบบจะส่งคืนที่อยู่อินทราเน็ต เพื่อตรวจสอบว่าเปิดใช้งานการควบคุมโดยผู้ปกครองหรือไม่ ให้พยายามแก้ไขชื่อ exampleadultsite.com และหากผลลัพธ์ไม่ตรงกับ IP จริง จะถือว่าการบล็อกเนื้อหาสำหรับผู้ใหญ่ทำงานอยู่ที่ระดับ DNS นอกจากนี้ ที่อยู่ IP ของ Google และ YouTube ยังได้รับการตรวจสอบเป็นสัญญาณเพื่อดูว่าถูกแทนที่ด้วยstrict.youtube.com, forcesafesearch.google.com และstrictmoderate.youtube.com หรือไม่ การตรวจสอบเหล่านี้อนุญาตให้ผู้โจมตีที่ควบคุมการทำงานของตัวแก้ไขหรือสามารถรบกวนการรับส่งข้อมูลสามารถจำลองพฤติกรรมดังกล่าวเพื่อปิดใช้งานการเข้ารหัสการรับส่งข้อมูล DNS
การทำงานผ่านบริการ DoH เดียวอาจทำให้เกิดปัญหากับการเพิ่มประสิทธิภาพการรับส่งข้อมูลในเครือข่ายการจัดส่งเนื้อหาที่สร้างสมดุลการรับส่งข้อมูลโดยใช้ DNS (เซิร์ฟเวอร์ DNS ของเครือข่าย CDN สร้างการตอบสนองโดยคำนึงถึงที่อยู่ของตัวแก้ไข และจัดเตรียมโฮสต์ที่ใกล้เคียงที่สุดเพื่อรับเนื้อหา) การส่งข้อความสอบถาม DNS จากตัวแก้ไขที่ใกล้กับผู้ใช้มากที่สุดใน CDN ดังกล่าวส่งผลให้ส่งคืนที่อยู่ของโฮสต์ที่ใกล้กับผู้ใช้มากที่สุด แต่การส่งคำถาม DNS จากตัวแก้ไขแบบรวมศูนย์จะส่งคืนที่อยู่โฮสต์ใกล้กับเซิร์ฟเวอร์ DNS-over-HTTPS มากที่สุด . การทดสอบในทางปฏิบัติแสดงให้เห็นว่าการใช้ DNS-over-HTTP เมื่อใช้ CDN ทำให้แทบไม่มีความล่าช้าก่อนเริ่มการถ่ายโอนเนื้อหา (สำหรับการเชื่อมต่อที่รวดเร็ว ความล่าช้าไม่เกิน 10 มิลลิวินาที และประสิทธิภาพที่เร็วขึ้นนั้นถูกตรวจพบในช่องทางการสื่อสารที่ช้า ). การใช้ส่วนขยายเครือข่ายย่อยไคลเอ็นต์ EDNS ยังได้รับการพิจารณาเพื่อให้ข้อมูลตำแหน่งไคลเอ็นต์แก่ตัวแก้ไข CDN
ที่มา: opennet.ru