VPN का DNS गलत? एक आधिकारिक सर्वर पुराना हो सकता है

VPN से जुड़ें और एक होस्टनाम कल के पते पर हल हो जाता है, या किसी चीज़ पर नहीं। डिस्कनेक्ट करें और यह फिर काम करता है। स्वाभाविक प्रतिक्रिया उस रिज़ॉल्वर को दोष देना है जिसे सुरंग ने थोपा, पर अधिक सामान्य कारण एक प्रकाशित नाम सर्वर है जिसने ज़ोन अपडेट मिलना बंद कर दिया। नया रास्ता बस उस आधिकारिक स्रोत से अलग स्रोत तक पहुँचा जहाँ से आपका कैश किया उत्तर आया था।

लक्षण रिज़ॉल्वर के साथ बदलता है

एक पुनरावर्ती रिज़ॉल्वर वह लौटाता है जो किसी आधिकारिक स्रोत ने उसे बताया, फिर उस उत्तर को TTL तक रखता है। अगर सुरंग कोई दूसरा रिज़ॉल्वर थोपती है, या रास्ता ऐसे बदलती है कि पुराना पहुँच से बाहर हो जाए, तो क्लाइंट किसी दूसरे आधिकारिक स्रोत से पूछता है और दूसरा उत्तर पाता है। उस पल डोमेन नहीं बदला; उसके बारे में आपका दृष्टिकोण बदला।

इसीलिए एक ही नाम एक दफ़्तर में काम कर सकता है और होटल से विफल हो सकता है, और इसीलिए स्थानीय कैश साफ़ करना केवल कभी-कभी मदद करता है। कैश साफ़ करने से प्रश्न फिर उसी आधिकारिक स्रोत पर जाता है।

भेद करने वाली परीक्षा हर प्रकाशित सर्वर से सीधी क्वेरी है।

हर आधिकारिक स्रोत से सीधे पूछें

याद रखी सूची से नहीं, डेलिगेशन से शुरू करें। मूल से NS सेट पूछें, फिर उस सेट के हर नाम से वह रिकॉर्ड पूछें जिसकी आपको ज़रूरत है। एक ही नाम के लिए अलग-अलग आधिकारिक स्रोतों पर दो क्वेरी तुरंत बताती हैं कि ज़ोन सुसंगत है या नहीं।

dig +short NS example.com
dig @ns1.dns.example app.example.com A
dig @ns2.dns.example app.example.com A

ज़ोन के शिखर के NS रिकॉर्ड के लिए भी वही करें, क्योंकि मूल डेलिगेशन और ज़ोन का अपना NS सेट माइग्रेशन के बाद अलग हो सकते हैं। SOA पर क्रम संख्याएँ तुलना की अगली चीज़ हैं, और बहुत पीछे रह गया द्वितीयक सर्वर स्थानांतरण की समस्या है, उत्तर की नहीं।

उन क्वेरी को उस नेटवर्क से चलाएँ जो विफल होता है, केवल अपने डेस्क से नहीं।

इच्छित दृश्यों को टूटे दृश्यों से अलग करें

कुछ डोमेन जानबूझकर क्षेत्र या रिज़ॉल्वर समूह के अनुसार अलग उत्तर देते हैं, और विभाजित क्षितिज विन्यास एंटरप्राइज़ नेटवर्क में सामान्य हैं।

प्रश्न यह है कि अंतर प्रलेखित और स्थिर है या नहीं। अनिच्छित दृश्य अलग दिखता है: एक आधिकारिक स्रोत के पास ऐसा रिकॉर्ड है जो बाकियों को कभी नहीं मिला, या उसके पास वह नहीं है जो सब साझा करते हैं। RFC 2182 के चयन और परिनियोजन दिशानिर्देश आधिकारिक उपलब्धता को साझा ज़िम्मेदारी मानते हैं, और यहीं सही ढाँचा यही है। अतिरेक तभी मौजूद है जब हर प्रकाशित सर्वर इच्छित डेटा का उत्तर दे सके, केवल पोर्ट 53 पर कनेक्शन स्वीकार करे वह नहीं।

SERVFAIL उत्तर देने वाला सर्वर आत्मविश्वास से गलत उत्तर देने वाले की तुलना में अधिक आसानी से निदान किया जा सकता है।

माइग्रेशन वह उजागर करता है जो कैश ने छिपाया था

प्रदाता बदलते समय दो आधिकारिक स्थान बदलते हैं: मूल डेलिगेशन और ज़ोन के अपने NS रिकॉर्ड। दोनों को अद्यतन करना होता है, और दोनों अपने TTL के लिए कैश होते हैं। अगर कोई पुराना सर्वर चालू रहता है और पिछला ज़ोन परोसता रहता है, तो जिनके रिज़ॉल्वर उससे पूछते हैं वे कटओवर पूरा दिखने के बहुत बाद तक पुराना उत्तर पाते रहेंगे।

लंबे समय तक टिकने वाला कैश ठीक इसी स्थिति को छिपाता है। जो वर्कस्टेशन पूरा हफ़्ता काम करता रहा वह ऐसे रिज़ॉल्वर से बात कर रहा था जिसके पास नए आधिकारिक स्रोत का ताज़ा उत्तर था, जबकि पुराना बाकी सबको पुराना डेटा बाँटता रहा।

लैपटॉप पर रिज़ॉल्वर बदलने से केवल वही लैपटॉप ठीक होता है, और कुछ नहीं।

ज़ोन ठीक करें, रिज़ॉल्वर नहीं

पहचानें कि कौन से सर्वर ज़ोन के लिए आधिकारिक होने चाहिए, प्रबंधित ज़ोन या डेलिगेशन सुधारें ताकि उनमें से हर एक इच्छित डेटा परोसे, और अपनी योजना बनाई अतिरेकता बनाए रखें। एक VPN एग्रेस को अजीब उत्तर मिलने के कारण नाम सर्वर हटाने से उपलब्धता घटती है और असंगति अपनी जगह रहती है।

फिर दोनों नेटवर्क से सीधी क्वेरी दोबारा चलाएँ और जिस रिकॉर्ड को आपने बदला उसका TTL खत्म होने तक प्रतीक्षा करें।

पुष्टि करें कि उत्तर हर आधिकारिक स्रोत से स्थिर है, और इच्छित दृश्य को ज़ोन प्रलेखन में लिखें ताकि अगला अंतर आसानी से वर्गीकृत हो सके।