नेमसर्वर बदलने के बाद हर कंट्रोल पैनल में माइग्रेशन सफल दिख सकता है, फिर भी वेबसाइट तक पहुँचना संभव नहीं होता। डोमेन सक्रिय होता है, नए प्राधिकृत नेमसर्वर अपेक्षित IP पता लौटा रहे होते हैं और वेब सर्वर में कोई बदलाव नहीं हुआ होता। इसके बावजूद DNSSEC सत्यापन करने वाले DNS रिज़ॉल्वर SERVFAIL लौटाते हैं। अक्सर इसका कारण DNSSEC डेलिगेशन होता है, जो अब भी पुराने DNS ऑपरेटर की साइनिंग कुंजी पर भरोसा कर रहा होता है।
इस जाँच के आधार बने मामले में सामान्य DNS क्वेरी विफल हो रही थीं, जबकि DNSSEC सत्यापन को बायपास करने पर वही क्वेरी सफल थीं। पैरेंट ज़ोन में पुराना DS रिकॉर्ड अब भी प्रकाशित था, लेकिन नया प्राधिकृत DNS ज़ोन शुरुआत में साइन नहीं किया गया था। उससे मेल खाने वाली कुंजी उपलब्ध कराने और नए ज़ोन को साइन करने के बाद जिन रिज़ॉल्वर पर परीक्षण किया गया, उनमें सत्यापित जवाब फिर मिलने लगे। इसका सबक यह नहीं है कि DNSSEC बंद कर देना चाहिए; अहम बात यह है कि नेमसर्वर बदलना और DNSSEC की भरोसे की शृंखला को स्थानांतरित करना दो अलग-अलग काम हैं।
A रिकॉर्ड सही होने पर भी SERVFAIL क्यों आता है?
DNS दो अलग सवालों का जवाब देता है। A रिकॉर्ड बताता है कि किसी नाम से कौन-सा IPv4 पता जुड़ा है। DNSSEC बताता है कि सत्यापन करने वाला रिज़ॉल्वर उस जवाब पर भरोसा कर सकता है या नहीं। पते की जानकारी सही होना अपने आप में DNSSEC की भरोसे की शृंखला के सही होने की गारंटी नहीं है।
DNSSEC से साइन किए गए डोमेन में भरोसे की शृंखला विश्वसनीय पैरेंट ज़ोन से शुरू होकर DS (Delegation Signer) रिकॉर्ड के ज़रिए चाइल्ड ज़ोन की DNSKEY तक जाती है। चाइल्ड ज़ोन अपने DNS डेटा के डिजिटल हस्ताक्षर (RRSIG रिकॉर्ड) प्रकाशित करता है। DS रिकॉर्ड में उस अधिकृत DNSKEY की पहचान करने वाला डाइजेस्ट होता है। यह न तो A रिकॉर्ड है, न प्राइवेट कुंजी की कॉपी और न ही सामान्य ज़ोन-फ़ाइल एडिटर की कोई सेटिंग।
प्राधिकृत नेमसर्वर बदलने के बाद भी पैरेंट ज़ोन पुराने साइनर से संबंधित DS रिकॉर्ड प्रकाशित करता रह सकता है। यदि नए ज़ोन में उससे मेल खाने वाली DNSKEY और हस्ताक्षर नहीं हैं, तो सत्यापन करने वाला रिज़ॉल्वर भरोसे की शृंखला पूरी नहीं कर सकता। आम तौर पर वह जवाब को अमान्य मानकर बिना सत्यापन वाला पता देने के बजाय SERVFAIL लौटाता है।
यह HTTP आउटेज से अलग समस्या है: संभव है कि अनुरोध वेब सर्वर तक पहुँचे ही नहीं। यह TLS सर्टिफ़िकेट की अवधि समाप्त होने जैसी समस्या भी नहीं है। DNSSEC, DNS डेटा का सत्यापन करता है; HTTPS बाद में ब्राउज़र और सर्वर के बीच बनने वाले कनेक्शन को सुरक्षित करता है।
DNSSEC की समस्या और गायब रिकॉर्ड के बीच अंतर कैसे पहचानें
सबसे उपयोगी जाँच में उसी रिज़ॉल्वर से उसी नाम के लिए दो बार क्वेरी की जाती है। पहले सामान्य क्वेरी चलाएँ और केवल जवाब नहीं, उसका स्टेटस भी देखें:
dig example.com A +noall +comments +answerफिर DNSSEC Checking Disabled (CD) बिट सेट करके वही क्वेरी दोहराएँ:
dig example.com A +cdflag +noall +comments +answerदेखी गई विफलता में सामान्य क्वेरी पर SERVFAIL आया, जबकि CD बिट के साथ अपेक्षित A रिकॉर्ड मिला। इस अंतर से मज़बूती से संकेत मिला कि समस्या DNS रिकॉर्ड के गायब होने या एप्लिकेशन के जवाब न देने के बजाय DNSSEC सत्यापन में थी। +cdflag विकल्प, इसका समर्थन करने वाले रिकर्सिव रिज़ॉल्वर से अनुरोध करता है कि वह उस क्वेरी के लिए अपना सामान्य DNSSEC सत्यापन न करे। यह समस्या की पहचान करने का तरीका है; इससे ब्राउज़र में खराबी ठीक नहीं होती और न ही आगंतुकों के लिए DNSSEC बंद होता है।
+short से खाली आउटपुट मिलने पर जल्दबाज़ी में निष्कर्ष न निकालें। इस फ़ॉर्मैट में रिकॉर्ड न मिलने पर भी आउटपुट खाली दिख सकता है और SERVFAIL आने पर भी। जाँच के दौरान +comments रखें, ताकि status: SERVFAIL और status: NOERROR स्पष्ट दिखें।
सिर्फ़ CD तुलना से यह पता नहीं चलता कि DNSSEC का कौन-सा हिस्सा विफल हुआ है; यह अगले चरण की जाँच की दिशा बताती है। रिज़ॉल्वर में अस्थायी अपस्ट्रीम त्रुटि भी हो सकती है, इसलिए ज़रूरत पड़ने पर परीक्षण दोहराएँ और पैरेंट डेलिगेशन की जाँच करें।
केवल DNS एडिटर नहीं, पैरेंट ज़ोन का DS रिकॉर्ड भी जाँचें
डोमेन के DS रिकॉर्ड देखें:
dig example.com DS +noall +comments +answerडेलिगेशन का पूरा रास्ता अधिक विस्तार से देखने के लिए सीधे DNS पदानुक्रम से क्वेरी करें:
dig +trace example.com DSसटीक प्राधिकृत पैरेंट नेमसर्वर शीर्ष-स्तरीय डोमेन के अनुसार अलग होगा। ज़रूरी जानकारी वह DS रिकॉर्ड सेट है जो वास्तव में पैरेंट ज़ोन प्रकाशित करता है, न कि केवल DNS होस्टिंग डैशबोर्ड का सारांश। डोमेन रजिस्ट्रार बदला जा सकता है और नेमसर्वर वही रह सकते हैं; इसी तरह रजिस्ट्रार बदले बिना भी नेमसर्वर बदले जा सकते हैं। दोनों ही स्थितियों में पैरेंट का DS सक्रिय प्राधिकृत ज़ोन के अनुरूप होना चाहिए।
DS रिकॉर्ड में चार महत्वपूर्ण फ़ील्ड होते हैं: की टैग, एल्गोरिदम, डाइजेस्ट टाइप और डाइजेस्ट। समस्या की जाँच में की टैग उपयोगी पहचान है, लेकिन अपने आप में यह प्रमाण नहीं कि DNSKEY मेल खाती है। डाइजेस्ट और एल्गोरिदम की जानकारी भी उस कुंजी के अनुरूप होनी चाहिए जो प्राधिकृत ज़ोन वास्तव में उपलब्ध कराता है।
इस मामले में निर्णायक स्थिति साफ़ थी: पैरेंट ज़ोन पुराने DNSSEC भरोसे से जुड़ी जानकारी प्रकाशित करता रहा, जबकि नए प्राधिकृत ज़ोन के इंटरफ़ेस के अनुसार साइनिंग निष्क्रिय थी। A रिकॉर्ड मौजूद थे और सत्यापन बायपास करने पर मिल रहे थे। एप्लिकेशन की कॉन्फ़िगरेशन बदलने या बार-बार वही A रिकॉर्ड संपादित करने से यह बेमेल स्थिति ठीक नहीं होती।
खराब DNSSEC डेलिगेशन को ठीक करने के दो तरीके
रिकवरी के दो वैध तरीके हैं। दोनों भरोसे की शृंखला में एक ही तरह के बेमेल को ठीक करते हैं, लेकिन संचालन पर इनके असर अलग होते हैं। सोच-समझकर एक तरीका चुनें; बिना वजह इनके बीच बार-बार न बदलें।
विकल्प 1: पुराना DS हटाकर कुछ समय बिना साइनिंग के चलाना
मौजूदा डोमेन रजिस्ट्रार से, या उसके समर्थित DNSSEC प्रबंधन इंटरफ़ेस के माध्यम से, पैरेंट ज़ोन से पुराना DS रिकॉर्ड हटवाएँ। जब पैरेंट सुरक्षित डेलिगेशन घोषित नहीं करता, तो सत्यापन करने वाले रिज़ॉल्वर बिना साइन किए गए चाइल्ड ज़ोन को अमान्य मानने के बजाय असुरक्षित अर्थात DNSSEC से अप्रमाणित मान सकते हैं। DNS काम करता रहता है, लेकिन उस डोमेन के लिए DNSSEC प्रमाणीकरण अस्थायी रूप से उपलब्ध नहीं रहता।
यदि पैरेंट DS रिकॉर्ड सेट को भरोसेमंद ढंग से बदलने का तरीका मौजूद है, तो आपात स्थिति में अक्सर यही सरल विकल्प होता है। पुराने DS रिकॉर्ड रिकर्सिव रिज़ॉल्वर के कैश से समाप्त होने तक मौजूदा साइनिंग कॉन्फ़िगरेशन स्थिर रखें। कंट्रोल पैनल से DS हटाने का संदेश अपने आप में पर्याप्त प्रमाण नहीं है: बाहर से पैरेंट रिकॉर्ड जाँचें और उसकी TTL अवधि का ध्यान रखें। HTTPS, DNSSEC सेटिंग से स्वतंत्र रहता है। इस अस्थायी बिना-साइनिंग वाले बदलाव का विवरण RFC 8078 में भी है।
विकल्प 2: नए ज़ोन को साइन करके उससे मेल खाने वाला DS प्रकाशित करना
दूसरा तरीका है नए प्राधिकृत DNS प्रदाता पर DNSSEC चालू करना, उसकी DNSKEY कुंजियाँ बनाना, ज़ोन को साइन करना और उससे संबंधित DS रिकॉर्ड पैरेंट ज़ोन में प्रकाशित करना। इसके बाद सत्यापन करने वाला रिज़ॉल्वर नई DNSKEY तक भरोसेमंद रास्ता बनाकर A रिकॉर्ड का सत्यापन कर सकता है।
इस मामले में वास्तव में रिकवरी इसी तरीके से हुई। DNS प्रबंधन इंटरफ़ेस ने बताया कि उसने कुंजियाँ बनाई हैं, ज़ोन को साइन किया है और नया DS प्रकाशित किया है। इसके बाद पैरेंट ज़ोन की क्वेरी में पुराने DS के साथ नया DS भी दिखा। DNSSEC सत्यापन करने वाले रिकर्सिव रिज़ॉल्वर अपेक्षित A रिकॉर्ड लौटाने लगे। बाद के एक परीक्षण में NOERROR के साथ ad फ़्लैग भी मिला, जो दर्शाता था कि उस रिज़ॉल्वर ने डेटा को प्रमाणित किया है।
यहाँ क्रम महत्वपूर्ण है: प्रकाशित DS तभी काम का है जब उससे मेल खाने वाली DNSKEY और वैध हस्ताक्षर प्राधिकृत DNS सेवा से पहले ही उपलब्ध हों। कंट्रोल पैनल में “प्रकाशित” दिखना बाहरी जाँच का विकल्प नहीं है। कैश में मौजूद DS, DNSKEY, RRSIG और NS रिकॉर्ड के कारण अलग-अलग रिज़ॉल्वर अलग-अलग समय पर फिर सही जवाब देने लग सकते हैं।
दो DS रिकॉर्ड होने पर भी साइट खराब क्यों नहीं रही?
एक चौंकाने वाला परिणाम यह था कि पैरेंट ज़ोन में कुछ समय तक पुराना DS और नया वैध DS, दोनों मौजूद थे, फिर भी DNSSEC सत्यापन सफल रहा। इसमें विरोधाभास नहीं है। DS रिकॉर्ड सेट में कई रिकॉर्ड हो सकते हैं, जैसा कुंजी बदलने के दौरान अक्सर होता है। सत्यापनकर्ता के लिए हर DS का वर्तमान में इस्तेमाल हो सकने वाली कुंजी की ओर इशारा करना ज़रूरी नहीं है। उसे केवल किसी उपयुक्त DS से DNSKEY और वैध हस्ताक्षरों तक पहुँचने वाला एक सही प्रमाणीकरण मार्ग चाहिए। RFC 6840 स्पष्ट करता है कि सत्यापनकर्ताओं को एक भी वैध मार्ग स्वीकार करना चाहिए।
इसका यह अर्थ नहीं कि पुराने रिकॉर्ड हमेशा बनाए रखना ठीक है। अप्रचलित DS से संचालन के दौरान अस्पष्टता बढ़ती है और नई भरोसे की शृंखला की पुष्टि हो जाने के बाद उसे हटाना चाहिए। लेकिन जब सत्यापित DNS क्वेरी पहले से सफल हैं, तब पुराने रिकॉर्ड की सफ़ाई एक रखरखाव का काम है, फिर से जोखिम भरा DNSSEC रीसेट करने का बहाना नहीं।
यहाँ कंट्रोल पैनल में एक ख़ास ख़तरा है: “आपात स्थिति में DS का प्रकाशन बंद करें” जैसा विकल्प नए, काम कर रहे DS समेत सभी DS रिकॉर्ड हटा सकता है। इसी तरह पैरेंट में DS प्रकाशित रहते हुए ज़ोन की साइनिंग बंद करना तुरंत फिर से आउटेज पैदा कर सकता है। इनमें से कोई भी कार्रवाई केवल एक अप्रचलित DS रिकॉर्ड हटाने के बराबर नहीं है। यदि इंटरफ़ेस अलग से किसी एक रिकॉर्ड को चुनने नहीं देता, तो सभी रिकॉर्ड रीसेट करने के बजाय रजिस्ट्रार द्वारा समर्थित चुनिंदा बदलाव कराएँ।
प्राधिकृत नेमसर्वर सुरक्षित तरीके से कैसे बदलें
सबसे सुरक्षित क्रम इस बात पर निर्भर करता है कि पुराना और नया DNS ऑपरेटर कुंजियों के प्रबंधन में समन्वय कर सकते हैं या नहीं। अस्थायी रूप से बिना DNSSEC साइनिंग के रहने वाले सामान्य माइग्रेशन में नीचे दिया क्रम इस मामले में सामने आए बेमेल से बचाता है:
- पहले नए ज़ोन को तैयार करें। आवश्यक A, AAAA, CNAME, MX, TXT और अन्य संबंधित रिकॉर्ड कॉपी करें। डेलिगेशन बदलने से पहले नए प्राधिकृत नेमसर्वरों से सीधे क्वेरी करके उनकी जाँच करें।
- पैरेंट ज़ोन में DNSSEC की स्थिति देखें। जाँचें कि DS रिकॉर्ड मौजूद हैं या नहीं और उन्हें कौन बदल सकता है। भले ही आपने स्वयं कभी DNSSEC चालू न किया हो, यह जाँच ज़रूर करें; कुछ DNS सेवाएँ साइनिंग अपने आप करती हैं।
- पुराना साइन किया हुआ ज़ोन चालू रहते हुए पुराना DS हटाएँ। प्राधिकृत पैरेंट पर बदलाव की पुष्टि करें, फिर पहले से कैश किए गए DS डेटा की अवधि समाप्त होने दें। इंतज़ार का समय किसी सार्वभौमिक तय मिनट संख्या से नहीं, देखी गई TTL अवधि से तय होगा।
- नेमसर्वर डेलिगेशन बदलें। पुराने प्राधिकृत DNS की सेवा चालू रखें, क्योंकि कैश में मौजूद NS डेलिगेशन अभी भी उसी की ओर इशारा कर सकते हैं। पैरेंट NS के TTL को ध्यान में रखें और जाँचें कि अलग-अलग रिज़ॉल्वर वास्तव में किन सर्वरों का इस्तेमाल कर रहे हैं।
- तय करें कि DNSSEC फिर चालू करना है या नहीं। यदि नया प्रदाता बिना साइनिंग के रहेगा, तो DS प्रकाशित न करें। यदि नया ज़ोन साइन करना है, तो मेल खाने वाला DS प्रकाशित करने से पहले पुष्टि करें कि नई DNSKEY और हस्ताक्षर सही ढंग से उपलब्ध हैं। पुराने NS कैश मौजूद रहने की स्थिति को ध्यान में रखकर यह बदलाव समन्वित करें, ताकि सत्यापन में फिर बेमेल न हो।
- स्वतंत्र रूप से सत्यापन करें। पैरेंट DS, प्राधिकृत DNSKEY, सामान्य रिकर्सिव रिज़ॉल्यूशन और सत्यापन करने वाले रिज़ॉल्वर से मिलने वाले प्रमाणित जवाब की जाँच करें।
यदि लगातार DNSSEC सुरक्षा बनाए रखना आवश्यक है, तो अस्थायी बिना-साइनिंग वाले चरण की जगह समन्वित कुंजी रोलओवर या मल्टी-साइनर माइग्रेशन बेहतर है। इसके लिए दोनों DNS ऑपरेटरों को आवश्यक कुंजियों और साइनिंग व्यवस्था का समर्थन करना होगा। पुराने DS डाइजेस्ट को बस नए प्रदाता के पास कॉपी कर देना रोलओवर नहीं है।
माइग्रेशन के बाद जाँच की संक्षिप्त सूची
DNSSEC से जुड़ा कोई भी बदलाव करने के बाद DNS रिकॉर्ड और इस बात के प्रमाण, दोनों जाँचें कि रिज़ॉल्वर उन्हें स्वीकार कर रहे हैं:
dig example.com DS +noall +comments +answer
dig example.com DNSKEY +dnssec +noall +comments +answer
dig example.com A +dnssec +noall +comments +answer
dig example.com A +cdflag +noall +comments +answerप्रमाणित जवाब जाँचने के लिए DNSSEC सत्यापन करने वाला रिकर्सिव रिज़ॉल्वर इस्तेमाल करें। उसके जवाब में NOERROR और अपेक्षित A रिकॉर्ड का मतलब है कि DNS रिज़ॉल्यूशन सफल रहा। इसके अलावा ad फ़्लैग होने पर रिज़ॉल्वर यह बता रहा होता है कि उसने अपनी DNSSEC नीति के अनुसार जवाब को प्रमाणित किया है। केवल ad फ़्लैग का न होना विफलता का प्रमाण नहीं है, क्योंकि रिज़ॉल्वर की क्षमताएँ, नीतियाँ और क्वेरी फ़्लैग अलग हो सकते हैं। आउटेज के दौरान किसी सत्यापन करने वाले रिज़ॉल्वर से DNSKEY क्वेरी विफल हो, तो जाँच के हिस्से के रूप में सक्रिय प्राधिकृत DNS सेवा से सीधे क्वेरी करें।
किसी एक रिज़ॉल्वर से सफल जवाब मिलते ही जाँच बंद न करें। अलग-अलग कैश में कुछ समय तक अलग डेलिगेशन और कुंजियाँ हो सकती हैं। यदि तकनीकी सहायता का अनुरोध खुला है, तो उसे भी अपडेट करें: सभी DS रिकॉर्ड हटाने का पहले दिया गया निर्देश, नया काम करने वाला DS प्रकाशित होने के बाद ख़तरनाक हो सकता है। अगले संदेश में स्पष्ट लिखें कि सक्रिय कुंजी सुरक्षित रखी जाए और ज़रूरत हो तो केवल अप्रचलित रिकॉर्ड हटाया जाए।
विफलता की वजह वेब सर्वर का ग़लत पता नहीं था। DNS जवाब देने वाले सर्वर बदल दिए गए थे, लेकिन रिज़ॉल्वर को यह बताने वाली भरोसे की जानकारी पहले से नए सेटअप के अनुरूप नहीं की गई थी कि किन जवाबों पर विश्वास करना है। इसलिए हर नेमसर्वर माइग्रेशन से पहले व्यावहारिक सवाल यह होना चाहिए: पैरेंट ज़ोन कौन-से DS रिकॉर्ड प्रकाशित कर रहा है, और क्या नए ज़ोन की DNSKEY तथा उसके हस्ताक्षर उन रिकॉर्ड के अनुरूप सत्यापन पूरा कर पाएँगे?