असली स्रोत खोजने के लिए DNS क्वेरी का कदम दर कदम पीछा करें
थोपा गया रिज़ॉल्वर पता यह तय नहीं करता कि रिज़ॉल्वर कौन सा स्रोत देखता है। क्लाइंट, फ़ॉरवर्डर और प्राप्त करने वाले सर्वर का पीछा करें, फिर पथ लिखें।
किसी क्लाइंट को रिज़ॉल्वर पता देना यह तय करता है कि क्वेरी कहाँ जाती हैं, यह नहीं कि रिज़ॉल्वर कौन सा स्रोत देखेगा। रूटिंग, फ़ॉरवर्डिंग और अनुवाद दोनों सिरों के बीच बारी-बारी से आते हैं। स्रोत से जुड़े सवालों की रनबुक क्वेरी का कदम दर कदम पीछा करती है और दर्ज करती है कि हर पर्यवेक्षक ने वास्तव में क्या देखा। क्रम मायने रखता है, क्योंकि अवलोकन से पहले कहा गया दावा केवल बेहतर स्वरूपण वाला अनुमान है।
साक्ष्य जुटाने से पहले व्यवस्था लिख लें
चार जगहें DNS स्रोत के बारे में कुछ बता सकती हैं और सब एक जैसा नहीं कहतीं। क्लाइंट का कर्नेल जानता है कि वह कौन सा स्रोत इस्तेमाल करेगा, फ़ॉरवर्डर जानता है कि उसने ऊपर क्या भेजा, अनुवाद करने वाला उपकरण जानता है कि उसने क्या दोबारा लिखा, और प्राप्त करने वाला रिज़ॉल्वर जानता है कि क्या पहुँचा। कुछ भी जुटाने से पहले लिखें कि इनमें से किन तक आप वास्तव में पहुँच सकते हैं।
| Observation point | What it can prove | What it cannot prove | How to read it |
|---|---|---|---|
| client kernel | which source address it would use for that resolver | anything a device in between rewrote | ip route get against the resolver address |
| forwarder | that it sent an upstream query, and from which source | what the client originally asked for | its own log and its cache state |
| translating device | that a source was rewritten, and to what | whether the query was legitimate | NAT policy and its counters |
| receiving resolver | the address that actually arrived | which client behind that address asked | a scoped capture on port 53 |
अपनी अपेक्षा भी लिखें, उस रिज़ॉल्वर सहित जिसे आप उपयोग में मानते हैं। बँटा हुआ मार्ग क्वेरी को बिल्कुल कहीं और भेज सकता है, और कैश बिना किसी ऊपरी अदला-बदली के उत्तर दे सकता है, इसलिए केवल स्मृति में रखी धारणा पहले आश्चर्य तक नहीं टिकेगी। घोषित डिज़ाइन और देखे गए पथ को एक ही नोट के अलग-अलग स्तंभों में रखें; जब दोनों में मेल न हो, तो आपने वह सवाल ढूँढ लिया है जिसका पीछा करना उचित है।
जाँचें कि क्वेरी वास्तव में किस प्रक्रिया ने भेजी
क्लाइंट से शुरू करें: रिज़ॉल्वर पता, क्वेरी का नाम और समय दर्ज करें, फिर पुष्टि करें कि किस प्रक्रिया ने उसे भेजा। नीचे की पहली पंक्ति उस प्रक्रिया का नाम लेती है जो UDP सॉकेट रखती है, और यही वह जाँच है जिसका यह शीर्षक वादा करता है। यदि वह प्रक्रिया सिस्टम रिज़ॉल्वर के बजाय ब्राउज़र सहायक या कंटेनर रनटाइम है, तो बाकी निशान ऐसे पथ का वर्णन करता है जो किसी ने नहीं माँगा।
ss -tunp 'dport = :53'
dig @10.20.30.53 host.corp.example +noall +answer
ip route get 10.20.30.53कई इंटरफ़ेस वाले होस्ट पर, कहीं और देखने से पहले पता करें कि कर्नेल उस गंतव्य के लिए कौन सा स्रोत पता चुनता है। यह वह अंतिम बिंदु है जहाँ पथ पूरी तरह आपके नियंत्रण में है, और यही वह मान है जिसकी तुलना आप रिज़ॉल्वर के बताए से करेंगे। असंगति इस बात का संकेत है कि बीच में किसी चीज़ ने पैकेट दोबारा लिखा, या दो अलग क्वेरी भेजी गईं।
परीक्षण नाम आंतरिक रखें, क्योंकि सार्वजनिक रिज़ॉल्वर को भेजा गया आंतरिक नाम आंतरिक पथ के बारे में कुछ सिद्ध नहीं करता और ऐसा नाम प्रकाशित करता है जिसे प्रकाशित करने की आपको आवश्यकता नहीं थी। सुरक्षित DNS वाला ब्राउज़र उस सॉकेट सूची में बिल्कुल नहीं दिखेगा, और वह अनुपस्थिति ही उत्तर है।
फ़ॉरवर्डर दूसरी, अलग क्वेरी करता है
फ़ॉरवर्डर एक अदला-बदली को दो में बदल देता है। नीचे से अनुरोध आता है, और फिर फ़ॉरवर्डर अपनी क्वेरी ऊपर उस पते से भेजता है जो वह चुनता है। उसका कॉन्फ़िगरेशन, क्लाइंट नहीं, तय करता है कि ऊपरी रिज़ॉल्वर क्या देखता है।
dnsmasq मैनुअल इसी कारण पढ़ने योग्य है: यह दस्तावेज़ित करता है कि फ़ॉरवर्डर ऊपरी सर्वर कैसे चुनता है और अपना सुनने वाला पक्ष कैसे बाँधता है, और उस व्यवस्था में कुछ भी क्लाइंट का स्रोत ऊपर नहीं ले जाता। इसलिए गेटवे पता दिखाने वाला रिज़ॉल्वर लॉग सामान्य है, खराबी का प्रमाण नहीं। अनुपस्थिति भी उतनी ही आसानी से गलत पढ़ी जा सकती है, क्योंकि कैश हिट कोई ऊपरी क्वेरी नहीं बनाता और ऐसी क्वेरी जैसा ही दिखता है जो कभी पहुँची ही नहीं। दोनों में से कोई निष्कर्ष निकालने से पहले फ़ॉरवर्डर का कॉन्फ़िगरेशन और उसके कैश की स्थिति पढ़ें। दो सवाल, देखने की दो जगहें।
स्रोत को प्राप्त करने वाले रिज़ॉल्वर पर पढ़ें
इसे तय करने वाला एकमात्र अवलोकन सर्वर पक्ष पर लिया जाता है। क्लाइंट के इंटरफ़ेस सूची से जो भी निकाला जाए वह अनुमान ही रहता है जब तक रिज़ॉल्वर यह न बताए कि वास्तव में क्या पहुँचा।
tcpdump -ni any port 53 and host 10.20.30.53रिज़ॉल्वर होस्ट पर कैप्चर करें, कैप्चर को छोटा और सीमित रखें, और उसे वहाँ संग्रहीत करें जहाँ नीति अनुमति देती है। यदि देखा गया स्रोत अनुवादित पता है, तो अगला सवाल यह है कि किस उपकरण ने अनुवाद किया और क्या उसकी नीति वही है जो इरादा था। कैप्चर बताता है कि क्या पहुँचा; यह नहीं बताता कि नीति ने क्यों अनुमति दी। नोट में पर्यवेक्षक और चरण का नाम लें, क्योंकि गेटवे के बारे में गोपनीयता का दावा उस चरण के बारे में है, पूरे पथ के बारे में नहीं।
निष्कर्ष को पथ के रूप में लिखें, पते के रूप में नहीं
क्लाइंट, रिज़ॉल्वर, कोई भी फ़ॉरवर्डर, हर चरण पर देखा गया स्रोत और उसे नियंत्रित करने वाली नीति दर्ज करें। ऐसा रिकॉर्ड अधिकांश भविष्य के सवालों का उत्तर बिना किसी और कैप्चर के दे देता है। इसे शृंखला की तरह बनाएँ, क्योंकि पतों की सूची छिपाती है कि किस चरण ने किसे उत्पन्न किया।
चित्र के साथ तिथि, क्लाइंट संस्करण और कॉन्फ़िगरेशन का संशोधन जोड़ें, ताकि बाद का पाठक बता सके कि क्या यह अब भी लागू है। परिवहन स्रोत को उस सबसे अलग रखें जो सेवा संसाधित करती है, क्योंकि गेटवे पता देखना इस बारे में कुछ नहीं कहता कि और क्या संग्रहीत है। रिज़ॉल्वर का स्थान भी इस बारे में कुछ नहीं कहता कि किस क्लाइंट ने पूछा। इन दावों को अलग रखना ही निष्कर्ष को समीक्षा में टिकाऊ बनाता है।