DNS-ওভার-TLS এবং DNS-ওভার-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, HTTPS এর উপর DNS) এবং TLS এর উপর DNS (DoT, TLS এর উপর DNS), সেইসাথে 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-ওভার-HTTP সমর্থন করতে, আপনাকে সেটিংসে "tls none" উল্লেখ করতে হবে। কীগুলি "tls" বিভাগে সংজ্ঞায়িত করা হয়েছে। ডিফল্ট নেটওয়ার্ক পোর্ট 853 DoT-এর জন্য, 443 DoH-এর জন্য এবং 80-এর জন্য DNS-over-HTTP-এর জন্য tls-port, https-পোর্ট এবং http-পোর্ট প্যারামিটারের মাধ্যমে ওভাররাইড করা যেতে পারে। উদাহরণ স্বরূপ:

tls local-tls { কী-ফাইল "/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-ওভার-HTTP-এর জন্য সমর্থন ডিবাগিং সহজ করার জন্য এবং অভ্যন্তরীণ নেটওয়ার্কের অন্য সার্ভারে ফরওয়ার্ড করার জন্য একটি স্তর হিসাবে প্রয়োগ করা হয় (একটি পৃথক সার্ভারে এনক্রিপশন সরানোর জন্য)। একটি দূরবর্তী সার্ভারে, nginx টিএলএস ট্র্যাফিক তৈরি করতে ব্যবহার করা যেতে পারে, যেভাবে ওয়েবসাইটগুলির জন্য HTTPS বাইন্ডিং সংগঠিত হয়।

আরেকটি বৈশিষ্ট্য হল সাধারণ পরিবহন হিসাবে DoH এর একীকরণ যা শুধুমাত্র সমাধানকারীর কাছে ক্লায়েন্টের অনুরোধগুলি পরিচালনা করার জন্যই নয়, সার্ভারের মধ্যে যোগাযোগ করার সময়, একটি প্রামাণিক DNS সার্ভার দ্বারা অঞ্চল স্থানান্তর করার সময় এবং অন্যান্য DNS দ্বারা সমর্থিত যেকোনো প্রশ্ন প্রক্রিয়া করার সময়ও ব্যবহার করা যেতে পারে। পরিবহন

DoH/DoT দিয়ে বিল্ডটি নিষ্ক্রিয় করে বা অন্য সার্ভারে এনক্রিপশন সরানোর মাধ্যমে যে ত্রুটিগুলি পূরণ করা যেতে পারে, তার মধ্যে কোড বেসের সাধারণ জটিলতা দেখা যায় - একটি অন্তর্নির্মিত HTTP সার্ভার এবং TLS লাইব্রেরি যোগ করা হয়েছে, যা সম্ভাব্য থাকতে পারে দুর্বলতা এবং আক্রমণের জন্য অতিরিক্ত ভেক্টর হিসাবে কাজ করে। এছাড়াও, DoH ব্যবহার করার সময়, ট্রাফিক বৃদ্ধি পায়।

আমাদের স্মরণ করা যাক যে ডিএনএস-ওভার-এইচটিটিপিএস প্রোভাইডারদের ডিএনএস সার্ভারের মাধ্যমে অনুরোধ করা হোস্টের নাম সম্পর্কে তথ্য ফাঁস প্রতিরোধে, এমআইটিএম আক্রমণ এবং ডিএনএস ট্র্যাফিক স্পুফিং (উদাহরণস্বরূপ, পাবলিক ওয়াই-ফাইয়ের সাথে সংযোগ করার সময়) প্রতিরোধের জন্য কার্যকর হতে পারে। ডিএনএস স্তরে ব্লক করা (ডিএনএস-ওভার-এইচটিটিপিএস ডিপিআই স্তরে প্রয়োগ করা ব্লকিং বাইপাসিংয়ে কোনও ভিপিএন প্রতিস্থাপন করতে পারে না) বা যখন সরাসরি ডিএনএস সার্ভার অ্যাক্সেস করা অসম্ভব (উদাহরণস্বরূপ, প্রক্সির মাধ্যমে কাজ করার সময়) কাজ সংগঠিত করার জন্য। যদি একটি স্বাভাবিক পরিস্থিতিতে ডিএনএস অনুরোধগুলি সরাসরি সিস্টেম কনফিগারেশনে সংজ্ঞায়িত ডিএনএস সার্ভারে পাঠানো হয়, তবে ডিএনএস-ওভার-এইচটিটিপিএসের ক্ষেত্রে হোস্ট আইপি ঠিকানা নির্ধারণের অনুরোধটি HTTPS ট্র্যাফিকের মধ্যে এনক্যাপসুলেট করা হয় এবং HTTP সার্ভারে পাঠানো হয়, যেখানে সমাধানকারী ওয়েব API এর মাধ্যমে অনুরোধগুলি প্রক্রিয়া করে।

স্ট্যান্ডার্ড ডিএনএস প্রোটোকল (নেটওয়ার্ক পোর্ট 853 সাধারণত ব্যবহার করা হয়) ব্যবহারে "TLS ওভার DNS" "DNS ওভার HTTPS" থেকে আলাদা, TLS/SSL সার্টিফিকেটের মাধ্যমে হোস্টের বৈধতা যাচাইয়ের সাথে TLS প্রোটোকল ব্যবহার করে সংগঠিত একটি এনক্রিপ্ট করা যোগাযোগ চ্যানেলে মোড়ানো। একটি সার্টিফিকেশন কর্তৃপক্ষ দ্বারা। বিদ্যমান DNSSEC মান শুধুমাত্র ক্লায়েন্ট এবং সার্ভারকে প্রমাণীকরণের জন্য এনক্রিপশন ব্যবহার করে, কিন্তু ট্রাফিককে বাধা থেকে রক্ষা করে না এবং অনুরোধের গোপনীয়তার গ্যারান্টি দেয় না।

কিছু অন্যান্য উদ্ভাবন:

• TCP এবং UDP-তে অনুরোধ পাঠানো এবং গ্রহণ করার সময় ব্যবহৃত বাফারের মাপ সেট করতে tcp-receive-buffer, tcp-send-buffer, udp-receive-buffer এবং udp-send-buffer সেটিংস যোগ করা হয়েছে। ব্যস্ত সার্ভারে, ইনকামিং বাফারগুলি ক্রমবর্ধমান ট্র্যাফিক পিক চলাকালীন প্যাকেটগুলিকে বাদ দেওয়া এড়াতে সাহায্য করবে এবং সেগুলি হ্রাস করা পুরানো অনুরোধগুলির সাথে মেমরি আটকানো থেকে মুক্তি পেতে সহায়তা করবে৷
• একটি নতুন লগ ক্যাটাগরি "rpz-passthru" যোগ করা হয়েছে, যা আপনাকে আলাদাভাবে 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 +qid= )
• OpenSSL 3.0 লাইব্রেরির জন্য সমর্থন যোগ করা হয়েছে।
• ডিএনএস ফ্ল্যাগ ডে 2020 দ্বারা চিহ্নিত বড় ডিএনএস বার্তাগুলি প্রক্রিয়া করার সময় আইপি ফ্র্যাগমেন্টেশনের সমস্যাগুলি সমাধান করার জন্য, কোনও অনুরোধের কোনও প্রতিক্রিয়া না থাকলে EDNS বাফারের আকার সামঞ্জস্য করে এমন কোডটি সমাধানকারী থেকে সরিয়ে দেওয়া হয়েছে। সমস্ত বহির্গামী অনুরোধের জন্য EDNS বাফার আকার এখন ধ্রুবক (edns-udp-size) সেট করা হয়েছে।
• বিল্ড সিস্টেমটি অটোকনফ, অটোমেক এবং লিবটুল এর সংমিশ্রণ ব্যবহার করে সুইচ করা হয়েছে।
• "মানচিত্র" বিন্যাসে (মাস্টারফাইল-ফরম্যাট মানচিত্র) জোন ফাইলগুলির জন্য সমর্থন বন্ধ করা হয়েছে। এই বিন্যাসের ব্যবহারকারীদের নাম-কম্পাইলজোন ইউটিলিটি ব্যবহার করে অঞ্চলগুলিকে কাঁচা বিন্যাসে রূপান্তর করার পরামর্শ দেওয়া হচ্ছে।
• পুরানো DLZ (গতিশীলভাবে লোডযোগ্য অঞ্চল) ড্রাইভারগুলির জন্য সমর্থন বন্ধ করা হয়েছে, DLZ মডিউল দ্বারা প্রতিস্থাপিত হয়েছে।
• উইন্ডোজ প্ল্যাটফর্মের জন্য বিল্ড এবং রান সমর্থন বন্ধ করা হয়েছে। উইন্ডোজে ইনস্টল করা শেষ শাখাটি হল BIND 9.16।

উত্স: opennet.ru