DNS-over-TLS ۽ DNS-over-HTTPS لاءِ سپورٽ سان BIND DNS سرور 9.18.0 جو رليز

ٻن سالن جي ترقي کان پوء، ISC کنسورشيم BIND 9.18 DNS سرور جي وڏي نئين شاخ جي پهرين مستحڪم رليز جاري ڪئي. شاخ 9.18 لاءِ مدد فراهم ڪئي ويندي ٽن سالن تائين 2 جي 2025nd چوٿين تائين وڌايل سپورٽ چڪر جي حصي طور. 9.11 برانچ لاءِ سپورٽ مارچ ۾ ختم ٿي ويندي، ۽ 9.16 برانچ لاءِ سپورٽ 2023 جي وچ ۾. BIND جي ايندڙ مستحڪم ورزن جي ڪارڪردگي کي ترقي ڪرڻ لاء، هڪ تجرباتي شاخ BIND 9.19.0 ٺاهي وئي آهي.

BIND 9.18.0 جو رليز قابل ذڪر آهي DNS مٿان HTTPS (DoH، DNS مٿان HTTPS) ۽ 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 parameters ذريعي ختم ڪري سگھجن ٿا. مثال طور:

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؛ ٻڌڻ تي پورٽ 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 ٽرئفڪ جي اسپفنگ (مثال طور، جڏهن عوامي وائي فائي سان ڳنڍڻ)، انسداد DNS سطح تي بلاڪ ڪرڻ (DNS-over-HTTPS DPI سطح تي لاڳو ٿيل بلاڪنگ کي بائي پاس ڪرڻ ۾ VPN کي تبديل نٿو ڪري سگهي) يا ڪم کي منظم ڪرڻ لاءِ جڏهن سڌو سنئون DNS سرور تائين رسائي ناممڪن آهي (مثال طور، جڏهن هڪ پراڪسي ذريعي ڪم ڪندي). جيڪڏهن عام صورتحال ۾ DNS درخواستون سڌو سنئون DNS سرور ڏانهن موڪليا وڃن ٿيون جيڪي سسٽم جي ترتيب ۾ بيان ڪيل آهن، پوء DNS-over-HTTPS جي صورت ۾ ميزبان IP پتي کي طئي ڪرڻ جي درخواست HTTPS ٽرئفڪ ۾ شامل ڪئي وئي آهي ۽ HTTP سرور ڏانهن موڪليو ويو آهي، جتي حل ڪندڙ ويب API ذريعي درخواستن تي عمل ڪري ٿو.

"DNS over TLS" معياري DNS پروٽوڪول جي استعمال ۾ "DNS over HTTPS" کان مختلف آهي (نيٽ ورڪ پورٽ 853 عام طور تي استعمال ڪيو ويندو آهي)، هڪ اينڪريپٽ ٿيل ڪميونيڪيشن چينل ۾ ويڙهيل TLS پروٽوڪول کي استعمال ڪندي منظم ڪيل TLS/SSL سرٽيفڪيٽن ذريعي تصديق ٿيل ميزباني جي تصديق سان. هڪ سرٽيفڪيشن اٿارٽي طرفان. موجوده DNSSEC معيار صرف ڪلائنٽ ۽ سرور جي تصديق ڪرڻ لاءِ انڪرپشن استعمال ڪري ٿو، پر ٽرئفڪ کي مداخلت کان نٿو بچائي ۽ درخواستن جي رازداري جي ضمانت نٿو ڏئي.

ڪجھ ٻيون جدت:

  • شامل ڪيو ويو tcp-receive-buffer, tcp-send-buffer, udp-receive-buffer ۽ udp-send-buffer سيٽنگون استعمال ٿيل بفرن جي سائز کي سيٽ ڪرڻ لاءِ جڏهن TCP ۽ UDP تي درخواستون موڪلڻ ۽ وصول ڪرڻ لاءِ. مصروف سرورن تي، ايندڙ ايندڙ بفرن کي وڌائڻ ۾ مدد ملندي ٽريفڪ جي چوٽيءَ دوران پيڪن کي ڇڏڻ کان بچڻ ۾، ۽ انھن کي گھٽائڻ ۾ مدد ملندي پراڻن درخواستن سان ميموري ڪلجنگ کان نجات حاصل ڪرڻ ۾.
  • هڪ نئون لاگ ڪيٽيگري ”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 +qid= ).
  • OpenSSL 3.0 لائبريري لاءِ سپورٽ شامل ڪئي وئي.
  • IP فرگمينٽيشن سان مسئلن کي حل ڪرڻ لاءِ جڏهن DNS فليگ ڊي 2020 پاران سڃاڻپ ٿيل وڏي ڊي اين ايس پيغامن کي پروسيس ڪندي، ڪوڊ جيڪو EDNS بفر جي سائيز کي ترتيب ڏئي ٿو جڏهن درخواست جو ڪو جواب نه آهي حل ڪندڙ کان هٽايو ويو آهي. EDNS بفر جي سائيز ھاڻي مقرر ڪئي وئي آھي مستقل (edns-udp-size) سڀني ٻاھرين درخواستن لاءِ.
  • تعميراتي نظام کي تبديل ڪيو ويو آهي autoconf، automake ۽ libtool جي ميلاپ کي استعمال ڪندي.
  • "نقشي" فارميٽ ۾ زون فائلن لاءِ سپورٽ (ماسٽر فائل فارميٽ نقشي) کي بند ڪيو ويو آھي. هن فارميٽ جي استعمال ڪندڙن کي صلاح ڏني وئي آهي ته زونن کي خام فارميٽ ۾ تبديل ڪن نالي-compilezone افاديت استعمال ڪندي.
  • پراڻن DLZ (Dynamically Loadable Zones) ڊرائيورن لاءِ سپورٽ بند ڪئي وئي، DLZ ماڊلز جي بدلي.
  • ونڊوز پليٽ فارم لاءِ تعمير ۽ هلائڻ جي سپورٽ کي بند ڪيو ويو آهي. آخري شاخ جيڪا ونڊوز تي نصب ٿي سگهي ٿي BIND 9.16 آهي.

جو ذريعو: opennet.ru

تبصرو شامل ڪريو