الحالة
تمت الموافقة في المراجعة الثانية 2025-04-01؛ تم تحديث المواصفات؛ لم يتم تنفيذها بعد.
نظرة عامة
لا يوجد نظام DNS مركزي في I2P. ومع ذلك، يتيح دفتر العناوين، جنبًا إلى جنب مع نظام اسم المضيف b32، لجهاز التوجيه البحث عن وجهات كاملة وجلب مجموعات الإيجار، التي تحتوي على قائمة بالبوابات والمفاتيح بحيث يمكن للعملاء الاتصال بتلك الوجهة.
لذا، فإن مجموعات الإيجار تشبه إلى حد ما سجل DNS. لكن لا يوجد حاليًا وسيلة لمعرفة ما إذا كان ذلك المضيف يدعم أي خدمات، سواء على تلك الوجهة أو على وجهة مختلفة، بطريقة مشابهة لسجلات DNS SRV SRV RFC2782.
قد يكون التطبيق الأول لهذا هو البريد الإلكتروني النظير للنظير. تطبيقات أخرى محتملة: DNS، GNS، خوادم المفاتيح، سلطات الشهادات، خوادم الوقت، تورنت، العملات المشفرة، تطبيقات نظير لنظير أخرى.
الاقتراحات والبدائل المتعلقة
قوائم الخدمة
عرّف اقتراح LS2 123 Prop123 سجلات الخدمة التي أشارت إلى أن الوجهة كانت تشارك في خدمة عالمية. كانت الفودفيل تجمع هذه السجلات في قوائم خدمة عالمية. لم يتم تنفيذ هذا أبدًا بسبب التعقيد، ونقص المصادقة، والمخاوف الأمنية، والبريد العشوائي.
هذا الاقتراح يختلف في أنه يوفر البحث عن خدمة لوجهة محددة، وليس مجموعة وجهات عالمية لخدمة عالمية ما.
GNS
يقترح GNS GNS أن يدير الجميع خادم DNS خاص بهم. هذا الاقتراح مكمل، حيث يمكننا استخدام سجلات الخدمة لتحديد ما إذا كان يتم دعم GNS (أو DNS)، مع اسم خدمة قياسي “domain” على المنفذ 53.
Dot well-known
في DOTWELLKNOWN يُقترح أن يتم البحث عن الخدمات عبر طلب HTTP إلى /.well-known/i2pmail.key. يتطلب ذلك أن يكون لكل خدمة موقع ويب ذو صلة لاستضافة المفتاح. معظم المستخدمين لا يديرون مواقع ويب.
إحدى الحلول البديلة هي افتراض أن خدمة لعنوان b32 تعمل فعليًا على ذلك العنوان b32. بحيث أن البحث عن الخدمة للــ example.i2p يتطلب جلب HTTP من http://example.i2p/.well-known/i2pmail.key، ولكن الخدمة للـ aaa…aaa.b32.i2p لا تتطلب ذلك البحث، يمكن فقط الاتصال مباشرة.
لكن هناك غموض هنا، لأن example.i2p يمكن الإشارة إليه أيضًا بواسطة b32.
سجلات MX
سجلات SRV هي ببساطة نسخة عامة من سجلات MX لأي خدمة. “_smtp._tcp” هو سجل “MX”. لا حاجة لسجلات MX إذا كان لدينا سجلات SRV، وسجلات MX وحدها لا توفر سجلًا عامًا لأي خدمة.
التصميم
يتم وضع سجلات الخدمة في قسم الخيارات في LS2 LS2. قسم خيارات LS2 حاليًا غير مستخدم. غير مدعوم لـ LS1. هذا مشابه لاقتراح عرض النفق [Prop168]، الذي يحدد الخيارات لسجلات بناء النفق.
للبحث عن عنوان خدمة لاسم مضيف محدد أو b32، يقوم الراوتر بجلب مجموعة الإيجار ويبحث عن سجل الخدمة في الخصائص.
قد يتم استضافة الخدمة على نفس الوجهة مثل LS نفسها، أو قد تشير إلى اسم مضيف/b32 مختلف.
إذا كانت الوجهة المستهدفة للخدمة مختلفة، فيجب أن تتضمن أيضًا مجموعة الأهداف المستهدفة أيضًا سجل الخدمة، مشيرة إلى نفسها، وأنها تدعم الخدمة.
التصميم لا يتطلب دعمًا خاصًا أو تخزينًا مؤقتًا أو أي تغييرات في الفودفيل. يجب فقط أن يقوم ناشر مجموعة الإيجار والعميل الذي يبحث عن سجل الخدمة بدعم هذه التغييرات.
يتم اقتراح امتدادات طفيفة لـ I2CP وSAM لتسهيل استرجاع سجلات الخدمة من قبل العملاء.
المواصفات
مواصفات خيار LS2
يجب أن تكون خيارات LS2 مرتبة حسب المفتاح، بحيث تكون التوقيع غير متغير.
يتم تعريفها كالتالي:
- serviceoption := optionkey optionvalue
- optionkey := _service._proto
- service := اسم رمزي للخدمة المطلوبة. يجب أن يكون بأحرف صغيرة. مثال: “smtp”. يُسمح بالأحرف [a-z0-9-] ولا يجب أن تبدأ أو تنتهي بـ ‘-’. يجب استخدام المعرفات القياسية من REGISTRY أو /etc/services في Linux إذا كانت معرفة هناك.
- proto := بروتوكول النقل للخدمة المطلوبة. يجب أن يكون بأحرف صغيرة، إما “tcp” أو “udp”. “tcp” تعني التدفق و"udp" تعني رزم يمكن الرد عليها. قد يتم تعريف مؤشرات البروتوكول للرزم الخام وdatagram2 لاحقًا. يُسمح بالأحرف [a-z0-9-] ولا يجب أن تبدأ أو تنتهي بـ ‘-’.
- optionvalue := self | srvrecord[,srvrecord]*
- self := “0” ttl port [appoptions]
- srvrecord := “1” ttl priority weight port target [appoptions]
- ttl := عمر البقاء، عدد صحيح بالثواني. عدد صحيح موجب. مثال: “86400”. يوصى بحد أدنى قدره 86400 (يوم واحد)، راجع قسم التوصيات أدناه للحصول على التفاصيل.
- priority := أولوية المضيف المستهدف، القيمة الأدنى تعني تفضيلاً أكبر. عدد صحيح غير سالب. مثال: “0”. مفيد فقط إذا كان هناك أكثر من سجل واحد، لكن مطلوب حتى إذا كان هناك سجل واحد فقط.
- weight := وزن نسبي للسجلات ذات نفس الأولوية. القيمة الأعلى تعني فرصة أكبر في الاقتناء. عدد صحيح غير سالب. مثال: “0”. مفيد فقط إذا كان هناك أكثر من سجل واحد، لكن مطلوب حتى إذا كان هناك سجل واحد فقط.
- port := منفذ I2CP الذي يمكن العثور فيه على الخدمة. عدد صحيح غير سالب. مثال: “25”. المنفذ 0 مدعوم ولكن غير موصى به.
- target := اسم المضيف أو b32 للوجهة التي تقدم الخدمة. اسم المضيف صالح كما في NAMING. يجب أن يكون بأحرف صغيرة. مثال: “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"
الحدود
صيغة هيكل البيانات المستخدمة لخيارات LS2 تحد الحدود للمفاتيح والقيم إلى 255 بايت (وليس رموز) بحد أقصى. مع هدف b32، تكون قيمة الخيار حوالي 67 بايت، لذلك يمكن فقط لثلاثة سجلات أن تتسع. ربما سجل واحد أو اثنان مع حقل appoptions طويل، أو حتى أربعة أو خمسة مع اسم مضيف قصير. ينبغي أن يكون ذلك كافياً؛ يجب أن تكون السجلات المتعددة نادرة.
الاختلافات عن RFC2782
- لا نقاط لاحقة
- لا يوجد اسم بعد الـ proto
- يتطلب أحرفًا صغيرة
- في صيغة نصية مع سجلات مفصولة بفواصل، وليس في صيغة DNS الثنائية
- مؤشرات نوع سجل مختلفة
- حقل appoptions إضافي
ملاحظات
لا يُسمح بأي تعميم مثل (asterisk)، (asterisk)._tcp، أو _tcp. يجب أن يكون لكل خدمة مدعومة سجل خاص بها.
سجل أسماء الخدمة
المعرفات غير القياسية التي ليست مدرجة في REGISTRY أو /etc/services في Linux يمكن طلبها وإضافتها إلى مواصفات الهيكل المشترك LS2.
يمكن أيضًا إضافة تنسيقات حقل appoptions خاصة بالخدمة هناك.
مواصفات I2CP
يجب توسيع بروتوكول I2CP لدعم عمليات البحث عن الخدمة. مطلوب رموز خطأ إضافية لـ MessageStatusMessage أو HostReplyMessage المتعلقة ببحث الخدمة. لجعل ميزة البحث عامة، وليست محددة بسجلات الخدمة فقط، التصميم هو دعم استرجاع جميع خيارات LS2.
التنفيذ: تمديد HostLookupMessage لإضافة طلب للحصول على خيارات LS2 للهاش، اسم المضيف، والوجهة (أنواع الطلب 2-4). تمديد HostReplyMessage لإضافة تعيين الخيارات إذا طُلب. تمديد HostReplyMessage مع رموز خطأ إضافية.
يمكن تخزين تعيينات الخيارات مؤقتًا أو بشكل مؤقت لقصير الوقت على جانب العميل أو جهاز التوجيه، حسب تنفيذ القرار. الحد الأقصى الموصى به للوقت هو ساعة واحدة، إلا إذا كان TTL سجل الخدمة أقصر. يمكن تخزين سجلات الخدمة مؤقتًا حتى TTL المحدد بواسطة التطبيق أو العميل أو جهاز التوجيه.
مدد المواصفات كالتالي:
خيارات الإعداد
إضافة ما يلي إلى [I2CP-OPTIONS]
i2cp.leaseSetOption.nnn
الخيارات المراد وضعها في مجموعة الإيجار. متاح فقط لـ LS2. يبدأ nnn من 0. تحتوي قيمة الخيار على “key=value”. (لا تشمل الاقتباسات)
مثال:
i2cp.leaseSetOption.0=_smtp._tcp=1 86400 0 0 25 bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb.b32.i2p
رسالة HostLookup
- نوع البحث 2: البحث عن الهاش، طلب تعيين الخيارات
- نوع البحث 3: البحث عن اسم المضيف، طلب تعيين الخيارات
- نوع البحث 4: البحث عن الوجهة، طلب تعيين الخيارات
لن تكون الوجهة
- مطلب نوع البحث 4، البند 5 هو أحد الوجهات
رسالة HostReply
بالنسبة لأنواع البحث 2-4، يجب أن يجلب جهاز الراوتر مجموعة الإيجار، حتى لو كان مفتاح البحث موجودًا في دفتر العناوين.
إذا كان ناجحًا، ستحتوي رسالت روزلة الاستضافة على تعيين الخيارات من مجموعة الإيجار، وتضمينه كبند 5 بعد الوجهة. إذا لم تكن هناك خيارات في مجموعة التعيين، أو كانت مجموعة الإيجار في الإصدار 1، فستبقى مشمولة كتعيين فارغ (بايتان: 0 0). سيتم تضمين جميع الخيارات من مجموعة الإيجار، وليس فقط خيارات سجل الخدمة. على سبيل المثال، قد تكون الخيارات للمعاملات المحددة في المستقبل موجودة.
في حالة فشل البحث في مجموعة الإيجار، ستكون الاستجابة تحتوي على رمز خطأ جديد 6 (فشل البحث في مجموعة الإيجار) ولن تشمل التعيين. عند إرجاع رمز الخطأ 6، قد تكون الحقل الوجهة موجودًا أو لا. سيكون موجودًا إذا كان بحث الاسم المضيف في دفتر العناوين ناجحًا، أو إذا كان بحث سابق ناجح ونتج عنه التخزين المؤقت، أو إذا كانت الوجهة موجودة في رسالة البحث (نوع البحث 4).
إذا لم يكن نوع البحث مدعومًا، فستكون الاستجابة تحتوي على رمز خطأ جديد 7 (نوع البحث غير مدعوم).
مواصفات SAM
يجب توسيع بروتوكول SAMv3 لدعم عمليات البحث عن الخدمة.
يمد NAMING LOOKUP كما يلي:
NAMING LOOKUP NAME=example.i2p OPTIONS=true يطلب تعيين الخيارات في الرد.
قد يكون NAME هو وجهة base64 كاملة عندما OPTIONS=true.
إذا كانت البحث عن الوجهة ناجحًا وكانت الخيارات موجودة في مجموعة الإيجار، فإنه في الرد، ستأتي بعد الوجهة، خيارات في شكل OPTION:key=value. كل خيار سيكون لديه Prefix 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.
بديل Lookup Naming
تم النظر في تصميم بديل، لدعم البحث عن الخدمات كاسم مضيف كامل، على سبيل المثال _smtp.tcp.example.i2p، عن طريق تحديث NAMING لتحديد معالجة لأسماء المضيفين التي تبدأ بـ ‘’. تم رفض ذلك لسببين:
- لا تزال تغييرات I2CP وSAM ضرورية لتمرير معلومات TTL والمنفذ إلى العميل.
- لن يكون مرفقًا عامًا يمكن استخدامه لاسترجاع خيارات LS2 الأخرى التي يمكن تعريفها في المستقبل.
التوصيات
ينبغي أن تحدد الخوادم TTL لا يقل عن 86400، و المنفذ القياسي للتطبيق.
الميزات المتقدمة
عمليات البحث المتكررة
قد يكون من المرغوب دعم عمليات البحث المتكررة، حيث يتم التحقق من كل مجموعة إجار متتالية لسجل الخدمة الذي يشير إلى مجموعة إجار أخرى، على طريقة DNS. هذا ربما ليس ضروريًا، على الأقل في التنفيذ المبدئي.
TODO
الحقول الخاصة بالتطبيق
قد يكون من المرغوب وجود بيانات خاصة بالتطبيق في سجل الخدمة. على سبيل المثال، قد يرغب مشغل example.i2p في الإشارة إلى أن البريد الإلكتروني يجب أن يُعاد توجيهه إلى example@mail.i2p. الجزء “example@” قد يحتاج إلى أن يكون في حقل منفصل في سجل الخدمة، أو أن يتم تجريده من الهدف.
حتى إذا كان المشغل يدير خدمته البريدية الخاصة به، قد يرغب في الإشارة إلى أن البريد الإلكتروني يجب أن يتم إرساله إلى example@example.i2p. معظم خدمات I2P تدار بواسطة شخص واحد. لذا قد يكون حقل منفصل مساعدًا هنا أيضًا.
TODO كيفية القيام بذلك بطريقة عامة
التغييرات المطلوبة للبريد الإلكتروني
خارج نطاق هذا الاقتراح. انظر DOTWELLKNOWN لمناقشة.
ملاحظات التنفيذ
يمكن أن يتم تخزين سجلات الخدمة مؤقتًا حتى TTL بواسطة الراوتر أو التطبيق، حسب تنفيذ القرار. سواء لتخزينها مؤقتًا بشكل دائم يعتمد أيضًا على تنفيذ القرار.
يجب أن تتم عمليات البحث أيضًا على مجموعة الإيجار المستهدفة والتحقق من أنها تحتوي على سجل “self” قبل إرجاع الوجهة المستهدفة إلى العميل.
تحليل الأمان
حيث أن مجموعة الإيجار موقعة، فأي سجل خدمة ضمنها مصادق بواسطة مفتاح توقيع الوجهة.
سجلات الخدمة تكون عامة ومرئية للفودفيل، ما لم تكن مجموعة الإيجار مشفرة. سيكون أي راوتر يطلب مجموعة الإيجار قادرًا على رؤية سجلات الخدمة.
لا يتطلب سجل SRV بخلاف “self” (بمعنى آخر، الذي يشير إلى هدف اسم مضيف/b32 مختلف) موافقة من اسم المضيف/b32 المستهدف. من غير الواضح ما إذا كان إعادة توجيه للخدمة إلى وجهة عشوائية يمكن أن يسهل نوعًا ما من الهجوم، أو ما هو هدف مثل هذا الهجوم. ومع ذلك، يُخفف هذا الاقتراح من مثل هذا الهجوم بمتطلبات أن تقوم أيضًا مجموعة الهدف بإصدار سجل SRV “self”. يجب على المنفذين فحص وجود سجل “self” في مجموعة الإيجار الخاصة بالهدف.
التوافق
LS2: لا توجد قضايا. تتجاهل جميع تنفيذات المعروفة حاليًا الحقل الخيارات في LS2، وتخطي بشكل صحيح عبر حقل الخيارات غير الفارغ. تم التحقق من ذلك في الاختبار بواسطة كل من Java I2P وi2pd خلال تطوير LS2. تم تنفيذ LS2 في 0.9.38 في عام 2016 ويدعمها بشكل جيد جميع تنفيذات الراوتر. التصميم لا يتطلب دعمًا خاصًا أو تخزينًا مؤقتًا أو أي تغييرات في الفودفيل.
التسمية: ‘_’ ليس رمزًا صالحًا في أسماء المضيفين في i2p.
I2CP: أنواع البحث 2-4 يجب ألا تُرسل إلى أجهزة التوجيه أدناه الإصدار API الأدنى الذي يدعمها (سيتم تحديده لاحقًا).
SAM: يتجاهل خادم سام جافا المفاتيح/القيم الإضافية مثل OPTIONS=true. ينبغي على i2pd كذلك، يجب التحقق من ذلك. لن يحصل عملاء سام على القيم الإضافية في الرد إلا إذا طُلبت مع OPTIONS=true. لا ينبغي أن يكون هناك حاجة إلى زيادة في الإصدار.