कम्पनीको DNS सर्भरले अपेक्षित निजी ठेगाना फर्काउँछ, तैपनि स्थानीय फर्वार्डिङ रिजोल्भरमार्फतको क्वेरी असफल हुन्छ। उत्तर अवस्थित छ, जसले माथिल्लो जोन र रेकर्ड आफैलाई बाहिर पार्छ। बाँकी रहन्छ त्यो चरण जहाँ रिजोल्भरले यो उत्तर ग्राहकलाई फर्काउने कि नगर्ने निर्णय गर्छ। यदि त्यो रिजोल्भर dnsmasq हो भने अस्वीकृति सम्भवतः पहिले नै लगमा छ।

उत्तर प्राप्त गर्नु र त्यसलाई फर्काउने छनोट गर्नु दुई फरक चरण हुन्।

दुवै रिजोल्भरमा उही नामको तुलना गर्नुहोस्

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

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

लक्षण होइन, अस्वीकृति पढ्नुहोस्

dnsmasq को stop-dns-rebind विकल्पले माथिबाट आउने र सर्त पूरा गर्ने निजी ठेगानाका उत्तरहरू अस्वीकार गर्छ र त्यसो गर्दा तिनलाई लगमा लेख्छ। यो सुरक्षा राम्रो कारणले छ: अचानक निजी ठेगानातर्फ जाने सार्वजनिक नाम नै क्लासिक rebinding आक्रमण हो। तर यो जानाजान निजी सेवासँग पनि ठोकिन्छ, र यही तपाईंको अवस्था हो।

केही परिवर्तन गर्नुअघि लगमा अस्वीकृति खोज्नुहोस्, किनकि सन्देशले संयन्त्रको नाम लिन्छ।

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

अपवाद एउटै डोमेनमा सीमित गर्नुहोस्

प्रमाणित डोमेनका लागि dnsmasq को पुस्तिकाले विश्वव्यापी स्विचको सट्टा डोमेन-सीमित अपवाद दिन्छ।

rebind-domain-ok=corp.example

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

rebinding पहिचानको अपवादले ठ्याक्कै एउटै काम गर्छ: त्यो डोमेनका उत्तरहरू जान दिन्छ।

यसले split-DNS फर्वार्डर कन्फिगर गर्दैन, न पुग्न नसकिने माथिल्लो स्रोतलाई पुग्न सकिने बनाउँछ र न फर्काइएको ठेगानासम्म मार्ग बनाउँछ। यीमध्ये प्रत्येक छुट्टै आवश्यकता हो जसको आफ्नै खराबी-चिह्न छ, र प्रत्येक ग्राहकमा फरक तरिकाले असफल हुन्छ।

सीमा नहटाई प्रमाणित गर्नुहोस्

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

अपवादको कारण कन्फिगरेसनको छेउमा, मिति र जिम्मेवार व्यक्तिसहित राख्नुहोस्।

निजी सेवा सरे वा डोमेन बदलिए पुनः जाँच्नुहोस्। सुरक्षा विश्वव्यापी रूपमा बन्द गर्दा असम्बन्धित उत्तरहरूको व्यवहार बदलिन्छ र rebinding कहिल्यै कारण नभए पनि मार्ग वा सेवाको खराबी जहाँको त्यहीं रहन्छ।

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