प्रॉम्प्ट
दसियों हज़ार हस्ताक्षरित ज़ोन होस्ट करने वाले प्लेटफ़ॉर्म के लिए एक DNSSEC की-रोलओवर कंट्रोल प्लेन डिज़ाइन करें। यह वैलिडेटिंग रिज़ॉल्वर को किसी टूटी हुई श्रृंखला के जोखिम में डाले बिना रजिस्ट्रार DS रिकॉर्ड, आधिकारिक DNS DNSKEY/RRSIG रिकॉर्ड और टेनेंट अनुमोदनों का समन्वय करता है।
परिदृश्य और बाधाएं
KSK और ZSK का जीवनकाल भिन्न होता है, रजिस्ट्रार API में देरी होती है और वे पुन: प्रयास योग्य होते हैं, और आधिकारिक नोड्स विभिन्न क्षेत्रों में फैले होते हैं। कंट्रोल प्लेन को इडेम्पोटेंट पुन: प्रयासों, प्रति-टेनेंट पॉज़, ऑडिट योग्य स्थिति परिवर्तनों और किसी एक चरण के अनिश्चित होने पर फ़ेल-क्लोज़्ड व्यवहार की आवश्यकता होती है।
यह क्या परीक्षण करता है
इसका मूल आधार स्टेट मशीन, समय के इनवेरिएंट्स, बाहरी साइड-इफ़ेक्ट ऑर्केस्ट्रेशन और ऑब्ज़र्वेबिलिटी है। मजबूत उत्तर DNSKEY प्री-पब्लिकेशन, DS पब्लिकेशन, पुरानी कुंजी की सेवानिवृत्ति और सिग्नेचर ओवरलैप में अंतर स्पष्ट करते हैं; केवल एक कुंजी उत्पन्न करना रोलओवर नहीं है।
संदर्भ दृष्टिकोण
प्रति-ज़ोन स्टेट मशीन को बनाए रखें: observe, prepublish, ds-submit, ds-visible, sign-with-both, retire-old, और verify। प्रत्येक संक्रमण पर वांछित संस्करण, ऑपरेशन टोकन, TTL बजट और साक्ष्य स्नैपशॉट रिकॉर्ड करें। नई DNSKEY को सभी आधिकारिक नोड्स पर प्रकाशित करें और इसके TTL की प्रतीक्षा करें, फिर रजिस्ट्रार के माध्यम से DS सबमिट करें। मूल DS के कई पुनरावर्ती रिज़ॉल्वर के माध्यम से दिखाई देने के बाद, एक सुरक्षा विंडो के लिए दोनों कुंजियों के साथ हस्ताक्षर करें, और उसके बाद ही पुराने DS और DNSKEY को हटाएं।
लीज़ के तहत एक समय में एक ज़ोन चलाएं। बाहरी कॉल इडेम्पोटेन्सी कुंजी और एक्सपोनेंशियल बैकऑफ़ का उपयोग करती हैं। SERVFAIL, DS/DNSKEY बेमेल, या समाप्त हो चुके RRSIG पर एक ज़ोन को फ़्रीज़ करें; पुरानी सामग्री को सुरक्षित रखें और मानव अनुमोदन का अनुरोध करें।
महत्वपूर्ण विवरण
डेटाबेस वांछित स्थिति को संग्रहीत करता है, जबकि DNS क्वेरी और रजिस्ट्रार रीडबैक सत्य के स्रोत हैं; विवादों को आँख बंद करके अधिलेखित नहीं किया जाना चाहिए। समय में आधिकारिक और पुनरावर्ती TTL, हस्ताक्षर वैधता और प्रसार मार्जिन शामिल हैं। निजी कुंजियों को नियंत्रित KMS स्टोरेज में रखें, और निजी सामग्री के बजाय फ़िंगरप्रिंट, की टैग, संस्करण और एक्टर्स को लॉग करें।
सामान्य गलतियाँ
टेनेंट्स के बीच एक रजिस्ट्रार ऑब्जेक्ट को समवर्ती रूप से बदलना; केवल आधिकारिक नोड्स की जांच करना न कि पैरेंट DS की; विफल चरण के तुरंत बाद पुरानी कुंजी को हटाना; कतार के पुन: प्रयासों को इडेम्पोटेन्सी मानना; और पॉज़ या मानव हस्तक्षेप के रास्तों को छोड़ देना।
मूल्यांकन मानदंड
मजबूत उत्तर कंट्रोल प्लेन, आधिकारिक DNS, रजिस्ट्रार, वैलिडेटिंग रिज़ॉल्वर और ऑडिट स्टोरेज के बीच सीमाओं को परिभाषित करते हैं; कम से कम तीन सुरक्षा इनवेरिएंट्स बताते हैं; और प्रत्येक स्थिति के लिए प्रवेश, निकास और रोलबैक शर्तों को निर्दिष्ट करते हैं। वे सफलता दर, SERVFAIL, प्रसार विलंबता और अटकी हुई लीज़ मेट्रिक्स का भी उल्लेख करते हैं।
फॉलो-अप प्रश्न
DS पब्लिकेशन आमतौर पर DNSKEY प्री-पब्लिकेशन के बाद क्यों होता है?
प्री-पब्लिकेशन आधिकारिक नोड्स और कैश को पहले नई DNSKEY प्राप्त करने की अनुमति देता है। पैरेंट DS तब ऐसी कुंजी की ओर इंगित कर सकता है जिसे सत्यापनकर्ता पुनर्प्राप्त कर सकते हैं, जिससे DS-दिखने/DNSKEY-गायब होने की विंडो कम हो जाती है।
जब कोई रजिस्ट्रार कॉल टाइम आउट हो जाती है लेकिन सफल हो सकती है, तो आप पुन: प्रयास कैसे करते हैं?
ज़ोन संस्करण और इडेम्पोटेन्सी टोकन का उपयोग करके रजिस्ट्रार के वर्तमान DS को पढ़ें, फिर निर्णय लें कि पुन: प्रयास करना है या नहीं। केवल एक टाइमआउट के आधार पर दूसरा अज्ञात परिवर्तन सबमिट न करें।
सिस्टम स्वचालित रूप से पुराने DS को कब हटा सकता है?
केवल तब जब नया DS लक्ष्य पुनरावर्ती-रिज़ॉल्वर सेट में दृश्यमान रहता है, RRSIG सत्यापन पास हो जाता है, और TTL तथा हस्ताक्षर विंडो नीति को पूरा करती हैं। अन्यथा ज़ोन फ़्रीज़ रहता है।