प्रॉम्प्ट और संदर्भ
कंपनी अपने सेंडिंग डोमेन के लिए DNSSEC और TLSA रिकॉर्ड्स प्रकाशित करके SMTP STARTTLS डाउनग्रेड और मैन-इन-द-मिडिल (man-in-the-middle) जोखिम को कम करना चाहती है। प्रत्येक प्राप्तकर्ता DANE का समर्थन नहीं करता है, और सर्टिफिकेट नियमित रूप से रोटेट होते हैं। MX डिस्कवरी, TLSA वैलिडेशन, कम्पैटिबिलिटी फ़ॉलबैक, रोटेशन, मॉनिटरिंग और इंसिडेंट रोलबैक डिज़ाइन करें।
इंटरव्यूअर क्या जांच रहा है
- यह समझना कि SMTP DANE केवल सर्टिफिकेट अथॉरिटी (CA) पर नहीं, बल्कि DNSSEC, MX टारगेट और TLSA पर निर्भर करता है।
- ऑपर्च्युनिस्टिक DANE, एनफ़ोर्स्ड TLSA, MTA-STS और TLS रिपोर्टिंग के बीच अंतर करना।
- TLSA जनरेशन, TTL, सर्टिफिकेट रोटेशन और DNSSEC विफलता प्रबंधन को डिज़ाइन करना।
- कैनरी में डिलीवरी सफलता, डाउनग्रेड, वैलिडेशन विफलता और प्राप्तकर्ता कम्पैटिबिलिटी को शामिल करना।
पहले स्पष्ट करने योग्य प्रश्न
- क्या आप सेंडिंग डोमेन, रिसीविंग डोमेन, या दोनों की सुरक्षा कर रहे हैं? क्या सेंडिंग MTA साथियों (peers) को वैलिडेट करता है?
- क्या DNSSEC चेन, रिज़ॉल्वर और कैश व्यवहार विश्वसनीय हैं?
- कितने प्रतिशत प्राप्तकर्ता DANE, MTA-STS, या केवल STARTTLS का समर्थन करते हैं?
- क्या सर्टिफिकेट CA-जारी किए गए हैं या सेल्फ-साइंड हैं, और रोटेशन तथा रोलबैक विंडो क्या हैं?
- विफलता पर, क्या डिलीवरी में देरी (delay) की जा सकती है, या इसे प्लेनटेक्स्ट पर फ़ॉलबैक करना होगा?
30-सेकंड का उत्तर ढांचा
सेंडिंग MTA MX को रिज़ॉल्व करता है, DNSSEC के माध्यम से TLSA को वैलिडेट करता है, और TLSA उपयोग (usage), सेलेक्टर, मैचिंग प्रकार और एसोसिएशन डेटा का उपयोग करके पीयर सर्टिफिकेट या की (key) की जांच करता है। DNSSEC विफलता या TLSA मिसमैच को सामान्य STARTTLS सफलता नहीं माना जाना चाहिए; नीति को डिलीवरी में देरी करनी चाहिए या उसे अस्वीकार करना चाहिए। ऑब्जर्वेशन मोड में शुरुआत करें, डोमेन को कैनरी करें, MTA-STS को TLS रिपोर्ट के साथ संयोजित करें, और ओवरलैपिंग रिकॉर्ड्स तथा एक रोलबैक विंडो के साथ रोटेट करें।
चरण-दर-चरण विस्तृत उत्तर
चरण 1: प्रोटोकॉल पाथ को ट्रेस करें
प्रेषक प्राप्तकर्ता डोमेन के MX रिकॉर्ड से ट्रांसपोर्ट होस्ट प्राप्त करता है और STARTTLS पर बातचीत (negotiate) करता है। DANE डोमेन, पोर्ट और टारगेट सर्टिफिकेट या की को बाइंड करने के लिए DNSSEC-संरक्षित TLSA रिकॉर्ड्स का उपयोग करता है। यह MX नाम को सर्टिफिकेट नाम के रूप में नहीं मानता है और न ही TLS हैंडशेक और होस्टनेम नियमों को बायपास करता है।
चरण 2: TLSA सेमांटिक्स चुनें
TLSA सर्टिफिकेट यूसेज, सेलेक्टर और मैचिंग प्रकार यह परिभाषित करते हैं कि क्या मैच किया जाएगा। एक रिकॉर्ड पूर्ण सर्टिफिकेट, SubjectPublicKeyInfo, या डाइजेस्ट से मेल खा सकता है। एक ढीला विकल्प रोटेशन को आसान बनाता है; एक सख्त विकल्प मजबूत नियंत्रण प्रदान करता है। रिकॉर्ड्स को वास्तविक परिनियोजन (deployment) चेन का प्रतिनिधित्व करना चाहिए और केवल एक मौजूदा फ़िंगरप्रिंट की प्रतिलिपि बनाने के बजाय एक बैकअप की का ध्यान रखना चाहिए।
चरण 3: DNSSEC और TTL डिज़ाइन करें
पैरेंट ज़ोन से TLSA तक DNSSEC चेन को सत्यापित करें और सिग्नेचर समाप्ति, DS परिवर्तनों और रिज़ॉल्यूशन त्रुटियों की निगरानी करें। TTL रोटेशन प्रसार और रिवोकेशन गति को नियंत्रित करता है, इसलिए आवश्यक विंडो के लिए रिकॉर्ड्स को ओवरलैप करें। रिज़ॉल्वर या कैश दोषों के बाद झूठे डाउनग्रेड से बचने के लिए DNSSEC विफलता, SERVFAIL और NXDOMAIN को "no TLSA" से अलग करें।
चरण 4: कम्पैटिबिलिटी नीति बनाएं
DANE-सक्षम गंतव्यों के लिए TLSA को वैलिडेट करें। दूसरों के लिए, MTA-STS, साधारण STARTTLS, या कतारबद्ध (queueing) करने के लिए एक डोमेन नीति लागू करें। एनफोर्समेंट को चुपचाप प्लेनटेक्स्ट पर फ़ॉलबैक नहीं होना चाहिए। विफलता का कारण, गंतव्य, DNSSEC स्थिति और पुनः प्रयास (retry) समय को एक सामान्य कनेक्शन त्रुटि के बजाय कतार और TLS रिपोर्ट में दर्ज करें।
चरण 5: सर्टिफिकेट और कीज़ को रोटेट करें
नए और पुराने TLSA रिकॉर्ड्स प्रकाशित करें, नया सर्टिफिकेट या की तैनात करें, TTL और ऑब्जर्वेशन विंडो की प्रतीक्षा करें, फिर पुराने रिकॉर्ड को हटा दें। हर चरण में कई रिज़ॉल्वरों और MTAs से दृश्यता (view) सत्यापित करें। डाइजेस्ट मिलान के लिए, टूल, एल्गोरिदम और इनपुट रिकॉर्ड करें। एक असफल रोटेशन पुराने रिकॉर्ड्स और पुराने सर्टिफिकेट दोनों को पुनर्स्थापित करता है।
चरण 6: कैनरी और ऑब्जर्वेशन
ऑब्जर्वेशन मोड में आंतरिक या कम जोखिम वाले प्राप्तकर्ता डोमेन के साथ शुरुआत करें, फिर धीरे-धीरे एनफोर्स करें। डिलीवरी सफलता, TLSA मिलान, DNSSEC विफलताओं, सर्टिफिकेट मिसमैच, कतार की आयु और प्लेनटेक्स्ट डाउनग्रेड की निगरानी करें। TLS रिपोर्टों को एकत्रित और रिडैक्ट (redact) करें; प्राप्तकर्ता के पते या पूर्ण संदेश मेटाडेटा को किसी तीसरे पक्ष को न भेजें।
चरण 7: घटनाओं और रिकवरी का अभ्यास करें
समाप्त हो चुके DNSSEC सिग्नेचर, खराब TLSA प्रकाशन, समय से पहले सर्टिफिकेट रोटेशन, MX परिवर्तन, रिज़ॉल्वर विफलता और गैर-DANE साथियों का अभ्यास करें। एनफोर्समेंट को रोकें (freeze), कतार पुनः प्रयासों को बढ़ाएं, और DNS या सर्टिफिकेट्स को रोलबैक करें; केवल स्वतंत्र MTAs और कई सार्वजनिक रिज़ॉल्वरों द्वारा रिकवरी की पुष्टि के बाद ही अनफ़्रीज़ करें।
उच्च-गुणवत्ता वाला नमूना उत्तर
मैं MX, DNSSEC, TLSA और SMTP TLS को अलग-अलग देखने योग्य चरण बनाऊंगा: MX को रिज़ॉल्व करें, DNSSEC को वैलिडेट करें, फिर TLSA उपयोग, सेलेक्टर और मैचिंग प्रकार का उपयोग करके पीयर सर्टिफिकेट या की की जांच करें। DNSSEC विफलता या TLSA मिसमैच से डोमेन-नीति अस्वीकृति या कतारबद्ध होना चाहिए, कभी भी चुपचाप प्लेनटेक्स्ट नहीं। ऑब्जर्वेशन मोड में रोल आउट करें, कैनरी एनफोर्समेंट करें, और MTA-STS को TLS रिपोर्ट के साथ संयोजित करें। नए सर्टिफिकेट से पहले ओवरलैपिंग TLSA रिकॉर्ड्स प्रकाशित करें, TTL की प्रतीक्षा करें, फिर पुराने रिकॉर्ड को हटा दें। DNS और सर्टिफिकेट रोलबैक पथ बनाए रखें और सिग्नेचर समाप्ति, MX परिवर्तन तथा रिज़ॉल्वर विफलता का अभ्यास करें।
सामान्य गलतियाँ
- DANE को केवल एक CA जांच या MX-होस्टनेम जांच के रूप में मानना।
- DNSSEC वैलिडेशन विफल होने के बाद साधारण STARTTLS या प्लेनटेक्स्ट के साथ जारी रखना।
- प्रतिस्थापन सर्टिफिकेट तैनात करने से पहले पुराने TLSA रिकॉर्ड को हटाना।
- एक रिज़ॉल्वर और प्रेषक के साथ परीक्षण करना और कैश प्रसार को अनदेखा करना।
- TLS रिपोर्ट में प्राप्तकर्ता के पते और पूर्ण संदेश मेटाडेटा को शामिल करना।
फॉलो-अप प्रश्न और उत्तर
फॉलो-अप 1: DANE और MTA-STS में क्या अंतर है?
DANE DNSSEC और TLSA पर निर्भर करता है और उन MTAs के लिए उपयुक्त है जो DNSSEC को वैलिडेट करते हैं। MTA-STS HTTPS पर नीति प्रकाशित करता है और CA सर्टिफिकेट्स पर निर्भर करता है। वे सह-अस्तित्व में रह सकते हैं; एक को दूसरे के गुप्त फ़ॉलबैक के रूप में मानने के बजाय पीयर क्षमता और ऑपरेटिंग सीमा द्वारा चयन करें।
फॉलो-अप 2: क्या TLSA किसी पब्लिक की से मेल खाता है या सर्टिफिकेट से?
सेलेक्टर और मैचिंग प्रकार यह तय करते हैं। एक की या डाइजेस्ट सर्टिफिकेट-चेन परिवर्तनों के प्रति संवेदनशीलता को कम कर सकता है, लेकिन गलत डाइजेस्ट से बचने के लिए सटीक इनपुट, एल्गोरिदम और रोटेशन रिकॉर्ड को सुरक्षित रखें।
फॉलो-अप 3: क्या DNSSEC SERVFAIL के बाद डिलीवरी प्लेनटेक्स्ट पर वापस जा सकती है?
तब नहीं जब डोमेन नीति DANE की मांग करती है। देरी करें या अस्वीकार करें और अलर्ट भेजें। केवल एक स्पष्ट रूप से अनुमत कम्पैटिबिलिटी नीति ही दूसरा रास्ता चुन सकती है, और उसे डाउनग्रेड को रिकॉर्ड करना होगा।
फॉलो-अप 4: आप खराब TLSA प्रकाशन को कैसे रोलबैक करते हैं?
पुराने TLSA और सर्टिफिकेट को पुनर्स्थापित करें, आधिकारिक DNS, TTL कैश और कई रिकर्सिव रिज़ॉल्वरों के अभिसरण (converge) की प्रतीक्षा करें, फिर कतार फ़्रीज़ को छोड़ें। ऑडिट के लिए खराब रिकॉर्ड, प्रभावित डोमेन और रिकवरी समय रखें।
फॉलो-अप 5: आप कैसे साबित करेंगे कि कोई प्लेनटेक्स्ट डाउनग्रेड नहीं हुआ था?
प्रति गंतव्य डोमेन TLS नेगोशिएशन, TLSA स्थिति और डाउनग्रेड गणना रिकॉर्ड करें और समय-समय पर एक स्वतंत्र MTA से सत्यापित करें। प्लेनटेक्स्ट प्रयासों को उच्च-प्राथमिकता वाले अलर्ट के रूप में मानें और उन्हें TLS रिपोर्ट और डिलीवरी लॉग के साथ सुसंगत करें।