एक सरकारी-डोमेन अध्ययन को पास-रेट चार्ट की आवश्यकता से पहले एक परिभाषित जनसंख्या की आवश्यकता होती है। एक पंजीकृत डोमेन एक वेबसाइट, एक सेवानिवृत्त कार्यक्रम या गैर-भेजने वाले उद्देश्य को पूरा कर सकता है। आधिकारिक सूची में इसकी उपस्थिति प्रमाण है, न कि इस बात का प्रमाण कि प्रत्येक एजेंसी संदेश उस डोमेन का उपयोग करता है या सफलतापूर्वक प्रमाणित करता है।
आधिकारिक फ़्रेम चुनें और फ़्रीज़ करें
CISA का dotgov-डेटा रिपॉजिटरी, व्यापक .gov क्षेत्र को कवर करते हुए, current-full.csv से, संघीय पंजीकरण वाले current-federal.csv को अलग करता है। इसके README का कहना है कि सूचियों में रेडी और ऑन होल्ड स्थिति में दूसरे स्तर के डोमेन शामिल हैं, प्रत्येक होस्टनाम नहीं; यह यह भी चेतावनी देता है कि पंजीकृत डोमेन को ऑनलाइन सेवा प्रदान करने की आवश्यकता नहीं है। अध्ययन शीर्षक और समावेशन नियमों में उन सीमाओं का उपयोग करें। संघीय स्वचालित रूप से कार्यकारी शाखा के समान नहीं है।
वास्तविक संग्रह के लिए, वास्तविक फ़ाइल बाइट्स, स्रोत यूआरएल, पुनर्प्राप्ति समय और सामग्री हैश, साथ ही उपलब्ध किसी भी संस्करण पहचानकर्ता को बनाए रखें। केवल बदलती मुख्य-शाखा फ़ाइल का लिंक रिकॉर्ड न करें। मूल फ़ील्ड और दस्तावेज़ सामान्यीकरण, डुप्लिकेट हैंडलिंग और बहिष्करण रखें। इस आलेख द्वारा कोई जनसंख्या स्नैपशॉट या सरकारी DNS माप प्रदान नहीं किया गया है।
परिणामों का निरीक्षण करने से पहले चयन ठीक करें
परिणाम एकत्र करने से पहले एक जनगणना चुनें या नमूना नियम, नमूना आकार और यादृच्छिक बीज या नियतात्मक क्रम घोषित करें। परिचित नामों की हाथ से चुनी गई जोड़ी एक उदाहरणात्मक केस स्टडी है, प्रतिनिधि नमूना नहीं। बाद में उनकी रजिस्ट्री सदस्यता को देखना चयन के बाद की पुष्टि है, न कि इस बात का सबूत कि उनका नमूना सूची से लिया गया था।
रिकॉर्ड एजेंसी, घटक और डोमेन अलग से। एक एजेंसी के स्वामित्व वाले तीन डोमेन तीन डोमेन अवलोकन हैं लेकिन तीन स्वतंत्र एजेंसियां नहीं हैं। निष्क्रिय, अनसुलझी और बहिष्कृत पंक्तियों को चुपचाप छोड़ने के बजाय कारणों सहित संरक्षित करें। किसी असफल अवलोकन को अधिक सुविधाजनक सफल डोमेन से न बदलें।
बूलियन बैज के बजाय क्वेरी साक्ष्य बनाए रखें
प्रत्येक चयनित पंक्ति के लिए, सटीक पूछे गए स्वामी और प्रकार, रिज़ॉल्वर, यूटीसी अनुरोध समय, प्रतिक्रिया या परिवहन त्रुटि, DNS स्थिति, उत्तर स्वामी/प्रकार/डेटा, प्रासंगिक झंडे और टीटीएल रिकॉर्ड करें। पार्सर संस्करण और उसके सामान्यीकरण नियमों के साथ कच्ची प्रतिक्रियाएँ रखें। एक सफल HTTP अनुरोध अकेले एक सफल DNS उत्तर स्थापित नहीं करता है। Google का प्रलेखित JSON API स्थिति, उत्तर और अन्य प्रतिक्रिया फ़ील्ड को अलग करता है; DNS स्थिति और परिवहन स्थिति अलग-अलग कॉलम में हैं।
TXT उत्तर के लिए, वर्ण-स्ट्रिंग सीमाओं को सुरक्षित रखें और तार्किक रिकॉर्ड सामग्री का सही ढंग से पुनर्निर्माण करें। गलती मत करो ए CNAME श्रृंखला को रिकॉर्ड किए बिना सीधे उत्तर के लिए लक्ष्य का डेटा। एक सटीक _dmarc क्वेरी का पूर्ण कार्यान्वयन नहीं है RFC 9989 नीति खोज. यदि वह अनुसंधान का दायरा है, तो प्रत्येक उपडोमेन के लिए प्रभावी नीति के बजाय इसे सटीक-स्वामी अवलोकन का लेबल दें।
एक काल्पनिक तीन पंक्ति वाले बहीखाते का निरीक्षण करें
ये आरक्षित नाम और परिणाम विधि चित्रण के लिए निर्धारित हैं, न कि CISA सूची सदस्यों या नेटवर्क टिप्पणियों के लिए। सभी पंक्तियाँ TXT प्रकार का उपयोग करती हैं; रिज़ॉल्वर पहचान और संग्रह टाइमस्टैम्प जानबूझकर प्रदान नहीं किए गए क्योंकि कोई क्वेरी नहीं चलाई गई थी।
- agency-a.example : प्रस्तावित एजेंसी ए, घटक अल्फा, मालिक _dmarc.agency-a.example । एक TXT उम्मीदवार के साथ NOERROR मान लें v=DMARC1; p=reject. पूर्ण वाक्यविन्यास और खोज सत्यापन लंबित होने पर, शाब्दिक रूप से अस्वीकार किए गए उम्मीदवार को वर्गीकृत करें; अनुपालन, प्रेषक कवरेज या प्राप्तकर्ता अस्वीकृति का अनुमान न लगाएं।
- programme-a.example : प्रस्तावित एजेंसी ए, घटक अल्फा, मालिक _dmarc.programme-a.example । बिना किसी प्रासंगिक उत्तर के NOERROR मान लें। NODATA वर्गीकृत करने से पहले CNAME /रेफ़रल/प्राधिकरण संदर्भ का निरीक्षण करें; कोई प्रभावी नीति न मानें.
- agency-b.example : प्रस्तावित एजेंसी बी, घटक बीटा, स्वामी _dmarc.agency-b.example । बिना किसी DNS प्रतिक्रिया के अनुरोध समयबाह्य मान लें। रिकॉर्ड अज्ञात और गायब साक्ष्य; इसे अनुपस्थित या अमान्य नीति में न बदलें।
खाता बही में तीन डोमेन पंक्तियाँ और दो प्रस्तावित एजेंसी लेबल हैं, लेकिन कोई वास्तविक भाजक या गोद लेने का प्रतिशत प्रदान नहीं करता है। एक शाब्दिक अस्वीकृत उम्मीदवार सरकारी गोद लेने की मापित दर नहीं है। एक वास्तविक रिपोर्ट में चयनित, प्रयास किए गए, व्याख्या योग्य और अनसुलझे गणनाओं को अलग-अलग दिखाना चाहिए, हर की व्याख्या करनी चाहिए और त्रुटियों को संरक्षित करना चाहिए।
परिचालन परिणामों से अवलोकन योग्य नीति को अलग करें
RFC 9989 नीति सिंटैक्स, खोज और रिसीवर प्रोसेसिंग का वर्णन करता है। एक प्रकाशित प्राथमिकता प्रत्येक रिसीवर की हैंडलिंग को बाध्य नहीं करती है और यह नहीं दिखाती है कि वैध मार्ग संरेखित हैं या नहीं। RFC 9990 अपने स्वयं के रिपोर्टिंग कवरेज के साथ अलग-अलग संदेश-व्युत्पन्न समग्र साक्ष्य का वर्णन करता है। न तो कोई DNS स्नैपशॉट और न ही समग्र प्रतिशत यह साबित करता है कि प्रत्येक नागरिक को एक अधिसूचना प्राप्त हुई है।
सरकारी आदेशों के लिए अलग से आधिकारिक प्रयोज्यता अनुसंधान की आवश्यकता होती है। रजिस्ट्री सदस्यता, अस्वीकार टैग या सफल पार्सर को कानूनी-अनुपालन बैज में अनुवाद न करें। यदि अनुरोधित निष्कर्ष के लिए प्रेषक सूची या प्राप्तकर्ता साक्ष्य की आवश्यकता है, तो इसे अनुमानित सफलता से भरने के बजाय अंतर बताएं।
एक प्रतिलिपि प्रस्तुत करने योग्य रिलीज़ पैकेट को परिभाषित करें
वास्तविक अनुभवजन्य निष्कर्षों को प्रकाशित करने से पहले, जमे हुए फ्रेम, प्रीकलेक्शन योजना, बहिष्करण, कच्ची प्रतिक्रियाएं, सामान्यीकृत पंक्तियां, पार्सर संस्करण, त्रुटि लॉग, संग्रह विंडो और दावा-से-पंक्ति मैपिंग को बनाए रखें। एक नया संग्रह एक नई समय विंडो को मापता है; यह अनुपलब्ध ऐतिहासिक रन को पूर्वव्यापी रूप से सत्यापित नहीं करता है। एक अन्य समीक्षक को दिए गए साक्ष्य के लिए रिपोर्ट की गई प्रत्येक संख्या का पता लगाने में सक्षम होना चाहिए।
यह लेख एक कार्यप्रणाली और लिखित उदाहरण है, एकत्रित सरकारी परिणामों की रिपोर्ट नहीं। इसके काल्पनिक बही-खाते के लिए कोई DNS परिवर्तन, लाइव क्वेरी या ईमेल नहीं भेजा गया। मूल पांडुलिपि के ऐतिहासिक दावों का उपयोग यहां वर्तमान साक्ष्य के रूप में नहीं किया गया है।