टनेल उठेको केही सेकेन्डपछि पृष्ठ खोल्नु DNS अब काम गर्छ भन्ने प्रमाण होइन, टिकटले सामान्यतया त्यसै भन्छ। त्यो अवलोकनमा केही पनि क्वेरी आवश्यक थिएन: नाम परिवर्तन अघि समाधान भइसकेको हुन सक्छ र टनेलले कहिल्यै नछोएको क्यासबाट पुनः प्रयोग भएको हुन सक्छ। दुई फरक परीक्षणले एउटै स्क्रिन उत्पादन गर्छन्।

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

पृष्ठ लोड गर्नु क्वेरी होइन

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

यो भिन्नताले अब तपाईंले के परीक्षण गर्नुपर्छ भन्ने परिवर्तन गर्छ। लक्ष्य नयाँ रिजोल्भरले जवाफ दिन्छ भनी देखाउनु हो भने, तपाईंले खाली नगरेको क्यासबाट सेवा गर्न नसकिने क्वेरी चाहिन्छ।

क्यास गरिएको सफलतालाई पहिले अप्राप्य सर्भर ठीक भयो भन्ने प्रमाणका रूपमा पढ्नु यो गल्तीको सबैभन्दा महँगो रूप हो, किनकि यसले घटनालाई झुटो आधारमा बन्द गर्छ।

निष्कर्ष निकाल्नु अघि क्यासहरू गन्नुहोस्

चार नाम दिन लायक छन्: अनुप्रयोगको आफ्नै समाधान, अपरेटिङ सिस्टमको क्लाइन्ट क्यास, ब्राउजरको आन्तरिक अवस्था, र क्वेरी अन्तमा पुग्ने कुनै पनि पुनरावृत्त रिजोल्भर। प्रत्येकको अलग जीवनकाल र खाली गर्ने अलग तरिका छ। एउटा खाली गरेर अर्को परीक्षण गर्नु नै मानिसहरूले खाली गर्दा केही भएन भन्ने निष्कर्ष निकाल्ने तरिका हो। एउटा फ्लस आदेशले प्रश्न कहिल्यै टुंग्याउँदैन।

नकारात्मक जवाफहरू पनि क्यास हुन्छन्। हराएको भनी रिपोर्ट गरिएको नाम नेटवर्क सुधारेपछि पनि हराएको रहन सक्छ, जसलाई बिग्रिएको टनेलका रूपमा पढिन्छ जबकि त्यो अझै नसकिएको TTL हो। DNS विशिष्टता ले यो डेटा कसरी राख्ने र पुनः प्रयोग गर्ने भन्ने वर्णन गर्छ।

घटना लेख्नुहोस्, छाप होइन

तीनमध्ये के परिवर्तन भयो लेख्नुहोस्: रेकर्ड, रिजोल्भरसम्मको बाटो, वा क्लाइन्ट सेटिङ। रेकर्ड सम्पादन आफ्नै तालिकाअनुसार फैलिन्छ, रुट परिवर्तन पुनः जोड्दा लागू हुन्छ, र ब्राउजर सेटिङ त्यही ब्राउजरमा मात्र लागू हुन्छ। तिनीहरूलाई एउटै अघि-र-पछि बनाउनुले कसैले अडिट गर्न नसक्ने समयरेखा बनाउँछ।

समय, प्रयोग गरिएको रिजोल्भर र प्राप्त जवाफ लेख्नुहोस्, जवाफ नकारात्मक भएको अवस्थासमेत। त्यो अरू कसैले जाँच्न सक्ने तथ्य हो।

तुलना दुई पटक एउटै तरिकाले गर्नुहोस्

तपाईंले परीक्षण गर्न चाहेको क्यास खाली गर्नुहोस्, मूल अवलोकन राख्नुहोस्, अनि सकेसम्म धेरै स्मृति बेवास्ता गर्ने तरिकाले क्वेरी गर्नुहोस्। रिजोल्भरलाई स्पष्ट नाम दिनुले त्यो रिजोल्भरलाई के थाहा छ भन्छ; यसले अनुप्रयोगले कुन रिजोल्भर छान्थ्यो भन्ने बताउँदैन।

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

Windows मा, क्लाइन्ट क्यास फ्लसले DNS क्लाइन्ट क्यास खाली गर्छ र अरू केही होइन। यसले ब्राउजरको निजी अवस्था वर्णन गर्दैन र अपस्ट्रिम सर्भर खाली गर्दैन, त्यसैले यसमा आधारित परीक्षणलाई साँघुरो रूपमा मात्र व्याख्या गर्न सकिन्छ। नतिजा रिपोर्ट गर्दा कुन क्यास खाली गर्नुभयो भन्नुहोस्।

त्यसपछि नयाँ अनुरोध र इच्छित रिजोल्भर नीति सक्रिय राखी वास्तविक अनुप्रयोग फेरि परीक्षण गर्नुहोस्। फरक नीतिअन्तर्गत उत्पादन गरिएको नतिजा सर्दैन।

सम्बन्धित लेखहरू