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 क्लायंट कॅशे मोकळा करतो आणि दुसरे काहीही नाही। ते ब्राउझरची खाजगी स्थिती वर्णन करत नाही आणि अपस्ट्रीम सर्व्हर मोकळा करत नाही, म्हणून त्यावर आधारित चाचणी केवळ संकुचितपणे अर्थ लावता येते। निकाल कळवताना तुम्ही कोणता कॅशे मोकळा केला ते सांगा।
नंतर नवीन विनंती आणि इच्छित रिझॉल्व्हर धोरण सक्रिय ठेवून प्रत्यक्ष अनुप्रयोगाची पुन्हा चाचणी करा। वेगळ्या धोरणाखाली तयार झालेला निकाल हस्तांतरित होत नाही।