आपके सर्वर के ऊपर की परतें: डोमेन, CDN, ट्रांज़िट

सर्वर कहां रखा जाए, यह तीन फ़ैसलों में से केवल एक है, और यही वह फ़ैसला शायद ही कभी नतीजा तय करता है। सर्वर के ऊपर एक नाम बैठा होता है, जिसे कोई और चलाता है। सर्वर के आगे, ज़्यादातर साइटों के लिए, एक रिवर्स प्रॉक्सी बैठी होती है, जिसे फिर कोई और चलाता है। इनमें से कोई भी आपके होस्ट की नीति से बंधा नहीं है, कोई भी आपके होस्ट के अधिकार क्षेत्र में नहीं आता, और दोनों को ऐसी अदालत कार्रवाई करने का आदेश मिल सकता है जिसकी पहुंच आपके होस्ट तक बिल्कुल नहीं है। यही वह हिस्सा है जिसे offshore होस्टिंग कवर नहीं करती, और यह जानना उपयोगी है कि यह ठीक कहां जाकर रुकती है।

तीन परतें, तीन अलग-अलग मालिक

किसी भी साइट का पहुंच में होना कम से कम तीन अलग-अलग कंपनियों पर निर्भर करता है, और ये तीनों एक-दूसरे से स्वतंत्र रूप से विफल होती हैं।

नाम। इसे आपको किसी रजिस्ट्रार ने बेचा; जिस एक्सटेंशन के अंतर्गत यह रहता है, उसे एक रजिस्ट्री चलाती है। दो कंपनियां, आमतौर पर दो देश, और दूसरी कंपनी ने आपका नाम कभी सुना तक नहीं है।

सामने की परत। अगर आपकी ओर से कुछ भी जवाब देता है — कोई CDN, कोई रिवर्स प्रॉक्सी, कोई एनीकास्ट एज — तो वह आपके विज़िटरों का कनेक्शन आपके सर्वर तक पहुंचने से पहले ही समाप्त कर देता है। इसलिए वह आपका ओरिजिन पता संरचना के आधार पर जानता है, और शिकायतें भी उसी तक पहुंचती हैं।

तार और मशीन। आपका होस्ट, उसके ट्रांज़िट कैरियर, फ़ैसिलिटी, और वह पता-सीमा जिसके भीतर आपका सर्वर बैठा है। यही वह परत है जिसे लोग ख़रीदते वक़्त परखते हैं, और तीनों में से यही एकमात्र परत है जिसे कोई होस्टिंग अधिकार क्षेत्र असल में नियंत्रित करता है।

छोड़ने लायक आदत यह है कि इन्हें एक ही ख़रीद मान लिया जाए। ये तीन हैं, और इन तीनों को एक ही हाथ में — या एक ही कानूनी व्यवस्था में — रख देना ही वह तरीका है जिससे एक अकेला आदेश सब कुछ एक साथ गिरा देता है।

डोमेन: रजिस्ट्रार, और उसके ऊपर बैठी रजिस्ट्री

आपका रजिस्ट्रार दुकान है। रजिस्ट्री वह थोक विक्रेता है जो एक्सटेंशन चलाता है, और यह वह परत है जिसे ख़रीदने से पहले लगभग कोई नहीं जांचता।

रजिस्ट्रार को क्या हरकत में लाता है

5 अप्रैल 2024 से, मान्यता-प्राप्त रजिस्ट्रारों पर एक संविदागत ज़िम्मेदारी है कि वे उस पर कार्रवाई करें जिसे ICANN DNS Abuse कहता है: जब उनके पास कार्रवाई-योग्य सबूत हों, तो उन्हें नाम को बाधित करने के लिए युक्तिसंगत रूप से आवश्यक शमन उपाय तुरंत लेने होते हैं। इस नियम का असली काम का हिस्सा इसकी परिभाषा है। DNS Abuse का मतलब है मैलवेयर, बॉटनेट, फ़िशिंग, फ़ार्मिंग, और स्पैम — जहां स्पैम इनमें से किसी और चीज़ को पहुंचाने का ज़रिया हो। वेबसाइट की सामग्री इसके दायरे से बाहर है, और कॉपीराइट भी इसके दायरे से बाहर है — स्पष्ट रूप से।

इसे राहत नहीं, एक दहलीज़ मानकर पढ़िए। यह आपको बताता है कि किसी शिकायत को कैसा आकार लेना होगा, इससे पहले कि आपका रजिस्ट्रार हरकत में आने को बाध्य हो; यह यह भी बताता है कि उस सूची से बाहर की हर चीज़ किसी अदालत या प्राधिकरण के आदेश के रूप में ही आ सकती है — जो धीमा, जांचने-योग्य और अपील-योग्य होता है। जो शिकायत आप पाने ही वाले हैं, उसे दर्ज करने से पहले दोनों पक्ष जान लेना उपयोगी है।

रजिस्ट्री क्या कर सकती है, और वह कहां खड़ी है

रजिस्ट्री के पास एक अकेला, निरपेक्ष लीवर है: वह आपके नाम पर ऐसी स्थिति लगा सकती है जो उसे ज़ोन से बाहर कर दे। इसके बाद वह नाम कहीं भी, किसी के लिए रिज़ॉल्व नहीं होता — चाहे आपका रजिस्ट्रार कुछ भी सोचे और आपका सर्वर कहीं भी हो। होस्टिंग परत पर कुछ भी इसका शमन नहीं करता, क्योंकि होस्टिंग परत का इसमें कोई हाथ ही नहीं होता।

यह सैद्धांतिक बात नहीं है। जून 2026 में टेक्सस की एक ज़िला अदालत ने Verisign — जो .com चलाती है — के नाम कुर्की का एक रिट जारी किया, ताकि motherless.com को रजिस्ट्री होल्ड में डाला जा सके। संचालक एक लक्ज़मबर्ग कंपनी थी, जिसने राज्य के आयु-सत्यापन कानून के तहत आए टेक्सस के एक फ़ैसले को नज़रअंदाज़ कर दिया था; आदेश ने नाम वापस पाने की शर्त के रूप में $9.14 मिलियन की ज़मानत तय की। साइट टेक्सस में होस्ट नहीं थी और कंपनी भी टेक्सस में नहीं थी। नाम .com में था, और .com एक अमेरिकी कंपनी द्वारा संयुक्त राज्य अमेरिका के अधिकार क्षेत्र में चलाया जाता है। यही काफ़ी था।

यहां सामान्य सीख उस मामले के बारे में नहीं है। सीख यह है कि आप जो एक्सटेंशन चुनते हैं, वह ठीक वैसा ही अधिकार-क्षेत्र का फ़ैसला है जैसा वह देश जिसमें आपका सर्वर बैठा है, और ज़्यादातर लोग यह फ़ैसला आदतन कर लेते हैं। पूछिए कि एक्सटेंशन को कौन चलाता है, किस कानून के तहत, और क्या उस कानूनी व्यवस्था को रजिस्ट्रियों को आदेश देने की आदत है। फिर तय कीजिए कि क्या आप अपना इकलौता नाम वहां रखना चाहते हैं।

नाम पर गोपनीयता प्रकाशन की बात है, जानकारी की नहीं

WHOIS और RDAP में जानकारी छुपाना थोक स्क्रेपरों और सामान्य जिज्ञासु देखने वालों को रोकता है। इससे आपका रजिस्ट्रार अनजान नहीं हो जाता: मान्यता उसे पंजीकरण डेटा रखने के लिए बाध्य करती है, और वह वह डेटा कानूनी प्रक्रिया के तहत उतनी ही आसानी से सौंप देता है जितनी कोई और कंपनी। रिकॉर्ड के आगे लगी कोई गोपनीयता सेवा एक प्रकाशन-सेटिंग है, कोई ढाल नहीं — और जिस रजिस्ट्रार ने आपसे कभी कुछ मांगा ही नहीं, वह वह चीज़ सौंप ही नहीं सकता जो उसके पास है ही नहीं, और यह पूरी तरह एक अलग गुण है, और भुगतान के लायक इकलौता गुण।

सामने खड़ी प्रॉक्सी: क्या हटाती है, क्या आगे भेजती है

CDN एक कैशिंग मध्यस्थ है। यह आपकी साइट को टिकाऊ ढंग से संग्रहित नहीं करता, इसलिए "फ़ाइल हटा दो" आमतौर पर ऐसी चीज़ नहीं जो वह कर सके। वह जो कर सकता है वह है आपको प्रॉक्सी करना बंद कर देना — और जो साइट पहुंच में बने रहने और अपना ओरिजिन छुपाए रखने के लिए प्रॉक्सी पर निर्भर है, उसके लिए यह एक ही झटके में हटाना भी है और उजागर करना भी।

ज़्यादा दिलचस्प व्यवहार रोज़मर्रा वाला है, और सबसे बड़ा प्रदाता इसे साफ़-साफ़ प्रकाशित करता है। जिस साइट को वह केवल प्रॉक्सी करता है, उसके बारे में दुरुपयोग की रिपोर्ट मिलने पर वह आपकी शिकायत वेबसाइट के संचालक और होस्टिंग प्रदाता तक आगे भेज देगा, और वह होस्टिंग प्रदाता को उस सामग्री का ओरिजिन IP पता सौंप देगा जिसकी शिकायत हुई है। ये दोनों बातें उसकी अपनी दुरुपयोग-नीति से उद्धृत हैं, और ये उससे बिल्कुल उलट हैं जो ख़रीदार यह सोचकर भुगतान करते हैं कि वे क्या पा रहे हैं।

यानी प्रॉक्सी आपके और आपके होस्ट के दुरुपयोग-डेस्क के बीच कोई बफ़र नहीं है। वह एक कूरियर है। वह शिकायत को आपके होस्ट तक पहुंचाती है, और आपके होस्ट को ठीक-ठीक बताती है कि किस मशीन को देखना है। अगर आपने अपना होस्ट इसलिए चुना कि वह शिकायतों को कैसे संभालता है, तो ठीक है — शिकायत वहीं पहुंचती है जहां आप चाहते थे कि वह पहुंचे। अगर आपने प्रॉक्सी इस उम्मीद में चुनी थी कि शिकायत वहीं रुक जाएगी, तो ऐसा नहीं होता।

उसी प्रदाता का दस्तावेज़ीकरण आप पर भी एक ज़िम्मेदारी डालता है: एक ऐसा दुरुपयोग-संपर्क पता बनाए रखें जो सक्रिय रूप से प्रबंधित और निगरानी में हो, और किसी भी दुरुपयोग-रिपोर्ट सूचना का जवाब चौबीस घंटे के भीतर दें। समय पर जवाब न देने पर रिपोर्ट की गई सामग्री हटाई या ब्लॉक की जा सकती है, और खाता निलंबित या समाप्त किया जा सकता है। जो मध्यस्थ आपकी सामग्री हटा नहीं सकता, उसने फिर भी अपने लिए हटाने का एक खंड लिख रखा है, और एक घड़ी भी।

एक अपवाद मायने रखता है। जहां वही कंपनी होस्टिंग भी करती है — उसका ऑब्जेक्ट स्टोरेज, उसका सर्वरलेस प्लेटफ़ॉर्म, उसके मीडिया और पेजेज़ उत्पाद — वहां वह उस सामग्री के लिए एक होस्टिंग प्रदाता है, वह ख़ुद यह कहती है, और वह सामग्री को सूचना-देकर-हटाने की उस प्रक्रिया के तहत हटाती है जिसमें प्रति-सूचना शामिल है, ठीक उसी रूप में जो संयुक्त राज्य अमेरिका का कानून तय करता है। एक ही विक्रेता के दो उत्पाद, दो बिल्कुल अलग जवाब। जान लीजिए कि आप असल में किसका इस्तेमाल कर रहे हैं।

CDN क्या नहीं छुपाता, और ओरिजिन कैसे खोजे जाते हैं

बहुत-से लोग सर्वर के आगे प्रॉक्सी सिर्फ़ एक वजह से लगाते हैं: ओरिजिन पते को सार्वजनिक इंटरनेट से दूर रखने के लिए। यह जानना उपयोगी है कि व्यवहार में यह कितना कारगर है, और ईमानदार जवाब यह है कि यह तब तक काम करता है जब तक पांच सामान्य ग़लतियों में से कोई एक इसे बिगाड़ न दे। इनमें से कोई भी विचित्र नहीं है; प्रॉक्सी बेचने वाले ख़ुद इन्हें दस्तावेज़ में दर्ज करते हैं।

वे रिकॉर्ड जो आपने कदम बढ़ाने से पहले प्रकाशित किए थे। DNS सार्वजनिक है और संग्रहित रहता है। लगभग हर वह साइट जो प्रॉक्सी के पीछे गई, उसका पुराना पता किसी न किसी के ऐतिहासिक डेटासेट में स्थायी रूप से बैठा है। बेचने वाले का अपना मार्गदर्शन यही है कि ऑनबोर्डिंग के बाद ओरिजिन पता बदल दिया जाए — अगर आपने ऐसा नहीं किया, तो वह कदम केवल दिखावटी था।

वे रिकॉर्ड जिन्हें आपने प्रॉक्सी के बिना छोड़ दिया। मशीन की तरफ़ सीधे इशारा करता एक अकेला सबडोमेन काफ़ी है: mail, ftp, cpanel, dev, staging, vpn, या वह मॉनिटरिंग होस्ट जो आपने कभी एक बार सेट किया था। ज़ोन के हर रिकॉर्ड का ऑडिट कीजिए, सिर्फ़ उन्हीं का नहीं जो आपको बनाते हुए याद हैं।

मशीन से बाहर जाती मेल। अगर ओरिजिन मेल भेजता है, तो उसका पता हेडरों में साथ चलता है। किसी ऐसे पते पर संदेश भेजिए जो मौजूद ही नहीं है, और बाउंस उसे साथ लेकर वापस आएगा। मेल उस मशीन से अलग किसी मशीन पर होनी चाहिए जिसे आप छुपाए रखने की कोशिश कर रहे हैं।

प्रमाणपत्र पारदर्शिता। हर सार्वजनिक रूप से भरोसेमंद प्रमाणपत्र उन नामों के साथ लॉग किया जाता है जिन्हें वह कवर करता है। ये लॉग कोई पता नहीं सौंपते, लेकिन ये आज़माने लायक सबडोमेन की पूरी सूची सौंप देते हैं — उन सबडोमेन समेत जिन्हें आप निजी समझते थे।

थोक स्कैनिंग। पूरा पता-क्षेत्र लगातार स्कैन किया जाता है और इस आधार पर इंडेक्स किया जाता है कि वह क्या जवाब देता है। किसी नंगे पते से परोसा गया कोई पहचाने-जाने लायक पेज एक डेटाबेस लुकअप है, कोई जांच-पड़ताल नहीं।

इनके समाधान अच्छी तरह समझे जा चुके हैं, और इन्हें सुविधा के क्रम में नहीं बल्कि मज़बूती के क्रम में अपनाना उपयोगी है।

1. केवल-आउटबाउंड टनल। ओरिजिन एज की ओर कनेक्शन खोलता है और ख़ुद किसी चीज़ पर सुनता नहीं। ढूंढने के लिए कोई पोर्ट है ही नहीं, इसलिए पता लीक होने पर भी दिलचस्पी की चीज़ नहीं रह जाता। इस सूची में यही इकलौता विकल्प है जो किसी नियम के सही होने पर निर्भर नहीं करता।
2. एज से पारस्परिक TLS। ओरिजिन सिर्फ़ उसी क्लाइंट को सेवा देता है जो प्रॉक्सी का प्रमाणपत्र पेश करे। पता लीक हो सकता है; लेकिन वह जवाब नहीं देगा। मज़बूत तरीका, और पते के सार्वजनिक हो जाने के बाद भी टिका रहता है।
3. प्रॉक्सी की प्रकाशित रेंजों तक फ़ायरवॉल। कुछ न होने से बेहतर और लागू करने में आसान, लेकिन रेंजें बदलती रहती हैं, और बेचने वाले की अपनी तुलना ही इस तरीके को spoofing के प्रति संवेदनशील बताती है। इसे एक न्यूनतम आधार मानिए, कोई समाधान नहीं।
4. नियमित रखरखाव। एज के पीछे आ जाने पर ओरिजिन पता बदल दीजिए, मेल को मशीन से हटाइए, और हर बदलाव के बाद बिना-प्रॉक्सी वाले रिकॉर्ड का ऑडिट कीजिए। ज़्यादातर उजागर होने के मामले इन्हीं तीन में से एक होते हैं, कोई चालाक हमला नहीं।

प्रॉक्सी ओरिजिन को ब्राउज़र लिए किसी अजनबी से छुपाती है। यह ओरिजिन को प्रॉक्सी से नहीं छुपाती — जो इसे परिभाषा के अनुसार जानती ही है, और जो किसी शिकायत मिलने पर आपके होस्टिंग प्रदाता को यह बताने के लिए बाध्य है कि वह क्या है।

मशीन के नीचे: ट्रांज़िट, प्रीफ़िक्स, फ़ैसिलिटी

आपके सर्वर के नीचे पक्षों का एक और समूह है, और आमतौर पर होस्ट इन्हीं के बारे में सबसे कम बात करना चाहता है।

ट्रांज़िट कैरियर। आपका होस्ट किसी से कनेक्टिविटी ख़रीदता है। उन कैरियरों के अपने दुरुपयोग-डेस्क, अपने अनुबंध और अपनी जोखिम-सहनशीलता होती है, और जो कैरियर तय कर ले कि आप मुसीबत हैं, वह आपके होस्ट का फ़ैसला उसकी जगह कर सकता है। पूछिए कि कितने कैरियर हैं — एक कैरियर होने का मतलब है नीति का भी एक अकेला केंद्र और विफलता का भी एक अकेला केंद्र — और यह तीखा सवाल पूछिए: क्या आपका होस्ट आपके ट्रैफ़िक पर, चुपचाप, कैरियर की तरफ़ से बनी ब्लॉकलिस्टें स्वीकार करता है?

वह प्रीफ़िक्स जो आप साझा करते हैं। प्रतिष्ठा-प्रणालियां पते की रेंजों पर काम करती हैं, ग्राहकों पर नहीं। आपको अपने पड़ोसी विरासत में मिलते हैं, और वे भी बिना यह बताए कि वे कौन हैं। यही उस प्रदाता की ठोस क़ीमत है जो ख़ुद को हर तरह की चीज़ के लिए शरणस्थली बताकर बेचता है: ब्लॉकलिस्टें उस रेंज तक पहुंचती हैं, और आपकी मेल और आपकी API कॉलें उसी के भीतर होती हैं।

फ़ैसिलिटी और हार्डवेयर। किराए की कैबिनेट का मतलब है एक ऐसा मकान-मालिक जिसकी अपनी दुरुपयोग-नीति है, जो आपके होस्ट के ऊपर, अदृश्य रूप से बैठा है, और आपके होस्ट के ऊपर की हर परत एक और ऐसा पक्ष है जो आपको ऐसे कारणों से समाप्त कर सकता है जो आप कभी देख भी नहीं पाएंगे।

चूंकि इस गाइड का मक़सद हर परत को जवाबदेह बनाना है, इसलिए यहां यह परत भी उन्हीं शर्तों में है। दो ट्रांज़िट कैरियर, BGP से संतुलित, बीस गीगाबिट का मिश्रित बैंडविड्थ, Chișinău में। हर पोर्ट के ऊपर, सबके लिए, बिना कुछ ख़रीदे, लेयर 3 और लेयर 4 फ़िल्टरिंग। कैरियर की तरफ़ से बनी ब्लॉकलिस्टें ग्राहक के ट्रैफ़िक पर स्वीकार नहीं की जातीं: अगर कुछ ब्लॉक करना ही ज़रूरी हो, तो अदालत ऐसा कहती है और हम आपको बताते हैं। हार्डवेयर किराए का नहीं बल्कि अपना है, एक ही देश में, उसी कंपनी के स्वामित्व में जिससे आप ख़रीदते हैं — पूरा ब्योरा नेटवर्क पेज और फ़ैसिलिटी पेज पर है।

और यह अंतर, साफ़ शब्दों में: हम डोमेन नहीं बेचते, और हम वह प्रॉक्सी नहीं चलाते जो आप अपने सर्वर के आगे लगाते हैं। ये दोनों परतें आपकी हैं। रजिस्ट्रियों के बारे में और आगे भेजी गई शिकायतों के बारे में ऊपर जो कुछ कहा गया है, वह आप पर ठीक वैसे ही लागू होता है जैसा लिखा है, और कोई भी होस्टिंग अधिकार क्षेत्र — हमारा भी शामिल — उसमें एक शब्द नहीं बदलता।

तीनों परतों को तीन अलग-अलग हाथों में रखना

पूरी गाइड मुट्ठी-भर फ़ैसलों तक सिमट जाती है, और इनमें से किसी का कोई ख़र्च नहीं है।

1. तीन परतें, तीन आपूर्तिकर्ता, तीन कानूनी परिवार। नाम, एज और सर्वर का एक ही कंपनी के हाथ में होना — एक अकेले आदेश की दूरी पर सब कुछ ख़त्म हो जाना है। तीन अलग-अलग हाथों में, इनमें से किसी एक के विरुद्ध आदेश बाकी दोनों को चलता छोड़ देता है, और आपको समय दे देता है।
2. हर परत से वही तीन सवाल पूछिए। आपको क्या आगे भेजने पर बाध्य किया जा सकता है, क्या हटाने पर बाध्य किया जा सकता है, और क्या सौंपने पर बाध्य किया जा सकता है? ये तीनों एक-दूसरे से स्वतंत्र रूप से विफल होते हैं, और जो आपूर्तिकर्ता तीनों का जवाब एक ही वाक्य में दे दे, उसने सवाल समझा ही नहीं।
3. ऐसे कॉन्फ़िगर कीजिए मानो प्रॉक्सी आगे भेजती ही है, क्योंकि वह भेजती है। मान लीजिए कि हर शिकायत आपके होस्ट तक आपके ओरिजिन पते के साथ पहुंचती है। अगर यह नतीजा किसी समस्या का सबब है, तो इसका समाधान होस्टिंग परत पर है, या आप जो प्रकाशित करते हैं उसमें है — किसी और मध्यस्थ को जोड़ने में नहीं।
4. ओरिजिन को ठीक से बंद कीजिए। केवल-आउटबाउंड टनल या पारस्परिक TLS; मेल किसी अलग मशीन पर; ऑनबोर्डिंग के बाद पता बदलना; बिना-प्रॉक्सी रिकॉर्ड का ऑडिट। चार चीज़ें, सभी उबाऊ, और ये लगभग हर असली उजागर होने की स्थिति को ढक लेती हैं।
5. नाम को अपनी विफलता का अकेला केंद्र मानिए, और उसके लिए योजना बनाइए। जान लीजिए कि आपका एक्सटेंशन किस रजिस्ट्री द्वारा और किस कानून के तहत चलाया जाता है। एक दूसरा नाम रखिए, किसी अलग एक्सटेंशन में, किसी अलग रजिस्ट्रार पर, और पहले से जान लीजिए कि आप लोगों को यह इस्तेमाल करने के लिए कैसे बताएंगे।

इनमें से कुछ भी सर्वर के आगे प्रॉक्सी लगाने के ख़िलाफ़ दलील नहीं है, और इनमें से कुछ भी offshore होस्टिंग के ख़िलाफ़ दलील नहीं है — इनमें से किसी भी दलील के लिए हम एक अजीब स्रोत होते। यह दलील इतनी है कि तीनों परतें तीन अलग-अलग ख़रीद हैं, तीन अलग-अलग तरह से विफल होने वाली, और जिस परत को ज़्यादातर लोग सबसे कड़ाई से जांचते हैं, वही वह परत नहीं जो उन्हें ख़त्म करने की सबसे ज़्यादा संभावना रखती है। अगर आप चाहते हैं कि जिस परत को हम ख़ुद चलाते हैं, वह भी उसी मानक पर परखी जाए, तो तिमाही आंकड़े और कानून-प्रवर्तन पेज देखने लायक जगहें हैं।

प्लेटफ़ॉर्म चलाने वाले इंजीनियरों द्वारा लिखा गया, और आज दोबारा पढ़ा गया। यदि यहां कुछ गलत है या पुराना हो चुका है, तो पैनल से बताएं — इनमें से लगभग आधी बातें वहीं से आई हैं।