DNS-over-TLS आणि DNS-over-HTTPS साठी समर्थनासह BIND DNS सर्व्हर 9.18.0 चे प्रकाशन

दोन वर्षांच्या विकासानंतर, ISC कन्सोर्टियमने BIND 9.18 DNS सर्व्हरच्या प्रमुख नवीन शाखेचे पहिले स्थिर प्रकाशन जारी केले आहे. विस्तारित समर्थन चक्राचा भाग म्हणून शाखा 9.18 साठी 2 च्या 2025र्‍या तिमाहीपर्यंत तीन वर्षांसाठी समर्थन प्रदान केले जाईल. 9.11 शाखेसाठी समर्थन मार्चमध्ये संपेल आणि 9.16 च्या मध्यात 2023 शाखेसाठी समर्थन. BIND च्या पुढील स्थिर आवृत्तीची कार्यक्षमता विकसित करण्यासाठी, BIND 9.19.0 ही प्रायोगिक शाखा तयार करण्यात आली आहे.

BIND 9.18.0 चे प्रकाशन HTTPS वर DNS (DoH, DNS वर HTTPS) आणि DNS प्रती TLS (DoT, DNS प्रती TLS), तसेच XoT (XFR-ओव्हर-TLS) यंत्रणेसाठी समर्थनाच्या अंमलबजावणीसाठी लक्षणीय आहे. DNS सामग्रीच्या सुरक्षित हस्तांतरणासाठी सर्व्हरमधील झोन (XoT द्वारे पाठवणे आणि प्राप्त करणे दोन्ही झोन ​​समर्थित आहेत). योग्य सेटिंग्जसह, एकल नावाची प्रक्रिया आता केवळ पारंपारिक DNS क्वेरीच नाही तर DNS-over-HTTPS आणि DNS-over-TLS वापरून पाठवलेल्या क्वेरी देखील देऊ शकते. डीएनएस-ओव्हर-टीएलएससाठी क्लायंट समर्थन डिग युटिलिटीमध्ये तयार केले आहे, जे "+tls" ध्वज निर्दिष्ट केल्यावर TLS वर विनंत्या पाठवण्यासाठी वापरले जाऊ शकते.

DoH मध्ये वापरल्या जाणार्‍या HTTP/2 प्रोटोकॉलची अंमलबजावणी nghttp2 लायब्ररीच्या वापरावर आधारित आहे, ज्याचा समावेश पर्यायी असेंबली अवलंबित्व म्हणून केला जातो. DoH आणि DoT साठी प्रमाणपत्रे वापरकर्त्याद्वारे प्रदान केली जाऊ शकतात किंवा स्टार्टअपच्या वेळी स्वयंचलितपणे तयार केली जाऊ शकतात.

DoH आणि DoT वापरून विनंती प्रक्रिया "http" आणि "tls" पर्याय लिसन-ऑन निर्देशामध्ये जोडून सक्षम केले आहे. एन्क्रिप्ट न केलेल्या 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 स्थानिक-http-सर्व्हर { एंडपॉइंट्स { "/dns-query"; }; }; पर्याय { https-पोर्ट 443; लिसन-ऑन पोर्ट 443 tls local-tls http myserver {any;}; }

BIND मधील DoH अंमलबजावणीचे एक वैशिष्ट्य म्हणजे TLS साठी एनक्रिप्शन ऑपरेशन्स दुसर्‍या सर्व्हरवर हलविण्याची क्षमता, जी TLS प्रमाणपत्रे दुसर्‍या सिस्टमवर (उदाहरणार्थ, वेब सर्व्हरसह इन्फ्रास्ट्रक्चरमध्ये) संग्रहित केली जातात आणि राखली जातात अशा परिस्थितीत आवश्यक असू शकतात. इतर कर्मचार्‍यांकडून. डीबगिंग सुलभ करण्यासाठी आणि अंतर्गत नेटवर्कवरील दुसर्‍या सर्व्हरवर फॉरवर्ड करण्यासाठी (वेगळ्या सर्व्हरवर एनक्रिप्शन हलविण्यासाठी) एक स्तर म्हणून एन्क्रिप्ट न केलेल्या DNS-over-HTTP साठी समर्थन लागू केले आहे. रिमोट सर्व्हरवर, nginx चा वापर TLS ट्रॅफिक व्युत्पन्न करण्यासाठी केला जाऊ शकतो, जसे की वेबसाइट्ससाठी HTTPS बंधनकारक व्यवस्था केली जाते.

आणखी एक वैशिष्ट्य म्हणजे सामान्य वाहतूक म्हणून DoH चे एकत्रीकरण जे केवळ क्लायंटच्या विनंत्या रिझॉल्व्हरला हाताळण्यासाठी वापरले जाऊ शकत नाही तर सर्व्हर दरम्यान संप्रेषण करताना, अधिकृत DNS सर्व्हरद्वारे झोन हस्तांतरित करताना आणि इतर DNS द्वारे समर्थित कोणत्याही क्वेरीवर प्रक्रिया करताना देखील वापरले जाऊ शकते. वाहतूक

DoH/DoT सह बिल्ड अक्षम करून किंवा एनक्रिप्शन दुसर्‍या सर्व्हरवर हलवून ज्या कमतरतांची भरपाई केली जाऊ शकते त्यापैकी, कोड बेसची सामान्य गुंतागुंत आहे - एक अंगभूत HTTP सर्व्हर आणि TLS लायब्ररी जोडली आहे, ज्यामध्ये संभाव्यतः समाविष्ट असू शकते. असुरक्षा आणि हल्ल्यांसाठी अतिरिक्त वेक्टर म्हणून कार्य करतात. तसेच, DoH वापरताना, रहदारी वाढते.

आपण हे लक्षात ठेवूया की डीएनएस-ओव्हर-एचटीटीपीएस प्रदात्यांच्या DNS सर्व्हरद्वारे विनंती केलेल्या होस्टच्या नावांची माहिती लीक रोखण्यासाठी, एमआयटीएम हल्ल्यांचा सामना करण्यासाठी आणि डीएनएस ट्रॅफिक स्पूफिंग (उदाहरणार्थ, सार्वजनिक वाय-फायशी कनेक्ट करताना), काउंटरिंगसाठी उपयुक्त ठरू शकते. डीएनएस स्तरावर ब्लॉक करणे (डीपीआय स्तरावर लागू केलेल्या बायपास ब्लॉकिंगमध्ये डीएनएस-ओव्हर-एचटीटीपीएस व्हीपीएन बदलू शकत नाही) किंवा डीएनएस सर्व्हरवर थेट प्रवेश करणे अशक्य असताना काम आयोजित करण्यासाठी (उदाहरणार्थ, प्रॉक्सीद्वारे काम करताना). जर सामान्य स्थितीत डीएनएस विनंत्या थेट सिस्टम कॉन्फिगरेशनमध्ये परिभाषित केलेल्या डीएनएस सर्व्हरवर पाठवल्या गेल्या असतील, तर डीएनएस-ओव्हर-एचटीटीपीएसच्या बाबतीत होस्ट आयपी पत्ता निर्धारित करण्याची विनंती HTTPS रहदारीमध्ये एन्कॅप्स्युलेट केली जाते आणि HTTP सर्व्हरला पाठविली जाते, जेथे रिझोल्व्हर वेब API द्वारे विनंतीवर प्रक्रिया करतो.

प्रमाणित DNS प्रोटोकॉल (नेटवर्क पोर्ट 853 सहसा वापरला जातो) च्या वापरामध्ये “TLS वर DNS” “DNS over HTTPS” पेक्षा वेगळे आहे, TLS/SSL प्रमाणपत्राद्वारे प्रमाणित केलेल्या होस्ट वैधता तपासणीसह TLS प्रोटोकॉल वापरून आयोजित केलेल्या एनक्रिप्टेड कम्युनिकेशन चॅनेलमध्ये गुंडाळलेले आहे. प्रमाणन प्राधिकरणाद्वारे. विद्यमान DNSSEC मानक केवळ क्लायंट आणि सर्व्हरचे प्रमाणीकरण करण्यासाठी एन्क्रिप्शन वापरते, परंतु ट्रॅफिकला व्यत्यय येण्यापासून संरक्षण देत नाही आणि विनंत्यांच्या गोपनीयतेची हमी देत ​​नाही.

इतर काही नवकल्पना:

• TCP आणि UDP वर विनंत्या पाठवताना आणि प्राप्त करताना वापरलेल्या बफरचे आकार सेट करण्यासाठी tcp-receive-buffer, tcp-send-buffer, udp-receive-buffer आणि udp-send-buffer सेटिंग्ज जोडल्या. व्यस्त सर्व्हरवर, इनकमिंग बफर वाढल्याने ट्रॅफिक पीक दरम्यान पॅकेट्स सोडले जाणे टाळण्यास मदत होईल आणि ते कमी केल्याने जुन्या विनंत्यांसह मेमरी क्लॉजिंगपासून मुक्त होण्यास मदत होईल.
• नवीन लॉग श्रेणी “rpz-pasthru” जोडली गेली आहे, जी तुम्हाला RPZ (प्रतिसाद धोरण क्षेत्र) फॉरवर्डिंग क्रिया स्वतंत्रपणे लॉग करण्याची परवानगी देते.
• प्रतिसाद-पॉलिसी विभागात, “nsdname-wait-recurse” पर्याय जोडला गेला आहे, जेव्हा “नाही” वर सेट केले जाते, तेव्हाच RPZ NSDNAME नियम लागू केले जातात जर कॅशेमध्ये उपस्थित अधिकृत नेम सर्व्हर विनंतीसाठी आढळल्यास, अन्यथा RPZ NSDNAME नियमाकडे दुर्लक्ष केले जाते, परंतु माहिती पार्श्वभूमीत पुनर्प्राप्त केली जाते आणि त्यानंतरच्या विनंत्यांना लागू होते.
• HTTPS आणि SVCB प्रकारांसह रेकॉर्डसाठी, "अतिरिक्त" विभागाची प्रक्रिया लागू केली गेली आहे.
• सानुकूल अपडेट-पॉलिसी नियम प्रकार जोडले - krb5-subdomain-self-rhs आणि ms-subdomain-self-rhs, जे तुम्हाला SRV आणि PTR रेकॉर्डचे अपडेट मर्यादित करू देतात. अपडेट-पॉलिसी ब्लॉक्स प्रत्येक प्रकारासाठी वैयक्तिक रेकॉर्डच्या संख्येवर मर्यादा सेट करण्याची क्षमता देखील जोडतात.
• डिग युटिलिटीच्या आउटपुटमध्ये ट्रान्सपोर्ट प्रोटोकॉल (UDP, TCP, TLS, HTTPS) आणि DNS64 उपसर्ग बद्दल माहिती जोडली. डीबगिंग हेतूंसाठी, dig ने विशिष्ट विनंती ओळखकर्ता (dig +qid=) निर्दिष्ट करण्याची क्षमता जोडली आहे.
• OpenSSL 3.0 लायब्ररीसाठी समर्थन जोडले.
• DNS फ्लॅग डे 2020 द्वारे ओळखल्या गेलेल्या मोठ्या DNS संदेशांवर प्रक्रिया करताना IP विखंडन समस्यांचे निराकरण करण्यासाठी, विनंतीला प्रतिसाद नसताना EDNS बफर आकार समायोजित करणारा कोड रिझोल्व्हरकडून काढून टाकण्यात आला आहे. EDNS बफर आकार आता सर्व आउटगोइंग विनंत्यांसाठी स्थिर (edns-udp-size) वर सेट केला आहे.
• autoconf, automake आणि libtool च्या संयोजनाचा वापर करून बिल्ड सिस्टम स्विच केले गेले आहे.
• “नकाशा” स्वरूपातील (मास्टरफाइल-स्वरूप नकाशा) झोन फाइल्ससाठी समर्थन बंद केले गेले आहे. या फॉरमॅटच्या वापरकर्त्यांना नाव-कंपाइलझोन युटिलिटी वापरून झोन रॉ फॉरमॅटमध्ये रूपांतरित करण्याची शिफारस केली जाते.
• जुन्या DLZ (डायनॅमिकली लोड करण्यायोग्य झोन) ड्रायव्हर्ससाठी समर्थन बंद केले आहे, DLZ मॉड्यूल्सने बदलले आहे.
• विंडोज प्लॅटफॉर्मसाठी समर्थन तयार करा आणि चालवा बंद केले गेले आहे. Windows वर स्थापित करता येणारी शेवटची शाखा BIND 9.16 आहे.

स्त्रोत: opennet.ru