क्या वाइल्डकार्ड जानबूझकर व्यापक होता है
एक रिपोर्ट उपभोक्ता प्राप्त करने को इच्छुक हो सकता है DMARC प्रत्येक संबंध के लिए एक प्राधिकरण स्वामी को प्रकाशित करने के बजाय किसी भी डोमेन के लिए रिपोर्ट। RFC 9990 उस उद्देश्य के लिए स्पष्ट रूप से वाइल्डकार्ड DNS रिकॉर्ड की अनुमति देता है। इसका उदाहरण स्थान ए TXT रिकॉर्ड पर *। _report._dmarc.example.com कम से कम v=DMARC1. यह प्राप्तकर्ता डोमेन द्वारा एक व्यापक ऑप्ट-इन है, न कि एक तंत्र जो यह साबित करता है कि प्रत्येक रिपोर्टिंग ग्राहक की जांच की गई है।
भेद परिचालनात्मक रूप से महत्वपूर्ण है। एक प्रदाता वैध रूप से व्यापक सेवन का चयन कर सकता है जबकि ग्राहक को डेटा दिखाने से पहले अलग से खाता-स्तरीय सत्यापन की आवश्यकता होती है। DNS रिकॉर्ड उन खाता नियंत्रणों को लागू नहीं करता है। एक सुरक्षा समीक्षा में सटीक रूप से यह पहचानना चाहिए कि वाइल्डकार्ड में कौन सी सीमा बदलती है और कौन सी सीमाएँ प्राप्त करने वाले एप्लिकेशन और उसके मालिकों की ज़िम्मेदारी बनी रहती हैं। RFC 9990 , अनुभाग 4
सटीक क्वेरीज़ को वाइल्डकार्ड के नीचे दृश्यमान रखें
रिपोर्टर अभी भी उस डोमेन से प्राधिकरण लुकअप का निर्माण करता है जहां नीति पुनर्प्राप्त की गई थी, _रिपोर्ट। _dmarc लेबल और गंतव्य होस्ट। वाइल्डकार्ड एक DNS प्रकाशन रणनीति है जो उन प्रश्नों का उत्तर दे सकती है; यह पूछे गए स्वामी या लौटाए गए मूल्य को समझने की आवश्यकता को दूर नहीं करता है। किसी विशेष संबंध को सत्यापित करते समय सटीक स्वामी और प्रतिक्रिया को सुरक्षित रखें।
पुष्टि करने वाले उत्तर को अनिवार्य प्रथम v=DMARC1. संस्करण मान अपने आवश्यक मामले के साथ DMARC1 रहता है। वाइल्डकार्ड का उपयोग करने का व्यवस्थापक का इरादा इस बात का सबूत नहीं है कि एक विशेष क्वेरी तैनात DNS ट्री में अपेक्षा के अनुरूप हल हो जाती है। सटीक-नाम रिकॉर्ड और DNS संरचना वास्तविक रिज़ॉल्यूशन को प्रभावित कर सकती है, इसलिए प्रस्तावित परीक्षणों को यह मानने के बजाय कि स्क्रीनशॉट कवरेज साबित करता है, वास्तविक उत्तर को बरकरार रखना चाहिए। RFC 9990 , अनुभाग 4; RFC 9989 , खंड 4.7
स्वामित्व और डेटा एक्सेस से अलग सेवन अनुमति
वाइल्डकार्ड कहता है कि प्राप्तकर्ता डोमेन प्रोटोकॉल व्यवस्था द्वारा कवर की गई रिपोर्ट प्राप्त करने के लिए इच्छुक है। यह स्थापित नहीं करता है कि डैशबोर्ड में साइन इन करने वाला व्यक्ति रिपोर्ट के अंदर नामित डोमेन को नियंत्रित करता है। यह यह भी स्थापित नहीं करता है कि अपलोड किए गए आर्टिफैक्ट का प्रेषक भरोसेमंद है या रिपोर्ट इसे प्राप्त करने वाले खाते से संबंधित है।
एप्लिकेशन-स्तरीय स्वीकृति आवश्यकताओं को अलग से परिभाषित करें: डोमेन-टू-टेनेंट बाइंडिंग, प्रमाणित पहुंच, उद्गम ट्रैकिंग, डुप्लिकेट हैंडलिंग और अप्रत्याशित डोमेन की समीक्षा। ये प्रस्तावित नियंत्रण हैं, कार्यान्वित EmailAuth प्लेटफ़ॉर्म के बारे में दावे नहीं। किसी संगठन का उल्लेख करने वाली रिपोर्ट में स्वचालित रूप से स्वामित्व संबंध नहीं बनाना चाहिए या नाम का दावा करने वाले पहले खाते में डेटा उजागर नहीं करना चाहिए।
बिलिंग, ऑनबोर्डिंग और डेटा प्राधिकरण को DNS अनुमान से बाहर रखें। ट्रैफ़िक प्राप्त करने की व्यापक इच्छा किसी संगठन को सशुल्क सेवा में नामांकित करने या उसके देखे गए कॉन्फ़िगरेशन को प्रकाशित करने की सहमति नहीं है। यदि किसी वर्कफ़्लो को इन कार्रवाइयों की आवश्यकता होती है, तो उसे वाइल्डकार्ड रिकॉर्ड से परे स्पष्ट निर्णय और साक्ष्य की आवश्यकता होती है। समीक्षा में एकल DNS परिणाम को व्यापक अनुमोदन मानने के बजाय प्रत्येक सीमा के लिए जिम्मेदार स्वामी का नाम बताना चाहिए।
दुरुपयोग और संसाधन दबाव का लेखा-जोखा रखें
RFC 9990 चेतावनी देता है कि रिपोर्ट सामग्री डीकंप्रेसर या XML पार्सर पर हमला कर सकती है और रिपोर्ट डेटा जाली हो सकता है। इसलिए एक व्यापक सेवन सेवा को यह मानना चाहिए कि रिपोर्ट प्राप्त करने की अनुमति प्रत्येक आने वाली फ़ाइल को सुरक्षित या सटीक नहीं बनाती है। क्षमता योजना, पार्सर सीमाएं और उद्गम जांच प्राधिकरण डिजाइन के साथ-साथ हैं।
बाउंडेड संदेश आकार, डीकंप्रेस्ड-आकार सीमाएं, पार्सिंग समय बजट, कतार अलगाव और अप्रत्याशित स्रोत मात्रा के लिए चेतावनी का प्रस्ताव करें। किसी आविष्कृत सार्वभौमिक सीमा से कॉपी करने के बजाय वास्तविक वातावरण के लिए संख्यात्मक मानों का चयन और परीक्षण किया जाना चाहिए। अस्वीकृति के कारणों को सुरक्षित रखें और शोर मचाने वाले किसी स्रोत को असंबंधित ग्राहक साक्ष्य को अस्पष्ट करने की अनुमति देने से बचें। इनमें से किसी भी नियंत्रण को यहां तैनात या परीक्षण किए जाने का दावा नहीं किया गया है। RFC 9990 , खंड 8.1 और 8.2
निकासी और कैश्ड प्राधिकरण
वॉल्यूम से अभिभूत एक रिपोर्ट उपभोक्ता पुष्टिकरण DNS रिकॉर्ड को हटा सकता है, लेकिन RFC 9990 नोट करता है कि सकारात्मक कैशिंग रिकॉर्ड के टीटीएल के रूप में लंबे समय तक प्रभाव में देरी कर सकती है। DNS परिवर्तन के बाद रिपोर्ट को तत्काल बंद करने का वादा न करें। इंटेक सिस्टम को ताजा लुकअप स्थिति से स्वतंत्र रूप से पहले से तैयार या कतारबद्ध रिपोर्ट को संभालने की भी आवश्यकता हो सकती है।
निकासी योजना में रिकॉर्ड स्वामी, अनुमोदन पथ, प्रासंगिक टीटीएल साक्ष्य, संक्रमण के दौरान सेवन व्यवहार और संचार जिम्मेदारियों की पहचान होनी चाहिए। वाइल्डकार्ड हटाने से एक साथ कई वैध रिश्ते प्रभावित हो सकते हैं। स्पष्ट रूप से प्रति-डोमेन प्राधिकरण के प्रस्तावित कदम के लिए न केवल उन संबंधों की एक सूची और एक सत्यापन योजना की आवश्यकता होती है एक अभिलिखित हटाना.
DNS निकासी और एप्लिकेशन एक्सेस निरस्तीकरण के बीच अंतर रखें। प्राप्त अनुमति को हटाने से संग्रहीत रिपोर्ट स्वयं नहीं हटती, ग्राहक खाते बंद नहीं होते या मौजूदा उपयोगकर्ता सत्र रद्द नहीं होते। वे अलग प्राधिकरण और प्रतिधारण निहितार्थ के साथ अलग नियंत्रण हैं। RFC 9990 , अनुभाग 4
काल्पनिक सीमा समीक्षा और परीक्षण डिज़ाइन
reports.example.net पर एक काल्पनिक उपभोक्ता पर विचार करें जो प्रस्तावित करता है *। _report._dmarc.reports.example.net मान v=DMARC1; . blue.example.com पर एक काल्पनिक नीति के लिए, सटीक क्वेरी blue.example.com._report._dmarc.reports.example.net होगी। इस उदाहरण के लिए कोई क्वेरी, प्रकाशन या DNS फ़िक्स्चर निष्पादित नहीं किया गया था।
सकारात्मक-केस योजना सटीक क्वेरी बनाए रखेगी और पुष्टि करेगी कि लौटाया गया प्राधिकरण मान पार्सिंग से गुजरता है। नकारात्मक-मामले की योजना को सावधानी से चुना जाना चाहिए: समान रूप से अधिकृत गंतव्य के लिए निर्देशित एक अन्य स्रोत डोमेन आवश्यक रूप से अनधिकृत नहीं है, क्योंकि वाइल्डकार्ड जानबूझकर आम तौर पर स्रोत डोमेन को कवर करता है। इसके बजाय, बिना अनुमति के एक अलग से नियंत्रित गंतव्य होस्ट बाहरी-गंतव्य सीमा को चित्रित कर सकता है, बशर्ते कोई भी वास्तविक स्थिरता अधिकृत और पृथक हो।
वर्कशीट में वाइल्डकार्ड स्वामी, अपेक्षित कवरेज, सटीक परीक्षण स्वामी, उत्तर, संस्करण पार्सिंग, गंतव्य-होस्ट सीमा और किरायेदार-पहुंच जांच की सूची होनी चाहिए। इसमें रोलबैक योजना और रिपोर्ट प्रोसेसिंग की सीमाएं भी दर्ज होनी चाहिए। अपेक्षित परिणाम तब तक डिज़ाइन परिकल्पनाएँ हैं जब तक कि वास्तविक परिबद्ध परीक्षण नहीं किए जाते; केवल इसलिए कि तर्क प्रशंसनीय है, उन्हें पारित करार नहीं दिया जाना चाहिए।
अनसुलझे मूल साक्ष्य और मुक्ति द्वार
कैटलॉग को सटीक प्राधिकरण स्वामी और उत्तर की आवश्यकता होती है, जिसमें एक सकारात्मक परीक्षण और एक अनधिकृत-गंतव्य परीक्षण शामिल है। वे मूल अवलोकन खुले रहते हैं। यह पांडुलिपि एक प्रस्तावित परीक्षण डिज़ाइन और काल्पनिक नाम प्रदान करती है, न कि एक कार्यशील वाइल्डकार्ड परिनियोजन या खाता-पहुँच मूल्यांकन।
एक सत्यापित परिचालन मार्गदर्शिका के रूप में प्रकाशन से पहले, एक योग्य समीक्षक को वास्तविक DNS प्रतिक्रियाओं का निरीक्षण करना चाहिए और पुष्टि करनी चाहिए कि नकारात्मक परीक्षण वास्तव में इच्छित प्राधिकरण सीमा को पार करता है। मूल साक्ष्य, मानव समीक्षा, स्रोत प्रयोज्यता, उत्पादन मार्ग, दृश्य पहुंच और मालिक की रिहाई खुली रहती है। इस कार्य के लिए कोई बाहरी संपर्क, रिपोर्ट अपलोड या DNS संशोधन नहीं किया गया।