الحالة
تمت الموافقة في المراجعة الثانية بتاريخ 2025-04-01؛ المواصفات محدثة؛ لم يتم تنفيذها بعد.
نظرة عامة
يخلو I2P من نظام DNS مركزي. ومع ذلك، فإن دفتر العناوين، جنبًا إلى جنب مع نظام اسم المضيف b32، يسمح للموجه بالبحث عن وجهات كاملة واسترجاع مجموعات التأجير (lease sets)، التي تحتوي على قائمة من البوابات والمفاتيح بحيث يمكن للعملاء الاتصال بتلك الوجهة.
إذًا، تشبه مجموعات التأجير (leasesets) سجلات DNS نوعًا ما. لكن حاليًا لا توجد وسيلة لمعرفة ما إذا كان هذا المضيف يدعم أي خدمات، سواء على تلك الوجهة أو غيرها، بطريقة مشابهة لسجلات DNS SRV كما هو محدد في RFC 2782 .
أول تطبيق محتمل لهذا قد يكون البريد الإلكتروني ندًا لند. تطبيقات محتملة أخرى: DNS، GNS، خوادم المفاتيح، سلطات الشهادات، خوادم الوقت، bittorrent، العملات الرقمية، تطبيقات ند لند أخرى.
المقترحات والبدائل ذات الصلة
قوائم الخدمات
عرف الاقتراح 123 Proposal 123 “سجلات الخدمة” التي تشير إلى أن وجهة ما تشارك في خدمة عالمية. وكانت خوادم الفيض (floodfills) ستجمع هذه السجلات في “قوائم خدمات” عالمية. ولم يُنفذ هذا أبدًا بسبب التعقيد، وغياب المصادقة، والمخاوف الأمنية ومخاوف التصيد (spamming).
يختلف هذا الاقتراح عن السابق بأنه يوفر بحثًا عن خدمة لوجهة محددة، وليس مجموعة عالمية من الوجهات لخدمة عالمية ما.
GNS
يقترح GNS أن يدير كل شخص خادم DNS خاص به. هذا الاقتراح تكميلي، بحيث يمكننا استخدام سجلات الخدمة لتحديد أن GNS (أو DNS) مدعوم، باسم خدمة قياسي هو “domain” على المنفذ 53.
Dot well-known
قد تم اقتراح أن تُبحث الخدمات عبر طلب HTTP إلى /.well-known/i2pmail.key. وهذا يتطلب أن يكون لكل خدمة موقع ويب مرتبط يستضيف المفتاح. ومعظم المستخدمين لا يشغلون مواقع ويب.
حل بديل واحد هو أن نفترض أن الخدمة لعنوان b32 تعمل فعليًا على ذلك العنوان b32. وبالتالي فإن البحث عن الخدمة لـ example.i2p يتطلب جلب HTTP من http://example.i 2p/.well-known/i2pmail.key، لكن الخدمة لـ aaa…aaa.b32.i2p لا تتطلب هذا البحث، ويمكنها الاتصال مباشرة.
لكن هناك غموضًا هنا، لأن example.i2p يمكن أيضًا التخاطب معها عبر عنوانها b32.
سجلات MX
سجلات SRV هي ببساطة نسخة عامة من سجلات MX لأي خدمة. “_smtp._tcp” هو سجل “MX”. لا حاجة لسجلات MX إذا كانت لدينا سجلات SRV، وسجلات MX وحدها لا توفر سجلًا عامًا لأي خدمة.
التصميم
تُوضع سجلات الخدمة في قسم الخيارات في LS2 . قسم خيارات LS2 غير مستخدم حاليًا. غير مدعوم لـ LS1. يشبه هذا الاقتراح اقتراح عرض النطاق الترددي للنفق ، الذي يعرّف خيارات لسجلات بناء النفق.
لبحث عنوان خدمة لاسم مضيف أو b32 معين، يسترد الموجه مجموعة التأجير (leaseset) ويبحث عن سجل الخدمة في الخصائص.
قد تكون الخدمة مستضافة على نفس الوجهة التي تخص LS نفسه، أو قد تشير إلى اسم مضيف/عنوان b32 مختلف.
إذا كانت الوجهة المستهدفة للخدمة مختلفة، يجب أن تتضمن مجموعة التأجير (LS) المستهدفة أيضًا سجل خدمة يشير إلى نفسها، للإشارة إلى أنها تدعم الخدمة.
لا يتطلب التصميم دعمًا خاصًا أو تخزينًا مؤقتًا أو أي تغييرات في خوادم الفيض (floodfills). فقط ناشر مجموعة التأجير (leaseset)، والعميل الذي يبحث عن سجل خدمة، يجب أن يدعموا هذه التغييرات.
تقترح إضافات طفيفة على I2CP وSAM لتسهيل استرجاع سجلات الخدمة من قبل العملاء.
المواصفات
مواصفات خيارات LS2
يجب أن تكون خيارات LS2 مرتبة حسب المفتاح، بحيث تكون التوقيعات ثابتة.
يُعرّف كما يلي:
- serviceoption := optionkey optionvalue
- optionkey := _service._proto
- service := الاسم الرمزي للخدمة المطلوبة. يجب أن يكون بأحرف صغيرة. مثال: “smtp”. الأحرف المسموحة هي [a-z0-9-] ولا يجب أن تبدأ أو تنتهي بـ ‘-’. يجب استخدام المعرفات القياسية من سجل أنواع خدمة DNS-SD أو من /etc/services في لينكس إن وُجدت.
- proto := بروتوكول النقل للخدمة المطلوبة. يجب أن يكون بأحرف صغيرة، إما “tcp” أو “udp”. “tcp” تعني تدفقًا (streaming)، و"udp" تعني حزم بيانات قابلة للإجابة (repliable datagrams). قد تُعرّف مؤشرات بروتوكول لحزم البيانات الخام (raw datagrams) وdatagram2 لاحقًا. الأحرف المسموحة هي [a-z0-9-] ولا يجب أن تبدأ أو تنتهي بـ ‘-’.
- optionvalue := self | srvrecord[,srvrecord]*
- self := “0” ttl port [appoptions]
- srvrecord := “1” ttl priority weight port target [appoptions]
- ttl := الوقت المتبقي للحياة (time to live)، بالثواني كعدد صحيح موجب. مثال: “86400”. يُوصى بحد أدنى قدره 86400 (يوم واحد)، انظر قسم التوصيات أدناه للتفاصيل.
- priority := أولوية المضيف المستهدف، القيمة الأقل تعني تفضيلًا أكبر. عدد صحيح غير سالب. مثال: “0” تكون مفيدة فقط إذا كان هناك أكثر من سجل واحد، لكنها مطلوبة حتى لو كان هناك سجل واحد فقط.
- weight := وزن نسبي للسجلات ذات الأولوية نفسها. القيمة الأعلى تعني فرصة أكبر للاختيار. عدد صحيح غير سالب. مثال: “0” تكون مفيدة فقط إذا كان هناك أكثر من سجل واحد، لكنها مطلوبة حتى لو كان هناك سجل واحد فقط.
- port := منفذ I2CP الذي توجد عليه الخدمة. عدد صحيح غير سالب. مثال: “25” يُدعم المنفذ 0 لكن لا يُوصى به.
- target := اسم المضيف أو b32 للوجهة التي تقدم الخدمة. اسم مضيف صالح . يجب أن يكون بأحرف صغيرة. مثال: “aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa.b32.i2p” أو “example.i2p”. يُوصى باستخدام b32 ما لم يكن اسم المضيف “معروفًا جيدًا”، أي موجودًا في دفاتر العناوين الرسمية أو الافتراضية.
- appoptions := نص حر مخصص للتطبيق، لا يجب أن يحتوي على " " أو “,”. الترميز هو UTF-8.
أمثلة
في LS2 لـ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa.b32.i2p، يشير إلى خادم SMTP واحد:
"_smtp._tcp" "1 86400 0 0 25 bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb.b32.i2p"
في LS2 لـ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa.b32.i2p، يشير إلى خادمين SMTP:
"_smtp._tcp" "1 86400 0 0 25 bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb.b32.i2p,86400 1 0 25 cccccccccccccccccccccccccccccccccccccccccccc.b32.i2p"
في LS2 لـ bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb.b32.i2p، يشير إلى نفسه كخادم SMTP:
"_smtp._tcp" "0 999999 25"
صيغة محتملة لإعادة توجيه البريد الإلكتروني (انظر أدناه):
"_smtp._tcp" "1 86400 0 0 25 smtp.postman.i2p example@mail.i2p"
القيود
يحدد تنسيق هيكل البيانات “Mapping” المستخدم في خيارات LS2 حدًا أقصى قدره 255 بايت (ليس حرفًا) لكل من المفاتيح والقيم. مع هدف b32، يكون optionvalue حوالي 67 بايت، لذا لن يناسب سوى 3 سجلات. ربما واحد أو اثنان فقط مع حقل appoptions طويل، أو حتى أربعة أو خمسة مع اسم مضيف قصير. يجب أن يكون هذا كافيًا؛ السجلات المتعددة يجب أن تكون نادرة.
الاختلافات عن RFC 2782
- لا توجد نقاط نهائية
- لا يوجد اسم بعد proto
- الأحرف الصغيرة مطلوبة
- في صيغة نصية بسجلات مفصولة بفواصل، وليس بصيغة DNS الثنائية
- مؤشرات نوع سجل مختلفة
- حقل appoptions إضافي
ملاحظات
لا يُسمح بالنمذجة (wildcarding) مثل (نجمة)، (نجمة)._tcp، أو _tcp. يجب أن يكون لكل خدمة مدعومة سجل خاص بها.
سجل أسماء الخدمات
يمكن طلب المعرفات غير القياسية غير المدرجة في سجل أنواع خدمة DNS-SD أو /etc/services في لينكس وإدراجها في مواصفات الهياكل المشتركة .
قد تُضاف أيضًا صيغ appoptions الخاصة بالخدمة هناك.
مواصفات I2CP
يجب توسيع بروتوكول I2CP لدعم بحث الخدمات. مطلوب أكواد خطأ إضافية في رسالة MessageStatusMessage و/أو HostReplyMessage تتعلق ببحث الخدمة. لجعل وسيلة البحث عامة، وليس مخصصة فقط لسجلات الخدمة، يكون التصميم داعمًا لاسترجاع جميع خيارات LS2.
التنفيذ: توسيع HostLookupMessage لإضافة طلب خيارات LS2 للـ hash، اسم المضيف، والوجهة (أنواع الطلب 2-4). توسيع HostReplyMessage لإضافة خريطة الخيارات إذا طُلب. توسيع HostReplyMessage بأكواد خطأ إضافية.
قد يتم تخزين خرائط الخيارات مؤقتًا أو سلبيًا لفترة قصيرة إما من جانب العميل أو الموجه، حسب التنفيذ. الحد الأقصى الموصى به هو ساعة واحدة، ما لم يكن TTL لسجل الخدمة أقصر. يمكن تخزين سجلات الخدمة مؤقتًا حتى TTL المحدد من قبل التطبيق أو العميل أو الموجه.
توسيع المواصفات كما يلي:
خيارات التهيئة
أضف ما يلي إلى خيارات تهيئة I2CP
i2cp.leaseSetOption.nnn
الخيارات المراد وضعها في مجموعة التأجير (leaseset). متاحة فقط لـ LS2. يبدأ nnn من 0. تحتوي قيمة الخيار على “key=value”. (لا تدرج علامات الاقتباس)
مثال: i2cp.leaseSetOption.0=_smtp._tcp=1 86400 0 0 25 bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb.b32.i2p
رسالة HostLookup
- نوع البحث 2: بحث بالهاش، طلب خريطة الخيارات
- نوع البحث 3: بحث باسم المضيف، طلب خريطة الخيارات
- نوع البحث 4: بحث بالوجهة، طلب خريطة الخيارات
بالنسبة لنوع البحث 4، يكون العنصر 5 هو الوجهة (Destination).
رسالة HostReply
بالنسبة لأنواع البحث 2-4، يجب على الموجه جلب مجموعة التأجير (leaseset)، حتى لو كان مفتاح البحث موجودًا في دفتر العناوين.
إذا نجح البحث، ستتضمن HostReply خريطة الخيارات من مجموعة التأجير، وتشملها كعنصر 5 بعد الوجهة. إذا لم تكن هناك خيارات في الخريطة، أو كانت مجموعة التأجير من الإصدار 1، فستُدرج كخريطة فارغة (بايتان: 0 0). ستُدرج جميع الخيارات من مجموعة التأجير، وليس فقط خيارات سجلات الخدمة. على سبيل المثال، قد تكون موجودة خيارات لمعايير معرفة في المستقبل.
في حالة فشل جلب مجموعة التأجير، ستتضمن الرد كود خطأ جديد 6 (فشل جلب مجموعة التأجير) ولن تشمل خريطة. عند إرجاع كود الخطأ 6، قد يكون حقل الوجهة (Destination) موجودًا أو غير موجود. سيكون موجودًا إذا كان بحث اسم المضيف في دفتر العناوين ناجحًا، أو إذا كان بحث سابق ناجحًا وتم تخزين النتيجة مؤقتًا، أو إذا كانت الوجهة موجودة في رسالة البحث (نوع البحث 4).
إذا لم يُدعم نوع البحث، فسوف تتضمن الرسالة كود خطأ جديد 7 (نوع البحث غير مدعوم).
مواصفات SAM
يجب توسيع بروتوكول SAMv3 لدعم بحث الخدمات.
توسيع NAMING LOOKUP كما يلي:
NAMING LOOKUP NAME=example.i2p OPTIONS=true يطلب خريطة الخيارات في الرد.
قد يكون NAME عبارة عن وجهة base64 كاملة عندما OPTIONS=true.
إذا كان بحث الوجهة ناجحًا وكانت الخيارات موجودة في مجموعة التأجير، فسيتم في الرد، بعد الوجهة، إدراج خيار أو أكثر على شكل OPTION:key=value. سيكون لكل خيار بادئة OPTION: منفصلة. ستُدرج جميع الخيارات من مجموعة التأجير، وليس فقط خيارات سجلات الخدمة. على سبيل المثال، قد تكون موجودة خيارات لمعايير معرفة في المستقبل. مثال:
NAMING REPLY RESULT=OK NAME=example.i2p VALUE=base64dest OPTION:_smtp._tcp=“1 86400 0 0 25 bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb.b32.i2p”
تعتبر المفاتيح التي تحتوي على ‘=’، والمفاتيح أو القيم التي تحتوي على سطر جديد، غير صالحة وسيتم إزالة زوج المفتاح/القيمة من الرد.
إذا لم تُعثر على خيارات في مجموعة التأجير، أو كانت مجموعة التأجير من الإصدار 1، فإن الاستجابة لن تتضمن أي خيارات.
إذا كانت OPTIONS=true في الطلب، ولم تُعثر على مجموعة التأجير، فسيتم إرجاع قيمة نتيجة جديدة LEASESET_NOT_FOUND.
بديل بحث التسمية
تم النظر في تصميم بديل لدعم بحث الخدمات كاسم مضيف كامل، على سبيل المثال _smtp.tcp.example.i2p، عن طريق تحديث مواصفات التسمية لتحديد معالجة أسماء المضيف التي تبدأ بـ ‘’. تم رفض هذا لسببين:
- لا تزال التغييرات في I2CP وSAM ضرورية لتمرير معلومات TTL والمنفذ إلى العميل.
- لن تكون وسيلة عامة يمكن استخدامها لاسترجاع خيارات LS2 أخرى قد تُعرّف في المستقبل.
التوصيات
ينبغي للخوادم تحديد TTL لا يقل عن 86400، والمنفذ القياسي للتطبيق.
الميزات المتقدمة
بحث تكراري
قد يكون من المستحسن دعم بحث تكراري، حيث يتم التحقق من كل مجموعة تأجير متتالية عن سجل خدمة يشير إلى مجموعة تأجير أخرى، على غرار DNS. من المحتمل أن هذا ليس ضروريًا، على الأقل في التنفيذ الأولي.
تحتاج إلى إنجاز (TODO)
حقول مخصصة للتطبيق
قد يكون من المستحسن وجود بيانات مخصصة للتطبيق في سجل الخدمة. على سبيل المثال، قد يرغب مشغل example.i2p في الإشارة إلى أن البريد الإلكتروني يجب إعادة توجيهه إلى example@mail.i2p . سيحتاج الجزء “example@” إلى أن يكون في حقل منفصل في سجل الخدمة، أو يتم حذفه من الهدف.
حتى لو كان المشغل يدير خدمة بريد إلكتروني خاصة به، فقد يرغب في الإشارة إلى أن البريد يجب إرساله إلى example@example.i2p . معظم خدمات I2P يديرها شخص واحد. لذلك قد يكون الحقل المنفصل مفيدًا هنا أيضًا.
تحتاج إلى إنجاز (TODO) كيفية القيام بذلك بطريقة عامة
التغييرات المطلوبة للبريد الإلكتروني
خارج نطاق هذا الاقتراح. انظر النقاش على i2pforum لمزيد من التفاصيل.
ملاحظات التنفيذ
يمكن للموجه أو التطبيق تخزين سجلات الخدمة مؤقتًا حتى TTL، حسب التنفيذ. ما إذا كان سيتم التخزين المؤقت بشكل دائم أيضًا يعتمد على التنفيذ.
يجب أن تتضمن عمليات البحث أيضًا البحث عن مجموعة التأجير المستهدفة والتحقق من احتوائها على سجل “self” قبل إرجاع الوجهة المستهدفة إلى العميل.
تحليل الأمان
بما أن مجموعة التأجير (leaseset) موقعة، فإن أي سجلات خدمة ضمنها تكون موثقة بواسطة مفتاح التوقيع الخاص بالوجهة.
سجلات الخدمة علنية ومرئية لخوادم الفيض (floodfills)، ما لم تكن مجموعة التأجير مشفرة. أي موجه يطلب مجموعة التأجير سيكون قادرًا على رؤية سجلات الخدمة.
لا يتطلب سجل SRV غير “self” (أي الذي يشير إلى هدف اسم مضيف/b32 مختلف) موافقة الاسم المضيف/b32 المستهدف. ليس من الواضح ما إذا كان إعادة توجيه خدمة إلى وجهة عشوائية يمكن أن يسهل نوعًا من الهجوم، أو ما هو الغرض من مثل هذا الهجوم. ومع ذلك، يخفف هذا الاقتراح من هذا الهجوم بشرط أن الهدف أيضًا ينشر سجل SRV من نوع “self”. يجب على المُنفِّذين التحقق من وجود سجل “self” في مجموعة التأجير الخاصة بالهدف.
التوافق
LS2: لا توجد مشكلات. جميع التنفيذات المعروفة حاليًا تتجاهل حقل الخيارات في LS2، وتتخطى بشكل صحيح حقل الخيارات غير الفارغ. تم التحقق من ذلك في الاختبارات بواسطة كل من Java I2P وi2pd أثناء تطوير LS2. تم تنفيذ LS2 في الإصدار 0.9.38 في عام 2016 وهو مدعوم جيدًا من جميع تنفيذات الموجه. لا يتطلب التصميم دعمًا خاصًا أو تخزينًا مؤقتًا أو أي تغييرات في خوادم الفيض (floodfills).
التسمية: ‘_’ ليس حرفًا صالحًا في أسماء المضيف في i2p.
I2CP: يجب عدم إرسال أنواع البحث 2-4 إلى الموجهات الأقدم من الإصدار الأدنى من واجهة API الذي يدعمه (سيُحدد لاحقًا).
SAM: خادم SAM في جافا يتجاهل المفاتيح/القيم الإضافية مثل OPTIONS=true. يجب أن يفعل i2pd الشيء نفسه، وسيتم التحقق من ذلك. لن يحصل عملاء SAM على القيم الإضافية في الرد ما لم يُطلب ذلك باستخدام OPTIONS=true. لن يكون من الضروري رفع رقم الإصدار.
الهجرة
يمكن للتنفيذات إضافة الدعم في أي وقت، ولا حاجة إلى تنسيق، باستثناء الاتفاق على إصدار واجهة API الفعّال للتغييرات في I2CP. ستُوثق إصدارات توافق SAM لكل تنفيذ في مواصفات SAM.