ترجمة الاسم لـ GarliCat

Proposal 105
متوقف
Author برنهارد ر. فيشر
Created 2009-12-04
Last Updated 2009-12-04

نظرة عامة

هذا الاقتراح يدور حول إضافة دعم للبحث العكسي لنظام أسماء النطاقات (DNS) إلى I2P.

آلية الترجمة الحالية

يقوم GarliCat (GC) بترجمة الأسماء لإعداد الاتصالات مع عقد أخرى لـ GC. هذه الترجمة للأسماء هي مجرد ترميز للتمثيل الثنائي لعناوين إلى شكل مشفر بـ Base32. لذا، فإن الترجمة تعمل ذهاباً وإياباً.

يتم اختيار هذه العناوين بحيث تكون بطول 80 بت. هذا لأن Tor يستخدم قيم بطول 80 بت لعنونه خدماته المخفية. لذا، يعمل OnionCat (والذي هو GC لـ Tor) مع Tor بدون تدخل إضافي.

لسوء الحظ (فيما يتعلق بهذا المخطط العنونة)، يستخدم I2P قيم بطول 256 بت لعنونه خدماته. كما ذكر سابقاً، يقوم GC بترميز متبادل بين الشكل الثنائي والشكل المشفر بـ Base32. بسبب طبيعة GC كشبكة VPN من الطبقة الثالثة، في تمثيله الثنائي تُعرَّف العناوين كعناوين IPv6 التي إجمالي طولها 128 بت. ومن الواضح أن عناوين I2P التي طولها 256 بت لا تتلائم معها.

لذا، يصبح من الضروري خطوة ثانية من ترجمة الأسماء: عنوان IPv6 (ثنائي) -1a-> عنوان Base32 (80 بت) -2a-> عنوان I2P (256 بت) -1a- … ترجمة GC -2a- … بحث في I2P hosts.txt

الحل الحالي هو السماح لموجه I2P القيام بهذه المهمة. يتم تحقيق ذلك عن طريق إدراج عنوان Base32 بطول 80 بت ووجهته (عنوان I2P) كزوج اسم/قيمة في ملف hosts.txt أو privatehosts.txt لموجه I2P.

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

حل قابل للتوسع

اقترح تغيير مراحل العنونة فيما يتعلق بـ I2P (وربما أيضاً لـ Tor) بحيث يقوم GC بالبحث العكسي لعناوين IPv6 باستخدام بروتوكول DNS التقليدي. يجب أن تحتوي المنطقة العكسية مباشرة على عنوان I2P بطول 256 بت في شكلها المشفر بـ Base32. هذا يغير آلية البحث لخطوة واحدة، مما يضيف مزايا إضافية. عنوان IPv6 (ثنائي) -1b-> عنوان I2P (256 بت) -1b- … البحث العكسي لـ DNS

البحث في DNS في الإنترنت يُعرف بأنه يسرب المعلومات فيما يتعلق بالخصوصية. لذا، يجب إجراء هذه العمليات ضمن I2P. وهذا يستلزم وجود عدة خدمات DNS ضمن I2P. حيث تتم عمليات استعلام DNS عادة باستخدام بروتوكول UDP، فإن GC نفسه مطلوب لنقل البيانات لأنه يحمل حزم UDP التي لا يدعمها I2P بطبيعتها.

هناك فوائد أخرى مرتبطة بـ DNS:

  1. إنه بروتوكول قياسي معروف، وبالتالي يتم تحسينه باستمرار وتوجد العديد من الأدوات (العملاء، الخوادم، المكتبات،…) له.
  2. إنه نظام موزع. يدعم مساحة الأسماء المستضافة على عدة خوادم بالتوازي بشكل افتراضي.
  3. يدعم التشفير (DNSSEC) الذي يمكن من التحقق من صحة سجلات الموارد. يمكن ربط ذلك مباشرةً بمفاتيح الوجهة.

فرص مستقبلية

قد يكون من الممكن أن تُستخدم خدمة التسمية هذه أيضاً للقيام بعمليات البحث الأمامية. وهذا يعني ترجمة أسماء المضيفين إلى عناوين I2P و/أو عناوين IPv6. ولكن هذا النوع من البحث يحتاج إلى مزيد من الدراسة لأن تلك الاستعلامات عادةً ما يقوم بها مكتبة المحلل المثبتة محلياً التي تستخدم خوادم أسماء الإنترنت العادية (مثل المحدد في /etc/resolv.conf على الأنظمة المشابهة لـ Unix). هذا يختلف عن عمليات البحث العكسي لـ GC التي شرحتها أعلاه. فرصة أخرى قد تكون أن يتم تسجيل عنوان I2P (الوجهة) تلقائياً عند إنشاء نفق وارد لـ GC. وهذا سيحسن بشكل كبير من قابلية الاستخدام.