अंतर्गत नावे गळून न घेता विभाजित DNS ची चाचणी

सार्वजनिक resolver ला अंतर्गत नाव विचारल्यास ते नाव गळते आणि तुम्हाला चाचणी करायची होती ती नियमावली वगळली जाते। क्वेरी तुम्ही नियंत्रित न करता त्या सर्व्हरपर्यंत पोहोचते, उत्तर अशा नावाच्या जागेतून येते ज्याने ते कधीही पाहू नये होते, आणि निकाल विभाजित DNS काम करते की नाही याबद्दल काहीही सांगत नाही। विभाजित DNS ची चाचणी करणे म्हणजे एखादे अनुप्रयोग प्रत्यक्षात वापरत असलेल्या resolver मार्गाची चाचणी करणे। तो मार्ग ऑपरेटिंग सिस्टम निवडते, VPN प्रोफाइलमधील डोमेन यादी निवडते आणि कधीकधी ब्राउझर निवडतो।

दोन नावे निवडा आणि आधी दोन्ही उत्तरांचा अंदाज लावा

नेटवर्कच्या मालकाकडून एक दस्तऐवजीकृत अंतर्गत चाचणी नाव मागा आणि संस्थेबद्दल काहीही न सांगणारे साधे सार्वजनिक नाव निवडा। काहीही चालवण्यापूर्वी प्रत्येकासाठी काय व्हायला हवे ते लिहा: अंतर्गत नाव टनेलच्या resolver पर्यंत पोहोचून अंतर्गत पत्ता परत द्यायला हवा, तर सार्वजनिक नाव सिस्टम सामान्यतः वापरत असलेल्या resolver द्वारे सोडवले जायला हवे। हे दोन अंदाजच चाचणी आहेत, कारण त्यांच्याशिवाय कोणतेही उत्तर नंतर योग्य ठरवता येते। जोडी प्रत्येक वेळी तशीच ठेवा जेणेकरून पुढील तुलनेला अर्थ असेल।

उद्दिष्ट नियम नाही, प्रत्यक्ष अंमलात असलेले नियम तपासा। VPN कनेक्शनला जोडलेली डोमेन यादी कोणता प्रत्यय कोणत्या resolver कडे जाईल हे ठरवते, आणि त्या यादीतील टायपो विश्वासार्ह पण चुकीचे विभाजन निर्माण करतो। व्यवस्थापित उपकरणावर प्रशासकाचा निदान मार्ग वापरा, कारण स्थानिक अधिलिखिते पुढील तपासणीत धोरणाने रीसेट होऊ शकतात।

त्याच तिकिटात पाहिलेल्या उत्तराच्या शेजारी अंदाज लिहा। अंदाजाशिवाय चाचणी अयशस्वी होऊ शकत नाही, आणि अयशस्वी होऊ शकत नाही अशी चाचणी काहीही शिकवत नाही।

अनुप्रयोग वापरतो त्या मार्गाची चाचणी करा, तुम्ही निवडलेल्या एका सर्व्हरची नाही

resolver ला स्पष्टपणे नाव देणारी आज्ञा केवळ त्या resolver ची चाचणी करते, इतर काहीही नाही। ती अंतर्गत सर्व्हर उत्तर देतो का हे सांगते, जे उपयुक्त आहे, आणि अनुप्रयोग नाव तिथे पाठवतो का हे सांगत नाही। आधी नेहमीच्या मार्गाने चाचणी करा: अनुप्रयोग जसे करेल तसे अंतर्गत नाव सोडवा, नंतर तसेच सार्वजनिक नाव सोडवा। त्यानंतरच वर्तन कुठे वेगळे होते हे शोधण्यासाठी विशिष्ट सर्व्हरला विचारा।

ब्राउझर चित्र गुंतागुंतीचे करतात, कारण सुरक्षित DNS सेटिंग्ज सिस्टम resolver पूर्णपणे टाळू शकतात। स्वतःच्या एन्क्रिप्टेड resolver सह कॉन्फिगर केलेला ब्राउझर विभाजन कधीही पाहत नाही, आणि बिघाड तुटलेल्या VPN प्रोफाइलसारखा दिसतो। टनेल बदलण्यापूर्वी ती सेटिंग तपासा।

पुनर्संचयन हा प्रश्न असेल तर पुन्हा कनेक्ट केल्यानंतर शोध पुन्हा करा। पुन्हा कनेक्ट होण्यापूर्वीचे कॅश केलेले उत्तर योग्यरित्या पुनर्संचयित विभाजनाला वास्तविकतेपेक्षा चांगले किंवा वाईट दाखवू शकते।

केवळ यश किंवा अपयश नाही, उत्तराची श्रेणी नोंदवा

चारपैकी काय घडले ते लिहा: अंतर्गत पत्ता, सार्वजनिक पत्ता, नकारात्मक उत्तर, किंवा कालबाह्यता। प्रत्येकाचा अर्थ वेगळा आहे। अंतर्गत नावासाठी अंतर्गत पत्ता हे अपेक्षित यश आहे; अंतर्गत नावासाठी सार्वजनिक पत्ता क्वेरी टनेलबाहेर गेल्याचे सूचित करतो; अधिकृत सर्व्हरकडून नकारात्मक उत्तर राउटिंग दोषाकडे नव्हे तर गहाळ नोंदीकडे निर्देश करते; आणि कालबाह्यता पोहोचण्याची अडचण किंवा क्वेरी कधीही न मिळालेला resolver दर्शवते। यश आणि अपयश कृती करण्यासाठी खूप स्थूल आहेत।

नवीन क्वेरी नसल्याचे स्पष्टीकरण देण्यापूर्वी कॅश विचारात घ्या, कारण कॅशमधील नकारात्मक उत्तर अस्तित्वात नसलेल्या नावासारखेच दिसते। समर्थित नियंत्रणांद्वारे काहीही पुसण्यापूर्वी उत्तर कैद करा, कारण पहिले उत्तर हाच पुरावा आहे।

अंदाज न लावता दोन्ही शाखांचा अर्थ लावा

अंतर्गत नाव योग्यरित्या सोडवले जाते पण अनुप्रयोग अजूनही अपयशी ठरतो, तर resolver ने आपले काम केले आहे आणि पुढील संशयित संसाधनावरील मार्ग आणि परवानग्या आहेत। खाजगी नाव सार्वजनिक resolver पर्यंत पोहोचले असेल, तर त्या शोधाला विभाजन नियम लागू होत नाही, म्हणून नावाच्या जागेच्या मालकासोबत डोमेन यादी आणि कोणतेही ब्राउझर धोरण तपासा। या दोन शाखांचे मालक वेगळे आहेत, म्हणून तुम्ही कोणती पाहिली हे नोंदवणे काहीतरी तुटले असे नोंदवण्यापेक्षा अधिक महत्त्वाचे आहे।

रचना टिकवून सामायिक आउटपुटमधील संवेदनशील भाग अस्पष्ट करा: कोणते नावाचे जाग, कोणता नियम, कोणती उत्तर श्रेणी। resolver च्या उत्तरात अंतर्गत पत्ते आणि होस्टनावे असू शकतात, आणि तिकीट दोन्हींसाठी टिकाऊ घर आहे।

नंतर निकाल नावाच्या जागेच्या मालकाला तुम्ही पाहिलेल्या दोन श्रेणींसह आणि नावे काढून द्या। तो एका आठवड्याच्या अंदाजाऐवजी पाच मिनिटांचा संवाद आहे।