रजिस्ट्रार लॉकडाउन बनाम लेयर्ड डिफेंस: कब कौन जीतता है

कल्पना कीजिए कि सुबह उठकर पता चलता है कि आपकी कंपनी के हर डोमेन — प्रोडक्शन, स्टेजिंग, और वह जिस पर आपके MX रिकॉर्ड हैं — रात भर में आपके डोमेन रजिस्ट्रार ने suspend कर दिए हैं। कोई deploy नहीं टूटा। कोई सर्वर क्रैश नहीं हुआ। किसी trust-and-safety टीम के किसी इंसान ने (या ज़्यादा संभावना है, किसी automated abuse pipeline ने) एक switch फ्लिप कर दिया, और आपकी पूरी इंटरनेट उपस्थिति गायब। यह काल्पनिक नहीं है: sysadmin forums पर रजिस्ट्रार द्वारा अनवेरिफ़ाइड abuse reports, अस्पष्ट tweets, या लाखों user uploads में से एक flagged image की वजह से अकाउंट बंद करने की डरावनी कहानियाँ लगातार आती रहती हैं।

मैंने infrastructure टीमों के लिए incident response में कई साल बिताए हैं, और पैटर्न हमेशा एक जैसा रहा है। Engineers compute के लिए बड़ी redundancy डिज़ाइन करते हैं — multi-AZ, multi-region, failover runbooks — और फिर उस एक चीज़ को छोड़ देते हैं जिसे दोबारा deploy नहीं किया जा सकता, यानी डोमेन नाम खुद, जो एक पासवर्ड और शायद SMS कोड से सुरक्षित एक ही अकाउंट में पड़ा रहता है। यह लेख इस जोखिम से निपटने के दो तरीकों की तुलना करता है: पारंपरिक registrar lockdown तरीका (अच्छा रजिस्ट्रार चुनो, अकाउंट को सख्त करो, और उस पर भरोसा करो) बनाम layered defense तरीका (मान लो कि आपका रजिस्ट्रार आपको धोखा देगा और उसके आसपास इंजीनियरिंग करो)। सच यह है कि आपको दोनों चाहिए, लेकिन रात 3 बजे आपको असल में बचाने वाला दूसरा वाला ही है।

आपका रजिस्ट्रार एक अलग किस्म का Single Point of Failure क्यों है

आपके stack में ज़्यादातर single points of failure ऐसे होते हैं जिन्हें आप नियंत्रित करते हैं। एक database primary, एक NAT gateway, एक message broker — आप इन्हें replicate कर सकते हैं, और failover plan भी आपने खुद लिखा होता है। रजिस्ट्रार तीन कारणों से अलग है। पहला, यह एक control-plane dependency है जिसे आप replicate नहीं कर सकते। एक ही डोमेन के लिए दो रजिस्ट्रार नहीं चल सकते; registry के पास केवल एक sponsor of record होता है। दूसरा, रजिस्ट्रार की failure modes धीमी होती हैं। सामान्य परिस्थितियों में domain transfer में पाँच से सात दिन लगते हैं, और अगर मौजूदा रजिस्ट्रार ने आपका अकाउंट disable कर दिया है, तो शायद आप transfer शुरू करने के लिए auth code भी नहीं ले सकते। तीसरा, यह failure अजीब तरह से adversarial होती है: इसमें कोई attacker नहीं होता, बल्कि provider खुद एक ऐसी abuse report के आधार पर आपके खिलाफ काम करता है जो आपने कभी देखी ही नहीं।

Blast radius भी लोगों की सोच से ज़्यादा बुरा है। जब कोई रजिस्ट्रार डोमेन suspend करता है, तो वे आमतौर पर NS records को takedown page पर point कर देते हैं या बस जवाब देना बंद कर देते हैं। इससे आपकी वेबसाइट तो बंद होती ही है। लेकिन इससे आपका email भी बंद होता है (MX records DNS में रहते हैं), आपका SSO अगर callbacks आपके डोमेन को refer करते हैं, आपके API clients, आपका status page अगर वह उसी डोमेन पर है, और — मेरा निजी पसंदीदा — वह email पता जिस पर आप recovery instructions प्राप्त करते। अगर आपके रजिस्ट्रार अकाउंट का email admin@yourdomain.com है और yourdomain.com suspend है, तो अब आप support को उस पते से अपनी पहचान साबित करने की कोशिश कर रहे हैं जिस पर वे भरोसा नहीं करेंगे। मैंने इस exact loop को एक पूरे incident का दिन खाते देखा है।

और आर्थिक प्रोत्साहन भी आपके खिलाफ जा रहे हैं। जब कोई रजिस्ट्रार private equity द्वारा acquire होता है — जैसा कई बड़े रजिस्ट्रारों के साथ हुआ है — तो playbook अनुमानित होता है: human support कम करो, abuse handling automate करो, कीमतें बढ़ाओ। Automated abuse systems उनके जोखिम के लिए optimize करते हैं, आपके के लिए नहीं। बाद में निर्दोष पाए गए डोमेन को suspend करने से उनका कुछ नहीं बिगड़ता। बाद में दोषी पाए गए डोमेन को चालू रखने से उन्हें registry की परेशानी और बुरी प्रेस झेलनी पड़ती है। अनुमान लगाइए automation किस तरफ गलती करता है।

पहला तरीका: Registrar Lockdown — एकल बिंदु को मज़बूत करो

Lockdown का दर्शन कहता है: मान लो कि रजिस्ट्रार एक single point of failure है, और उस बिंदु को जितना हो सके मज़बूत बनाओ। ज़्यादातर कंपनियाँ यही रणनीति चलाती हैं, चाहे उन्होंने इसे शब्दों में रखा हो या नहीं। ठीक से किया जाए तो यह कुछ ऐसा दिखता है:

• Support की गुणवत्ता के आधार पर रजिस्ट्रार चुनो, कीमत के आधार पर नहीं। हर डोमेन पर बचाए गए $3 सालाना, एक दिन के downtime के सामने कुछ भी नहीं हैं। आपको phone support चाहिए, बड़े portfolios के लिए एक named account rep, और ऐसी कंपनी जिस पर अपने क्षेत्राधिकार में मुकदमा किया जा सके, अगर नौबत आए।
• हर डोमेन पर registrar lock (clientTransferProhibited) चालू करो, और महत्वपूर्ण डोमेन पर registry lock। Registry lock nameservers या transfers में किसी भी बदलाव से पहले out-of-band verification माँगता है — आमतौर पर passphrase के साथ phone call। यह परेशान करने वाला है, और यही इसका मकसद है।
• Hardware-key या TOTP two-factor auth इस्तेमाल करो, SMS कभी नहीं। Support agents के चतुर chat कहानी सुनकर 2FA हटा देने की war stories बहुत हैं; कुछ रजिस्ट्रार अब 'hardware key के बिना कोई account change नहीं' नीति देते हैं। उसे अपनाओ।
• रजिस्ट्रार अकाउंट के लिए एक समर्पित, role-based email पता इस्तेमाल करो जो उस रजिस्ट्रार पर registered किसी डोमेन पर NOT हो। domains-admin@example.org किसी बिल्कुल दूसरी जगह registered।
• पहुँच सीमित करो। दो-तीन नामित लोग, company vault में credentials, spreadsheet में shared login नहीं।
• सब कुछ documented रखो: account number, PINs, support escalation paths, वे exact identity documents जिनसे अकाउंट verified है। इसे अपने incident runbook में डालो।

Lockdown की असली ताकतें हैं। यह सबसे आम रजिस्ट्रार आपदा को रोकता है, जो seizure नहीं बल्कि hijacking है। Social engineering से की गई transfers और account takeovers सालों से high-value डोमेन चुरा रहे हैं, और registry lock तथा hardware 2FA उनमें से लगभग सबको रोक देते हैं। यह सस्ता भी है और इसमें लगातार engineering की ज़रूरत नहीं होती।

पर एक असहज सच्चाई है: lockdown आपको attackers से बचाता है, रजिस्ट्रार से नहीं। ऊपर का हर control एक ऐसा control है जिसे रजिस्ट्रार ही चलाता है। अगर उनकी abuse automation आपका अकाउंट disable कर दे, तो आपका registrar lock अब आपको ही बाहर रख रहा है, आपका support PIN एक ऐसे सिस्टम में है जहाँ आप पहुँच नहीं सकते, और जो इंसान सब कुछ override कर सकता था, शायद अब मौजूद ही नहीं क्योंकि पिछली तिमाही में support को 'optimize' कर दिया गया था। सीधे-साधे false-positive मामलों में भी practitioners छह घंटे से ज़्यादा की restoration time बताते हैं, और suspension अगर weekend पर फैले तो कई दिनों की गाथा बन जाती है। Lockdown ज़रूरी है। पर वह काफी नहीं है।

दूसरा तरीका: Layered Defense — मान लो रजिस्ट्रार धोखा देगा

Layered दर्शन एक गहरी धारणा से शुरू होता है: किसी दिन, बदनीयती, automation या गलती से, आपका रजिस्ट्रार आपके डोमेन बंद कर देगा, और उनकी support queue तक पहुँचने से पहले आपको वापस online होना होगा। यही सोच catastrophic failure के खिलाफ defensive engineering के पीछे है — आप आपदा को रोकते नहीं, आप उसे झेलने लायक बनाते हैं।

मुख्य तकनीक उन layers को अलग करना है जो आमतौर पर एक साथ बंधी होती हैं। ज़्यादातर छोटी कंपनियाँ डोमेन रजिस्ट्रार से खरीदती हैं, उसी का DNS इस्तेमाल करती हैं, उसी की hosting सेवा पर होस्ट करती हैं, और email भी वहीं से लेती हैं। यानी एक ही अकाउंट में चार single points of failure एक पर एक रखे हुए हैं। इन्हें अलग करो:

• Registration: रजिस्ट्रार A पर, स्थिरता और support के आधार पर चुना गया।
• Authoritative DNS: एक स्वतंत्र DNS provider B पर (या dual-primary configuration में दो providers), code के रूप में managed।
• Hosting: जहाँ workload के लिए सबसे सही हो, इन दोनों से असंबद्ध।
• Email: एक समर्पित provider, जिसमें A और B के account-recovery पते किसी और डोमेन पर रहें।
• Spare domain: एक अलग रजिस्ट्रार पर पहले से provisioned fallback डोमेन, जिसके TLS certs जारी हो चुके हों और आपकी सबसे महत्वपूर्ण सेवाओं का न्यूनतम संस्करण उस पर पहले से जवाब दे रहा हो।

Spare domain पर ज़ोर देना ज़रूरी है क्योंकि इसे लगभग कोई नहीं करता, और यही सबसे ज़्यादा फायदेमंद कदम है। जब आपके primary डोमेन suspend होते हैं, तो DNS TTL और resolver caches का मतलब है कि आप बस 'backup पर switch' नहीं कर सकते — backup को incident से पहले मौजूद होना, warm होना और resolve होना चाहिए था। example-status.net जैसा कोई fallback, जो कहीं और registered हो और आपका status page, incident comms और एक emergency MX record लिए हो, एक कंपनी-खत्म करने वाले outage को एक शर्मनाक मंगलवार में बदल देता है।

DNS as Code: वह layer जिसे हर कोई छोड़ देता है

यह असफलता मैंने असली incidents में दो बार देखी है: टीम रजिस्ट्रार suspension के बाद डोमेन वापस पाती है, सब कुछ फिर चालू करती है — और DNS गलत होता है, क्योंकि उनके zone का 'source of truth' रजिस्ट्रार का web UI था, जो incident के दौरान अनुपलब्ध था और वैसे भी किसी की याद से मेल नहीं खाता था। Outage के बीच 200 records वाली zone file को याद से दोबारा बनाना एक खास किस्म का दुख है। जैसा हम पहले लिख चुके हैं, DNS misconfiguration सामान्य परिस्थितियों में भी production तोड़ता रहता है; रजिस्ट्रार incident के दौरान यह विनाशकारी होता है।

उपाय उबाऊ है: अपनी DNS zone को version control में, CI से deploy होने वाले code के रूप में manage करो। dnscontrol या Terraform के DNS providers जैसे tools zone को declaratively describe करने और उसे कई providers पर push करने देते हैं। अब आपका DNS state किसी भी provider के control plane के खोने पर भी बचा रहता है, और 'DNS provider B पर failover' एक लाइन का बदलाव और एक deploy है, कोई वीरतापूर्ण copy-paste सत्र नहीं।

# dnsconfig.js — one zone, two providers, deployed by CI
var REG_NONE = NewRegistrar('none');
var DSP_CLOUDFLARE = NewDnsProvider('cloudflare');
var DSP_ROUTE53 = NewDnsProvider('route53');
D('example.com', REG_NONE,
DnsProvider(DSP_CLOUDFLARE),
DnsProvider(DSP_ROUTE53),   // dual-authoritative: either can die
A('@', '203.0.113.10'),
A('www', '203.0.113.10'),
MX('@', 10, 'mail.example.net.'),   // MX on a DIFFERENT TLD/provider domain
TXT('@', 'v=spf1 include:_spf.example.net -all'),
CNAME('status', 'statuspage.example.net.')
);

Dual-authoritative DNS को कम आंका जाता है। ज़्यादातर resolvers सूचीबद्ध सभी nameservers को खुशी-खुशी आज़माते हैं, इसलिए अगर एक provider में outage होता है (और बड़े DNS providers में होते हैं), तो resolution चलता रहता है। चुनौती यह है कि दोनों providers को sync रखा जाए — और यही DNS-as-code मुफ्त में देता है। उसके बिना dual-provider DNS एक drift generator है और शायद single provider से भी बुरा है।

TTLs पर एक चेतावनी: टीमें 'performance के लिए' TTL 86400 तक बढ़ाना पसंद करती हैं, और फिर incident में पता चलता है कि इंटरनेट का एक चौथाई हिस्सा पूरे एक दिन तक उनके पुराने nameserver records कैश करता है। Nameserver-संबंधित records और किसी भी ऐसी चीज़ के लिए जिसे आपातकाल में बदलना पड़ सकता है, TTL 300–900 सेकंड रखो। Query-volume की लागत चुस्ती की तुलना में नगण्य है।

आमने-सामने: कब कौन सा तरीका जीतता है

सीधी बात करते हैं, क्योंकि दोनों रणनीतियाँ अलग खतरों और अलग संगठनों के लिए optimize होती हैं।

• Threat model: Lockdown hijacking और social engineering के खिलाफ जीतता है — यही सांख्यिकीय रूप से आम आपदाएँ हैं। Layered defense रजिस्ट्रार-पक्ष की विफलताओं के खिलाफ जीतता है: abuse automation, account seizure, insolvency, या support का ढह जाना।
• Cost: Lockdown लगभग मुफ्त है — registry lock की फीस, एक hardware key, और अनुशासन। Layered defense में दूसरे provider का बिल, एक spare domain, CI का ढाँचा, और drift रोकने के लिए लगातार ध्यान लगता है।
• Recovery time: Seizure की स्थिति में, केवल lockdown वाली टीमें support queue की दया पर होती हैं (घंटों से दिनों तक, जैसा हर war story में सुना है)। गर्म spare domain वाली layered टीमें मिनटों से घंटों में वापस आ जाती हैं।
• Operational burden: Lockdown set-and-forget है। Layered defense बिना देखभाल के सड़ जाता है — बिना टेस्ट किया fallback domain, जिसका cert expire हो चुका हो, सिर्फ security theater है।
• Organizational fit: एक एकल SaaS product वाली पाँच लोगों की startup को पूरा lockdown और दो सबसे सस्ते layered कदम करने चाहिए: बाहरी DNS-as-code और off-domain recovery email। जिस कंपनी का revenue डोमेन के साथ ही खत्म हो जाए, उसे पूरा layered stack चाहिए।

Lockdown आपके डोमेन को attackers से बचाता है। Layered defense आपके व्यवसाय को आपके रजिस्ट्रार से बचाता है। आप दोनों के संपर्क में हैं, इसलिए आपको दोनों चाहिए।

Recovery Runbook जो तब तक कोई नहीं लिखता जब तक बहुत देर न हो जाए

जो भी posture चुनो, seizure runbook अभी लिख लो। जिन incidents को मैंने सुचारु रूप से चलते देखा, उन सबके पास एक था; आपदाएँ इसलिए बिगड़ीं क्योंकि लोग अंदाज़े से काम कर रहे थे। तुम्हारे runbook में क्रम से ये होना चाहिए: scope की पुष्टि करो (क्या एक डोमेन है या पूरा अकाउंट — whois status codes जैसे clientHold या serverHold देखो), documented account identifiers के साथ support ticket खोलो, fallback domain सक्रिय करो और अपने status comms अपडेट करो, ग्राहकों को ऐसे चैनलों से सूचित करो जो मरे हुए डोमेन पर निर्भर न हों, और समानांतर में transfer-out प्रक्रिया शुरू करो — यह तय करने के लिए समाधान का इंतज़ार मत करो कि तुम छोड़ रहे हो।

उबाऊ हिस्सों का अभ्यास भी करो। क्या तुम साफ़ डिवाइस से, hardware key के साथ, उस password manager के बिना रजिस्ट्रार में लॉग इन कर सकते हो जो suspended डोमेन पर SSO के पीछे है? क्या registry-lock passphrase वहाँ है जहाँ on-call उसे ढूँढ सके? टीमें database failover को हर तिमाही टेस्ट करती हैं, और रजिस्ट्रार recovery कभी नहीं। चूँकि रजिस्ट्रार की विफलता वह SSO भी गिरा देती है जिससे आप बाकी सब तक पहुँचते हैं, यह प्राथमिकता उल्टी है।

मेरी सिफारिश

Lockdown पूरी तरह करो — यह एक दोपहर का काम है और सबसे संभावित हमले को रोकता है। फिर layered defense के बस ये तीन हिस्से इसी क्रम में लागू करो: authoritative DNS को रजिस्ट्रार से हटाकर code के रूप में manage करो; रजिस्ट्रार अकाउंट का recovery email किसी अलग रजिस्ट्रार पर डोमेन में ले जाओ; और certs, status page और emergency MX के साथ एक warm fallback domain खड़ा करो। ये तीन कदम कुछ सौ डॉलर सालाना में मुख्य विफलता वाले मोड कवर कर देते हैं। पूरी dual-registrar, dual-DNS architecture उन संगठनों के लिए रखो जो बता सकें कि पूरे डोमेन खोने का एक दिन उन्हें कितने में पड़ेगा — अगर वह संख्या छह अंकों की है, तो तुम्हें पहले से पता है कि क्या करना है।

और अगर तुम अब भी मुख्यतः कीमत देखकर रजिस्ट्रार चुन रहे हो, तो रुक जाओ। सस्ते रजिस्ट्रार का बाज़ार ऐसे मालिकों के हाथों में समेकित हो रहा है जिनका प्रोत्साहन मानवीय विवेक को automation से बदलना है, जो झूठे positive पर खुशी-खुशी तुम्हें suspend कर देगा और तुम्हारे ticket तक गुरुवार को पहुँचेगा। तुम्हारा डोमेन वह अकेला infrastructure है जिसे तुम container image से दोबारा deploy नहीं कर सकते। उसके साथ वैसा ही व्यवहार करो।