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 संपेपर्यंत थांबा।

प्रत्येक अधिकाराकडून उत्तर स्थिर असल्याची खात्री करा, आणि पुढील फरक सहज वर्गीकृत करता यावा म्हणून इच्छित दृश्य झोन दस्तऐवजात लिहा।