นักพัฒนาเซิร์ฟเวอร์ BIND DNS ประกาศเพิ่มการรองรับเซิร์ฟเวอร์สำหรับเทคโนโลยี DNS ผ่าน HTTPS (DoH, DNS ผ่าน HTTPS) และ DNS ผ่าน TLS (DoT, DNS ผ่าน TLS) รวมถึงกลไก XFR-over-TLS เพื่อความปลอดภัย ถ่ายโอนเนื้อหาของโซน DNS ระหว่างเซิร์ฟเวอร์ DoH พร้อมสำหรับการทดสอบในรุ่น 9.17 และมีการรองรับ DoT ตั้งแต่รุ่น 9.17.10 หลังจากการรักษาเสถียรภาพแล้ว การสนับสนุน DoT และ DoH จะถูกส่งกลับไปยังเวอร์ชัน 9.17.7 ที่เสถียร
การใช้งานโปรโตคอล HTTP/2 ที่ใช้ใน DoH นั้นขึ้นอยู่กับการใช้ไลบรารี nghttp2 ซึ่งรวมอยู่ในการขึ้นต่อกันของแอสเซมบลี (ในอนาคต ไลบรารีมีแผนที่จะถ่ายโอนไปยังจำนวนการขึ้นต่อกันที่เป็นทางเลือก) รองรับการเชื่อมต่อ HTTP/2 ที่เข้ารหัส (TLS) และที่ไม่ได้เข้ารหัส ด้วยการตั้งค่าที่เหมาะสม กระบวนการที่กำหนดชื่อกระบวนการเดียวสามารถให้บริการไม่เพียงแต่การสืบค้น DNS แบบดั้งเดิมเท่านั้น แต่ยังรวมถึงการสืบค้นที่ส่งโดยใช้ DoH (DNS-over-HTTPS) และ DoT (DNS-over-TLS) ยังไม่มีการใช้การสนับสนุน HTTPS ในฝั่งไคลเอ็นต์ (ขุด) รองรับ XFR-over-TLS สำหรับคำขอทั้งขาเข้าและขาออก
การประมวลผลคำขอโดยใช้ DoH และ DoT ถูกเปิดใช้งานโดยการเพิ่มตัวเลือก http และ tls ให้กับคำสั่ง Listen-on หากต้องการรองรับ DNS-over-HTTP ที่ไม่ได้เข้ารหัส คุณควรระบุ "tls none" ในการตั้งค่า คีย์ถูกกำหนดไว้ในส่วน "tls" พอร์ตเครือข่ายเริ่มต้น 853 สำหรับ DoT, 443 สำหรับ DoH และ 80 สำหรับ DNS-over-HTTP สามารถแทนที่ได้ผ่านพารามิเตอร์ tls-port, https-port และ http-port ตัวอย่างเช่น: tls local-tls { key-file "/path/to/priv_key.pem"; ไฟล์ใบรับรอง "/path/to/cert_chain.pem"; }; http local-http-server { ปลายทาง { "/dns-query"; }; }; ตัวเลือก { https-พอร์ต 443; พอร์ตการฟัง 443 tls local-tls http myserver {ใด ๆ ;}; }
ในบรรดาคุณสมบัติของการใช้งาน DoH ใน BIND นั้น การรวมจะถูกบันทึกว่าเป็นการขนส่งทั่วไป ซึ่งสามารถใช้ได้ไม่เพียงแต่ในการประมวลผลคำขอของไคลเอนต์ไปยังตัวแก้ไข แต่ยังรวมถึงเมื่อแลกเปลี่ยนข้อมูลระหว่างเซิร์ฟเวอร์ เมื่อถ่ายโอนโซนโดยเซิร์ฟเวอร์ DNS ที่เชื่อถือได้ และ เมื่อประมวลผลคำขอใด ๆ ที่สนับสนุนโดยการขนส่ง DNS อื่น ๆ
คุณสมบัติอีกประการหนึ่งคือความสามารถในการย้ายการดำเนินการเข้ารหัสสำหรับ TLS ไปยังเซิร์ฟเวอร์อื่น ซึ่งอาจจำเป็นในเงื่อนไขที่เก็บใบรับรอง TLS ไว้ในระบบอื่น (เช่น ในโครงสร้างพื้นฐานที่มีเว็บเซิร์ฟเวอร์) และดูแลโดยบุคลากรอื่น มีการนำการสนับสนุน DNS-over-HTTP ที่ไม่ได้เข้ารหัสมาใช้เพื่อลดความซับซ้อนของการดีบักและเป็นเลเยอร์สำหรับการส่งต่อในเครือข่ายภายใน โดยสามารถจัดระเบียบการเข้ารหัสบนเซิร์ฟเวอร์อื่นได้ บนเซิร์ฟเวอร์ระยะไกล สามารถใช้ nginx เพื่อสร้างการรับส่งข้อมูล TLS ได้ เช่นเดียวกับวิธีจัดระเบียบการเชื่อมโยง HTTPS สำหรับเว็บไซต์
ขอให้เราจำไว้ว่า DNS-over-HTTPS จะมีประโยชน์ในการป้องกันการรั่วไหลของข้อมูลเกี่ยวกับชื่อโฮสต์ที่ร้องขอผ่านเซิร์ฟเวอร์ DNS ของผู้ให้บริการ ต่อสู้กับการโจมตี MITM และการปลอมแปลงการรับส่งข้อมูล DNS (เช่น เมื่อเชื่อมต่อกับ Wi-Fi สาธารณะ) การตอบโต้ การบล็อกที่ระดับ DNS (DNS-over-HTTPS ไม่สามารถแทนที่ VPN ในการเลี่ยงผ่านการบล็อกที่ดำเนินการในระดับ DPI) หรือสำหรับการจัดระเบียบงานเมื่อไม่สามารถเข้าถึงเซิร์ฟเวอร์ DNS โดยตรง (เช่น เมื่อทำงานผ่านพรอกซี) หากในสถานการณ์ปกติ คำขอ DNS ถูกส่งโดยตรงไปยังเซิร์ฟเวอร์ DNS ที่กำหนดไว้ในการกำหนดค่าระบบ ในกรณีของ DNS-over-HTTPS คำขอเพื่อกำหนดที่อยู่ IP ของโฮสต์จะถูกห่อหุ้มในการรับส่งข้อมูล HTTPS และส่งไปยังเซิร์ฟเวอร์ HTTP โดยที่ ตัวแก้ไขจะประมวลผลคำขอผ่าน Web API
“DNS over TLS” แตกต่างจาก “DNS over HTTPS” ในการใช้โปรโตคอล DNS มาตรฐาน (โดยปกติจะใช้พอร์ตเครือข่าย 853) ซึ่งรวมอยู่ในช่องทางการสื่อสารที่เข้ารหัสซึ่งจัดโดยใช้โปรโตคอล TLS พร้อมการตรวจสอบความถูกต้องของโฮสต์ผ่านใบรับรอง TLS/SSL ที่ได้รับการรับรอง โดยหน่วยงานออกใบรับรอง มาตรฐาน DNSSEC ที่มีอยู่ใช้การเข้ารหัสเพื่อตรวจสอบสิทธิ์ไคลเอ็นต์และเซิร์ฟเวอร์เท่านั้น แต่ไม่ได้ป้องกันการรับส่งข้อมูลจากการสกัดกั้น และไม่รับประกันการรักษาความลับของคำขอ
ที่มา: opennet.ru