डोमेन रजिस्ट्रार सुरक्षा के लिए हर कॉल पर मंजूरी जरूरी है

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

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

एक क्रेडेंशियल कई सुरक्षा सीमाएं छिपाता है

रजिस्ट्रार क्रेडेंशियल प्रमाणीकरण का तथ्य है, मानवीय इरादे का बयान नहीं। प्रोवाइडर भले ही बारीक API अनुमतियां दे, टीमें अक्सर एक ऑटोमेशन जॉब पूरा कराने के लिए कई जरूरी write क्रियाएं एक ही रोल में रख देती हैं। दूसरे प्रोवाइडर एक व्यापक रजिस्ट्रार टोकन देते हैं। दोनों मामलों में, कुंजी का होना बस यह बताता है कि अनुरोध कौन कर सकता है। यह नहीं बताता कि यह खास बदलाव अभी होना चाहिए या नहीं।

मूल प्रोटोकॉल भी इन कार्रवाइयों को समान नहीं मानते। रजिस्ट्रार और रजिस्ट्री के बीच इस्तेमाल होने वाली EPP domain mapping, RFC 5731 में नेमसर्वर संबंधों, संपर्क संबंधों, स्थिति मानों और ऑथराइजेशन जानकारी को डोमेन के अलग गुण बताया गया है। इसका update command नेमसर्वर और संपर्क जोड़ या हटा सकता है, रजिस्ट्रेंट बदल सकता है, ऑथराइजेशन जानकारी बदल सकता है और client status मान बदल सकता है। सुविधाजनक API इन्हें एक क्रेडेंशियल के तहत रख सकता है, लेकिन रजिस्ट्री स्थिति इनके अर्थ अलग रखती है।

एक सार्वजनिक क्लाउड रजिस्ट्रार अपनी कमांड सूची में यही अंतर साफ दिखाता है। Route 53 Domains API में UpdateDomainNameservers, UpdateDomainContact, DisableDomainTransferLock, AssociateDelegationSignerToDomain और DisassociateDelegationSignerFromDomain अलग-अलग ऑपरेशन हैं। यह सूची उपयोगी प्रमाण है, क्योंकि यह उन निर्णयों के नाम बताती है जिन्हें मंजूरी प्रणाली को सुरक्षित रखना चाहिए, registrar.write में मिला नहीं देना चाहिए।

किसी एजेंट को रजिस्ट्रार पहुंच देने से पहले मैं चार सवाल पूछता हूं:

• क्या यह कॉल पूरे डोमेन का रिजॉल्यूशन दूसरी जगह मोड़ सकती है?
• क्या इससे आगे चलकर चोरी या रिकवरी आसान हो सकती है?
• क्या यह नियंत्रण या सत्यापन संदेश पाने वाले व्यक्ति को बदल सकती है?
• क्या इससे validating resolvers सही DNS जवाबों को भी अस्वीकार कर सकते हैं?

अगर दो कॉल के जवाब अलग हैं, तो वे अलग मंजूरी कार्रवाइयां हैं। एक API कुंजी साझा होने से वे एक नहीं हो जाते।

नेमसर्वर बदलाव पूरे जोन की जिम्मेदारी सौंपता है

नेमसर्वर बदलने पर DNS अथॉरिटी नए सर्वर सेट को मिल जाती है, इसलिए इसका असर एक रिकॉर्ड बदलने से बहुत अधिक होता है। RFC 8499 delegation को ऐसे परिभाषित करता है कि पैरेंट चाइल्ड origin के लिए NS record set जोड़ता है। कैश इस delegation का पालन करने लगें, तो नए authoritative server जोन के वेब पते, मेल एक्सचेंजर, service discovery रिकॉर्ड और सत्यापन TXT रिकॉर्ड के जवाब दे सकते हैं।

आखिरी श्रेणी में जोखिम को कम आंकना आसान है। RFC 8555 के अनुसार, ACME client _acme-challenge के तहत TXT मान देकर डोमेन पर नियंत्रण साबित कर सकता है। delegated zone को नियंत्रित करने वाला ऑपरेटर उस चुनौती का जवाब दे सकता है और certificate authority की जांचों के अधीन डोमेन के नामों के लिए प्रमाणपत्र मांग सकता है। इसलिए नेमसर्वर बदलाव केवल होस्टिंग सेटिंग नहीं है।

मंजूरी में पुराने और नए सर्वर सेट पूरे दिखने चाहिए, update DNS जैसे वाक्य से काम नहीं चलेगा। सेट मायने रखते हैं, क्योंकि माइग्रेशन में अक्सर पुराने हटाने से पहले सर्वर जोड़े जाते हैं, जबकि कुछ रजिस्ट्रार API एक कॉल में पूरा सेट बदल देते हैं। समीक्षक को दिखना चाहिए कि अनुरोध हर अपेक्षित सर्वर रखता है या नहीं, glue address शामिल हैं या नहीं, और क्या लक्ष्य सर्वर पहले से जोन के लिए authoritative जवाब दे रहे हैं।

मंजूरी से पहले recursive cache पर भरोसा करने के बजाय हर प्रस्तावित सर्वर से सीधे क्वेरी करें:

for ns in ns1.new-dns.example ns2.new-dns.example; do
  dig +norecurse +short @"$ns" example.com SOA
  dig +norecurse +short @"$ns" example.com MX
done

स्वस्थ जांच में हर सर्वर से SOA लाइन और अपेक्षित MX target मिलते हैं। खाली आउटपुट, अलग-अलग serial या authority के बिना जवाब की जांच करनी चाहिए। सटीक माइग्रेशन योजना तय करती है कि serial पहले से मिलने चाहिए या नहीं, लेकिन जिस सर्वर ने जोन के लिए जवाब नहीं दिया हो उसका नाम समीक्षक को कभी मंजूर नहीं करना चाहिए।

मंजूरी रिकॉर्ड में इस कार्रवाई को nameserver.replace बताएं, क्रमबद्ध अनुरोध और normalized set diff शामिल करें, और लिखें कि कॉल glue भी बदलती है या नहीं। इसे सामान्य डोमेन अपडेट में न छिपाएं, क्योंकि यहां एजेंट की एक विश्वसनीय लगने वाली गलती एक साथ हर सेवा को दूसरी जगह भेज सकती है।

ट्रांसफर लॉक हटाने से एक अवधि खुलती है

ट्रांसफर लॉक बंद करने से डोमेन ट्रांसफर नहीं होता, लेकिन ट्रांसफर रोकने वाला एक नियंत्रण हट जाता है। ICANN परिचित रजिस्ट्रार लॉक को clientTransferProhibited या मिलती-जुलती स्थिति कहता है। RFC 5731 कहता है कि clientTransferProhibited या serverTransferProhibited लागू होने पर ट्रांसफर अनुरोध अस्वीकार होना चाहिए।

समीक्षा के दौरान यह अंतर महत्वपूर्ण है। नियोजित स्थानांतरण से पहले एजेंट को डोमेन का लॉक हटाना सही रूप से जरूरी हो सकता है, फिर भी अनपेक्षित लॉक हटाना खतरनाक है क्योंकि यह किसी दूसरे व्यक्ति के लिए उपयोगी पूर्वशर्त बनाता है। transfer_lock.disable को अलग कार्रवाई मानें और अनुरोध में लक्ष्य रजिस्ट्रार, बदलाव टिकट और अपेक्षित relock या पूरा होने का समय लिखना जरूरी करें। ये फ़ील्ड रजिस्ट्रार से योजना लागू नहीं कराते, लेकिन मंजूरी देने वाले को बिना स्पष्टीकरण वाला लॉक हटाना अस्वीकार करने के लिए पर्याप्त संदर्भ देते हैं।

ऑथराइजेशन कोड अलग रहस्य और अलग निर्णय है। उसे पाना लॉक हटाने की मंजूरी में कभी छिपा नहीं होना चाहिए। उपयोगी कंट्रोल प्लेन लॉक हटाने के लिए एक बार और ट्रांसफर ऑथराइजेशन कोड पाने या इस्तेमाल करने के लिए फिर मंजूरी मांगता है। अगर वर्कफ़्लो रजिस्ट्रेंट भी बदलता है, तो क्रम मायने रखता है, क्योंकि ICANN की Transfer Policy के अनुसार कुछ स्थितियों में Change of Registrant के बाद 60 दिनों का इंटर-रजिस्ट्रार लॉक लगता है, जब तक रजिस्ट्रार ने बदलाव से पहले ऑप्ट आउट का विकल्प दिया हो और रजिस्ट्रेंट ने उसे चुना हो।

एक प्रचलित सलाह है कि डोमेन को लॉक ही रखें और इसलिए रजिस्ट्रार ऑटोमेशन को सुरक्षित मानें। लॉक मदद करता है, लेकिन यह सलाह एक कदम पहले रुक जाती है। जिस क्रेडेंशियल से लॉक हट सकता है, वह सुरक्षा भी हटा सकता है। हर कॉल की मंजूरी उस क्षण हटाने को दिखाती है जब यह मायने रखता है, जबकि मौजूदा लॉक स्थिति जांचने वाली स्थायी नीति अगले API अनुरोध से निष्प्रभावी हो सकती है।

लॉक चालू करना आमतौर पर कम जोखिम वाला सुधार है, फिर भी इसके संचालनात्मक परिणाम होते हैं। यह पहले से जारी वैध ट्रांसफर को रोक सकता है। लंबित ट्रांसफर स्थिति दिखाएं और किसी व्यक्ति से पुष्टि लें, जब तक किसी घटना प्रक्रिया ने आपातकालीन relocking को साफ तौर पर अधिकृत न किया हो।

संपर्क बदलाव रिकवरी का रास्ता बदलते हैं

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

ICANN रजिस्ट्रेंट को संपर्क जानकारी अद्यतन रखने को कहता है, क्योंकि रजिस्ट्रार सुरक्षा और प्रबंधन की सूचनाएं ईमेल से भेजते हैं। उसकी Transfer Policy कुछ स्थितियों में Change of Registrant को 60 दिन के ट्रांसफर लॉक से भी जोड़ती है। नियोजित ट्रांसफर से ठीक पहले रजिस्ट्रेंट ईमेल बदलने वाला एजेंट काम में देरी कर सकता है। रजिस्ट्रार और रजिस्ट्री प्रक्रिया के आधार पर, पहुंच योग्य संपर्क बदलने वाला हमलावर सूचनाओं या भविष्य की रिकवरी में दखल दे सकता है।

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

किसी असफल संपर्क अपडेट को ठीक करने के लिए एजेंट को फ़ील्ड बदलते रहने की अनुमति न दें, जब तक API स्वीकार न कर ले। रजिस्ट्रियों के सत्यापन नियम अलग होते हैं और कुछ country code डोमेन अतिरिक्त शर्तें लागू करते हैं। अधिक सुरक्षित तरीका है payload सत्यापित करना, अंतिम diff के लिए मंजूरी मांगना, उसे एक बार सबमिट करना और प्रोवाइडर का operation identifier दर्ज करना। अगर प्रोवाइडर बदलाव को asynchronous तरीके से करता है, तो इच्छित स्थिति पढ़कर पुष्टि होने तक कार्रवाई लंबित रहती है।

संपर्क गोपनीयता भी अलग कार्रवाई है। गोपनीयता दिखने का स्तर बदलना, मूल रजिस्ट्रेंट बदलने जैसा नहीं है। समीक्षक गोपनीयता टॉगल स्वीकार कर सकता है और स्वामित्व बदलाव अस्वीकार कर सकता है, इसलिए केवल एक vendor endpoint होने पर भी मंजूरी प्रणाली को दोनों नहीं मिलाने चाहिए।

DNSSEC बदलाव सही जवाबों को भी विफल कर सकते हैं

DNSSEC delegation बदलाव उस श्रृंखला को बदलता है जिससे validating resolvers चाइल्ड जोन को प्रमाणित करते हैं। RFC 4034 स्पष्ट है: DS record, key tag, algorithm और digest के जरिए DNSKEY की ओर इशारा करता है, और DS record delegation के पैरेंट साइड में रहता है। संबंधित DNSKEY चाइल्ड जोन में रहता है। रजिस्ट्रार API अक्सर DS सामग्री रजिस्ट्री तक भेजते हैं, क्योंकि रजिस्ट्रेंट पैरेंट जोन को सीधे संपादित नहीं कर सकता।

गलत नेमसर्वर जवाबों को दूसरी जगह मोड़ सकता है। गलत DS record resolvers से असली जवाबों को bogus चिह्नित करवा सकता है। यह अलग तरह की विफलता है और अलग समीक्षा चाहिए। DS हटाने से कैश अपडेट होने के बाद सुरक्षित delegated जोन असुरक्षित delegation बन सकता है। प्रकाशित DNSKEY से मेल न खाने वाला DS जोड़ने से सत्यापन टूट सकता है। key rollover के दौरान पुराना DS बहुत जल्दी हटाने से उन validators को समस्या हो सकती है जो अभी भी cached डेटा पर निर्भर हैं।

dnssec.ds.add, dnssec.ds.replace और dnssec.ds.remove की मंजूरी में key tag, algorithm, digest type, digest fingerprint और हर authoritative server से जुटाया DNSKEY प्रमाण दिखना चाहिए। समीक्षक को यह भी दिखना चाहिए कि अनुरोध rollover के दौरान overlap जोड़ता है या एक ही बार में अकेला DS बदल देता है।

ये कमांड श्रृंखला के दोनों पक्ष दिखाते हैं:

dig +short example.com DS
dig +short example.com DNSKEY
dig +dnssec example.com A

पहली क्वेरी सामान्य resolution path से पैरेंट साइड DS डेटा मांगती है। दूसरी चाइल्ड DNSKEY सेट लेती है। तीसरी जवाब और सत्यापन के लिए इस्तेमाल DNSSEC रिकॉर्ड दिखाती है। validating path पर डेटा प्रमाणित होने पर response flags में ad आ सकता है। समीक्षा को केवल संख्यात्मक key tag मिलाने तक सीमित न रखें। digest और algorithm का इच्छित DNSKEY से मिलना जरूरी है और rollout क्रम में cache का ध्यान रखना होगा।

DNS host का एक-क्लिक enable DNSSEC flow किसी व्यक्ति के लिए इन बारीकियों को समन्वित कर सकता है। रजिस्ट्रार और DNS API अलग-अलग इस्तेमाल करने वाले एजेंट को यह सुरक्षा अपने आप नहीं मिलती। प्रस्तावित क्रम, नई key प्रकाशित होने का प्रमाण और पैरेंट साइड के हर बदलाव के लिए साफ मंजूरी जरूरी करें।

मंजूरी को normalized action से बांधें

मंजूरी ऑब्जेक्ट को सिर्फ raw HTTP अनुरोध दिखाने के बजाय उसका अर्थ बताना चाहिए। URLs, प्रोवाइडर ऑपरेशन नाम और JSON संरचनाएं अलग-अलग होती हैं। स्थिर आंतरिक कार्रवाई नाम से समीक्षक अलग रजिस्ट्रारों में एक ही सुरक्षा घटना पहचान पाता है, बिना यह दिखावा किए कि प्रोवाइडर एक जैसे व्यवहार करते हैं।

एजेंट टूल सीमा के लिए यह व्यावहारिक action envelope है:

{
  "action": "nameserver.replace",
  "domain": "example.com",
  "before": {
    "nameservers": ["ns1.old-dns.example", "ns2.old-dns.example"]
  },
  "after": {
    "nameservers": ["ns1.new-dns.example", "ns2.new-dns.example"]
  },
  "reason": "CHG-1842 registrar migration",
  "evidence": {
    "authoritative_checks": "passed",
    "checked_at": "2026-07-24T14:25:00Z"
  },
  "request_hash": "sha256:..."
}

गेटवे को method, endpoint और सत्यापित body से कार्रवाई निकालनी चाहिए। एजेंट अपनी पसंद का दोस्ताना action label चुनकर अलग अनुरोध नहीं भेज सकता। मंजूरी को canonical request hash से बांधें, ताकि एजेंट एक नेमसर्वर सेट के लिए सहमति लेकर दूसरा सबमिट न कर सके। अगर asynchronous प्रोवाइडर को ऑपरेशन पुष्टि करने के लिए दूसरी कॉल चाहिए, तो वह कॉल जिस प्रतिबद्धता को पूरा करती है उसके अनुसार उसे वर्गीकृत और मंजूर करें।

Normalization मिश्रित बदलाव भी सामने लाता है। RFC 5731 एक domain update command में नेमसर्वर, संपर्क, status values और authorization information बदलने देता है। अगर रजिस्ट्रार endpoint एक payload में कई श्रेणियां लेता है, तो API अनुमति दे तो मंजूरी से पहले workflow अलग करें। अगर नहीं देता, तो मंजूरी में हर कार्रवाई दिखाएं और सबसे सख्त निर्णय लागू करें। domain.update जैसा लेबल समीक्षक को लगभग कुछ नहीं बताता।

ऐसे अनुरोध अस्वीकार करें जिनमें मौजूदा स्थिति न हो। नया read न होने पर diff पुराने अनुमान पर बन सकता है और किसी अन्य व्यक्ति का बदलाव मिटा सकता है। उपलब्ध हो तो प्रोवाइडर का version token या conditional request सुविधा इस्तेमाल करें। अगर दोनों न हों, तो सबमिट करने से ठीक पहले read करें, normalized state को मंजूर before मान से मिलाएं और किसी भी अंतर पर रुक जाएं।

रीड और राइट के लिए अलग स्तर की रुकावट चाहिए

हर कॉल की मंजूरी में रजिस्ट्रार क्रेडेंशियल के संवेदनशील उपयोग शामिल होने चाहिए, लेकिन लोगों को बेअसर inventory reads पर क्लिक करने की आदत नहीं डालनी चाहिए। अगर हर list operation डेवलपर को रोकता है, तो मंजूरी तंत्र बाधा बन जाता है और समीक्षक पढ़ना बंद कर देते हैं। सही सीमा असर और जानकारी उजागर होने के आधार पर तय होती है।

बिना प्रमाणीकरण वाली सार्वजनिक DNS lookups को रजिस्ट्रार क्रेडेंशियल नहीं चाहिए। डोमेन inventory, निजी संपर्क डेटा, ट्रांसफर कोड, बिलिंग डेटा या लंबित ऑपरेशन के authenticated reads को अलग तरीके से संभालना चाहिए। डोमेन विवरण पढ़ने से निजी संपर्क जानकारी उजागर हो सकती है। API catalog उसे read कहे, फिर भी authorization code लेने से तुरंत ट्रांसफर करने की क्षमता बन जाती है।

एक छोटी, समझने योग्य वर्गीकरण तालिका रखें:

मैनेज किए गए डोमेन सूचीबद्ध करना और masked status पढ़ना आमतौर पर सेशन मंजूरी से हो सकता है, क्योंकि वे बदलाव किए बिना inventory दिखाते हैं। ट्रांसफर authorization code पाने के लिए हर कॉल की मंजूरी चाहिए, क्योंकि उससे ऐसा रहस्य मिलता है जो ट्रांसफर करा सकता है।

नेमसर्वर बदलना, ट्रांसफर लॉक हटाना, रजिस्ट्रेंट या प्रशासनिक संपर्क बदलना और DS डेटा को जोड़ना, बदलना या हटाना, सभी के लिए हर कॉल की मंजूरी चाहिए क्योंकि हर एक नियंत्रण या सत्यापन बदलता है। Renewal नीति पर निर्भर है: इसमें पैसा खर्च होता है, लेकिन आमतौर पर नियंत्रण बना रहता है, इसलिए टीम तय खर्च सीमा के भीतर इसे पहले से मंजूर कर सकती है।

आखिरी पंक्ति को जानबूझकर उसी उत्तर में नहीं बांधा गया है। Renewal के वित्तीय और जीवनचक्र प्रभाव हैं, लेकिन इसका जोखिम डोमेन को मोड़ने या ट्रांसफर करने से अलग है। टीमें खर्च सीमा के भीतर renewal पहले से मंजूर कर सकती हैं और फिर भी हर delegation बदलाव के लिए किसी व्यक्ति की मंजूरी मांग सकती हैं। कार्रवाइयों को साफ नाम देने का यही मतलब है।

HTTP method को अकेला classifier न बनाएं। कुछ API read और write दोनों के लिए सामान्य POST इस्तेमाल करते हैं। Write जैसी व्यापक प्रोवाइडर श्रेणी भी इस्तेमाल न करें। Route 53 Domains authorization reference सही रूप से नेमसर्वर बदलाव, संपर्क अपडेट और ट्रांसफर लॉक हटाने को अलग permissions बताता है, लेकिन मंजूरी परत को फिर भी सही डोमेन और value diff चाहिए।

समीक्षक को प्रमाण चाहिए, एजेंट का विवरण नहीं

एजेंट द्वारा बनाया गया स्पष्टीकरण संदर्भ है, प्रमाण नहीं। मंजूरी की शुरुआत स्वतंत्र रूप से जुटाए तथ्यों से होनी चाहिए: प्रमाणित प्रोसेस, सटीक डोमेन, normalized action, पहले और बाद के मान, और जांच के परिणाम। इन फ़ील्ड के बाद एजेंट का कारण रखें।

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

मंजूरी की अवधि खत्म होनी चाहिए। पांच घंटे पुराना नेमसर्वर diff अब मौजूदा स्थिति नहीं दिखा सकता। समाप्ति अवधि इतनी छोटी हो कि बदलाव न खिसके और इतनी लंबी हो कि व्यक्ति प्रमाण देख सके। हर workflow में कॉपी किया गया एक सार्वभौमिक आंकड़ा न रखें। इसे रजिस्ट्रार के concurrency model और टीम के जवाब देने के समय के आधार पर तय करें, फिर before स्थिति बदलने पर अस्वीकार करें।

बैच मंजूरी तभी सुरक्षित है जब हर सदस्य दिखाई दे और सब एक जैसे हों। बीस parked domains के लिए समान नेमसर्वर माइग्रेशन मंजूर करना उचित हो सकता है, अगर कार्ड हर डोमेन सूचीबद्ध करे और हर एक के लिए प्रमाण पास हो। नेमसर्वर बदलाव, लॉक हटाने और संपर्क अपडेट को एक approve migration बटन में मिलाना उन भेदों को नष्ट कर देता है जिनकी समीक्षक को जरूरत है।

मंजूरी अस्वीकार होने पर कॉल रुकनी चाहिए, एजेंट को तब तक शब्द बदलकर फिर प्रयास करने का निमंत्रण नहीं मिलना चाहिए जब तक कोई हां न कर दे। अस्वीकृति को request hash के साथ दर्ज करें। महत्वपूर्ण रूप से बदला अनुरोध फिर पूछ सकता है, लेकिन प्रणाली को अंतर साफ दिखाना चाहिए।

सत्यापन भी कार्रवाई का हिस्सा है

सफल HTTP response का अर्थ अक्सर यह होता है कि रजिस्ट्रार ने जॉब स्वीकार कर ली है, यह नहीं कि रजिस्ट्री और DNS अब इच्छित स्थिति दिखा रहे हैं। कई domain API बाद में polling के लिए operation identifier लौटाते हैं। जर्नल में submission, provider completion और public verification को अलग स्थितियां मानें।

संवेदनशील बदलाव के बाद संक्षिप्त सत्यापन क्रम अधिकतर चौंकाने वाली समस्याएं पकड़ लेता है:

1. प्रोवाइडर का operation identifier सहेजें और उसकी दस्तावेज की गई स्थिति poll करें, जब तक वह terminal state तक न पहुंचे।
2. रजिस्ट्रार स्थिति फिर पढ़ें और मंजूर after object से मिलाएं।
3. एक से अधिक recursive path से पैरेंट साइड NS और DS डेटा क्वेरी करें, फिर authoritative servers से सीधे क्वेरी करें।
4. जोन पर निर्भर कुछ सेवाओं का परीक्षण करें, जिनमें उपलब्ध होने पर mail routing और certificate validation records शामिल हों।
5. प्रमाण मेल खाने पर ही बदलाव बंद करें, या तैयार recovery path चलाएं।

यह उन कुछ जगहों में से है जहां retries की कठोर सीमा चाहिए। टाइम आउट हुए read को फिर आजमाना सामान्य है। अनजान response के बाद state बदलने वाले अनुरोध को फिर भेजने से ओवरलैप होती jobs बन सकती हैं या मान दो बार बदल सकता है। फिर प्रयास करने से पहले idempotency token से क्वेरी करें या मौजूदा operation और domain state पढ़ें। अगर प्रोवाइडर idempotency तंत्र नहीं देता, तो अनुमान लगाने के बजाय अस्पष्ट परिणाम को आगे भेजें।

Rollback भी कार्रवाई के अनुसार अलग होता है। पुराने नेमसर्वर लौटाने से delegation वापस आ सकता है, लेकिन caches के कारण परिणाम देर से मिलेंगे। अगर कोई ट्रांसफर आगे नहीं बढ़ा, तो ट्रांसफर लॉक फिर चालू करना जोखिम की अवधि बंद कर सकता है। संपर्क वापस करने पर फिर पुष्टि या लॉक लग सकता है। पुराना DS लौटाना विफल हो सकता है, अगर उससे मेल खाती private signing key अब सक्रिय न हो। recovery record में मंजूरी से पहले, कार्रवाई के अनुसार reversal और उसकी पूर्वशर्तें लिखी होनी चाहिए।

maintenance window सत्यापन की जगह नहीं ले सकती। DNS बदलाव मौजूदा TTL के अनुसार caches में फैलते हैं और रजिस्ट्रार ऑपरेशन asynchronous हो सकते हैं। जब तक पुरानी और नई स्थिति माइग्रेशन योजना के अनुमान के अनुसार व्यवहार न करें, monitoring जारी रखें।

अलग क्रेडेंशियल हर कॉल की सहमति की जगह नहीं लेते

न्यूनतम अधिकार अब भी मायने रखते हैं। एजेंट को केवल उसी रजिस्ट्रार account, डोमेन और ऑपरेशन तक पहुंच दें जिनकी उसे जरूरत है। जहां प्रोवाइडर अनुमति दे, billing या असंबंधित portfolio पहुंच अलग रखें। कम अवधि वाले क्रेडेंशियल और process isolation जोखिम को और घटाते हैं।

लेकिन एक व्यापक टोकन को चार क्रेडेंशियल में बांट देना इरादा साबित नहीं करता। एजेंट नेमसर्वर क्रेडेंशियल का अपने अनुमत दायरे में भी गलत इस्तेमाल कर सकता है और समझौता किया गया प्रोसेस सही टोकन आने की प्रतीक्षा कर सकता है। अलग क्रेडेंशियल अधिकतम असर घटाते हैं। हर कॉल की सहमति तय करती है कि कोई खास असर होना चाहिए या नहीं।

सेशन authorization और हर कॉल की मंजूरी अलग समस्याएं हल करते हैं। सेशन authorization बताता है कि एजेंट प्रोसेस अपने रन के दौरान gateway से कार्रवाई कर सकता है या नहीं। हर कॉल की मंजूरी उन कुछ ऑपरेशनों पर रोक लगाती है जहां व्यक्ति को इरादे और सटीक असर की तुलना करनी होती है। reads और रोजमर्रा की कम असर वाली कॉल सेशन के तहत चल सकती हैं, जबकि मंजूरी के लिए चिह्नित रजिस्ट्रार कुंजी हर उपयोग पर रुकती है।

Sallyport इस अलगाव को vault gate, हर नए एजेंट प्रोसेस के लिए authorization और हर उपयोग पर मंजूरी मांगने वाले per-key विकल्प के साथ लागू करता है। इस दौरान रजिस्ट्रार रहस्य एजेंट से बाहर रहता है। व्यापक रजिस्ट्रार क्रेडेंशियल के लिए कुंजी को हर कॉल पर चिह्नित करें और अनुरोध विवरण में ऊपर बताए गए normalized action और diff रखें।

एजेंट को API token अस्थायी रूप से रखने की शिक्षा न दें ताकि वह बैच पूरा कर सके। एक बार token model process में पहुंच गया, तो मंजूरी सलाह मात्र रह जाती है क्योंकि आगे की कॉल gate को बायपास कर सकती हैं। क्रेडेंशियल रखने वाले component को मंजूर अनुरोध खुद चलाना चाहिए और केवल परिणाम लौटाना चाहिए।

ऑडिट रिकॉर्ड से निर्णय फिर बनाया जा सके

agent called registrar कहने वाली ऑडिट एंट्री किसी घटना का निपटारा नहीं कर सकती। रिकॉर्ड में दिखना चाहिए कि व्यक्ति ने क्या देखा, क्या मंजूर किया, कौन से bytes भेजे गए, प्रोवाइडर ने क्या लौटाया और बाद में सत्यापन में क्या मिला। वरना टीम गतिविधि साबित कर सकती है, authorization नहीं।

हर संवेदनशील कॉल के लिए process identity, session identifier, approver, decision time, normalized action, domain, before और after objects, request hash, provider operation identifier, response status और verification result सुरक्षित रखें। निजी संपर्क मानों को अपने डेटा प्रबंधन नियमों के अनुसार सुरक्षित रखें, लेकिन स्थिर digest या नियंत्रित encrypted copy रखें ताकि जांचकर्ता दो बदलावों में अंतर कर सकें।

अस्वीकृति और revocation घटनाएं भी रखें। अगर ऑपरेटर अनपेक्षित लॉक हटाने का अनुरोध देखकर एजेंट सेशन रद्द करता है, तो यह क्रम बताता है कि बाद की कॉल क्यों रुकीं। केवल जोड़ने वाला, hash-chained log चुपचाप बदलाव को पकड़ने योग्य बनाता है, जबकि स्वतंत्र export या verification उस इंटरफ़ेस पर निर्भर रहने से बचाता है जिसने कार्रवाई की थी।

Sallyport एक encrypted, hash-chained audit log में agent sessions और individual calls दर्ज करता है। sp audit verify vault key के बिना ciphertext पर ही chain को offline जांचता है। सत्यापन साबित करता है कि रिकॉर्ड की chain बदली नहीं गई है, जबकि action envelope जांचकर्ताओं को जरूरी डोमेन-विशिष्ट अर्थ देता है।

मंजूरी रिकॉर्ड को प्रोवाइडर abstraction के बाद भी टिकना चाहिए। provider operation name को normalized action के साथ रखें, उसकी जगह नहीं। इससे जांचकर्ता dnssec.ds.remove जैसे portable label को सटीक API call तक ले जा सकता है और हर समीक्षक को vendor शब्दावली सीखने की जरूरत नहीं पड़ती। canonical request bytes या उनका cryptographic digest सुरक्षित रखें और लिखें कि किस normalization version ने कार्रवाई बनाई। classifier बाद में बदले, तो जांचकर्ता नए तर्क से पुराने events को परखने के बजाय वह निर्णय दोहरा सकें जो ऑपरेटर ने वास्तव में देखा था।

उस रिकॉर्ड को भरोसा करने से पहले जांचें। एक सुरक्षित staging-domain बदलाव को मंजूरी से गुजारें, उसी बताए गए कारण के साथ बदले अनुरोध को अस्वीकार करें, एजेंट सेशन रद्द करें और सत्यापित करें कि जर्नल तीनों घटनाएं सही क्रम में रखता है। फिर अस्पष्ट provider timeout का अनुकरण करें और पुष्टि करें कि workflow बिना सोचे फिर सबमिट करने के बजाय स्थिति पढ़ता है। केवल सफल कॉल के लिए काम करने वाला ऑडिट डिजाइन उसी घटना में विफल होगा जिसे समझाने के लिए वह बनाया गया था।

पहला उपयोगी बदलाव यह है कि रजिस्ट्रार टूल को update domain कहना बंद करें। नेमसर्वर बदलने, ट्रांसफर लॉक हटाने, संपर्क बदलाव, authorization code पाने और DS बदलाव को अलग नाम दें। फिर मानवीय सहमति को उस कॉल पर रखें जिसमें हर असर मौजूद है। प्रोवाइडर के डिजाइन के कारण क्रेडेंशियल व्यापक रह सकता है, लेकिन निर्णय को व्यापक रहने की जरूरत नहीं है।