क्या VPN ने DNS ठीक किया, या सिर्फ़ कैश किया हुआ जवाब दोबारा इस्तेमाल किया?

टनल आने के कुछ सेकंड बाद पेज खोलना इस बात का सबूत नहीं है कि DNS अब काम करता है, हालाँकि टिकट आमतौर पर ऐसा ही कहता है। उस अवलोकन में कुछ भी क्वेरी की माँग नहीं करता था: नाम बदलाव से पहले हल हो सकता था और ऐसे कैश से दोबारा इस्तेमाल हुआ हो सकता है जिसे टनल ने कभी छुआ ही नहीं। दो अलग परीक्षण एक ही स्क्रीन बनाते हैं।

बदलाव को श्रेय देने से पहले तुलना करें कि हर परीक्षण ने असल में क्या अभ्यास किया।

पेज लोड करना क्वेरी नहीं है

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

यह अंतर बदलता है कि आगे आपको क्या परखना चाहिए। अगर लक्ष्य यह दिखाना है कि नया रिज़ॉल्वर जवाब देता है, तो आपको ऐसी क्वेरी चाहिए जिसे उस कैश से पूरा न किया जा सके जिसे आपने साफ़ नहीं किया।

कैश की गई सफलता को यह सबूत पढ़ना कि पहले अप्राप्य सर्वर ठीक हो गया, इस गलती का सबसे महँगा रूप है, क्योंकि यह घटना को झूठी धारणा पर बंद कर देता है।

नतीजा निकालने से पहले कैश गिनें

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

नकारात्मक जवाब भी कैश होते हैं। जिस नाम की गुम होने की सूचना दी गई थी, वह नेटवर्क ठीक होने के बाद भी गुम रह सकता है, जिसे टूटी टनल की तरह पढ़ा जाता है जबकि वह ऐसा TTL है जो खत्म नहीं हुआ। DNS विनिर्देश बताता है कि इस डेटा को कैसे रखा और दोबारा इस्तेमाल किया जाना चाहिए।

घटना लिखें, छाप नहीं

लिखें कि तीन में से क्या बदला: रिकॉर्ड, रिज़ॉल्वर तक का रास्ता, या क्लाइंट सेटिंग। रिकॉर्ड संपादन अपने समय-चक्र पर फैलता है, रूट बदलाव दोबारा जुड़ने पर लागू होता है, और ब्राउज़र सेटिंग सिर्फ़ उसी ब्राउज़र पर लागू होती है। उन्हें एक ही पहले-और-बाद में समेटने से ऐसी समयरेखा बनती है जिसका कोई ऑडिट नहीं कर सकता।

समय, इस्तेमाल किया गया रिज़ॉल्वर और मिला जवाब लिखें, उस स्थिति सहित जब जवाब नकारात्मक हो। यह ऐसा तथ्य है जिसे कोई और जाँच सकता है।

तुलना दो बार एक ही तरीके से करें

जिस कैश को आप परखना चाहते हैं उसे साफ़ करें, मूल अवलोकन रखें, और फिर ऐसे क्वेरी करें जो ज़्यादा से ज़्यादा स्मृति को बचा जाए। रिज़ॉल्वर का स्पष्ट नाम लेना आपको बताता है कि वह रिज़ॉल्वर क्या जानता है; यह नहीं बताता कि एप्लिकेशन कौन-सा रिज़ॉल्वर चुनता।

resolvectl flush-caches
ipconfig /flushdns
dig +noall +answer internal.example @10.44.0.53
dig +short internal.example

Windows पर, क्लाइंट कैश फ़्लश DNS क्लाइंट कैश साफ़ करता है और कुछ नहीं। यह ब्राउज़र की निजी स्थिति नहीं बताता और अपस्ट्रीम सर्वर साफ़ नहीं करता, इसलिए इस पर बना परीक्षण सिर्फ़ संकीर्ण रूप से समझा जा सकता है। नतीजा बताते समय कहें कि आपने कौन-सा कैश साफ़ किया।

फिर असली एप्लिकेशन को नई रिक्वेस्ट और इच्छित रिज़ॉल्वर नीति सक्रिय रखकर दोबारा परखें। अलग नीति के तहत बना नतीजा स्थानांतरित नहीं होता।