بعد عامين من التطوير، أصدر اتحاد ISC أول إصدار مستقر لفرع رئيسي جديد لخادم BIND 9.18 DNS. سيتم تقديم الدعم للفرع 9.18 لمدة ثلاث سنوات حتى الربع الثاني من عام 2 كجزء من دورة دعم ممتدة. وسينتهي دعم فرع 2025 في شهر مارس، ودعم فرع 9.11 في منتصف عام 9.16. لتطوير وظيفة الإصدار المستقر التالي من BIND، تم إنشاء فرع تجريبي BIND 2023.
يتميز إصدار BIND 9.18.0 بتنفيذ دعم DNS عبر HTTPS (DoH، DNS عبر HTTPS) وDNS عبر TLS (DoT، DNS over TLS)، بالإضافة إلى آلية XoT (XFR-over-TLS) للنقل الآمن لمناطق محتوى DNS بين الخوادم (يتم دعم مناطق الإرسال والاستقبال عبر XoT). باستخدام الإعدادات المناسبة، يمكن الآن لعملية مسماة واحدة أن تخدم ليس فقط استعلامات DNS التقليدية، ولكن أيضًا الاستعلامات المرسلة باستخدام DNS-over-HTTPS وDNS-over-TLS. تم دمج دعم العملاء لـ DNS-over-TLS في الأداة المساعدة dig، والتي يمكن استخدامها لإرسال الطلبات عبر TLS عند تحديد علامة "+tls".
يعتمد تنفيذ بروتوكول HTTP/2 المستخدم في DoH على استخدام مكتبة 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 { ملف المفتاح "/path/to/priv_key.pem"; ملف الشهادة "/path/to/cert_chain.pem"; }; http local-http-server { endpoints { "/dns-query"; }; }; الخيارات {https-المنفذ 443؛ منفذ الاستماع 443 tls local-tls http myserver {any;}; }
إحدى ميزات تنفيذ DoH في BIND هي القدرة على نقل عمليات التشفير لـ 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 أن يحل محل VPN في تجاوز الحظر المطبق على مستوى DPI) أو لتنظيم العمل عندما يكون من المستحيل الوصول مباشرة إلى خوادم DNS (على سبيل المثال، عند العمل من خلال وكيل). إذا تم إرسال طلبات DNS في الوضع العادي مباشرة إلى خوادم DNS المحددة في تكوين النظام، ففي حالة DNS-over-HTTPS، يتم تغليف طلب تحديد عنوان IP المضيف في حركة مرور HTTPS وإرساله إلى خادم HTTP، حيث يقوم المحلل بمعالجة الطلبات عبر Web API.
يختلف "DNS over TLS" عن "DNS over HTTPS" في استخدام بروتوكول DNS القياسي (يتم استخدام منفذ الشبكة 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"، عند التعيين على "لا"، يتم تطبيق قواعد 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.
- لمعالجة المشكلات المتعلقة بتجزئة IP عند معالجة رسائل DNS الكبيرة التي تم تحديدها بواسطة DNS Flag Day 2020، تمت إزالة التعليمات البرمجية التي تضبط حجم المخزن المؤقت EDNS عندما لا تكون هناك استجابة لطلب من المحلل. تم الآن ضبط حجم المخزن المؤقت EDNS على ثابت (edns-udp-size) لجميع الطلبات الصادرة.
- تم تحويل نظام البناء إلى استخدام مزيج من autoconf وautomake وlibtool.
- تم إيقاف دعم ملفات المنطقة بتنسيق "الخريطة" (خريطة تنسيق الملف الرئيسي). يُنصح مستخدمو هذا التنسيق بتحويل المناطق إلى تنسيق أولي باستخدام الأداة المساعدة المسماة -compilezone.
- تم إيقاف دعم برامج تشغيل DLZ الأقدم (المناطق القابلة للتحميل ديناميكيًا)، وتم استبدالها بوحدات DLZ.
- لقد تم إيقاف دعم إنشاء وتشغيل نظام التشغيل Windows. آخر فرع يمكن تثبيته على Windows هو BIND 9.16.
المصدر: opennet.ru