इस सीरीज़ की बाक़ी हर गाइड "इस पर एक सबडोमेन पॉइंट करें" से शुरू होती है, लेकिन कोई नहीं बताता कि डोमेन आता कहाँ से है। यह सेल्फ़-होस्टेड स्टैक का वह एकमात्र हिस्सा है जो जानबूझकर प्रकाशित किया जाता है — एक रजिस्ट्री एंट्री, एक रजिस्ट्रार खाता, एक भुगतान, और एक सार्वजनिक लॉग जो आपके माँगे हर सर्टिफिकेट का होस्टनेम सूचीबद्ध करता है। एक नाम को इस तरह रजिस्टर करने और बनाए रखने के छह चरण कि उसमें से कुछ भी वापस आप तक न पहुँचे: वे चार रिकॉर्ड जो एक रजिस्ट्रेशन वास्तव में बनाता है, वे रजिस्ट्री जो आपको मना कर देंगी, Monero में भुगतान करना, और वे दो लीक जो हफ़्तों बाद, जब आप देखना बंद कर चुके होंगे, पूरी मेहनत को बेकार कर देती हैं।
मॉडल
चार रिकॉर्ड, एक नहीं
चुनें
रजिस्ट्री ही न्यूनतम स्तर तय करती है
रजिस्टर करें
स्वामित्व के तीन मॉडल
भुगतान
एक्सचेंज ही वह लीक है
डेलिगेट करें
DNS, TLS, और सार्वजनिक लॉग
बनाए रखें
नवीनीकरण, लॉक, अभ्यास किया गया निकास
डोमेन नेम सिस्टम एक डेलिगेशन प्रणाली है, और डेलिगेशन तभी काम करता है जब कोई प्राधिकृत पक्ष यह बताए कि इसका धारक कौन है। एक रजिस्ट्री अपने टॉप-लेवल डोमेन की सूची रखती है; एक रजिस्ट्रार आपको उस सूची में एक एंट्री बेचता है और यह वारंट करता है कि वह जानता है कि आप कौन हैं; इसके बाद नाम resolve होता है क्योंकि सर्वरों की एक श्रृंखला दर्ज रूप से यह कहने को तैयार है कि यह ज़ोन उन नेमसर्वरों का है। इसका कोई ऐसा रूप नहीं है जिसमें कोई कुछ भी न जानता हो। आप जो तय कर सकते हैं वह यह है कि कितने पक्ष जानते हैं, वे क्या जानते हैं, और कोई अनजान व्यक्ति उनसे यह कितनी आसानी से निकाल सकता है।
यह उस समस्या से सचमुच अलग समस्या है जिससे यह बाक़ी सीरीज़ जूझती है। एक सर्वर गुमनाम रूप से किराए पर लिया जा सकता है क्योंकि होस्टिंग का संबंध द्विपक्षीय होता है: आप और होस्ट, और किसी और को इसकी कोई प्रति नहीं चाहिए। एक डोमेन अपनी बनावट से ही बहुपक्षीय होता है — एक रजिस्ट्री, एक रजिस्ट्रार, अक्सर एक रीसेलर, एक DNS ऑपरेटर, एक सर्टिफिकेट प्राधिकरण, और सार्वजनिक लॉग का एक सेट जो ठीक इसलिए मौजूद है ताकि जारी करने की प्रक्रिया का ऑडिट उन लोगों द्वारा किया जा सके जो आप नहीं हैं। इसे VPS पर काम करने वाली प्रवृत्तियों के साथ अपनाना एक बड़ी आत्मविश्वास भरी ग़लती पैदा करता है।
अच्छी ख़बर यह है कि डिफ़ॉल्ट स्थिति पाठक के पक्ष में बहुत आगे बढ़ चुकी है, और इस विषय पर अधिकतर सलाह अभी तक इसके साथ तालमेल नहीं बिठा पाई है। 2018 से एक जेनेरिक टॉप-लेवल डोमेन का सार्वजनिक रजिस्ट्रेशन रिकॉर्ड रिडैक्ट कर दिया जाता है: जो कॉन्टैक्ट फ़ील्ड पहले नाम, गली और फ़ोन नंबर दिखाते थे, वे अब सबके लिए कुछ भी नहीं दिखाते, और इसके लिए कुछ भुगतान भी नहीं करना पड़ता। इसे नियंत्रित करने वाली नीति — ICANN की Registration Data Policy, जिसने GDPR लागू होने पर अपनाए गए आपातकालीन उपाय की जगह ली — यह भी तय करती है कि वैध हित रखने वाला कोई व्यक्ति किस दर्ज प्रक्रिया के ज़रिए अंतर्निहित डेटा का अनुरोध कर सकता है। रिकॉर्ड ख़त्म नहीं हुआ है। इसे प्रकाशित करने के बजाय रखा जाता है, और यह जानना कि इसे ठीक-ठीक कौन रखता है, ही असली काम है।
तीन व्यवस्थाओं की तुलना नीचे की गई है, और इनमें फ़र्क़ यह है कि आख़िर में कौन-सा पक्ष क्या रखता है। तीसरी वाली व्यवस्था तो डोमेन ही नहीं है, और यही वजह है कि यह यहाँ दिखती है: परियोजनाओं के एक सार्थक समूह के लिए यही सही जवाब है, और बाक़ी दो पर पैंतालीस मिनट ख़र्च करने से पहले यह जान लेना ज़रूरी है।
| विशेषता | आपका अपना नाम, रिडैक्ट किया हुआ रिकॉर्ड | प्रॉक्सी स्वामित्व | एक version-3 onion address |
|---|---|---|---|
| रजिस्ट्री रिकॉर्ड में कौन है | आप — एकत्र किए गए, रखे गए, प्रकाशित नहीं किए गए | प्रदाता, क़ानूनी रजिस्ट्रेंट के रूप में | कोई रजिस्ट्री नहीं है |
| आपके विवरण किससे माँगे जा सकते हैं | रजिस्ट्रार और रजिस्ट्री, एक दर्ज अनुरोध पर | सिर्फ़ प्रदाता, अपनी ही नीति के तहत | कोई नहीं — माँगने लायक़ कोई रिकॉर्ड ही नहीं है |
| नाम कौन छीन सकता है | रजिस्ट्री, रजिस्ट्रार, एक विवाद पैनल, एक अदालत | यह सब, और साथ में प्रदाता ख़ुद भी | कोई नहीं — यह address आपकी key से निकला है |
| साल भर की क़ीमत | लगभग $10 to $60, एक्सटेंशन के अनुसार | उससे कई गुना ज़्यादा — यही प्रीमियम की खूबी है | कभी कुछ नहीं, और यह समाप्त भी नहीं हो सकता |
| एक सामान्य ब्राउज़र में सुलभ | हां | हां | केवल Tor के ज़रिए |
एक खुलासा, क्योंकि यह पेज इस बारे में है कि किसी सुझाव से फ़ायदा किसे होता है। NordBastion डोमेन नाम नहीं बेचता। इस गाइड से कोई रजिस्ट्रार लिंक नहीं किया गया है, कोई भी हमारा एफ़िलिएट नहीं है, और ऐसा कोई प्रबंध नहीं है जिसके तहत इसे पढ़ने के बाद आप जो भी करें उसके लिए हमें भुगतान मिले। नीचे जो बताया गया है वह वही है जो हम पैनल में पूछने वाले किसी व्यक्ति को बताते, और यही वह मानक भी है जिसके अनुसार बाक़ी लाइब्रेरी लिखी गई है।
किसी नाम को रजिस्टर करने से आपका एक रिकॉर्ड नहीं बनता। इससे चार रिकॉर्ड बनते हैं, चार अलग-अलग जगहों पर, चार अलग-अलग समूहों के पास जो उन्हें रखने की चार अलग-अलग वजहें रखते हैं और उन्हें सौंपने की चार अलग-अलग सीमाएँ रखते हैं। इस क्षेत्र में लगभग हर विफलता तब होती है जब कोई इन चारों में से एक को तो सुरक्षित बना लेता है, लेकिन यह मान लेता है कि बाक़ी तीन भी अपने-आप सुरक्षित हो गए।
रजिस्ट्रेशन डेटा। नाम, डाक पता, ईमेल, फ़ोन नंबर — ख़रीद के समय रजिस्ट्रार द्वारा एकत्र किया जाता है, रजिस्ट्रार की मान्यता की एक शर्त के रूप में किसी तीसरे पक्ष के पास एस्क्रो में रखा जाता है, और एक्सटेंशन के अनुसार पूरी या आंशिक रूप से रजिस्ट्री को भेजा जाता है। यही वह हिस्सा है जिसके बारे में सब सोचते हैं, और यही वह हिस्सा है जो जेनेरिक डोमेन के लिए सार्वजनिक रूप से पहले से ही रिडैक्ट किया हुआ है। इसे एक दर्ज प्रक्रिया के ज़रिए अनुरोध पर प्रकट किया जाता है, और EU के भीतर रजिस्ट्री और रजिस्ट्रेशन सेवाएँ दोनों, NIS2 निर्देश के Article 28 के तहत, इसे सटीक और पूर्ण बनाए रखने और बिना अनुचित देरी के वैध अनुरोधकर्ताओं को जारी करने के एक सकारात्मक कर्तव्य के अधीन हैं।
रजिस्ट्रार खाता। रजिस्ट्रेशन डेटा से भी ज़्यादा भरा-पूरा, और लगभग कभी चर्चा में न आने वाला। इसमें addresses और timestamps के साथ लॉगिन इतिहास, पेमेंट इंस्ट्रूमेंट, आपके खोले गए सपोर्ट टिकट, और — यही वह हिस्सा है जो असल में मायने रखता है — उसी खाते में मौजूद बाक़ी हर डोमेन रहता है। आपके क़ानूनी नाम के तहत एक पेशेवर डोमेन और एक ऐसी परियोजना, जिससे आप जुड़ा नहीं दिखना चाहते, दोनों को एक ही खाते में रखना उन्हें उस हर व्यक्ति के लिए स्थायी रूप से जोड़ देता है जो वह खाता पढ़ सकता है — भले ही सार्वजनिक रिकॉर्ड दोनों में से किसी के बारे में कुछ भी कहे।
भुगतान। कार्ड एक ऐसा पहचान दस्तावेज़ है जो पैसे का निपटारा करता है। बैंक ट्रांसफर भी वही चीज़ है, बस उसकी पूँछ लंबी होती है। एक Bitcoin भुगतान एक स्थायी सार्वजनिक प्रविष्टि है जो उस पल पहचान दस्तावेज़ बन जाती है जब इसके इतिहास में मौजूद कोई भी पता आपसे जोड़ दिया जाता है। इस सूची में Monero ही एकमात्र माध्यम है जो किसी तीसरे पक्ष के पढ़ने लायक़ प्रविष्टि नहीं छोड़ता — लेकिन जिस खाते से आपने इसे हासिल किया था, उसके पास एक ऐसी निकासी का रिकॉर्ड हो सकता है जो समय और राशि में इनवॉइस से मेल खाता है, और वही सहसंबंध पूरा हमला है।
एग्ज़ॉस्ट। वह सब कुछ जो रजिस्ट्रेशन के बाद पैदा होता है, जिसके लिए कोई बजट नहीं बनाता, क्योंकि यह तब जमा होता रहता है जब आप देख नहीं रहे होते। सर्टिफिकेट ट्रांसपेरेंसी लॉग हर उस होस्टनेम को स्थायी और खोजी जा सकने वाली सूची में दर्ज करते हैं जिसके लिए आपने कभी सर्टिफिकेट माँगा हो। passive-DNS डेटासेट यह दर्ज करते हैं कि कौन-से नाम किन पतों पर resolve हुए हैं, और इसी तरह एक सर्वर पर मौजूद दो असंबंधित परियोजनाएँ एक ही परियोजना बन जाती हैं। ऐतिहासिक रजिस्ट्रेशन आर्काइव आपके गोपनीयता ऑन करने से पहले के रिकॉर्ड का एक स्नैपशॉट रखते हैं, और बाद में भी उसे हटाते नहीं। और सामग्री स्वयं भी लीक करती है: एक दोबारा इस्तेमाल किया गया एनालिटिक्स आइडेंटिफ़ायर, एक बार-बार आने वाला favicon हैश, एक सपोर्ट पता जो दोनों साइटों पर दिखता है।
एक वाक्य में लिख लें कि आप किससे अपने-आप को अपठनीय बनाने की कोशिश कर रहे हैं। एक सर्च बॉक्स वाला प्रतिस्पर्धी, मार्केटिंग लिस्ट बनाने वाला कोई मास स्क्रेपर, वकील वाला कोई वादी, या क़ानूनी प्रक्रिया वाला कोई राष्ट्र — यह चार अलग-अलग समस्याएँ हैं, और पहली दो उन डिफ़ॉल्ट सुरक्षाओं से ही हल हो जाती हैं जो आपके पास पहले से हैं। यह सवाल पूछने वाले अधिकतर लोगों को दूसरी वाली चाहिए होती है; लगभग किसी को चौथी नहीं चाहिए होती, और उससे निपटने वाले उपाय डोमेन से बहुत पहले ही शुरू हो जाते हैं।
कुछ भी करने से पहले, जो नाम आपके पास पहले से है उसका मौजूदा सार्वजनिक रिकॉर्ड पढ़ें। रजिस्ट्री-साइड का वह इंटरफ़ेस जिसने पुराने टेक्स्ट प्रोटोकॉल की जगह ली है, स्ट्रक्चर्ड डेटा लौटाता है, और यह आपको ठीक-ठीक दिखाता है कि आपका एक्सटेंशन कौन-से फ़ील्ड प्रकाशित करता है — न कि वह जो 2017 की कोई ब्लॉग पोस्ट बताती है कि वह प्रकाशित करता है:
whois example.com | sed -n '1,40p' # the legacy view, still served by many registries
curl -s https://rdap.org/domain/example.com | jq '.entities[].roles, .status'
# the structured view — roles, status codes, redaction
उस आउटपुट में दो चीज़ें कॉन्टैक्ट फ़ील्ड से भी ज़्यादा मायने रखती हैं। status ऐरे आपको बताता है कि नाम ट्रांसफर के ख़िलाफ़ लॉक है या नहीं, और क्या कोई रजिस्ट्री-स्तर की होल्ड लगी हुई है। और किसी कॉन्टैक्ट एंटिटी का न होना ही रिडैक्शन के काम करने का सबूत है — अगर आपको 2026 में किसी जेनेरिक डोमेन के लिए पूरा डाक पता दिखता है, तो इसकी वजह यह है कि रजिस्ट्रेंट ने इसे जान-बूझकर प्रकाशित किया है, जो आश्चर्यजनक रूप से अब भी कई संगठन करते हैं।
एक रजिस्ट्रार आपको केवल वही बेच सकता है जिसकी अनुमति उसकी रजिस्ट्री देती है। अगर रजिस्ट्री को स्थानीय उपस्थिति चाहिए, तो कोई भी गोपनीयता सेवा उस ज़रूरत को ख़त्म नहीं कर सकती; अगर रजिस्ट्री रजिस्ट्रेंट का नाम पूरा प्रकाशित करती है, तो कोई ऐड-ऑन उसे दबा नहीं सकता। यह ख़रीद के सामान्य क्रम के उलट है — लोग पहले एक नाम चुनते हैं, फिर एक रजिस्ट्रार, और फिर विफलता के क्षण में रजिस्ट्री के नियमों का पता चलता है। पहले एक्सटेंशन का परिवार चुनें।
व्यक्तिगत एक्सटेंशन की एक सूची के बजाय — जो एक साल के भीतर ही पुरानी पड़ जाएगी, क्योंकि रजिस्ट्री उद्योग के बाहर किसी को बताए बिना अपनी शर्तें बदल देती हैं — काम की बात यह है कि रजिस्ट्री क्या माँगती है, उसके आधार पर बँटवारा किया जाए। इसमें पाँच परिवार हैं और एक ग़ैर-डोमेन विकल्प, और आप जिस भी एक्सटेंशन पर विचार करेंगे वह लगभग हमेशा साफ़-साफ़ इनमें से किसी एक में आ जाता है।
| परिवार | रजिस्ट्री क्या माँगती है | निर्णय |
|---|---|---|
| लीगेसी जेनेरिक — .com, .net, .org | रजिस्ट्रार द्वारा एकत्र किया गया सटीक डेटा, सार्वजनिक रिकॉर्ड में रिडैक्ट, एक दर्ज अनुरोध पर प्रकट किया जाने वाला। कोई पात्रता परीक्षण नहीं। | डिफ़ॉल्ट जवाब। उबाऊ, पोर्टेबल, सार्वभौमिक रूप से स्वीकृत। |
| नया जेनेरिक — .dev, .app, .xyz, .site | वही केंद्रीय नीति, साथ ही जो कुछ अलग रजिस्ट्री अपनी शर्तों में जोड़ दे। कुछ डिज़ाइन के हिसाब से स्थायी रूप से सिर्फ़ HTTPS वाले होते हैं। | ठीक है, बशर्ते आपने अंदाज़ा लगाने के बजाय उस रजिस्ट्री की अपनी शर्तें पढ़ ली हों। |
| पात्रता-आधारित कंट्री-कोड — .eu, .us, .ca, .fr | निवास, नागरिकता या एक स्थानीय प्रतिष्ठान, जो ख़रीद के समय घोषित किया जाता है और बाद में सत्यापित किया जा सकता है। एक झूठी घोषणा एक ख़ामी नहीं, बल्कि रद्दीकरण का आधार है। | केवल तभी जब आप सचमुच वह शर्त पूरी करते हों। |
| सत्यापित कंट्री-कोड | एक पहचान जाँच, एक राष्ट्रीय पहचानकर्ता, या एक स्थानीय प्रशासनिक संपर्क — अक्सर रजिस्ट्रेंट का नाम पूरी तरह प्रकाशित होता है, चाहे रजिस्ट्रार आपको जो भी बेचे। | इस मक़सद के लिए इससे बचें। फ़ैसला रजिस्ट्रार नहीं, रजिस्ट्री करती है। |
| जेनेरिक की तरह बेचा जाने वाला खुला कंट्री-कोड | कोई निवास-परीक्षण नहीं, लेकिन रजिस्ट्री की अपनी नीति ही पूरा अनुबंध है — और कुछ रजिस्ट्री सब कुछ प्रकाशित कर देती हैं, या किसी राष्ट्रीय संस्था के अनौपचारिक अनुरोध पर सस्पेंड कर देती हैं। | मामले के अनुसार अलग। रीसेलर को नहीं, रजिस्ट्री के नीति पेज को पढ़ें। |
| एक version-3 onion address | कुछ भी नहीं। यह आपके द्वारा जनरेट की गई एक key pair से निकला है, इसलिए इसकी कोई रजिस्ट्री नहीं, कोई रजिस्ट्रार नहीं, कोई भुगतान नहीं और कोई समाप्ति तिथि नहीं। | अजेय, बशर्ते सिर्फ़ Tor वाली पहुँच स्वीकार्य हो। |
तीन सवाल यह फ़ैसला तय कर देते हैं, और तीनों के जवाब दुकान पर नहीं, बल्कि ख़ुद रजिस्ट्री के नीति पेज पर मिलते हैं। क्या कोई पात्रता शर्त है? अगर हाँ, तो या तो आप उसे पूरा करते हैं या कोई दूसरा एक्सटेंशन चुनते हैं — जो निवास आपके पास नहीं है उसका दावा करना एक गोपनीयता उपाय को एक ऐसे रद्दीकरण खंड में बदल देता है जो पहली शिकायत पर सक्रिय हो जाता है। रजिस्ट्री स्वयं क्या प्रकाशित करती है? जेनेरिक डोमेन के लिए रिडैक्शन केंद्रीय रूप से अनिवार्य है; कंट्री-कोड रजिस्ट्री अपने नियम स्वयं लिखती हैं और उनमें से कई रजिस्ट्रेंट का नाम प्रकाशित कर देती हैं, चाहे आपका रजिस्ट्रार गोपनीयता के लिए आपसे कुछ भी वसूल करे। सस्पेंशन का रेकॉर्ड कैसा है? जो रजिस्ट्री एक प्रकाशित विवाद प्रक्रिया चलाती है, उससे आप बहस कर सकते हैं; जिस रजिस्ट्री का इतिहास किसी अनौपचारिक फ़ोन कॉल पर कार्रवाई करने का रहा है, उससे नहीं।
एक चौथा सवाल है जो ख़रीद के समय लगभग कोई नहीं पूछता और सबको तेरहवें महीने में मिलता है: नवीनीकरण की क़ीमत क्या है? किसी अनोखे एक्सटेंशन पर एक प्रोमोशनल पहला साल, जिसके बाद कई गुना बड़ा एक सामान्य नवीनीकरण आता है, ऐसा फ़ैसला है जो आपको हर साल दोहराना पड़ता है, और जो नाम आप आराम से नवीनीकृत करने की हैसियत में नहीं हैं, वह आख़िरकार किसी ऐसे व्यक्ति के हाथ चला जाएगा जो ठीक इसी पल का इंतज़ार कर रहा था। दसवें साल की क़ीमत देखें, पहले साल की नहीं।
यह पढ़ने वाले लगभग हर व्यक्ति के लिए, क्रिप्टो स्वीकार करने वाले किसी रजिस्ट्रार के ज़रिए रजिस्टर किया गया एक लीगेसी जेनेरिक एक्सटेंशन ही सही जवाब है, और वही चतुर शब्द-खेल वाला अनोखा कंट्री-कोड तीन साल बाद सपोर्ट टिकट पैदा करता है। किसी जाने-पहचाने एक्सटेंशन से मिलने वाली गोपनीयता एक जैसी ही होती है; जो बदलता है वह यह है कि कितने पक्ष इसे आपसे छीन सकते हैं, और आपने उनमें से कितनों के बारे में कभी सुना है।
मॉडल एक — आपके अपने विवरण, डिफ़ॉल्ट रिडैक्शन के पीछे। आप ही रजिस्ट्रेंट हैं, डेटा सटीक है, और सार्वजनिक रिकॉर्ड उसमें से कुछ भी नहीं दिखाता। यह नाम क़ानूनी रूप से आपका है, यह किसी भी अन्य एसेट की तरह ट्रांसफर होता है, और कोई किसी मंगलवार को यह तय नहीं कर सकता कि वह चाहेगा कि यह आपके पास न रहे। आप जो स्वीकार कर रहे हैं वह यह है कि रजिस्ट्रार के पास आपका एक सच्चा रिकॉर्ड रहता है, और एक दर्ज अनुरोध उसे बाहर निकाल सकता है। अधिकतर परियोजनाओं के लिए यह पर्याप्त भी है और सही भी, और जो लोग इसे नकारते हैं वे आमतौर पर इसकी तुलना किसी वास्तविक विकल्प से नहीं, बल्कि किसी कल्पित विकल्प से कर रहे होते हैं।
मॉडल दो — एक छद्मनामी रजिस्ट्रेंट जो सचमुच संपर्क योग्य हो। एक काम करने वाला नाम और एक काम करने वाला पता जो आप तक पहुँचते हैं, बिना उन पर आपकी क़ानूनी पहचान लिखे। यह ख़ुद में क़ानूनी है और अधिकतर लोग "गुमनाम रजिस्ट्रेशन" से यही समझते हैं; जो चीज़ इसे कमज़ोर के बजाय टिकाऊ बनाती है वह यह है कि इसका संपर्क योग्य होना ज़रूरी है। रजिस्ट्रेशन डेटा के ग़लत होने की रिपोर्ट पर रजिस्ट्रार के लिए कार्रवाई करना अनिवार्य होता है, और कार्रवाई का पहला क़दम दर्ज पते पर एक मैसेज भेजना होता है। अगर वह मैसेज पहुँच जाता है, तो प्रक्रिया आमतौर पर वहीं ख़त्म हो जाती है। अगर नहीं पहुँचता, तो नाम आपके सोते समय सस्पेंड कर दिया जाता है, और यह ठीक उस वजह से सस्पेंड होता है जिसे आप आसानी से ठीक नहीं कर सकते — रिकॉर्ड पर मौजूद व्यक्ति आप नहीं हैं।
मॉडल तीन — प्रॉक्सी स्वामित्व। एक प्रदाता नाम को अपने ही क़ानूनी नाम पर रजिस्टर करता है और आपको इसके उपयोग का अधिकार देता है। आप रजिस्ट्री में कहीं नहीं हैं, क्योंकि आप रजिस्ट्रेंट नहीं हैं; आपके पास जो है वह एक अनुबंध है। रजिस्ट्रेशन डेटा के आपसे जुड़े होने के ख़िलाफ़ यह सबसे मज़बूत उपलब्ध सुरक्षा है, और यह एक कंपनी से जुड़ी एक इकलौती विफलता-बिंदु भी है। अब सब कुछ इस पर निर्भर करता है कि वह प्रदाता सॉल्वेंट बना रहे, अपनी नीतियाँ बनाए रखे, और आपके निर्देशों पर काम करने को सहमत रहे — जिसमें बाद में छोड़ना चाहने पर रजिस्ट्रेशन सौंप देने का निर्देश भी शामिल है। हम इस मॉडल के एक लंबे समय से चले आ रहे ऑपरेटर की तुलना अपने Njalla तुलना पेज पर करते हैं; वहाँ का आकलन भी यहाँ जैसा ही है — कि यह एक मुफ़्त अपग्रेड नहीं, बल्कि एक असली ट्रेड-ऑफ़ वाला असली प्रोडक्ट है।
| मॉडल | कब विफल होता है | इसे चुनें जब |
|---|---|---|
| अपने विवरण, रिडैक्ट किए हुए | क़ानूनी हैसियत रखने वाला कोई व्यक्ति एक दर्ज प्रकटीकरण अनुरोध करता है। | आप चाहते हैं कि नाम स्पष्ट रूप से आपका हो, और जनता के लिए अपठनीय हो। |
| छद्मनामी, सुलभ | दर्ज पता काम करना बंद कर देता है और एक सटीकता संबंधी शिकायत आ जाती है। | यह परियोजना आपका क़ानूनी व्यक्तित्व नहीं है, और आप उस मेलबॉक्स को सचमुच पढ़ेंगे। |
| प्रॉक्सी स्वामित्व | प्रदाता का अधिग्रहण हो जाता है, वह नीति बदल देता है, या बस जवाब देना बंद कर देता है। | अगर ज़रूरी हो तो नाम बदला जा सकता है, और यहाँ पोर्टेबिलिटी से ज़्यादा रजिस्ट्री रिकॉर्ड मायने रखता है। |
आप जो भी मॉडल चुनें, उसके इर्द-गिर्द बना खाता ही वह हिस्सा है जो तय करता है कि कहानी का अंत कैसा होगा, और यह कुछ भी रजिस्टर करने से पहले पाँच मिनट में बना लिया जाता है। एक समर्पित ईमेल पता जो सिर्फ़ इस खाते के लिए हो और किसी और चीज़ के लिए नहीं — न वह जो आपके कमिट इतिहास में है, न वह जो 2019 के किसी ब्रीच डेटा में है, और न वह जो उस डोमेन पर होस्ट किया गया हो जिसे आप रजिस्टर करने जा रहे हैं, क्योंकि जिस नाम का रिकवरी पता ख़ुद उसी नाम पर टिका हो, उसके समाप्त होने के बाद उसे रिकवर नहीं किया जा सकता। एक पासवर्ड जो और कहीं मौजूद न हो। एक टाइम-बेस्ड वन-टाइम-पासवर्ड सेकंड फ़ैक्टर, जिसके रिकवरी कोड उस मेलबॉक्स से अलग किसी जगह रखे गए हों जिसकी वे रक्षा करते हैं। और अगर रजिस्ट्रार फ़ोन नंबर छोड़ने की छूट दे, तो कोई फ़ोन नंबर न दें, क्योंकि नंबर फ़ॉर्म पर मौजूद किसी भी और चीज़ से ज़्यादा मज़बूत पहचानकर्ता होता है।
जेनेरिक डोमेन के लिए रजिस्ट्रार को रजिस्ट्रेंट के ईमेल पते को सत्यापित करना ज़रूरी होता है, और यह इसे ठीक एक मैसेज भेजकर करता है जिसमें एक लिंक होता है। अगर उस लिंक को पंद्रह दिनों के भीतर नहीं खोला जाता, तो रजिस्ट्रार के लिए नाम को सस्पेंड करना अनिवार्य होता है — साइट बंद हो जाती है, मेल रुक जाती है, और सर्टिफिकेट का नवीनीकरण विफल हो जाता है। यह ख़रीद के कुछ ही मिनटों के भीतर आ जाता है, यह रजिस्ट्रार के हर दूसरे ट्रांज़ैक्शनल मैसेज जैसा ही दिखता है, और यही वह सबसे सामान्य तरीक़ा है जिससे बड़ी सावधानी से योजना बनाई गई एक गुमनाम रजिस्ट्रेशन पखवाड़े भर में ही समाप्त हो जाती है। टैब बंद करने से पहले लिंक खोलें, फिर खाते में जाकर पुष्टि करें कि पता वेरिफ़ाइड दिखा रहा है।
एक और आदत जिसमें कुछ ख़र्च नहीं होता और जो इस क्षेत्र की सबसे अपरिवर्तनीय ग़लती को रोक देती है: एक हिस्सा, एक खाता। अगर किसी परियोजना को किसी दूसरी परियोजना से अलग-अलग दिखना ज़रूरी है, तो दोनों नाम एक रजिस्ट्रार खाता, एक पेमेंट सोर्स, एक नेमसर्वर सेट या एक सर्वर पता साझा न करें। बाद में उन्हें अलग करना असंभव है, क्योंकि वह कड़ी उस दिन ही दर्ज हो गई थी जब वे बनाए गए थे, और जिन डेटासेट ने उसे दर्ज किया वे भूलते नहीं।
क्रिप्टोकरेंसी स्वीकार करने वाला रजिस्ट्रार उस स्पष्ट समस्या को हल करता है: कोई कार्ड नंबर नहीं, कोई बिलिंग पता नहीं, कोई बैंक नहीं जो किसी छोटे विदेशी भुगतान की रिपोर्ट दर्ज करे। लेकिन यह उस समस्या को हल नहीं करता जो वास्तव में गुमनामी को तोड़ती है, और जो इससे एक क़दम पहले, यानी कॉइन जहाँ से आया वहाँ बैठी होती है। किसी की पहचान तक पहुँचने वाली तर्क की लगभग हर श्रृंखला किसी सत्यापित एक्सचेंज खाते से शुरू होकर आगे की ओर चली है, न कि किसी रजिस्ट्रार से शुरू होकर पीछे की ओर।
Monero यहाँ सबसे कम चलायमान हिस्सों वाला माध्यम है, क्योंकि राशियाँ, भेजने वाले और पाने वाले कहीं प्रकाशित नहीं होते। इसमें कोई लेजर प्रविष्टि नहीं होती जिसे कोई तीसरा पक्ष बाद में आपस में जोड़कर सहसंबंध बना सके, जिससे उन तमाम समस्याओं की पूरी श्रेणी समाप्त हो जाती है जो Bitcoin दस साल के दायरे में पैदा करता है। हमारी चरण-दर-चरण Monero गाइड वॉलेट और पुष्टियों को कवर करती है, और तरीक़ा बिल्कुल एक-जैसा रहता है, चाहे इनवॉइस किसी सर्वर का हो या किसी डोमेन का।
Bitcoin, चाहे ऑन-चेन हो या Lightning के ज़रिए, कहीं अधिक व्यापक रूप से स्वीकार किया जाता है और एक स्थायी, सार्वजनिक, खोजी जा सकने वाली प्रविष्टि छोड़ जाता है। यह अपने-आप में कोई समस्या नहीं है — समस्या तब बनती है जब उन कॉइन के इतिहास में मौजूद कोई भी पता कभी आपसे जोड़ दिया जाए, और यह पहचान से जोड़ना एक ऐसी सेवा है जिसे कई कंपनियाँ बेचती हैं। इस मामले में Lightning, ऑन-चेन से बेहतर है क्योंकि भुगतान स्वयं कोई लेजर प्रविष्टि नहीं होता, लेकिन चैनल की फ़ंडिंग ज़रूर थी, और कॉइन कहीं-न-कहीं से आए थे। Lightning गाइड दोनों माध्यमों को कवर करती है।
तीन आदतें कॉइन की पसंद से भी ज़्यादा असर डालती हैं। हासिल करने और ख़र्च करने के बीच फ़ासला रखें — समय का फ़ासला, और कम-से-कम एक ऐसा पड़ाव जो किसी सत्यापित खाते से सीधे व्यापारी तक की सीधी निकासी न हो। एक गोल रकम में एक प्रीपेड बैलेंस फ़ंड करके राशि-आधारित सहसंबंध को तोड़ें, बजाय इसके कि हर इनवॉइस का उसकी सटीक और असामान्य क़ीमत पर भुगतान किया जाए, क्योंकि "14:07 पर 0.0413 XMR की निकासी" और "14:09 पर 0.0413 XMR का इनवॉइस" — यह मेल कोई भी बना सकता है। और रजिस्ट्रार को ऑटोमैटिक नवीनीकरण के लिए कोई पेमेंट तरीक़ा दर्ज रखने न दें: एक स्टोर किया गया कार्ड वही पहचान दस्तावेज़ है जिसे आपने ख़रीद से हटाया था, और वह दूसरे साल फिर लौट आता है, जबकि एक स्टोर किया गया क्रिप्टो बैलेंस उसी ज़रूरत का बेहतर जवाब है।
रजिस्ट्रेशन का भुगतान करते समय ही नवीनीकरण के लिए भी बजट बना लें, क्योंकि यहीं सबसे बड़ी संख्या में गुमनाम नाम ख़ामोशी से समाप्त होते हैं। रजिस्ट्री एक ही ट्रांज़ैक्शन में जितने साल की अनुमति दे, उतने साल के लिए रजिस्टर करें — अधिकतर जेनेरिक एक्सटेंशन दस साल तक की अनुमति देते हैं — और इससे आपने एक बार-बार होने वाले जोखिम को एक ही भुगतान में बदल दिया और नौ मौक़े हटा दिए जिनमें किसी असफल नवीनीकरण से नाम आपसे छिन सकता था। यह इस पेज पर जोखिम घटाने का सबसे सस्ता तरीक़ा है, और आमतौर पर इसे नहीं अपनाया जाता क्योंकि पहला साल ही काफ़ी लगता है।
वह मशीन जिस पर नाम पॉइंट करता है, इस समस्या का आसान वाला आधा हिस्सा है, क्योंकि होस्टिंग का संबंध द्विपक्षीय होता है और कुछ भी प्रकाशित करना ज़रूरी नहीं होता। NordBastion पर साइन-अप के समय कोई ईमेल सत्यापन नहीं, कोई पहचान दस्तावेज़ नहीं, कोई कार्ड नहीं और खाते पर कोई क़ानूनी नाम नहीं होता; बैलेंस Monero, Bitcoin या कई अन्य एसेट में फ़ंड किया जाता है, और सर्वर उस बैलेंस से ऑर्डर किया जाता है। डोमेन ही वह उजागर सतह बना रहता है। होस्ट को दूसरी उजागर सतह बनने की ज़रूरत नहीं है।
डेलिगेशन ख़ुद में सिर्फ़ दो रिकॉर्ड और पाँच मिनट का काम है। रजिस्ट्रार पर नेमसर्वर सेट करें, होस्ट के लिए एक address रिकॉर्ड बनाएँ, बदलाव के रजिस्ट्री तक प्रोपगेट होने का इंतज़ार करें, और इसकी पुष्टि अपने ही नेटवर्क के बाहर से करें, न कि उस मशीन से जो जवाब पहले से जानती है। बाक़ी के चालीस मिनट उस हर चीज़ के लायक़ हैं जिसे डेलिगेशन बाद में दिखा देता है।
dig +short NS example.com @1.1.1.1 # the delegation as the world sees it, not your cache
dig +short A app.example.com # must return the VPS address before you deploy anything
dig +short CAA example.com # empty today; step 05 fills it in
dig +short DS example.com # non-empty only if DNSSEC is actually signed
प्राधिकृत सर्वर कौन चलाता है के मामले में, ईमानदार जवाब वह नहीं है जो यह सीरीज़ बाक़ी जगहों पर आमतौर पर देती है। प्राधिकृत DNS की सेल्फ़-होस्टिंग वह एक घटक है जहाँ यह ख़ुद करना आमतौर पर ज़्यादा बुरा साबित होता है: इसके लिए अलग-अलग नेटवर्कों पर दो या अधिक सर्वर चाहिए, इसे ठीक उस आउटेज के दौरान भी काम करते रहना पड़ता है जिसने आपके मुख्य बॉक्स को गिरा दिया है, इसे एम्प्लिफ़िकेशन के दुरुपयोग से बचने के लिए निरंतर देखभाल चाहिए, और जब यह विफल होता है तो इसके साथ सब कुछ विफल हो जाता है — यहाँ तक कि वह सर्टिफिकेट नवीनीकरण भी जिससे आप स्थिति ठीक कर सकते थे। यह वह सहसंबंध भी बना देता है जिससे आप बचना चाहते थे, क्योंकि दो परियोजनाओं के बीच साझा किया गया एक सेल्फ़-रन नेमसर्वर उन्हें, किसी भी व्यक्ति द्वारा क्वेरी किए जा सकने वाले डेटासेट में, सार्वजनिक रूप से आपस में जोड़ देता है। एक ऐसा DNS ऑपरेटर इस्तेमाल करें जिसका anycast नेटवर्क हो, उसे उसकी फ़ीचर लिस्ट के बजाय इस आधार पर चुनें कि उसे पहचान दस्तावेज़ चाहिए या नहीं, और एक एक्सपोर्ट की गई ज़ोन फ़ाइल रखें ताकि जगह बदलना खुदाई जैसा नहीं, बल्कि बस पेस्ट करने जैसा काम रहे। यह सीरीज़ में मौजूद प्राइवेट रिकर्सिव रिज़ॉल्वर से एक अलग काम है, जो आप क्या खोजते हैं इसका लॉग आपकी अपनी मशीन पर ले जाता है और करने लायक़ है।
अब वह लीक, जो इस पेज पर किसी भी और चीज़ से ज़्यादा सावधानी से बनाए गए सेटअप बिगाड़ती है, क्योंकि यह ख़ामोशी से और आपके ध्यान देना बंद कर देने के बाद काम करती है। किसी सार्वजनिक रूप से भरोसेमंद प्राधिकरण द्वारा जारी हर सर्टिफिकेट ऐसे स्थायी सार्वजनिक लॉग में दाख़िल किया जाता है जिससे प्रविष्टियाँ कभी हटती नहीं, और ब्राउज़र उन सर्टिफिकेट को अस्वीकार कर देते हैं जो ऐसा नहीं करते। यह लॉग इसलिए मौजूद हैं ताकि ग़लत-जारी को पहचाना जा सके, जो सचमुच एक अच्छी बात है, और इन्हें मुफ़्त सर्च इंटरफ़ेस द्वारा इंडेक्स किया जाता है। इसका नतीजा यह है कि आपने जिस भी होस्टनेम के लिए कभी सर्टिफिकेट माँगा हो, वह किसी के लिए भी, हमेशा के लिए, बस एक कीवर्ड सर्च दूर है — इसमें staging., vpn., backup. और वह प्रशासनिक नाम भी शामिल है जिसके बारे में आपने सोचा था कि कोई अंदाज़ा नहीं लगा पाएगा।
# every certificate ever issued under the zone, and every hostname inside each one
curl -s 'https://crt.sh/?q=%25.example.com&output=json' | jq -r '.[].name_value' | sort -u
इसका उपाय है ज़ोन के लिए एक इकलौता वाइल्डकार्ड सर्टिफिकेट, जिसे इसके नीचे मौजूद हर इंटरनल होस्टनेम के लिए सर्व किया जाए। इसके बाद लॉग एंट्री सिर्फ़ यह दर्ज करती है कि ज़ोन के लिए एक सर्टिफिकेट मौजूद है, इसके भीतर क्या है इसके बारे में कुछ नहीं। इसकी क़ीमत यह है कि एक वाइल्डकार्ड के लिए आसान वाली फ़ाइल-आधारित चुनौती के बजाय DNS-आधारित चुनौती चाहिए, यानी बॉक्स पर आपके DNS ऑपरेटर के लिए एक API टोकन — दस मिनट का सेटअप, आपकी इंटरनल नेमिंग स्कीम की एक स्थायी सार्वजनिक सूची के मुक़ाबले। एक वाइल्डकार्ड जारी करें, उसे रिवर्स प्रॉक्सी पर रखें, और प्रति-होस्टनेम सर्टिफिकेट माँगना बंद कर दें।
दो रिकॉर्ड यह काम पूरा कर देते हैं। एक CAA रिकॉर्ड यह बताता है कि इस नाम के लिए कौन-से सर्टिफिकेट प्राधिकरण जारी करने के लिए अधिकृत हैं, जिससे किसी भी अन्य प्राधिकरण द्वारा ग़लत-जारी को बाद में पहचानने के बजाय स्रोत पर ही मना कर दिया जाता है। और DNSSEC, अगर आपकी रजिस्ट्री और आपका DNS ऑपरेटर दोनों इसे सपोर्ट करते हैं, तो डेलिगेशन पर हस्ताक्षर कर देता है ताकि एक रिज़ॉल्वर किसी जाली जवाब को असली जवाब से अलग बता सके — यह अधिकतर ऑपरेटरों पर बस एक स्विच है और रजिस्ट्रार पर एक रिकॉर्ड है, और सावधानी बरतने की एकमात्र बात यह है कि जिस साइन की गई ज़ोन की keys ठीक से नहीं संभाली जातीं, वह पूरी तरह विफल हो जाती है — यानी पूरी तरह बंद हो जाती है।
; in the zone — only this authority may issue, and tell us if anyone tries
example.com. IN CAA 0 issue "letsencrypt.org"
example.com. IN CAA 0 issuewild "letsencrypt.org"
example.com. IN CAA 0 iodef "mailto:abuse@example.com"
अंत में, सहसंबंध वाली परत, जहाँ बिना किसी की कोई गलती किए भी दो अलग-अलग हिस्से एक बन जाते हैं। passive-DNS डेटासेट यह दर्ज करते हैं कि कौन-से नाम कब किन पतों पर resolve हुए; एक साझा पता, एक साझा नेमसर्वर सेट या एक साझा मेल एक्सचेंजर, दो ऐसी परियोजनाओं को जोड़ने के लिए काफ़ी होता है जिनमें और कुछ भी साझा नहीं है। अगर दो नामों को बिना जुड़े रहना ज़रूरी है, तो उन्हें अलग सर्वर, अलग नेमसर्वर सेट और अलग मेल रूटिंग चाहिए — और यही उन छोटी चीज़ों पर भी लागू होता है जिन्हें कोई नहीं गिनता, जैसे दोनों साइटों पर दोबारा इस्तेमाल किया गया एक एनालिटिक्स आइडेंटिफ़ायर या एक जैसा favicon, जो दोनों ही इंटरनेट-स्तर पर उस किसी भी व्यक्ति के लिए खोजे जा सकते हैं जो खोजना चाहे।
इस सीरीज़ में डोमेन ही एकमात्र घटक है जिसकी एक्सपायरी तिथि होती है, और इसे खोना यहाँ की एकमात्र ऐसी विफलता है जो सचमुच अपरिवर्तनीय है। जब कोई नाम समाप्त हो जाता है तो साइट बंद हो जाती है, मेल रुक जाती है, सर्टिफिकेट का नवीनीकरण विफल हो जाता है, उस डोमेन पर मौजूद किसी पते से जुड़ा हर खाता अप्राप्य हो जाता है, और एक तय समय-सीमा के बाद कोई भी इसे रजिस्टर कर सकता है — यहाँ तक कि वह व्यक्ति भी जो इसके गिरने का इंतज़ार ठीक इसलिए कर रहा था क्योंकि इस पर ट्रैफ़िक था। इसके लिए कोई बैकअप नहीं है जो इसे बहाल कर सके।
यह टाइमलाइन ठीक-ठीक जान लेना उचित है, क्योंकि हर चरण की क़ीमत अलग होती है और आख़िरी चरण की कोई क़ीमत ही नहीं होती। समाप्ति पर नाम आमतौर पर तुरंत resolve होना बंद कर देता है जबकि एक ग्रेस अवधि चलती है, जिसके दौरान नवीनीकरण की लागत सामान्य फ़ीस जितनी ही रहती है। इसके बाद यह लगभग तीस दिन की एक रिडेम्पशन अवधि में प्रवेश करता है, जिसके दौरान इसे अब भी वापस पाया जा सकता है, लेकिन रजिस्ट्रार के बजाय रजिस्ट्री द्वारा तय की गई एक दंडात्मक फ़ीस पर। इसके बाद एक छोटा-सा पेंडिंग-डिलीट चरण आता है जिसमें कोई भी कुछ नहीं कर सकता। इसके बाद यह गिर जाता है, और जो भी पक्ष सबसे पहले इस तक पहुँचता है, वही इसका मालिक बन जाता है। अंतराल रजिस्ट्री के अनुसार बदलते हैं; लेकिन यह क्रम नहीं बदलता।
| अवस्था | नाम है | रिकवरी |
|---|---|---|
| ग्रेस, समाप्ति के बाद | आमतौर पर पहले से resolve नहीं होता | सामान्य क़ीमत पर नवीनीकरण करें |
| रिडेम्पशन, लगभग 30 दिन | रजिस्ट्री के पास रखा हुआ, बंद | संभव है, एक दंडात्मक रजिस्ट्री फ़ीस पर |
| पेंडिंग डिलीट, लगभग 5 दिन | रिलीज़ के लिए क़तार में | किसी के लिए भी कोई नहीं |
| ड्रॉप हो गया | पूरी दुनिया के लिए उपलब्ध | जो भी तेज़ था, उससे इसे वापस ख़रीद लें |
इस सब के सामने एक नाम को चार चीज़ें बनाए रखती हैं। लंबी अवधि के लिए रजिस्टर करें — जहाँ रजिस्ट्री अनुमति दे वहाँ दस साल के लिए, जिससे किसी नवीनीकरण के विफल होने के नौ मौक़े ख़त्म हो जाते हैं। ट्रांसफर लॉक ऑन रखें, वह स्टेटस कोड जो आपके पहले अनलॉक किए बिना ट्रांसफर शुरू होने से रोकता है, और अगर आपका एक्सटेंशन रजिस्ट्री-स्तर का लॉक देता है और नाम मायने रखता है, तो उसे भी जोड़ें। प्राधिकरण कोड को ऑफ़लाइन स्टोर करें, उसी जगह जहाँ सेकंड-फ़ैक्टर रिकवरी कोड और एक्सपोर्ट की गई ज़ोन फ़ाइल रखी हो, क्योंकि जिस दिन आपको इसकी ज़रूरत होगी, वही वह दिन होगा जब खाता जवाब नहीं दे रहा होगा। और समाप्ति तिथि को उस कैलेंडर में रखें जिसे आप सचमुच पढ़ते हैं, न कि केवल रजिस्ट्रार के नोटिफ़िकेशन सिस्टम में — जिस रजिस्ट्रार ने आपका खाता बंद कर दिया है, उसने आपको इस बारे में ईमेल भेजना भी बंद कर दिया है।
जब कुछ भी गड़बड़ न हो, तब एक बार निकास का अभ्यास कर लें। अनलॉक करें, प्राधिकरण कोड का अनुरोध करें, यह पुष्टि करें कि आप दर्ज पते पर ट्रांसफर मैसेज पा सकते हैं, फिर उसे फिर से लॉक कर दें — बीस मिनट, जो किसी आपातकाल को एक प्रक्रिया में बदल देते हैं। ध्यान रहे कि किसी रजिस्ट्रेशन या पिछले ट्रांसफर के बाद पहले साठ दिनों में ट्रांसफर उपलब्ध नहीं होता, और यही वह अवधि है जिसमें अक्सर पता चलता है कि नया रजिस्ट्रार ग़लत चुनाव था।
अंत में, वह चीज़ जो सचमुच उस तरह से मज़बूत है जैसी कोई रजिस्टर किया गया नाम कभी नहीं हो सकता। एक version-3 onion address की कोई रजिस्ट्री नहीं होती, कोई रजिस्ट्रार नहीं होता, कोई नवीनीकरण नहीं होता, कोई भुगतान नहीं होता, और ऐसा कुछ भी नहीं होता जिसे कोई निरस्त कर सके, क्योंकि यह address उस key pair से निकला है जो आपके पास है। clearnet साइट के साथ-साथ इसे चलाने में केवल दो पंक्तियों का कॉन्फ़िगरेशन लगता है, और यह आपको एक ऐसा address देता है जो उस दिन भी काम करता रहता है जब रजिस्ट्रार खाता बंद कर देता है — इसे साइट पर प्रकाशित करें, Onion-Location हेडर जोड़ें ताकि Tor उपयोगकर्ता को यह स्वतः ऑफ़र हो जाए, और यह वह फ़ॉलबैक बन जाता है जो इस पूरे चरण की असल चिंता वाली विफलता में भी बचा रहता है। गुप्त सेवा गाइड शुरू से आख़िर तक बीस मिनट की है।
एक मैसेज, जो ख़रीद के कुछ ही मिनटों बाद भेजा जाता है, और जिसे बगल की रसीद से अलग बता पाना मुश्किल होता है। पंद्रह दिन बाद रजिस्ट्रार के लिए नाम सस्पेंड करना अनिवार्य हो जाता है: साइट बंद हो जाती है, मेल रुक जाती है, सर्टिफिकेट का नवीनीकरण विफल हो जाता है। टैब बंद करने से पहले इसे खोलें, फिर खाते में जाकर पुष्टि करें कि पता वेरिफ़ाइड दिखा रहा है।
एक ख़त्म हो चुका क्रिप्टो बैलेंस, ख़ुद उस डोमेन पर मौजूद मेलबॉक्स को भेजा गया एक नोटिफ़िकेशन, एक ऐसा रजिस्ट्रार जिसके रिमाइंडर मार्केटिंग में दर्ज हो गए थे। रिडेम्पशन के बाद कोई भी इसे रजिस्टर कर सकता है, और कोई-न-कोई ठीक इसी पल का इंतज़ार करता रहता है। दस साल के लिए रजिस्टर करें, तारीख़ को अपने ही कैलेंडर में रखें, और रिकवरी को कभी उस नाम पर न टिकाएँ जिसकी वह रक्षा करती है।
जो एक्सटेंशन निवास, नागरिकता या किसी स्थानीय प्रतिष्ठान की माँग करता है, वह चेकआउट के बाद भी माँगना बंद नहीं करता। जो आपके पास नहीं है उसे घोषित करना रजिस्ट्रेशन को एक ऐसे रद्दीकरण खंड में बदल देता है जो पहली शिकायत पर ही सक्रिय हो जाता है — और नाम बिना किसी ऐसी प्रक्रिया के चला जाता है जिसमें शामिल होने लायक़ कुछ हो।
जिस भी सर्टिफिकेट पर सार्वजनिक रूप से भरोसा किया जाता है, वह एक ऐसे स्थायी लॉग में दर्ज हो जाता है जिससे प्रविष्टियाँ कभी हटती नहीं और जिसे कोई भी डोमेन के आधार पर खोज सकता है। इसमें कोई ऑप्ट-आउट नहीं है, और होना भी नहीं चाहिए। ज़ोन के लिए एक वाइल्डकार्ड सर्टिफिकेट सिर्फ़ ज़ोन को प्रकाशित करता है, उसके नीचे कुछ भी नहीं; जबकि प्रति-होस्टनेम सर्टिफिकेट आपकी पूरी इंटरनल नेमिंग स्कीम को स्थायी रूप से प्रकाशित कर देते हैं।
कमर्शियल आर्काइव रजिस्ट्रेशन रिकॉर्ड का लगातार स्नैपशॉट लेते हैं और उन्हें रखते हैं। जो नाम कभी आपके विवरणों के साथ खुले में रजिस्टर हुआ था, वह उनके इतिहास में वैसा ही बना रहता है, चाहे आज का रिकॉर्ड जो भी कहे। किसी नाम को क्लीन मानने से पहले जाँच लें कि वहाँ पहले से क्या स्टोर है — और जो भी चीज़ मायने रखती हो, उसके लिए ट्रांसफर के बजाय एक ताज़ा रजिस्ट्रेशन को प्राथमिकता दें।
एक पेशेवर डोमेन और एक ऐसी परियोजना, जिससे आप जुड़ा नहीं दिखना चाहते, दोनों एक ही रजिस्ट्रार खाते में, एक ही पेमेंट सोर्स पर, एक ही नेमसर्वर के पीछे। सार्वजनिक रिकॉर्ड कुछ भी न कहे, फिर भी वे जुड़े रहते हैं — उस खाते को पढ़ सकने वाले किसी भी व्यक्ति के लिए, और बाक़ी सबके लिए passive-DNS डेटासेट में।
यह करते समय सामने आने वाले ग्यारह सवाल — उस सवाल से शुरू करते हुए जो यह तय करता है कि इसमें से कुछ भी टिकता है या नहीं।
अपनी पहचान प्रकाशित किए बिना डोमेन रजिस्टर करना क़ानूनी और सामान्य बात है; ग़लत विवरणों के साथ रजिस्टर करना एक अलग बात है, और पूरा विषय इसी अंतर पर टिका है। 2018 में रजिस्ट्रेशन डेटा को संभालने के तरीक़े में हुए बदलाव के बाद से, एक जेनेरिक टॉप-लेवल डोमेन का सार्वजनिक रिकॉर्ड डिफ़ॉल्ट रूप से रिडैक्ट रहता है — आपके विवरण एकत्र किए और रखे जाते हैं, बस पूछने वाले किसी को भी प्रकाशित नहीं किए जाते। 2026 में यही किसी डोमेन की सामान्य स्थिति है, कोई गोपनीयता की तिकड़म नहीं, और यही वजह है कि एक ऐड-ऑन के रूप में "WHOIS गोपनीयता" का बाज़ार अब काफ़ी हद तक उस चीज़ का बाज़ार बन गया है जो आपके पास पहले से ही है। जो सचमुच वैकल्पिक बचता है वह यह है कि सटीक विवरण आपके क़ानूनी नाम के तहत किसी रजिस्ट्रार के पास रहें, या कोई तीसरा पक्ष रजिस्ट्रेशन रखे और आपके पास उससे एक अनुबंध हो। दोनों ही क़ानूनी हैं। जो क़ानूनी नहीं है, या कम-से-कम टिकाऊ नहीं है, वह है जान-बूझकर ग़लत विवरण देना: ICANN के accreditation अनुबंध के तहत रजिस्ट्रार को ग़लत डेटा की रिपोर्ट पर कार्रवाई करनी ही होती है, और EU के भीतर, NIS2 निर्देश का Article 28, रजिस्ट्री और रजिस्ट्रेशन सेवाओं को सटीक और पूर्ण डेटा रखने और उसे सत्यापित करने के एक सकारात्मक कर्तव्य के अधीन रखता है। किसी मनगढ़ंत पहचान पर बनाई गई रजिस्ट्रेशन ऐसी रजिस्ट्रेशन है जिसे उसी क्षण रद्द किया जा सकता है जब कोई शिकायत करे — और वही वह क्षण है जब आप इसे खोना सबसे कम चाहेंगे। व्यावहारिक स्थिति यह है: सटीक डेटा, जितने कम पक्षों के पास हो सके उतने कम के पास रखा गया, किसी के सामने प्रकाशित नहीं। यहाँ कुछ भी क़ानूनी सलाह नहीं है।
पहले जितना अब नहीं, और इसका फ़र्क़ इसके लिए भुगतान करने से पहले समझ लेना ज़रूरी है। किसी जेनेरिक टॉप-लेवल डोमेन के लिए सार्वजनिक रिकॉर्ड पहले से ही कॉन्टैक्ट फ़ील्ड रिडैक्ट किए हुए दिखाता है, इसलिए एक पेड गोपनीयता सेवा उसमें कुछ नहीं जोड़ती जो कोई अनजान व्यक्ति पढ़ सकता है। फिर भी यह दो काम की चीज़ें करती है। यह उन जगहों पर आपके पते के बदले एक फ़ॉरवर्डिंग पता रख देती है जहाँ रिडैक्शन नहीं पहुँचता — रजिस्ट्रार के अपने डायरेक्टरी पेज, वह डेटा जो कुछ रजिस्ट्री अभी भी पूरा प्रकाशित करती हैं, बल्क फ़ीड, और ट्रांसफर पुष्टि वाले ईमेल। और यह आपके और रिकॉर्ड पर दर्ज पते की ओर आने वाले स्वचालित दुरुपयोग की मात्रा के बीच एक पक्ष खड़ा कर देती है। जो तीन चीज़ें यह नहीं करती, वे कहीं ज़्यादा अहम हैं। यह आपके रजिस्ट्रार के पास मौजूद विवरणों को प्रभावित नहीं करती, जो एक दर्ज अनुरोध पर वैसे भी प्रकट कर दिए जाते हैं। यह पहले से हुए के लिए लागू नहीं होती: अगर वह नाम कभी आपके विवरणों के साथ खुले में रजिस्टर हुआ था, तो वह स्नैपशॉट आधा दर्जन कमर्शियल ऐतिहासिक आर्काइव में स्थायी रूप से मौजूद रहता है, और आज गोपनीयता ऑन करने से वह हटता नहीं। और कई कंट्री-कोड डोमेन पर यह बिल्कुल उपलब्ध ही नहीं होती, क्योंकि क्या प्रकाशित होगा यह रजिस्ट्रार नहीं, रजिस्ट्री तय करती है। इसे स्पैम नियंत्रण और एक हल्की परत के रूप में देखें, गुमनामी के रूप में नहीं।
इसका इतना मायने नहीं है जितना यह मायने रखता है कि कॉइन कहाँ से आया, और यही वह हिस्सा है जिसे लोग उल्टा समझ लेते हैं। एक Bitcoin भुगतान एक स्थायी सार्वजनिक प्रविष्टि है जो एक राशि और एक समय को एक पते से जोड़ती है, और अगर वह पता कभी आपसे जुड़ जाए — क्योंकि आपने इसे किसी पहचान दस्तावेज़ से खोले गए खाते से निकाला था, क्योंकि आपने इसे दोबारा इस्तेमाल किया, क्योंकि किसी चेन-एनालिसिस फ़र्म ने इसे किसी ऐसे पते के साथ जोड़ दिया जो पहले से जुड़ा था — तो वह भुगतान उस दिन आपके नाम और उस रजिस्ट्रार के बीच एक टिकाऊ कड़ी बन जाता है। Monero राशियाँ, भेजने वाले या पाने वाले प्रकाशित नहीं करता, इसलिए वही भुगतान कोई समान प्रविष्टि नहीं छोड़ता। लेकिन अगर वह Monero कुछ मिनट पहले ही किसी ऐसे एक्सचेंज से ख़रीदा गया था जिसने आपकी पहचान सत्यापित की थी, और सीधे रजिस्ट्रार को निकाल दिया गया, तो उस एक्सचेंज के पास एक ऐसी निकासी का रिकॉर्ड रहता है जो राशि और समय में इनवॉइस से क़रीब-क़रीब पूरी तरह मेल खाता है, और वह सहसंबंध बनाना मुश्किल नहीं है। जो नियम वास्तव में काम करता है वह कॉइन के बारे में नहीं, बल्कि फ़ासले के बारे में है: जहाँ से आपने वैल्यू हासिल की और जहाँ आपने उसे ख़र्च किया, उसके बीच समय, राशि-आकार और कम-से-कम एक ऐसा पड़ाव रखें जो किसी से जुड़ा हुआ न हो, और हर इनवॉइस का उसकी सटीक क़ीमत पर भुगतान करने के बजाय एक गोल रकम में प्रीपेड बैलेंस फ़ंड करने को प्राथमिकता दें। हमारी Monero गाइड और Lightning गाइड दोनों माध्यमों की बारीकियाँ कवर करती हैं।
नहीं, और इस मॉडल का कोई अच्छा प्रदाता यह साफ़-साफ़ कहता भी है। प्रॉक्सी स्वामित्व में प्रदाता नाम को अपने ही क़ानूनी नाम पर रजिस्टर करता है और आपको इसे उपयोग करने व निर्देशित करने का अधिकार देता है; आपके पास एक अनुबंध होता है, कोई रजिस्ट्रेशन नहीं। यही बात इसे प्रभावी बनाती है — रजिस्ट्री में आपका कहीं कोई रिकॉर्ड नहीं होता, क्योंकि आप रजिस्ट्रेंट नहीं हैं — और यही बात इसे जोखिम का एक संकेंद्रण भी बना देती है। अब सब कुछ एक ही कंपनी की सॉल्वेंसी, उसकी नीतियों और आपके निर्देशों पर काम करने की उसकी इच्छा पर निर्भर करता है — जिसमें बाद में छोड़ना चाहने पर रजिस्ट्रेशन आपको ट्रांसफर करने की इच्छा भी शामिल है। जो प्रदाता यह अच्छी तरह करते हैं वे अनुरोध पर ट्रांसफर करने की एक स्पष्ट प्रतिबद्धता प्रकाशित करते हैं और उसका पालन करने का एक दृश्य रिकॉर्ड रखते हैं, और वही रिकॉर्ड आपके पास उपलब्ध एकमात्र वास्तविक जाँच का आधार है। इसे विफलता की स्थिति के सामने तौलें: जिस दिन प्रदाता का अधिग्रहण हो जाए, वह अपनी शर्तें बदल दे, यह तय कर दे कि आपकी सामग्री उसकी नीति से बाहर है, या बस जवाब देना बंद कर दे, उस दिन आपके पास एक ऐसा नाम रह जाता है जिसे आप हिला नहीं सकते। जिस परियोजना का नाम बदला जा सकता हो, उसके लिए यह सौदा अक्सर उचित होता है। लेकिन जिस किसी चीज़ का address ही उसकी पहचान है — एक प्रकाशित सॉफ़्टवेयर रिपॉज़िटरी, एक मेल डोमेन, ग्राहकों वाली एक दुकान — उसके लिए यह किसी तीसरे पक्ष पर लगाई गई एक शर्त है, जो गोपनीयता सेवा के पीछे की एक सीधी रजिस्ट्रेशन आपसे नहीं माँगती। हम इस मॉडल के एक प्रदाता की तुलना अपने Njalla तुलना पेज पर करते हैं।
एक साल के भीतर पुरानी पड़ जाने वाली किसी सूची के बजाय, रजिस्ट्री के अपने नीति पेज पर तीन सवाल आज़माएँ। पहला: क्या यह कोई पात्रता शर्त लगाती है — निवास, नागरिकता, एक स्थानीय कंपनी, एक स्थानीय प्रशासनिक संपर्क? अगर हाँ, तो उस शर्त को पूरा करने का मतलब है या तो वह चीज़ होना, या यह दावा करना कि आप वह हैं — और दूसरा विकल्प कोई तोड़ नहीं, बल्कि रद्दीकरण का आधार है। दूसरा: रजिस्ट्री स्वयं क्या प्रकाशित करती है? जेनेरिक डोमेन के लिए रजिस्ट्रेशन डेटा नीति केंद्रीय रूप से तय होती है और कॉन्टैक्ट फ़ील्ड रिडैक्ट करती है, लेकिन कंट्री-कोड रजिस्ट्री अपने नियम स्वयं तय करती हैं और उनमें से कई रजिस्ट्रेंट का नाम पूरा प्रकाशित कर देती हैं, चाहे आपका रजिस्ट्रार आपको जो भी बेचे। तीसरा: रजिस्ट्री के पीछे कौन है और नाम सस्पेंड करने का उसका रेकॉर्ड कैसा है? कुछ रजिस्ट्री एक दर्ज विवाद प्रक्रिया पर चलती हैं; कुछ ने किसी राष्ट्रीय संस्था के अनौपचारिक अनुरोध पर नाम हटा दिए हैं, और जो डोमेन बिना किसी ऐसी प्रक्रिया के छीना जाए जिसमें आप शामिल हो सकें, वह ऐसा डोमेन है जिसका आप बचाव नहीं कर सकते। एक चौथा सवाल है जो कोई नहीं पूछता और सबको पूछना चाहिए: दूसरे साल नवीनीकरण की क़ीमत क्या है? किसी अनोखे एक्सटेंशन पर एक प्रोमोशनल पहला साल, जिसके बाद एक बड़ा सामान्य नवीनीकरण आता है, ऐसा फ़ैसला है जो आपको बार-बार दोहराना पड़ता है, और जो नाम आप नवीनीकृत करने की हैसियत में नहीं हैं, वह आख़िरकार किसी ऐसे व्यक्ति के हाथ चला जाएगा जो उसके गिरने का इंतज़ार कर रहा हो।
परियोजनाओं की एक वास्तविक श्रेणी के लिए, हाँ, और यह इस पेज पर एकमात्र ऐसी व्यवस्था है जिसमें न कोई रजिस्ट्रार है, न कोई रजिस्ट्री, न कोई नवीनीकरण तिथि और न कोई भुगतान। version-3 onion address किसी के द्वारा आवंटित नहीं किया जाता: यह आपके द्वारा जनरेट की गई key pair से निकली एक 56-कैरेक्टर एन्कोडिंग है, जो इस address को स्व-प्रमाणीकृत और अपरिवर्तनीय बना देती है — कोई भी इसे न ट्रांसफर कर सकता है, न सस्पेंड कर सकता है, न समाप्त होने दे सकता है, क्योंकि इसका कहीं कोई ऐसा रिकॉर्ड ही नहीं है जिस पर कोई कार्रवाई की जा सके। इसके बदले आप जो छोड़ते हैं वह है हर वह व्यक्ति जो Tor Browser इंस्टॉल नहीं करेगा, जो अधिकतर सार्वजनिक-मुखी परियोजनाओं के लिए लगभग सभी होते हैं, साथ ही सर्च में दिखना, साथ ही मेल, साथ ही हर वह इंटीग्रेशन जो एक सामान्य होस्टनेम मानकर चलता है। व्यवहार में जो व्यवस्था काम करती है वह दोनों का मेल है: पहुँच के लिए इस गाइड में बताया गया एक clearnet डोमेन रजिस्टर करना, जो चाहें उनके लिए एक onion सेवा, और clearnet साइट पर Onion-Location हेडर, जिससे किसी Tor उपयोगकर्ता को onion स्वतः ऑफ़र हो जाए। इससे आपको एक फ़ॉलबैक भी मिल जाता है जो डोमेन खोने के बाद भी बचा रहता है — जिस दिन रजिस्ट्रार आपका खाता बंद करता है, उस दिन भी onion address काम करता रहता है, और वही वह दिन है जब आप चाहेंगे कि आपके पास एक होता। हमारी Tor गुप्त सेवा गाइड इसका पूरा वॉक-थ्रू है।
हाँ, और यही वह लीक है जो अक्सर एक अन्यथा सावधानी से बनाए गए सेटअप को बिगाड़ देती है, क्योंकि यह तब सक्रिय होती है जब आप काम ख़त्म करके ध्यान देना बंद कर चुके होते हैं। कोई भी सर्टिफिकेट जो किसी सार्वजनिक रूप से भरोसेमंद प्राधिकरण द्वारा जारी किया जाता है, एक ऐसे स्थायी सार्वजनिक लॉग में दर्ज हो जाता है जिससे प्रविष्टियाँ कभी हटाई नहीं जा सकतीं, और ब्राउज़र उन सर्टिफिकेट को अस्वीकार कर देते हैं जो ऐसा नहीं करते। ये लॉग मुफ़्त सर्च इंटरफ़ेस द्वारा मिरर और इंडेक्स किए जाते हैं, इसलिए आपने जिस भी चीज़ के लिए सर्टिफिकेट माँगा हो, उसका पूरा होस्टनेम बस एक कीवर्ड सर्च दूर है — किसी के लिए भी, हमेशा के लिए, यहाँ तक कि उन staging., backup., vpn. और admin- नामों के लिए भी जिनके बारे में आपने सोचा था कि कोई अंदाज़ा नहीं लगा पाएगा। इसमें कोई ऑप्ट-आउट नहीं है, और होना भी नहीं चाहिए; यही लॉग हैं जो ग़लत-जारी को पहचाने जाने लायक़ बनाते हैं। एक साफ़ उपाय मौजूद है: पूरी ज़ोन के लिए एक ही वाइल्डकार्ड सर्टिफिकेट माँगें और हर इंटरनल होस्टनेम को उसी से सर्व करें, जिससे लॉग एंट्री सिर्फ़ यह बताती है कि ज़ोन के लिए एक सर्टिफिकेट मौजूद है। इसकी क़ीमत यह है कि आपको आसान वाले HTTP चैलेंज के बजाय DNS-01 चैलेंज अपनाना पड़ता है, जो एक स्थायी खुलासे के बदले दस मिनट के सेटअप जैसा सस्ता सौदा है। आगे बढ़ने से पहले अपने ही डोमेन पर यह सर्च कर लें — इसमें बस एक कमांड लगता है, और लोग अक्सर यह देखकर हैरान होते हैं कि किसी एक बार जारी करके भुला दिए गए सर्टिफिकेट से जुड़ा हुआ क्या-क्या पहले से वहाँ मौजूद है।
इसे किसी दुर्घटना के रूप में नहीं, बल्कि एक दशक में किसी न किसी क्षण घटित होने वाली एक तय बात के रूप में लेकर योजना बनाएँ, क्योंकि इसका ट्रिगर आमतौर पर बहुत मामूली होता है: किसी क्रिप्टो पेमेंट पर एक स्वचालित फ़्रॉड नियम, डोमेन पर किसी चीज़ की एक शिकायत, रजिस्ट्रार में स्वामित्व का कोई बदलाव, या ऐसा कोई क्षेत्राधिकार जिसमें कंपनी अब आगे कोई एक्सपोज़र नहीं चाहती। चार तैयारियाँ इसे झेलने लायक़ बना देती हैं, और चारों मुफ़्त हैं। ट्रांसफर लॉक ऑन रखें, लेकिन एक ताज़ा प्राधिकरण कोड ऑफ़लाइन स्टोर करके भी रखें, क्योंकि जिस रजिस्ट्रार ने आपका खाता बंद कर दिया है वह आपके लिए एक नया कोड जनरेट नहीं करने वाला। अपना रजिस्ट्रेशन डेटा दिल से याद रखें — निर्माण तिथि, दर्ज रजिस्ट्रेंट ईमेल, आख़िरी ट्रांसफर तिथि — क्योंकि कोई भी रिकवरी प्रक्रिया यही माँगेगी। ज़ोन फ़ाइल को रजिस्ट्रार के बाहर कहीं एक्सपोर्ट करके रखें, ताकि किसी नए रजिस्ट्रार पर इसे फिर से बनाना किसी पुरातत्व-खुदाई जैसे काम के बजाय पंद्रह मिनट का पेस्ट-काम बन जाए। और रजिस्ट्रार को अपने DNS ऑपरेटर, अपने होस्ट और अपने मेल प्रदाता जैसी ही कंपनी न बनने दें, क्योंकि तब एक बंद खाता चारों को एक साथ ले जाता है। अगर ऐसा हो भी जाए, तो ट्रांसफर पॉलिसी के तहत रजिस्ट्रार के लिए एक दर्ज प्रक्रिया और एक एस्केलेशन बिंदु रखना अनिवार्य होता है, और उसके ऊपर मौजूद रजिस्ट्री अपने ख़ुद के शिकायत-मार्ग वाला एक अलग पक्ष होती है। जवाब धीमा, प्रक्रियात्मक और आमतौर पर सफल होता है — बशर्ते आपने वह मेलबॉक्स भी न खो दिया हो जिस पर पूरा खाता टिका है।
आमतौर पर नहीं, और यह इस सीरीज़ के उन कुछ गिने-चुने हिस्सों में से एक है जहाँ सेल्फ़-होस्टिंग कमज़ोर जवाब है। प्राधिकृत DNS को अलग-अलग नेटवर्कों पर दो या अधिक सर्वर चाहिए, ठीक उस घटना के दौरान सही तरीक़े से काम करना चाहिए जिसने आपके मुख्य सर्वर को गिरा दिया है, और एम्प्लिफ़िकेशन दुरुपयोग के प्रति एक प्रतिरोध चाहिए जो कोई एक बार की कॉन्फ़िगरेशन नहीं, बल्कि एक चलता रहने वाला काम है — और अगर यह विफल हो जाए, तो उस नाम के ज़रिए resolve होने वाली हर चीज़ इसके साथ विफल हो जाती है, यहाँ तक कि वह सर्टिफिकेट नवीनीकरण भी जो हालात ठीक करने में मदद कर सकता था। इसके विरुद्ध एक गोपनीयता वाला तर्क भी है, जो आम तर्क के उलट चलता है: आपके बाक़ी संचालन के समान ही address ब्लॉक पर चलने वाला एक सेल्फ़-रन प्राधिकृत सर्वर, उन सबके बीच एक सीधा संबंध बना देता है, जो किसी भी व्यक्ति द्वारा क्वेरी किए जा सकने वाले passive-DNS डेटासेट में दिखाई देता है। व्यावहारिक व्यवस्था एक ऐसा DNS ऑपरेटर है जिसका एक anycast नेटवर्क हो, जिसे उसकी फ़ीचर लिस्ट के बजाय इस आधार पर चुना जाए कि उसे पहचान दस्तावेज़ की ज़रूरत पड़ती है या नहीं, और एक ऐसी ज़ोन जिसे आप एक ही कमांड में एक्सपोर्ट कर सकें। ध्यान दें कि यह सीरीज़ में अन्यत्र बताए गए प्राइवेट रिज़ॉल्वर से एक अलग काम है: वह आप क्या खोजते हैं इसका लॉग आपकी अपनी मशीन पर ले जाता है, जो साफ़ तौर पर एक फ़ायदा है। यह वाला यह प्रकाशित कर देगा कि बाक़ी सब आपके बारे में क्या खोजते हैं, जो पूरी तरह एक अलग जोखिम प्रोफ़ाइल है।
हाँ, और यह इस पेज के सबसे मूल्यवान पाँच मिनट हैं। रजिस्ट्रार खाते पर दर्ज पता कोई सामान्य कॉन्टैक्ट विवरण नहीं है, वह मास्टर-की है: उसी पर वह वेरिफ़िकेशन मैसेज आता है जिसकी समय-सीमा समाप्त होने पर नाम सस्पेंड हो सकता है, वही ट्रांसफर को मंज़ूरी देता है, वही पासवर्ड रीसेट करता है, और वही हर रिकवरी प्रक्रिया का आधार है। तीन विशेषताएँ मायने रखती हैं। यह समर्पित होना चाहिए, यानी वह पता नहीं होना चाहिए जो आपके कमिट इतिहास में, आपकी फ़ोरम प्रोफ़ाइल में और 2019 के किसी ब्रीच डेटा में मौजूद है — दोबारा इस्तेमाल ही वह सबसे सामान्य तरीक़ा है जिससे एक सावधानी से गुमनाम बनाई गई रजिस्ट्रेशन किसी व्यक्ति से जुड़ जाती है, और इससे बचने में कुछ भी ख़र्च नहीं होता। यह टिकाऊ होना चाहिए: एक डिस्पोज़ेबल इनबॉक्स जो मौजूद रहना बंद कर दे, वही वजह है जिससे लोगों को अपना वेरिफ़िकेशन ईमेल नौ महीने बाद पता चलता है, और मुफ़्त प्रदाता निष्क्रिय खाते बंद कर देते हैं। और यह ऐसा होना चाहिए जिसे आप सचमुच पढ़ते हों, क्योंकि जो मैसेज मायने रखते हैं वे कभी-कभार आते हैं और ठीक उन जैसे ही दिखते हैं जो मायने नहीं रखते। या तो किसी मेल प्रदाता पर आपका अपना डोमेन इस्तेमाल करें, या चेन से बाहर के किसी प्रदाता पर एक पेड मेलबॉक्स — लेकिन वह डोमेन नहीं जिसे आप रजिस्टर कर रहे हैं, क्योंकि जिस नाम का रिकवरी ईमेल ख़ुद उसी नाम पर टिका हो, उसके समाप्त होने के बाद उसे रिकवर नहीं किया जा सकता। उसी बैठक में खाते पर एक टाइम-बेस्ड वन-टाइम-पासवर्ड सेकंड फ़ैक्टर जोड़ें, और रिकवरी कोड को उस मेलबॉक्स में रखने के बजाय प्राधिकरण कोड के साथ रखें जिसकी वे रक्षा करते हैं।
क्योंकि यह दोनों अलग-अलग चीज़ें उजागर करते हैं, और जिस विरोधी के पास एक होगा वह दूसरे की खोज में निकल जाएगा। डोमेन रिकॉर्ड इस सवाल का जवाब देता है कि "इस नाम को किसने रजिस्टर किया"; होस्टिंग खाता इस सवाल का जवाब देता है कि "मशीन का भुगतान कौन करता है, किस पते से, किस कार्ड से, और वह और क्या-क्या चलाता है" — और यह दूसरी फ़ाइल आमतौर पर कहीं ज़्यादा भरी-पूरी होती है। यह वह फ़ाइल भी है जो किसी सार्वजनिक इंटरफ़ेस से पढ़े जाने के बजाय क़ानूनी प्रक्रिया के ज़रिए माँगी जाती है, जिसका मतलब है कि यह जिस क्षेत्राधिकार में बैठी है वह आपके असली एक्सपोज़र का हिस्सा है। इससे दो विशेषताएँ निकलती हैं। मशीन कहाँ बैठी है, यह तय करता है कि उस तक कौन-सी प्रक्रिया पहुँच सकती है: Stockholm, Helsinki, Oslo और Reykjavík चार ऐसे संवैधानिक शासन-तंत्र हैं जिनकी प्रेस-स्वतंत्रता की परंपरा मज़बूत है, और सभी EEA के भीतर हैं, जिससे उस अंतरराष्ट्रीय-स्थानांतरण वाले सवाल से भी छुटकारा मिल जाता है जो आपको वैसे लिखना पड़ता। और खाते पर किसका नाम है, यह तय करता है कि खाता स्वयं क्या उजागर करता है — NordBastion पर कोई पहचान दस्तावेज़ नहीं है, कोई क़ानूनी नाम नहीं है और कोई कार्ड नहीं है, इनवॉइस का भुगतान Monero या Bitcoin में होता है, और ग्राहक रिकॉर्ड में वह चीज़ ही मौजूद नहीं होती जिसे कोई माँग सकता। यह डोमेन को प्राइवेट नहीं बनाता; कुछ भी किसी डोमेन को प्राइवेट नहीं बनाता। यह सिर्फ़ डोमेन को उस श्रृंखला की पहली कड़ी बनने से रोकता है जो आख़िर में आपके पासपोर्ट वाली एक होस्टिंग फ़ाइल पर जाकर ख़त्म होती है। क्षेत्राधिकार गाइड इन चारों में से हर एक की क़ानूनी न्यूनतम सीमा को कवर करती है।
Sentinel — 2 vCPU, 4 GB और 120 GB NVMe, $3.90 प्रति माह में, Helsinki, Stockholm, Oslo या Reykjavík में — उस साइट के लिए पर्याप्त है जिस पर नाम पॉइंट करता है, और इसे बिना ईमेल सत्यापन, बिना पहचान दस्तावेज़ और बिना कार्ड के ऑर्डर किया जाता है। बैलेंस Monero या Bitcoin में फ़ंड किया जाता है। रजिस्ट्री डोमेन के बारे में जो भी प्रकाशित करे, इसके पीछे मौजूद होस्टिंग फ़ाइल में माँगने लायक़ कुछ भी नहीं होता।
अंतिम review · 2026-10-12 · स्रोत · ICANN Registration Data Policy; ICANN Transfer Policy; ICANN Expired Registration Recovery Policy; 2013 का Registrar Accreditation Agreement और उसका Whois Accuracy Program Specification; निर्देश (EU) 2022/2555 (NIS2) Article 28; .eu टॉप-लेवल डोमेन पर विनियमन (EU) 2019/517; RFC 9082 और RFC 9083 (RDAP); RFC 9162 (सर्टिफिकेट ट्रांसपेरेंसी); RFC 8659 (CAA); RFC 3915 (रिडेम्पशन ग्रेस पीरियड) · आवृत्ति · वार्षिक
This guide is one spoke of a larger series. The pillar walks the three privacy layers end to end — the sibling spokes below dive into the specifics.
Three independent layers — signup, payment, network — explained, legal context included, common mistakes flagged.
What “no KYC” actually means — and what it does not.
Why Sweden, Finland, Norway and Iceland — the legal floor of each.
Deploy your own MCP server on a no-KYC VPS — TLS, streamable HTTP, OAuth.
Host an MCP server with no ID — the privacy stack, crypto-paid.
निजी होस्टिंग, उत्तर में निर्मित।