अवलोकन
यह प्रस्ताव I2P में DNS रिवर्स लुकअप के लिए समर्थन जोड़ने के बारे में है।
वर्तमान अनुवाद प्रणाली
गार्लीकैट (GC) अन्य GC नोड्स के साथ कनेक्शन सेटअप के लिए नाम अनुवाद करता है। यह नाम अनुवाद एक पते के बाइनरी स्वरूप को बेस32 एन्कोडेड रूप में पुनः कोडिंग करना है। इसलिए, अनुवाद आगे और पीछे दोनों तरह से काम करता है।
ये पते 80 बिट लंबाई के चुने गए हैं। ऐसा इसलिए क्योंकि टोर अपने छिपे सेवाओं को संबोधित करने के लिए 80 बिट लंबाई के मान प्रयोग करता है। इसलिए, ओनियनकैट (जो कि टोर के लिए GC है) टोर के साथ बिना किसी अतिरिक्त हस्तक्षेप के काम करता है।
दुर्भाग्यवश, I2P अपनी सेवाओं को संबोधित करने के लिए 256 बिट लंबाई के मान का प्रयोग करता है। जैसा कि पहले ही उल्लेख किया गया है, GC बाइनरी और बेस32 एन्कोडेड स्वरूप के बीच ट्रांसकोड करता है। GC के एक लेयर 3 वीपीएन होने के कारण, बाइनरी स्वरूप में पते को IPv6 पते के रूप में परिभाषित किया गया है, जिसकी कुल लंबाई 128 बिट होती है। स्पष्ट रूप से, 256 बिट के I2P पते उसमें नहीं फिट हो सकते।
इसलिए, नाम अनुवाद का एक दूसरा चरण आवश्यक हो जाता है: IPv6 पता (बाइनरी) -1a-> बेस32 पता (80 बिट) -2a-> I2P पता (256 बिट) -1a- … GC अनुवाद -2a- … I2P hosts.txt लुकअप
वर्तमान समाधान I2P राउटर को कार्य संपादित करने देना है। यह I2P राउटर की hosts.txt या privatehosts.txt फाइल में 80 बिट बेस32 पता और उसका डेस्टिनेशन (I2P पता) एक नाम/मूल्य जोड़ी के रूप में डालने से संपन्न होता है।
यह मूल रूप से काम करता है लेकिन यह एक नाम सेविस पर निर्भर करता है जो (मेरे विचार में) खुद एक विकास की अवस्था में है और पर्याप्त परिपक्व नहीं है (विशेष रूप से नाम वितरण के संदर्भ में)।
एक स्केलेबल समाधान
मैं प्रस्ताव करता हूं कि आई2पी (और शायद टोर के लिए भी) में GC IPv6 पते पर नियमित DNS प्रोटोकॉल का उपयोग करते हुए रिवर्स लुकअप करता है। रिवर्स ज़ोन में सीधे 256 बिट I2P पते मौजूद हों जो बेस32 एन्कोडेड रूप में हो। यह लुकअप प्रणाली को एकल चरण में बदल देता है जिससे और अधिक लाभ होते हैं। IPv6 पता (बाइनरी) -1b-> I2P पता (256 बिट) -1b- … DNS रिवर्स लुकअप
इंटरनेट के भीतर DNS लुकअप गोपनीयता की दृष्टि से जानकारी का रिसाव होते हैं। इसलिए, वे लुकअप I2P के भीतर किए जाने चाहिए। इसका मतलब है कि I2P के भीतर कई DNS सेवाएँ होनी चाहिए। चूंकि DNS क्वेरीज़ आमतौर पर UDP प्रोटोकॉल का उपयोग करती हैं, GC स्वयं डेटा ट्रांसपोर्ट के लिए आवश्यक होता है क्योंकि यह UDP पैकेट्स को ले जाता है जो I2P मूल रूप से नहीं करता।
DNS से जुड़े और भी फायदे हैं:
- यह एक प्रसिद्ध मानक प्रोटोकॉल है, इसलिए, इसे निरंतर सुधारित किया जा रहा है और कई उपकरण (क्लाइंट्स, सर्वर्स, लाइब्रेरीज़, …) मौजूद हैं।
- यह एक वितरित प्रणाली है। यह डिफ़ॉल्ट रूप से कई सर्वरों पर नाम स्थान को होस्ट करने का समर्थन करता है।
- यह क्रिप्टोग्राफी (DNSSEC) को समर्थन करता है जो संसाधन रिकॉर्ड्स की प्रमाणीकरण को सक्षम बनाता है। इसे सीधे डेस्टिनेशन की कुंजियों के साथ बांधा जा सकता है।
भविष्य के अवसर
संभव है कि यह नामकरण सेवा आगे लुकअप करने के लिए भी प्रयोग की जा सके। यह होस्टनेम्स को I2P पतों और/या IPv6 पतों में अनुवादित करता है। लेकिन इस प्रकार के लुकअप को और अधिक जांच की आवश्यकता है क्योंकि ये लुकअप आमतौर पर स्थानीय रूप से इंस्टॉल किए गए रिज़ॉल्वर लाइब्रेरी के जरिए किए जाते हैं जो नियमित इंटरनेट नाम सर्वरों का उपयोग करते हैं (उदाहरण के लिए यूनिक्स जैसे सिस्टम पर /etc/resolv.conf में निर्दिष्ट)। यह GC के रिवर्स लुकअप से अलग है जिसे मैंने ऊपर समझाया है। एक और अवसर यह हो सकता है कि जब एक GC इनबाउंड टनल बनाए जाने पर I2P पता (डेस्टिनेशन) स्वचालित रूप से पंजीकृत हो जाए। इससे उपयोगिता काफी बढ़ जाएगी।