DNS-over-TLS और DNS-over-HTTPS के समर्थन के साथ BIND DNS सर्वर 9.18.0 का रिलीज़

दो साल के विकास के बाद, ISC कंसोर्टियम ने BIND 9.18 DNS सर्वर की एक प्रमुख नई शाखा की पहली स्थिर रिलीज़ जारी की है। विस्तारित समर्थन चक्र के हिस्से के रूप में शाखा 9.18 के लिए 2 की दूसरी तिमाही तक तीन वर्षों के लिए सहायता प्रदान की जाएगी। 2025 शाखा के लिए समर्थन मार्च में समाप्त हो जाएगा, और 9.11 शाखा के लिए समर्थन 9.16 के मध्य में समाप्त हो जाएगा। BIND के अगले स्थिर संस्करण की कार्यक्षमता विकसित करने के लिए, एक प्रायोगिक शाखा BIND 2023 का गठन किया गया है।

BIND 9.18.0 की रिलीज़ HTTPS पर DNS (DoH, HTTPS पर DNS) और TLS पर DNS (DoT, TLS पर DNS) के साथ-साथ XoT (XFR-over-TLS) तंत्र के लिए समर्थन के कार्यान्वयन के लिए उल्लेखनीय है। DNS सामग्री के सुरक्षित हस्तांतरण के लिए। सर्वरों के बीच ज़ोन (XoT के माध्यम से भेजने और प्राप्त करने वाले ज़ोन दोनों समर्थित हैं)। उपयुक्त सेटिंग्स के साथ, एक एकल नामित प्रक्रिया अब न केवल पारंपरिक डीएनएस क्वेरीज़, बल्कि डीएनएस-ओवर-एचटीटीपीएस और डीएनएस-ओवर-टीएलएस का उपयोग करके भेजी गई क्वेरीज़ भी प्रदान कर सकती है। डीएनएस-ओवर-टीएलएस के लिए क्लाइंट समर्थन डिग उपयोगिता में बनाया गया है, जिसका उपयोग "+टीएलएस" ध्वज निर्दिष्ट होने पर टीएलएस पर अनुरोध भेजने के लिए किया जा सकता है।

DoH में प्रयुक्त HTTP/2 प्रोटोकॉल का कार्यान्वयन nghttp2 लाइब्रेरी के उपयोग पर आधारित है, जिसे वैकल्पिक असेंबली निर्भरता के रूप में शामिल किया गया है। DoH और DoT के लिए प्रमाणपत्र उपयोगकर्ता द्वारा प्रदान किए जा सकते हैं या स्टार्टअप समय पर स्वचालित रूप से जेनरेट किए जा सकते हैं।

DoH और DoT का उपयोग करके अनुरोध प्रसंस्करण को सुनने के निर्देश में "http" और "tls" विकल्प जोड़कर सक्षम किया गया है। अनएन्क्रिप्टेड DNS-ओवर-HTTP का समर्थन करने के लिए, आपको सेटिंग्स में "tls none" निर्दिष्ट करना चाहिए। कुंजियाँ "टीएलएस" अनुभाग में परिभाषित की गई हैं। DoT के लिए डिफ़ॉल्ट नेटवर्क पोर्ट 853, DoH के लिए 443 और DNS-over-HTTP के लिए 80 को tls-port, https-port और http-port पैरामीटर के माध्यम से ओवरराइड किया जा सकता है। उदाहरण के लिए:

tls लोकल-tls { key-file "/path/to/priv_key.pem"; सर्टिफिकेट-फ़ाइल "/path/to/cert_चेन.pem"; }; http स्थानीय-http-सर्वर { समापन बिंदु { "/dns-query"; }; }; विकल्प { https-पोर्ट 443; लिसन-ऑन पोर्ट 443 टीएलएस लोकल-टीएलएस http मायसर्वर {कोई भी;}; }

BIND में DoH कार्यान्वयन की विशेषताओं में से एक TLS के लिए एन्क्रिप्शन संचालन को दूसरे सर्वर पर स्थानांतरित करने की क्षमता है, जो उन स्थितियों में आवश्यक हो सकता है जहां TLS प्रमाणपत्र किसी अन्य सिस्टम पर संग्रहीत होते हैं (उदाहरण के लिए, वेब सर्वर के साथ बुनियादी ढांचे में) और बनाए रखा जाता है अन्य कर्मियों द्वारा. डिबगिंग को सरल बनाने और आंतरिक नेटवर्क पर किसी अन्य सर्वर पर अग्रेषित करने के लिए एक परत के रूप में (एन्क्रिप्शन को एक अलग सर्वर पर ले जाने के लिए) अनएन्क्रिप्टेड डीएनएस-ओवर-HTTP के लिए समर्थन लागू किया गया है। किसी दूरस्थ सर्वर पर, nginx का उपयोग TLS ट्रैफ़िक उत्पन्न करने के लिए किया जा सकता है, ठीक उसी तरह जैसे वेबसाइटों के लिए HTTPS बाइंडिंग को व्यवस्थित किया जाता है।

एक अन्य विशेषता एक सामान्य परिवहन के रूप में DoH का एकीकरण है जिसका उपयोग न केवल रिज़ॉल्वर के लिए क्लाइंट अनुरोधों को संभालने के लिए किया जा सकता है, बल्कि सर्वर के बीच संचार करते समय, एक आधिकारिक DNS सर्वर द्वारा ज़ोन स्थानांतरित करते समय, और अन्य DNS द्वारा समर्थित किसी भी प्रश्न को संसाधित करते समय भी किया जा सकता है। परिवहन.

DoH/DoT के साथ बिल्ड को अक्षम करके या एन्क्रिप्शन को किसी अन्य सर्वर पर ले जाकर जिन कमियों की भरपाई की जा सकती है, उनमें कोड बेस की सामान्य जटिलता सामने आती है - एक अंतर्निहित HTTP सर्वर और TLS लाइब्रेरी जोड़ी जाती है, जो संभावित रूप से शामिल हो सकती है कमजोरियाँ और हमलों के लिए अतिरिक्त वैक्टर के रूप में कार्य करते हैं। साथ ही, DoH का उपयोग करने पर ट्रैफ़िक बढ़ जाता है।

आइए याद रखें कि DNS-ओवर-HTTPS प्रदाताओं के DNS सर्वर के माध्यम से अनुरोधित होस्ट नामों के बारे में जानकारी के लीक को रोकने, MITM हमलों और DNS ट्रैफ़िक स्पूफिंग (उदाहरण के लिए, सार्वजनिक वाई-फाई से कनेक्ट होने पर) का मुकाबला करने के लिए उपयोगी हो सकता है। डीएनएस स्तर पर ब्लॉक करना (डीपीआई स्तर पर कार्यान्वित ब्लॉकिंग को बायपास करने में डीएनएस-ओवर-एचटीटीपीएस वीपीएन को प्रतिस्थापित नहीं कर सकता है) या काम को व्यवस्थित करने के लिए जब डीएनएस सर्वर तक सीधे पहुंच असंभव हो (उदाहरण के लिए, प्रॉक्सी के माध्यम से काम करते समय)। यदि सामान्य स्थिति में DNS अनुरोध सीधे सिस्टम कॉन्फ़िगरेशन में परिभाषित DNS सर्वर पर भेजे जाते हैं, तो DNS-ओवर-HTTPS के मामले में होस्ट IP पता निर्धारित करने का अनुरोध HTTPS ट्रैफ़िक में समाहित किया जाता है और HTTP सर्वर पर भेजा जाता है, जहां रिज़ॉल्वर वेब एपीआई के माध्यम से अनुरोधों को संसाधित करता है।

मानक DNS प्रोटोकॉल (आमतौर पर नेटवर्क पोर्ट 853 का उपयोग किया जाता है) के उपयोग में "टीएलएस पर डीएनएस" "एचटीटीपीएस पर डीएनएस" से भिन्न होता है, जो प्रमाणित टीएलएस/एसएसएल प्रमाणपत्रों के माध्यम से होस्ट वैधता जांच के साथ टीएलएस प्रोटोकॉल का उपयोग करके आयोजित एक एन्क्रिप्टेड संचार चैनल में लपेटा जाता है। प्रमाणन प्राधिकारी द्वारा. मौजूदा DNSSEC मानक केवल क्लाइंट और सर्वर को प्रमाणित करने के लिए एन्क्रिप्शन का उपयोग करता है, लेकिन ट्रैफ़िक को अवरोध से नहीं बचाता है और अनुरोधों की गोपनीयता की गारंटी नहीं देता है।

कुछ अन्य नवाचार:

• टीसीपी और यूडीपी पर अनुरोध भेजते और प्राप्त करते समय उपयोग किए जाने वाले बफ़र्स के आकार को सेट करने के लिए टीसीपी-रिसीव-बफ़र, टीसीपी-सेंड-बफ़र, यूडीपी-रिसीव-बफ़र और यूडीपी-सेंड-बफ़र सेटिंग्स जोड़ी गईं। व्यस्त सर्वर पर, इनकमिंग बफ़र्स बढ़ाने से ट्रैफ़िक चरम के दौरान पैकेट गिरने से बचने में मदद मिलेगी, और उन्हें कम करने से पुराने अनुरोधों के साथ मेमोरी क्लॉगिंग से छुटकारा पाने में मदद मिलेगी।
• एक नई लॉग श्रेणी "आरपीज़-पासथ्रू" जोड़ी गई है, जो आपको आरपीजेड (रिस्पॉन्स पॉलिसी जोन) अग्रेषण कार्यों को अलग से लॉग करने की अनुमति देती है।
• प्रतिक्रिया-नीति अनुभाग में, "nsdname-wait-recurse" विकल्प जोड़ा गया है, जब "नहीं" पर सेट किया जाता है, तो RPZ NSDNAME नियम केवल तभी लागू होते हैं जब कैश में मौजूद आधिकारिक नाम सर्वर अनुरोध के लिए पाए जाते हैं, अन्यथा RPZ NSDNAME नियम को नजरअंदाज कर दिया जाता है, लेकिन जानकारी पृष्ठभूमि में पुनर्प्राप्त की जाती है और बाद के अनुरोधों पर लागू होती है।
• HTTPS और SVCB प्रकार वाले रिकॉर्ड के लिए, "अतिरिक्त" अनुभाग का प्रसंस्करण लागू किया गया है।
• कस्टम अपडेट-पॉलिसी नियम प्रकार जोड़े गए - krb5-subdomain-self-rhs और ms-subdomain-self-rhs, जो आपको SRV और PTR रिकॉर्ड के अपडेट को सीमित करने की अनुमति देते हैं। अद्यतन-नीति ब्लॉक प्रत्येक प्रकार के लिए अलग-अलग रिकॉर्ड की संख्या पर सीमा निर्धारित करने की क्षमता भी जोड़ते हैं।
• डिग उपयोगिता के आउटपुट में ट्रांसपोर्ट प्रोटोकॉल (यूडीपी, टीसीपी, टीएलएस, एचटीटीपीएस) और डीएनएस64 उपसर्गों के बारे में जानकारी जोड़ी गई। डिबगिंग उद्देश्यों के लिए, dig ने एक विशिष्ट अनुरोध पहचानकर्ता (dig +qid=) निर्दिष्ट करने की क्षमता जोड़ी है ).
• ओपनएसएसएल 3.0 लाइब्रेरी के लिए समर्थन जोड़ा गया।
• डीएनएस फ्लैग डे 2020 द्वारा पहचाने गए बड़े डीएनएस संदेशों को संसाधित करते समय आईपी विखंडन के मुद्दों को संबोधित करने के लिए, अनुरोध का कोई जवाब नहीं होने पर ईडीएनएस बफर आकार को समायोजित करने वाले कोड को रिज़ॉल्वर से हटा दिया गया है। EDNS बफ़र आकार अब सभी आउटगोइंग अनुरोधों के लिए स्थिर (edns-udp-size) पर सेट है।
• बिल्ड सिस्टम को ऑटोकॉन्फ, ऑटोमेक और लिबटूल के संयोजन का उपयोग करके स्विच किया गया है।
• "मैप" प्रारूप (मास्टरफ़ाइल-प्रारूप मानचित्र) में ज़ोन फ़ाइलों के लिए समर्थन बंद कर दिया गया है। इस प्रारूप के उपयोगकर्ताओं को नामांकित-कंपाइलज़ोन उपयोगिता का उपयोग करके ज़ोन को कच्चे प्रारूप में बदलने की सलाह दी जाती है।
• पुराने DLZ (डायनामिकली लोडेबल ज़ोन) ड्राइवरों के लिए समर्थन बंद कर दिया गया है, उनकी जगह DLZ मॉड्यूल ने ले ली है।
• विंडोज़ प्लेटफ़ॉर्म के लिए बिल्ड और रन समर्थन बंद कर दिया गया है। विंडोज़ पर स्थापित की जा सकने वाली अंतिम शाखा BIND 9.16 है।

स्रोत: opennet.ru