dnsmasq एक निजी DNS उत्तर गिरा रहा है: क्या वजह rebinding सुरक्षा है?

कंपनी का DNS सर्वर अपेक्षित निजी पता लौटाता है, और फिर भी स्थानीय फ़ॉरवर्डिंग रिज़ॉल्वर के ज़रिए क्वेरी विफल हो जाती है। उत्तर मौजूद है, जो ऊपरी ज़ोन और रिकॉर्ड को ही बाहर कर देता है। बचता है वह चरण जहाँ रिज़ॉल्वर तय करता है कि यह उत्तर क्लाइंट को लौटाना है या नहीं। अगर वह रिज़ॉल्वर dnsmasq है, तो अस्वीकृति संभवतः पहले से लॉग में है।

उत्तर प्राप्त करना और उसे लौटाने का चयन करना दो अलग चरण हैं।

दोनों रिज़ॉल्वर पर उसी नाम की तुलना करें

लिखें कि ऐप वास्तव में कौन-सा रिज़ॉल्वर इस्तेमाल करता है और कौन-सा सटीक होस्टनाम पूछता है। फिर ऊपरी परिणाम की तुलना उसी नाम के लिए फ़ॉरवर्डिंग रिज़ॉल्वर की घटना से करें। ऊपर से उत्तर न मिलना, कैश में रखा नकारात्मक उत्तर और लॉग में दर्ज अस्वीकृति तीन अलग सुधार मांगते हैं।

सीधी नैदानिक क्वेरी में दिखता पता यह साबित नहीं करता कि ऐप को वह अपने सामान्य रास्ते से मिला। दोनों क्वेरी अलग-अलग रिज़ॉल्वर से या एक ही रिज़ॉल्वर से अलग नीतियों के तहत निकल सकती हैं। सिद्धांत बनाने से पहले दोनों परिणाम लिख लें, क्योंकि इसी चरण में एक को दूसरे से बदल दिया जाता है। तुलना ही पूरा निदान है।

लक्षण नहीं, अस्वीकृति पढ़ें

dnsmasq का stop-dns-rebind विकल्प ऊपर से आने वाले शर्तें पूरी करने वाले निजी पते वाले उत्तरों को अस्वीकार करता है और ऐसा करते समय उन्हें लॉग में दर्ज करता है। यह सुरक्षा एक अच्छे कारण से मौजूद है: एक सार्वजनिक नाम जो अचानक निजी पते पर हल हो जाए, वही क्लासिक rebinding हमला है। लेकिन यह जानबूझकर निजी सेवा से भी टकराता है, और यही आपका मामला है।

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

अगर न अस्वीकृति है और न ऊपर से उत्तर, तो rebinding सुरक्षा आपकी समस्या नहीं है, और उसे बंद करना ऐसा बदलाव होगा जो कुछ ठीक नहीं करता और जोखिम बढ़ाता है। यह मूल खराबी से बदतर है, क्योंकि यह एक नियंत्रण हटा देता है और दोष छोड़ जाता है। पहले ठोस लॉग पंक्ति की पुष्टि करें। फिर तय करें।

अपवाद को एक ही डोमेन तक सीमित करें

सत्यापित डोमेन के लिए dnsmasq का मैनुअल वैश्विक स्विच के बजाय डोमेन-सीमित अपवाद देता है।

rebind-domain-ok=corp.example

ऊपर दिया डोमेन केवल उदाहरण है। वह प्रशासनिक डोमेन इस्तेमाल करें जो आप वास्तव में चलाते हैं, और विकल्प लागू करने से पहले उसका मिलान-दायरा समझें, क्योंकि प्रत्यय नियम परीक्षण किए गए एक होस्ट से ज़्यादा को कवर करता है। राउटर का कॉन्फ़िगरेशन जनरेटर वही सेटिंग कच्चे निर्देश के बजाय अपने नियंत्रण से दिखा सकता है। दोनों रास्ते ठीक हैं बशर्ते परिणामी दायरा वही हो जो आपका इरादा था।

rebinding पहचान से अपवाद ठीक एक काम करता है: उस डोमेन के उत्तरों को गुज़रने देता है।

यह split-DNS फ़ॉरवर्डर कॉन्फ़िगर नहीं करता, न दुर्गम ऊपरी स्रोत को सुलभ बनाता है और न लौटाए गए पते तक कोई मार्ग बनाता है। इनमें से हर एक अलग आवश्यकता है जिसका अपना विफलता-चिह्न है, और हर एक क्लाइंट में अलग तरह से विफल होता है।

सीमा हटाए बिना सत्यापित करें

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

अपवाद का कारण कॉन्फ़िगरेशन के साथ, तिथि और ज़िम्मेदार व्यक्ति के साथ रखें।

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