إيقاف استخدام أسماء النطاقات في عناوين الموجه

نظرة عامة

اعتبارًا من الإصدار 0.9.32، تحديث مواصفات netdb لإيقاف استخدام أسماء النطاقات في معلومات الموجهات، أو بشكل أدق، في العناوين الفردية للموجه. في جميع تطبيقات I2P، الموجهات الناشرة التي تم تكوينها بأسماء النطاقات يجب أن تستبدلها بعناوين IP قبل النشر، ويجب أن تتجاهل الموجهات الأخرى العناوين التي تحتوي على أسماء نطاقات. ينبغي ألا تقوم الموجهات بعمليات بحث DNS لأسماء النطاقات المنشورة.

الدافع

تم السماح باستخدام أسماء النطاقات في عناوين الموجهات منذ بداية I2P. ومع ذلك، تقوم عدد قليل جدًا من الموجهات بنشر أسماء النطاقات، لأنه يتطلب وجود اسم نطاق عام (وهو ما يمتلكه قليل من المستخدمين)، وتكوين يدوي (وهو ما يقوم به قليل من المستخدمين). في عينة حديثة، كانت 0.7% من الموجهات تنشر اسم نطاق.

كان الغرض الأصلي من أسماء النطاقات مساعدة المستخدمين الذين يمتلكون عناوين IP تتغير بشكل متكرر وخدمة DNS ديناميكية (مثل http://dyn.com/dns/) حتى لا يفقدوا الاتصال عندما يتغير عنوان IP الخاص بهم. ومع ذلك، كان في ذلك الوقت الشبكة صغيرة وكانت مدة انتهاء المعلومات أطول. أيضًا، لم يكن لدى شيفرة Java منطق عامل لإعادة تشغيل الموجه أو إعادة نشر معلومات الموجه عندما يتغير IP المحلي.

أيضًا، في البداية، لم يدعم I2P بروتوكول IPv6، لذا لم يكن هناك تعقيد في تحديد اسم النطاق إلى عنوان IPv4 أو IPv6.

في Java I2P، كان دائمًا من التحديات نشر الاسم المكون إلى النقل المنشور، وأصبح الوضع أكثر تعقيدًا مع IPv6. ليس من الواضح إذا كان الجهاز المزدوج البروتوكول يجب أن ينشر كلا من اسم النطاق وعنوان IPv6 الفعلي. يتم نشر اسم النطاق لعنوان SSU ولكن ليس لعنوان NTCP.

مؤخرًا، تم إثارة قضايا تتعلق بـ DNS (بشكل غير مباشر ومباشر) بواسطة بحث في معهد جورجيا للتكنولوجيا. قامت الباحثين بتشغيل عدد كبير من الملئ بالفيضانات بأسماء نطاقات منشورة. كانت المشكلة المباشرة هي أنه بالنسبة لعدد صغير من المستخدمين الذين قد تكون لديهم DNS محلية مكسورة، فقد تسبب في تعليق I2P بالكامل.

المشكلة الأكبر كانت في نظام أسماء النطاقات بشكل عام، وكيف يمكن استخدام DNS (سواء كان نشطًا أو غير نشط) بسرعة فائقة في تعداد الشبكة، وخاصة إذا كانت الموجهات الناشرة ملء بالفيضانات. يمكن استخدام أسماء النطاقات غير الصالحة أو المستجيبين لـ DNS غير المستجيبين أو البطيئين أو الخبيثين في هجمات إضافية. قد يوفر EDNS0 المزيد من السيناريوهات للتعداد أو الهجوم. قد يوفر DNS أيضًا طرقًا للهجوم بناءً على وقت البحث، كشفت أوقات اتصال الموجه إلى الموجه، تساعد في بناء رسوم بيانية للاتصال، تقدير الحركة، واستنتاجات أخرى.

أيضًا، وضعت المجموعة في معهد جورجيا للتكنولوجيا بقيادة ديفيد داجون عدة مخاوف تتعلق بنظام DNS في التطبيقات التي تركز على الخصوصية. عادةً ما يتم تنفيذ عمليات بحث DNS من قبل مكتبة منخفضة المستوى، لا تتحكم بها التطبيق. لم تصمم هذه المكتبات خصيصًا لحفظ الهوية؛ قد لا توفر تحكم دقيق من قبل التطبيق؛ وقد تكون مخرجاتها قابلة للبصمة. المكتبات الجافا على وجه الخصوص قد تكون إشكالية، لكن هذا ليس مجرد قضية جافا. بعض المكتبات تستخدم استفسارات DNS من نوع ANY التي قد يتم رفضها. وكل هذا يجعل المواقف أكثر إثارة للقلق بسبب الوجود الواسع لمراقبة DNS السلبية والاستفسارات المتاحة لعدة منظمات. كل مراقبة وهجمات DNS هي خارج النطاق من منظور موجهات I2P وتتطلب القليل من الموارد داخل شبكة I2P، ولا تحتاج إلى تعديل تنفيذات موجودة.

بينما لم نفكر بشكل كامل في القضايا المحتملة، يبدو أن سطح الهجوم كبير. هناك طرق أخرى لتعداد الشبكة وجمع البيانات ذات الصلة، لكن قد تكون هجمات DNS أسهل بكثير وأسرع وأقل قابلية للاكتشاف.

يمكن نظريًا تحويل تنفيذات الموجه إلى استخدام مكتبة DNS تابعة لجهة ثالثة معقدة، لكن ذلك سيكون معقدًا للغاية، ويشكل عبء صيانة، ويأتي خارج نطاق خبرة مطوري I2P الأساسية.

الحلول الفورية المنفذة لجافا 0.9.31 تضمنت إصلاح مشكلة التعليق، زيادة أوقات ذاكرة التخزين المؤقت لـ DNS، وتنفيذ ذاكرة التخزين المؤقت السلبية لـ DNS. بالطبع، زيادة أوقات ذاكرة التخزين المؤقت تقلل من فائدة وجود أسماء النطاقات في معلومات الموجه أصلاً.

ومع ذلك، هذه التغييرات هي فقط تخفيفات قصيرة الأجل ولا تحل المشكلات الأساسية المذكورة أعلاه. لذلك، الحل الأبسط والأكثر اكتمالاً هو حظر أسماء النطاقات في معلومات الموجه، وبالتالي القضاء على عمليات البحث عن DNS لها.

التصميم

بالنسبة لكود نشر معلومات الموجه، أمام المنفذين خيارين، إما تعطيل/إزالة خيار تكوين أسماء النطاقات، أو تحويل أسماء النطاقات المكونة إلى عناوين IP في وقت النشر. في كلتا الحالتين، يجب على الموجهات إعادة النشر فورًا عندما يتغير عنوان IP الخاص بها.

بالنسبة لكود التحقق من صحة معلومات الموجه وشفرة وصلة النقل، ينبغي على المنفذين أن يتجاهلوا عناوين الموجه التي تحتوي على أسماء نطاقات، ويستخدموا العناوين الأخرى المنشورة التي تحتوي على عناوين IP، إن وجدت. إذا لم تحتوي أي عناوين في معلومات الموجه على عناوين IP، لا ينبغي للموجه الاتصال بالموجه المنشور. في أي حالة، لا ينبغي للموجه أن يقوم ببحث DNS لاسم نطاق منشور، سواء بشكل مباشر أو عبر مكتبة أساسية.

المواصفات

تغيير مواصفات النقل NTCP وSSU لتوضيح أن معلمة “host” يجب أن تكون عنوان IP، وليس اسم نطاق، وأنه يجب على الموجهات تجاهل عناوين الموجه الفردية التي تحتوي على أسماء النطاقات.

ينطبق هذا أيضًا على المعلمات “ihost0”، “ihost1”، و"ihost2" في عنوان SSU. يجب على الموجهات تجاهل عناوين المعرّف التي تحتوي على أسماء نطاقات.

ملاحظات

هذا الاقتراح لا يعالج أسماء النطاقات لمضيفي reseed. بينما تكون عمليات البحث عن DNS لمضيفي reseed أقل تكرارًا بكثير، قد يظل هناك مشكلة. إذا لزم الأمر، يمكن إصلاح ذلك ببساطة من خلال استبدال أسماء النطاقات بعناوين IP في قائمة عناوين URL الثابتة؛ لن تكون هناك حاجة لإجراء تغييرات في المواصفات أو التعليمات البرمجية.

الترحيل

يمكن تنفيذ هذا الاقتراح على الفور، دون الحاجة إلى ترحيل تدريجي، لأن عددًا قليلًا جدًا من الموجهات تنشر أسماء نطاقات، وأولئك الذين يفعلون ذلك عمومًا لا ينشرون اسم النطاق في جميع العناوين.

لا تحتاج الموجهات للتحقق من إصدار الموجه المنشور قبل أن تقرر تجاهل أسماء النطاقات، ولا هناك حاجة لإصدار منسق أو استراتيجية مشتركة عبر التنفيذات المختلفة للموجهات.

بالنسبة لتلك الموجهات التي لا تزال تنشر أسماء النطاقات، ستحصل على عدد أقل من الاتصالات الواردة، وقد تواجه في النهاية صعوبة في إنشاء الأنفاق الواردة.

للتقليل من التأثير، يمكن للمنفذين أن يبدأوا بتجاهل عناوين الموجهات التي تحتوي على أسماء نطاقات فقط للموجهات الملئ بالفيضانات، أو للموجهات ذات الإصدار المنشور الأقل من 0.9.32، وتجاهل أسماء النطاقات لجميع الموجهات في إصدار لاحق.