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) र DNS मा TLS (DoT, DNS मा TLS), साथै XoT (XFR-over-TLS) संयन्त्रको लागि समर्थनको कार्यान्वयनको लागि उल्लेखनीय छ। DNS सामग्रीको सुरक्षित स्थानान्तरणको लागि। सर्भरहरू बीचको क्षेत्रहरू (XoT मार्फत पठाउने र प्राप्त गर्ने क्षेत्रहरू समर्थित छन्)। उपयुक्त सेटिङहरूसँग, एकल नामको प्रक्रियाले अब परम्परागत DNS प्रश्नहरू मात्र होइन, DNS-over-HTTPS र DNS-over-TLS प्रयोग गरेर पठाइएका प्रश्नहरू पनि सेवा गर्न सक्छ। 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-over-HTTPS प्रदायकहरूको DNS सर्भरहरू मार्फत अनुरोध गरिएको होस्ट नामहरूको बारेमा जानकारी चुहावट रोक्न, MITM आक्रमणहरू र DNS ट्राफिक स्पूफिङ (उदाहरणका लागि, सार्वजनिक Wi-Fi जडान गर्दा), काउन्टरिङको लागि उपयोगी हुन सक्छ। DNS स्तरमा रोक लगाउने (DNS-over-HTTPS ले DPI स्तरमा लागू गरिएको ब्लकिङलाई बाइपास गर्न VPN लाई प्रतिस्थापन गर्न सक्दैन) वा DNS सर्भरहरूमा प्रत्यक्ष पहुँच गर्न असम्भव हुँदा काम व्यवस्थित गर्न (उदाहरणका लागि, प्रोक्सी मार्फत काम गर्दा)। यदि सामान्य अवस्थामा DNS अनुरोधहरू सिधै प्रणाली कन्फिगरेसनमा परिभाषित DNS सर्भरहरूमा पठाइन्छ, तब DNS-over-HTTPS को मामलामा होस्ट IP ठेगाना निर्धारण गर्ने अनुरोध HTTPS ट्राफिकमा समेटिएको छ र HTTP सर्भरमा पठाइन्छ, जहाँ रिजोल्भरले वेब एपीआई मार्फत अनुरोधहरू प्रक्रिया गर्दछ।

"TLS मा DNS" मानक DNS प्रोटोकल (नेटवर्क पोर्ट 853 सामान्यतया प्रयोग गरिन्छ) को प्रयोग मा "HTTPS मा DNS" भन्दा भिन्न छ, TLS/SSL प्रमाणपत्र प्रमाणित मार्फत होस्ट वैधता जाँच संग TLS प्रोटोकल प्रयोग गरी संगठित एक गुप्तिकरण संचार च्यानलमा बेरिएको। प्रमाणीकरण प्राधिकरण द्वारा। अवस्थित DNSSEC मानकले ग्राहक र सर्भरलाई प्रमाणीकरण गर्न मात्र इन्क्रिप्सन प्रयोग गर्दछ, तर ट्राफिकलाई अवरोधबाट जोगाउँदैन र अनुरोधहरूको गोपनीयताको ग्यारेन्टी गर्दैन।

केहि अन्य आविष्कारहरू:

• TCP र UDP मा अनुरोधहरू पठाउँदा र प्राप्त गर्दा प्रयोग हुने बफरहरूको आकार सेट गर्न tcp-receive-buffer, tcp-send-buffer, udp-receive-buffer र udp-send-buffer सेटिङहरू थपियो। व्यस्त सर्भरहरूमा, बढ्दो आगमन बफरहरूले ट्राफिक शिखरहरूमा प्याकेटहरू छोड्नबाट जोगिन मद्दत गर्नेछ, र तिनीहरूलाई घटाउँदा पुरानो अनुरोधहरूसँग मेमोरी क्लोजिङबाट छुटकारा पाउन मद्दत गर्नेछ।
• नयाँ लग कोटी "rpz-passthru" थपिएको छ, जसले तपाईंलाई RPZ (प्रतिक्रिया नीति क्षेत्रहरू) फर्वार्डिङ कार्यहरू छुट्टै लग गर्न अनुमति दिन्छ।
• प्रतिक्रिया-नीति खण्डमा, "nsdname-wait-recurse" विकल्प थपिएको छ, जब "no" मा सेट गरिएको छ, 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 फ्ल्याग डे २०२० द्वारा पहिचान गरिएका ठूला DNS सन्देशहरू प्रशोधन गर्दा IP खण्डीकरणका समस्याहरूलाई सम्बोधन गर्न, अनुरोधको कुनै प्रतिक्रिया नभएको बेला EDNS बफर साइज समायोजन गर्ने कोडलाई समाधानकर्ताबाट हटाइएको छ। EDNS बफर साइज अब सबै बहिर्गमन अनुरोधहरूको लागि स्थिर (edns-udp-size) मा सेट गरिएको छ।
• निर्माण प्रणाली autoconf, automake र libtool को संयोजन प्रयोग गरेर स्विच गरिएको छ।
• "नक्सा" ढाँचा (मास्टरफाइल-ढाँचा नक्शा) मा क्षेत्र फाइलहरूको लागि समर्थन बन्द गरिएको छ। यस ढाँचाका प्रयोगकर्ताहरूलाई नाम-कम्पाइलजोन उपयोगिता प्रयोग गरी क्षेत्रहरूलाई कच्चा ढाँचामा रूपान्तरण गर्न सिफारिस गरिन्छ।
• पुराना DLZ (गतिशील रूपमा लोड योग्य क्षेत्रहरू) ड्राइभरहरूको लागि समर्थन बन्द गरिएको छ, DLZ मोड्युलहरूद्वारा प्रतिस्थापन गरिएको छ।
• Windows प्लेटफर्मको लागि निर्माण र चलाउन समर्थन बन्द गरिएको छ। विन्डोजमा स्थापना गर्न सकिने अन्तिम शाखा BIND 9.16 हो।

स्रोत: opennet.ru