कोई भी सार्वजनिक प्रमाणीकरण रिकॉर्ड का निरीक्षण कर सकता है। उस क्षमता को किसी ग्राहक की रिपोर्ट या प्रशासन कंसोल तक पहुंच प्रदान नहीं करनी चाहिए। एक डोमेन ऑनबोर्डिंग प्रक्रिया को अधिकार के प्रमाण, एक परिभाषित दायरे और संबंध बदलने पर पहुंच वापस लेने के तरीके की आवश्यकता होती है।
परिभाषित करें कि दावे का क्या अर्थ है
कानूनी स्वामित्व, DNS का नियंत्रण, ग्राहक के लिए कार्य करने का प्राधिकरण और किसी सेवा का उपयोग करने की अनुमति में अंतर करें। एक DNS चुनौती नियंत्रण प्रदर्शित कर सकती है एक अभिलिखित एक समय में. यह अपने आप में प्रत्येक उपडोमेन और संबद्ध ग्राहक खाते पर कानूनी स्वामित्व, आवेदक के रोजगार या अधिकार को स्थापित नहीं करता है।
एमएसपी के लिए, ग्राहक अनुबंध और नामित संपर्कों के माध्यम से अनुरोध करने वाले संगठन और प्रत्यायोजित प्राधिकारी की पुष्टि करें। अनुरोध किए जा रहे सटीक डोमेन, किरायेदार, उद्देश्य और पहुंच को रिकॉर्ड करें। विवादों या स्थानांतरणों के लिए एक स्वतंत्र ग्राहक अनुमोदन पथ का उपयोग करें। केवल इसलिए किरायेदारों का स्वचालित रूप से विलय न करें क्योंकि वे एक ही डोमेन का दावा करते हैं।
किसी चुनौती को बांधें और सीमित करें
एक उदाहरणात्मक डिज़ाइन एक डोमेन, किरायेदार, दावेदार और समाप्ति से जुड़ी एक अप्रत्याशित चुनौती जारी करता है। अपेक्षित आधिकारिक साक्ष्य की जाँच करें, अवलोकन समय सुरक्षित रखें और सफल उपयोग के बाद चुनौती को अमान्य कर दें। किसी अन्य डोमेन या पिछले ऑनबोर्डिंग प्रयास से टोकन स्वीकार करने से बचें। यह एक अनुशंसित डिज़ाइन है, न कि प्रोटोकॉल आवश्यकता या EmailAuth कार्यान्वयन के बारे में दावा।
दावा शुरू करने से पहले एक प्रमाणित पहचान की आवश्यकता होती है, फिर प्रत्येक बाद की पहुंच को स्वतंत्र रूप से अधिकृत करें। OWASP का प्राधिकरण मार्गदर्शन प्रत्येक अनुरोध पर डिफ़ॉल्ट अस्वीकृति और अनुमति जांच के लिए कॉल करता है। सफल डोमेन सत्यापन से केवल स्पष्ट रूप से अनुमोदित अनुमति स्थापित होनी चाहिए, न कि असंबंधित किरायेदारों या ऐतिहासिक रिपोर्ट अभिलेखागार पर प्रशासनिक अधिकार।
सही दावों और प्रतिकूल मामलों का परीक्षण करें
मान लीजिए कि एक नई एजेंसी अनुरोधित DNS चुनौती को प्रकाशित कर सकती है लेकिन पिछली एजेंसी के लिए एकत्र की गई रिपोर्ट तक पहुंच चाहती है। DNS अवलोकन उस रिकॉर्ड के वर्तमान नियंत्रण का समर्थन करता है; यह पिछले किरायेदार के संग्रह तक पहुंच को अधिकृत नहीं करता है। जब तक ग्राहक सत्यापित स्वतंत्र पथ के माध्यम से विशिष्ट डेटा और प्राप्तकर्ता को मंजूरी नहीं दे देता, तब तक संग्रह पहुंच को रोक कर रखें।
अलग-अलग, गलत किरायेदार के तहत, समाप्ति के बाद और सफल उपयोग के बाद अन्यथा वैध चुनौती का परीक्षण करें। इस प्रस्तावित डिज़ाइन में उन मामलों को खारिज कर दिया जाना चाहिए जबकि एक वैध दायरे वाले दावे को अलग से आवश्यक प्राधिकारी और अनुमति जांच के लिए आगे बढ़ना चाहिए। ये काल्पनिक अपेक्षित निर्णय हैं, आपूर्ति किए गए टोकन, DNS अवलोकन या निष्पादित परीक्षण नहीं हैं। अनुमोदित परीक्षण वातावरण में वास्तविक चुनौती निर्माण, आधिकारिक लुकअप, कैशिंग और सेवा प्राधिकरण को सत्यापित करें।
स्थानांतरण और निरसन को स्पष्ट रूप से संभालें
डोमेन बिक्री, एजेंसी परिवर्तन और कर्मचारी प्रस्थान के लिए अलग-अलग कार्रवाइयों की आवश्यकता होती है। सत्यापित संपर्कों के साथ प्राधिकरण की जाँच करते समय विवादित परिवर्तनों को रोकें। पिछले ग्राहक की रिपोर्ट को नए दावेदार के सामने उजागर किए बिना पुराने और नए दावे के साक्ष्य को सुरक्षित रखें। DNS के नए नियंत्रक को स्वचालित रूप से ऐतिहासिक किरायेदार डेटा प्राप्त नहीं करना चाहिए।
सक्रिय सत्रों, पृष्ठभूमि नौकरियों और लागू होने वाले दायरे वाले क्रेडेंशियल सहित सेवा स्तर पर पहुंच रद्द करें। DNS चुनौती को हटाना अनुमतियाँ वापस लेने का विकल्प नहीं है। किसी भी चल रहे डेटा संग्रह की अलग से समीक्षा करें ताकि निरस्त किए गए उपयोगकर्ता रिपोर्ट निर्यात करना या प्राप्त करना जारी न रख सकें।
सही साक्ष्य स्वीकार करें
ऑनबोर्डिंग तभी बंद करें जब प्राधिकारी जांच, कार्यक्षेत्र अनुमोदन, पहचान प्रावधान और नकारात्मक पहुंच परीक्षण पूरे हो जाएं। रिकॉर्ड करें कि रिश्ते को किसने मंजूरी दी और कौन सी पहुंच प्रदान की गई। सामग्री स्वामित्व या सेवा परिवर्तन के बाद पुनः सत्यापित करें। एक मजबूत सत्यापन प्रक्रिया एक सीमित प्राधिकरण निर्णय और पुनर्प्राप्ति योग्य ऑडिट इतिहास उत्पन्न करती है, न कि यह स्थायी दावा कि एक व्यक्ति हमेशा के लिए एक डोमेन का मालिक है।