BIND DNS Server 9.18.0 ເປີດຕົວດ້ວຍການຮອງຮັບ DNS-over-TLS ແລະ DNS-over-HTTPS

ຫຼັງຈາກສອງປີຂອງການພັດທະນາ, ສະມາຄົມ ISC ໄດ້ອອກການປ່ອຍຄວາມຫມັ້ນຄົງຄັ້ງທໍາອິດຂອງສາຂາໃຫມ່ທີ່ສໍາຄັນຂອງເຄື່ອງແມ່ຂ່າຍ DNS BIND 9.18. ການສະຫນັບສະຫນູນສາຂາ 9.18 ຈະຖືກສະຫນອງໃຫ້ເປັນເວລາສາມປີຈົນກ່ວາໄຕມາດທີ 2 ຂອງປີ 2025 ເປັນສ່ວນຫນຶ່ງຂອງວົງຈອນການສະຫນັບສະຫນູນທີ່ຂະຫຍາຍອອກໄປ. ການສະຫນັບສະຫນູນສາຂາ 9.11 ຈະສິ້ນສຸດໃນເດືອນມີນາ, ແລະການສະຫນັບສະຫນູນສາຂາ 9.16 ໃນກາງປີ 2023. ເພື່ອພັດທະນາການທໍາງານຂອງ BIND ຮຸ່ນທີ່ຫມັ້ນຄົງຕໍ່ໄປ, ສາຂາທົດລອງ BIND 9.19.0 ໄດ້ຖືກສ້າງຕັ້ງຂຶ້ນ.

ການປ່ອຍ BIND 9.18.0 ມີຄວາມໂດດເດັ່ນສໍາລັບການຈັດຕັ້ງປະຕິບັດການສະຫນັບສະຫນູນ DNS ຜ່ານ HTTPS (DoH, DNS over HTTPS) ແລະ DNS over TLS (DoT, DNS over TLS), ເຊັ່ນດຽວກັນກັບກົນໄກ XoT (XFR-over-TLS) ສໍາລັບການໂອນຂໍ້ມູນ DNS ທີ່ປອດໄພ. ເຂດລະຫວ່າງເຊີບເວີ (ທັງເຂດສົ່ງ ແລະຮັບຜ່ານ XoT ແມ່ນຮອງຮັບ). ດ້ວຍການຕັ້ງຄ່າທີ່ເຫມາະສົມ, ຂະບວນການທີ່ມີຊື່ດຽວໃນປັດຈຸບັນສາມາດຮັບໃຊ້ບໍ່ພຽງແຕ່ການສອບຖາມ DNS ແບບດັ້ງເດີມ, ແຕ່ຍັງມີການສອບຖາມທີ່ສົ່ງໂດຍໃຊ້ DNS-over-HTTPS ແລະ DNS-over-TLS. ການສະຫນັບສະຫນູນລູກຄ້າສໍາລັບ DNS-over-TLS ຖືກສ້າງຂຶ້ນໃນເຄື່ອງມືຂຸດ, ເຊິ່ງສາມາດນໍາໃຊ້ເພື່ອສົ່ງຄໍາຮ້ອງຂໍຜ່ານ TLS ເມື່ອທຸງ "+tls" ຖືກລະບຸ.

ການປະຕິບັດຂອງ HTTP/2 protocol ທີ່ໃຊ້ໃນ DoH ແມ່ນອີງໃສ່ການນໍາໃຊ້ຫ້ອງສະຫມຸດ nghttp2, ເຊິ່ງລວມເປັນການຂຶ້ນກັບການປະກອບທາງເລືອກ. ໃບຢັ້ງຢືນສໍາລັບ DoH ແລະ DoT ສາມາດໃຫ້ໂດຍຜູ້ໃຊ້ຫຼືສ້າງໂດຍອັດຕະໂນມັດໃນເວລາເລີ່ມຕົ້ນ.

ການຮ້ອງຂໍການປະມວນຜົນໂດຍໃຊ້ DoH ແລະ DoT ຖືກເປີດໃຊ້ໂດຍການເພີ່ມຕົວເລືອກ "http" ແລະ "tls" ໃສ່ຄໍາສັ່ງຟັງ. ເພື່ອສະຫນັບສະຫນູນ DNS-over-HTTP ທີ່ບໍ່ໄດ້ເຂົ້າລະຫັດ, ທ່ານຄວນລະບຸ "tls none" ໃນການຕັ້ງຄ່າ. ຄີແມ່ນຖືກກໍານົດຢູ່ໃນສ່ວນ "tls". ພອດເຄືອຂ່າຍເລີ່ມຕົ້ນ 853 ສໍາລັບ DoT, 443 ສໍາລັບ DoH ແລະ 80 ສໍາລັບ DNS-over-HTTP ສາມາດ overridden ຜ່ານພາລາມິເຕີ tls-port, https-port ແລະ http-port. ຍົກ​ຕົວ​ຢ່າງ:

tls local-tls { key-file "/path/to/priv_key.pem"; cert-file "/path/to/cert_chain.pem"; }; http local-http-server { endpoints { "/dns-query"; }; }; ຕົວເລືອກ { https-port 443; listen-on port 443 tls local-tls http myserver {any;}; }

ຫນຶ່ງໃນລັກສະນະການປະຕິບັດ DoH ໃນ BIND ແມ່ນຄວາມສາມາດໃນການຍ້າຍການປະຕິບັດການເຂົ້າລະຫັດສໍາລັບ TLS ໄປຫາເຄື່ອງແມ່ຂ່າຍອື່ນ, ເຊິ່ງອາດຈະມີຄວາມຈໍາເປັນໃນເງື່ອນໄຂທີ່ໃບຢັ້ງຢືນ TLS ຖືກເກັບໄວ້ໃນລະບົບອື່ນ (ຕົວຢ່າງເຊັ່ນໃນໂຄງສ້າງພື້ນຖານທີ່ມີເຄື່ອງແມ່ຂ່າຍເວັບ) ແລະຮັກສາໄວ້. ໂດຍບຸກຄະລາກອນອື່ນໆ. ການສະຫນັບສະຫນູນ DNS-over-HTTP ທີ່ບໍ່ເຂົ້າລະຫັດແມ່ນປະຕິບັດເພື່ອເຮັດໃຫ້ການດີບັກງ່າຍແລະເປັນຊັ້ນສໍາລັບການສົ່ງຕໍ່ໄປຫາເຄື່ອງແມ່ຂ່າຍອື່ນໃນເຄືອຂ່າຍພາຍໃນ (ສໍາລັບການຍ້າຍການເຂົ້າລະຫັດກັບເຄື່ອງແມ່ຂ່າຍແຍກຕ່າງຫາກ). ໃນເຊີບເວີຫ່າງໄກສອກຫຼີກ, nginx ສາມາດຖືກນໍາໃຊ້ເພື່ອສ້າງການຈະລາຈອນ TLS, ຄ້າຍຄືກັບວິທີການເຊື່ອມໂຍງ HTTPS ສໍາລັບເວັບໄຊທ໌.

ລັກສະນະອື່ນແມ່ນການລວມ DoH ເປັນການຂົນສົ່ງທົ່ວໄປທີ່ສາມາດນໍາໃຊ້ບໍ່ພຽງແຕ່ເພື່ອຈັດການກັບຄໍາຮ້ອງຂໍຂອງລູກຄ້າກັບຕົວແກ້ໄຂ, ແຕ່ຍັງໃນເວລາທີ່ການສື່ສານລະຫວ່າງເຄື່ອງແມ່ຂ່າຍ, ເມື່ອການໂອນເຂດໂດຍເຄື່ອງແມ່ຂ່າຍ DNS ທີ່ມີອໍານາດ, ແລະໃນເວລາທີ່ດໍາເນີນການສອບຖາມໃດໆທີ່ສະຫນັບສະຫນູນໂດຍ DNS ອື່ນໆ. ການຂົນສົ່ງ.

ໃນບັນດາຂໍ້ບົກຜ່ອງທີ່ສາມາດຊົດເຊີຍໄດ້ໂດຍການປິດການກໍ່ສ້າງດ້ວຍ DoH / DoT ຫຼືການຍ້າຍການເຂົ້າລະຫັດກັບເຄື່ອງແມ່ຂ່າຍອື່ນ, ຄວາມສັບສົນທົ່ວໄປຂອງຖານລະຫັດແມ່ນໂດດເດັ່ນ - ເຄື່ອງແມ່ຂ່າຍ HTTP ທີ່ມີການກໍ່ສ້າງແລະຫ້ອງສະຫມຸດ TLS ໄດ້ຖືກເພີ່ມ, ເຊິ່ງອາດຈະບັນຈຸ. ຄວາມອ່ອນແອແລະເຮັດຫນ້າທີ່ເປັນ vectors ເພີ່ມເຕີມສໍາລັບການໂຈມຕີ. ນອກຈາກນັ້ນ, ເມື່ອນໍາໃຊ້ DoH, ການຈະລາຈອນເພີ່ມຂຶ້ນ.

ໃຫ້ພວກເຮົາຈື່ວ່າ DNS-over-HTTPS ສາມາດເປັນປະໂຫຍດສໍາລັບການປ້ອງກັນການຮົ່ວໄຫລຂອງຂໍ້ມູນກ່ຽວກັບຊື່ໂຮດທີ່ຮ້ອງຂໍຜ່ານເຄື່ອງແມ່ຂ່າຍ DNS ຂອງຜູ້ໃຫ້ບໍລິການ, ຕ້ານການໂຈມຕີ MITM ແລະການຫຼອກລວງການຈາລະຈອນ DNS (ຕົວຢ່າງ, ເມື່ອເຊື່ອມຕໍ່ກັບ Wi-Fi ສາທາລະນະ), ໂຕ້ແຍ້ງ. ການຂັດຂວາງໃນລະດັບ DNS (DNS-over-HTTPS ບໍ່ສາມາດທົດແທນ VPN ໃນການຂ້າມການບລັອກທີ່ປະຕິບັດຢູ່ໃນລະດັບ DPI) ຫຼືສໍາລັບການຈັດຕັ້ງການເຮັດວຽກໃນເວລາທີ່ບໍ່ສາມາດເຂົ້າຫາເຄື່ອງແມ່ຂ່າຍ DNS ໂດຍກົງ (ຕົວຢ່າງ, ເມື່ອເຮັດວຽກຜ່ານຕົວແທນ). ຖ້າໃນສະຖານະການປົກກະຕິການຮ້ອງຂໍ DNS ຖືກສົ່ງໂດຍກົງໄປຫາເຄື່ອງແມ່ຂ່າຍ DNS ທີ່ກໍານົດໄວ້ໃນການຕັ້ງຄ່າລະບົບ, ຫຼັງຈາກນັ້ນໃນກໍລະນີຂອງ DNS-over-HTTPS ການຮ້ອງຂໍເພື່ອກໍານົດທີ່ຢູ່ IP ຂອງເຈົ້າພາບແມ່ນ encapsulated ໃນການຈະລາຈອນ HTTPS ແລະຖືກສົ່ງໄປຫາເຄື່ອງແມ່ຂ່າຍ HTTP, ບ່ອນທີ່ ຕົວແກ້ໄຂດໍາເນີນການຮ້ອງຂໍຜ່ານ Web API.

"DNS over TLS" ແຕກຕ່າງຈາກ "DNS over HTTPS" ໃນການນໍາໃຊ້ໂປໂຕຄອນ DNS ມາດຕະຖານ (ປົກກະຕິພອດເຄືອຂ່າຍ 853), ຫໍ່ຢູ່ໃນຊ່ອງທາງການສື່ສານທີ່ຖືກເຂົ້າລະຫັດທີ່ຖືກຈັດຕັ້ງໂດຍໃຊ້ໂປໂຕຄອນ TLS ດ້ວຍການກວດສອບຄວາມຖືກຕ້ອງຂອງເຈົ້າພາບໂດຍຜ່ານໃບຢັ້ງຢືນ TLS / SSL ທີ່ໄດ້ຮັບການຮັບຮອງ. ໂດຍອົງການຢັ້ງຢືນ. ມາດຕະຖານ DNSSEC ທີ່ມີຢູ່ແລ້ວໃຊ້ການເຂົ້າລະຫັດພຽງແຕ່ເພື່ອພິສູດຢືນຢັນລູກຄ້າແລະເຄື່ອງແມ່ຂ່າຍ, ແຕ່ບໍ່ໄດ້ປົກປ້ອງການຈະລາຈອນຈາກການຂັດຂວາງແລະບໍ່ຮັບປະກັນຄວາມລັບຂອງຄໍາຮ້ອງຂໍ.

ບາງປະດິດສ້າງອື່ນໆ:

• ເພີ່ມ tcp-receive-buffer, tcp-send-buffer, udp-receive-buffer ແລະ udp-send-buffer ເພື່ອກໍານົດຂະຫນາດຂອງ buffers ທີ່ໃຊ້ໃນເວລາສົ່ງແລະຮັບຄໍາຮ້ອງຂໍຜ່ານ TCP ແລະ UDP. ໃນເຊີບເວີທີ່ຫວ່າງ, ການເພີ່ມ buffers ຂາເຂົ້າຈະຊ່ວຍໃຫ້ຫລີກລ່ຽງແພັກເກັດຖືກຫຼຸດລົງໃນລະຫວ່າງການຈະລາຈອນສູງສຸດ, ແລະການຫຼຸດຜ່ອນພວກມັນຈະຊ່ວຍກໍາຈັດການອຸດຕັນຂອງຫນ່ວຍຄວາມຈໍາກັບຄໍາຮ້ອງຂໍເກົ່າ.
• ປະເພດບັນທຶກໃຫມ່ "rpz-passthru" ໄດ້ຖືກເພີ່ມ, ເຊິ່ງຊ່ວຍໃຫ້ທ່ານສາມາດບັນທຶກການສົ່ງຕໍ່ RPZ (ເຂດນະໂຍບາຍການຕອບສະຫນອງ) ແຍກຕ່າງຫາກ.
• ໃນພາກສ່ວນນະໂຍບາຍການຕອບໂຕ້, ທາງເລືອກ "nsdname-wait-recurse" ໄດ້ຖືກເພີ່ມ, ເມື່ອຕັ້ງເປັນ "ບໍ່", ກົດລະບຽບ RPZ NSDNAME ຖືກນໍາໃຊ້ພຽງແຕ່ຖ້າເຄື່ອງແມ່ຂ່າຍຊື່ທີ່ມີອໍານາດທີ່ມີຢູ່ໃນ cache ໄດ້ຖືກພົບເຫັນສໍາລັບການຮ້ອງຂໍ, ຖ້າບໍ່ດັ່ງນັ້ນ. ກົດລະບຽບ RPZ NSDNAME ແມ່ນຖືກລະເລີຍ, ແຕ່ຂໍ້ມູນຈະຖືກດຶງມາໃນພື້ນຫຼັງ ແລະນຳໃຊ້ກັບການຮ້ອງຂໍຕໍ່ໄປ.
• ສໍາລັບບັນທຶກທີ່ມີ HTTPS ແລະ SVCB, ການປະມວນຜົນຂອງພາກສ່ວນ "ເພີ່ມເຕີມ" ໄດ້ຖືກປະຕິບັດ.
• ເພີ່ມປະເພດກົດລະບຽບການປັບປຸງແບບກໍານົດເອງ - krb5-subdomain-self-rhs ແລະ ms-subdomain-self-rhs, ເຊິ່ງຊ່ວຍໃຫ້ທ່ານສາມາດຈໍາກັດການປັບປຸງບັນທຶກ SRV ແລະ PTR. ບລັອກນະໂຍບາຍການປັບປຸງຍັງເພີ່ມຄວາມສາມາດໃນການກໍານົດຂໍ້ຈໍາກັດກ່ຽວກັບຈໍານວນບັນທຶກ, ບຸກຄົນສໍາລັບແຕ່ລະປະເພດ.
• ເພີ່ມຂໍ້ມູນກ່ຽວກັບໂປໂຕຄອນການຂົນສົ່ງ (UDP, TCP, TLS, HTTPS) ແລະ DNS64 ຄໍານໍາຫນ້າກັບຜົນໄດ້ຮັບຂອງຜົນປະໂຫຍດການຂຸດ. ສໍາລັບຈຸດປະສົງ debugging, dig ໄດ້ເພີ່ມຄວາມສາມາດໃນການລະບຸຕົວກໍານົດການຮ້ອງຂໍສະເພາະ (dig +qid= ).
• ເພີ່ມການສະຫນັບສະຫນູນສໍາລັບຫ້ອງສະຫມຸດ OpenSSL 3.0.
• ເພື່ອແກ້ໄຂບັນຫາການແບ່ງແຍກ IP ໃນເວລາປະມວນຜົນຂໍ້ຄວາມ DNS ຂະຫນາດໃຫຍ່ທີ່ຖືກກໍານົດໂດຍ DNS Flag Day 2020, ລະຫັດທີ່ປັບຂະຫນາດ EDNS buffer ເມື່ອບໍ່ມີການຕອບສະຫນອງຕໍ່ການຮ້ອງຂໍໄດ້ຖືກໂຍກຍ້າຍອອກຈາກຕົວແກ້ໄຂ. ຕອນນີ້ EDNS buffer size ຖືກຕັ້ງເປັນຄົງທີ່ (edns-udp-size) ສຳລັບການຮ້ອງຂໍທີ່ອອກມາທັງໝົດ.
• ລະບົບການກໍ່ສ້າງໄດ້ຖືກປ່ຽນໄປໃຊ້ການປະສົມປະສານຂອງ autoconf, automake ແລະ libtool.
• ການ​ສະ​ຫນັບ​ສະ​ຫນູນ​ໄຟລ​໌​ເຂດ​ໃນ​ຮູບ​ແບບ "ແຜນ​ທີ່​" (ແຜນ​ທີ່​ຮູບ​ແບບ masterfile​) ໄດ້​ຖືກ​ຢຸດ​ເຊົາ​ການ​. ຜູ້ໃຊ້ຂອງຮູບແບບນີ້ແມ່ນແນະນໍາໃຫ້ປ່ຽນເຂດເປັນຮູບແບບດິບໂດຍນໍາໃຊ້ຜົນປະໂຫຍດທີ່ມີຊື່ compilezone.
• ການຮອງຮັບໄດເວີ DLZ (Dynamically Loadable Zones) ເກົ່າໄດ້ຢຸດເຊົາ, ແທນທີ່ດ້ວຍໂມດູນ DLZ.
• ການກໍ່ສ້າງແລະດໍາເນີນການສະຫນັບສະຫນູນສໍາລັບເວທີ Windows ໄດ້ຢຸດເຊົາ. ສາຂາສຸດທ້າຍທີ່ສາມາດຕິດຕັ້ງໃນ Windows ແມ່ນ BIND 9.16.

ແຫຼ່ງຂໍ້ມູນ: opennet.ru