dnsmasq खाजगी DNS उत्तर टाकून देत आहे: कारण rebinding संरक्षण आहे का?

कंपनीचा DNS सर्व्हर अपेक्षित खाजगी पत्ता परत करतो, तरीही स्थानिक फॉरवर्डिंग रिझॉल्व्हरमार्फत केलेली क्वेरी अयशस्वी होते. उत्तर अस्तित्वात आहे, ज्यामुळे वरील झोन आणि रेकॉर्डच बाद होतो. राहते ती पायरी जिथे रिझॉल्व्हर हे उत्तर क्लायंटला परत द्यायचे की नाही हे ठरवतो. जर तो रिझॉल्व्हर dnsmasq असेल, तर नकार बहुधा आधीच लॉगमध्ये आहे.

उत्तर मिळवणे आणि ते परत देण्याची निवड करणे या दोन वेगळ्या पायऱ्या आहेत.

दोन्ही रिझॉल्व्हरवर त्याच नावाची तुलना करा

अ‍ॅप प्रत्यक्षात कोणता रिझॉल्व्हर वापरते आणि कोणते नेमके होस्टनाव विचारते ते लिहून ठेवा. नंतर वरील निकालाची तुलना त्याच नावासाठी फॉरवर्डिंग रिझॉल्व्हरच्या घटनेशी करा. वरून उत्तर न मिळणे, कॅशेमधील नकारात्मक उत्तर आणि लॉगमधील नोंदवलेला नकार यांना तीन वेगळ्या दुरुस्त्या लागतात.

थेट निदानात्मक क्वेरीत दिसणारा पत्ता हे सिद्ध करत नाही की अ‍ॅपला तो तिच्या नेहमीच्या मार्गाने मिळाला. दोन्ही क्वेरी वेगळ्या रिझॉल्व्हरकडून किंवा एकाच रिझॉल्व्हरकडून वेगळ्या धोरणांनुसार निघू शकतात. सिद्धांत मांडण्यापूर्वी दोन्ही निकाल लिहून ठेवा, कारण याच पायरीत एकाची जागा दुसऱ्याने घेतली जाते. तुलना हेच संपूर्ण निदान आहे.

लक्षण नाही, नकार वाचा

dnsmasq मधील stop-dns-rebind पर्याय वरून येणारी आणि अटी पूर्ण करणारी खाजगी पत्त्याची उत्तरे नाकारतो आणि तसे करताना ती लॉगमध्ये नोंदवतो. हे संरक्षण एका चांगल्या कारणासाठी आहे: अचानक खाजगी पत्त्याकडे जाणारे सार्वजनिक नाव हा क्लासिक rebinding हल्ला आहे. पण ते मुद्दाम खाजगी सेवेशीही टकरते, आणि हीच तुमची गोष्ट आहे.

काहीही बदलण्यापूर्वी लॉगमध्ये नकार शोधा, कारण संदेश यंत्रणेचे नाव सांगतो.

जर नकार नाही आणि वरून उत्तरही नाही, तर rebinding संरक्षण तुमची समस्या नाही, आणि ते बंद करणे हा असा बदल असेल जो काहीही सुधारत नाही आणि धोका वाढवतो. हे मूळ बिघाडापेक्षा वाईट आहे, कारण ते एक नियंत्रण काढून टाकते आणि दोष तसाच ठेवते. आधी ठोस लॉग ओळीची खात्री करा. मग ठरवा.

अपवाद एकाच डोमेनपुरता मर्यादित करा

सत्यापित डोमेनसाठी dnsmasq चे पुस्तिका जागतिक स्विचऐवजी डोमेन-मर्यादित अपवाद देते.

rebind-domain-ok=corp.example

वरील डोमेन केवळ उदाहरण आहे. तुम्ही प्रत्यक्षात चालवता तो प्रशासकीय डोमेन वापरा, आणि पर्याय लागू करण्यापूर्वी त्याची जुळणीची व्याप्ती समजून घ्या, कारण प्रत्यय नियम तुम्ही तपासलेल्या एका होस्टपेक्षा जास्त व्यापतो. राउटरचा कॉन्फिगरेशन जनरेटर तीच सेटिंग कच्च्या निर्देशाऐवजी स्वतःच्या नियंत्रणातून दाखवू शकतो. दोन्ही मार्ग ठीक आहेत जर अंतिम व्याप्ती हेतू असलेली असेल.

rebinding ओळखीतील अपवाद नेमके एक काम करतो: त्या डोमेनची उत्तरे जाऊ देतो.

तो split-DNS फॉरवर्डर कॉन्फिगर करत नाही, न दुर्गम वरचा स्रोत सुलभ करतो आणि न परत दिलेल्या पत्त्यापर्यंत मार्ग तयार करतो. यातील प्रत्येक स्वतंत्र गरज आहे जिचे स्वतःचे बिघाड-चिन्ह आहे, आणि प्रत्येक क्लायंटमध्ये वेगळ्या पद्धतीने अयशस्वी होते.

सीमा न काढता पडताळा

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

अपवादाचे कारण कॉन्फिगरेशनजवळ, तारीख आणि जबाबदार व्यक्तीसह ठेवा.

खाजगी सेवा हलली किंवा डोमेन बदलला तर तो पुन्हा तपासा. संरक्षण जागतिक पातळीवर बंद केल्यास असंबंधित उत्तरांची हाताळणी बदलेल आणि rebinding कधीच कारण नसले तरी मार्ग किंवा सेवेचा बिघाड तसाच राहील.