DKIM सत्यापन DNS के माध्यम से सार्वजनिक सत्यापन सामग्री पुनर्प्राप्त करने पर निर्भर करता है। एक हस्ताक्षर क्रिप्टोग्राफ़िक रूप से अच्छी तरह से बनाया जा सकता है, फिर भी प्रासंगिक लुकअप अनुपलब्ध होने पर अप्राप्य रहता है। कुंजियाँ बदलने या संदेश सामग्री बदलने से पहले DNS पथ और प्राप्तकर्ता के प्रयास के समय की जाँच करें।
किसी घटना के बाद एक सफल खोज उपयोगी पुनर्प्राप्ति साक्ष्य है, लेकिन यह स्थापित नहीं करता है कि असफल प्रयास के दौरान क्या हुआ था। मूल प्रमाणीकरण परिणाम, संदेश, टाइमस्टैम्प और किसी भी उपलब्ध रिज़ॉल्वर लॉग को सुरक्षित रखें। इसका उद्देश्य रिसीवर के बुनियादी ढांचे में दृश्यता का दावा किए बिना देखी गई विफलता की व्याख्या करना है जो आपके पास नहीं है।
सटीक लुकअप और परिणाम स्थापित करें
प्रभावित से डी और एस पढ़ें DKIM-Signature और निर्माण करें चयनकर्ता d की _domainkey के अंतर्गत लुकअप करें। अंतर्गत RFC 6376 §3.6.2.1 और RFC 1034 §3.6.2, यदि समर्थित सेटअप का उपयोग करता है CNAME, श्रृंखला और अंतिम सत्यापन उत्तर कैप्चर करें। जहां उपलब्ध हो वहां प्रतिक्रिया कोड, समय, रिज़ॉल्वर और आधिकारिक सर्वर शामिल करें।
RFC 6376 §6.1.2 उस क्वेरी को अलग करता है जो प्रतिक्रिया देने में विफल रहती है और उस कुंजी रिकॉर्ड से अलग करती है जो मौजूद नहीं है। पहले वाले से TEMPFAIL और बाद का प्रयास प्राप्त हो सकता है; बाद वाले को उस हस्ताक्षर के लिए एक बिना कुंजी वाले PERMFAIL की आवश्यकता होती है। RFC 8601 §2.7.1 temperror इसी तरह एक संभावित क्षणिक सत्यापन त्रुटि का भी वर्णन करता है। सभी DNS-संबंधी विफलताओं को एक गुम-रिकॉर्ड निदान में न बदलें।
विचारों को बढ़ा-चढ़ाकर बताए बिना उनकी तुलना करें
आधिकारिक क्षेत्र और प्रतिनिधि पुनरावर्ती रिज़ॉल्वर की जाँच करें। कोई अंतर पुराने कैश्ड डेटा, डेलिगेशन विसंगतियों या DNS पथ के हिस्से तक पहुंचने में समस्या की ओर इशारा कर सकता है। यदि कोई प्रदाता-प्रबंधित लक्ष्य शामिल है, तो उस लक्ष्य के साथ-साथ ग्राहक-नियंत्रित उपनाम की भी जांच करें।
केवल त्रुटि लेबल में से किसी एक को चुनने के बजाय संभावित कारणों के लिए साक्ष्य रिकॉर्ड करें। उदाहरण के लिए, एक रिज़ॉल्वर की SERVFAIL और अधिक निदान की आवश्यकता है; यह इस बात का प्रमाण नहीं है कि कुंजी हटा दी गई थी। DNSSEC सत्यापन (देखें) RFC 4035 §5.5), प्रतिनिधिमंडल और परिवहन समस्याओं के लिए DNS ऑपरेटर के लॉग और विशेषज्ञता की आवश्यकता हो सकती है। केवल एक लुकअप को सफल बनाने के लिए सत्यापन को डिफ़ॉल्ट समाधान के रूप में अक्षम न करें।
समय-आधारित उदाहरण का अनुसरण करें
उदाहरणात्मक क्रम: एक रिसीवर 10:00 बजे active1._domainkey.sender.example को पुनः प्राप्त करने का प्रयास करता है और एक अस्थायी कुंजी पुनर्प्राप्ति त्रुटि की रिपोर्ट करता है। 10:05 पर, एक व्यवस्थापक एक अलग रिज़ॉल्वर से एक वैध कुंजी पुनर्प्राप्त करता है। दोनों अवलोकन सत्य हो सकते हैं। दूसरा उस क्वेरी के लिए 10:05 पर उपलब्धता स्थापित करता है, पहले रिसीवर के लिए पांच मिनट पहले उपलब्धता नहीं।
इसके विपरीत, यदि घटना के समय आधिकारिक उत्तर यह स्थापित करता है कि सक्रिय चयनकर्ता अनुपस्थित है, तो क्षणिक आउटेज के साफ़ होने की प्रतीक्षा करने से कॉन्फ़िगरेशन समस्या का समाधान नहीं हो सकता है। यदि रिकॉर्ड पुनर्स्थापित किया जाता है, तो नकारात्मक कैशिंग नीचे आती है RFC 2308 §5 जब अन्य रिज़ॉल्वर इसका निरीक्षण करते हैं तो यह भी प्रभावित हो सकता है। उदाहरण एक डायग्नोस्टिक टाइमलाइन है, न कि मापा गया आउटेज या वादा किया गया पुनर्प्राप्ति अंतराल।
पुनर्प्राप्ति के बाद शेष सत्यापन की जाँच करें
अगले RFC 6376 §6.1.2 और RFC 6376 §6.1.3, एक बार कुंजी पुनर्प्राप्ति कार्य करने के बाद, पुष्टि करें कि लौटाया गया रिकॉर्ड प्रयोग करने योग्य है और हस्ताक्षरकर्ता से मेल खाता है। पुनर्प्राप्त कुंजी अभी भी निरस्त, विकृत या असंगत हो सकती है। एक मिलान कुंजी हस्ताक्षर करने के बाद संशोधित सामग्री की भरपाई नहीं कर सकती है। घटना रिकॉर्ड में लुकअप, कुंजी सत्यापन, बॉडी-हैश सत्यापन और हस्ताक्षर सत्यापन को अलग-अलग चरणों के रूप में रखें।
जब कई हस्ताक्षर मौजूद होते हैं, तो एक असफल लुकअप आवश्यक रूप से प्रत्येक संरेखित प्रमाणीकरण पथ को नहीं हटाता है। अंतर्गत RFC 9989 §5.3.5, अन्य हस्ताक्षरों का निरीक्षण करें और SPF निष्कर्ष निकालने से पहले DMARC असफल। अंतर्गत RFC 6376 §6.3 और RFC 9989 §5.4, रिसीवर डिलीवरी नीति एक और अलग निर्णय है; एक क्षणिक DKIM समस्या स्थगन या स्वीकृति की गारंटी नहीं देती है।
नियंत्रित परीक्षणों के साथ आउटेज को बंद करें
DNS ऑपरेटर की अधिकृत मरम्मत के बाद, प्रासंगिक दृश्यों के माध्यम से प्रभावित लुकअप का परीक्षण करें और मूल मार्ग के माध्यम से नए संदेश भेजें। अपेक्षित और देखे गए परिणाम रिकॉर्ड करें। जब कारण आपके प्रशासनिक दायरे से बाहर हो तो DNS और प्रदाता घटना साक्ष्य के लिए पूछें।
प्रत्यायोजित चयनकर्ता लक्ष्यों और उनके स्वामियों की एक सूची रखें ताकि अगला अलर्ट सही टीम तक पहुंचे। निर्भरता की निगरानी करें जो वास्तव में विफल रही, लेकिन निगरानी के दायरे का ईमानदारी से वर्णन करें: एक आवधिक सार्वजनिक क्वेरी प्रत्येक रिसीवर के कैश, नेटवर्क या सत्यापन व्यवहार को पुन: उत्पन्न नहीं करती है। क्लोजर में यह बताया जाना चाहिए कि क्या बरामद हुआ, कौन से सबूत निदान का समर्थन करते हैं और क्या अनदेखा रह गया है।
एक बंधा हुआ निष्कर्ष सुरक्षित रखें
10:00 विफलता और 10:05 सफलता को दो रिकॉर्ड के रूप में रखें, प्रत्येक रिज़ॉल्वर, क्वेरी नाम, परिणाम और दृश्यता सीमा के साथ। पाँच मिनट का अंतराल उदाहरणात्मक है, पुनर्प्राप्ति लक्ष्य नहीं। DNS टीटीएल एक नवीनता अंतराल है, वैश्विक निरस्तीकरण की समय सीमा नहीं: RFC 8767 §4 अर्हक बासी उपयोग की अनुमति देता है। कोई रिज़ॉल्वर आउटेज, पुनर्प्राप्ति या मेल परीक्षण नहीं मापा गया।