HTTP प्रॉक्सी शृंखला में DNS विफलताएँ: कौन-सा हॉप नाम हल करता है?
श्रृंखलित फ़ॉरवर्ड प्रॉक्सी का निदान करते समय स्थानीय प्रॉक्सी तक पहुँचना, पैरेंट को हल करना और वेबसाइट को हल करना अलग करें।
client → local forward proxy → HTTP parent → websiteयह कहने के बजाय कि सारा DNS “प्रॉक्सी” का है, विफल हो रहे नाम से शुरू करें:
| आवश्यक नाम | वह हॉप जिसे इसे पाना है |
|---|---|
| स्थानीय प्रॉक्सी एंडपॉइंट | क्लाइंट |
| HTTP पैरेंट एंडपॉइंट | स्थानीय फ़ॉरवर्ड प्रॉक्सी |
| वेबसाइट एंडपॉइंट | पैरेंट, जब वह अंतिम कनेक्शन खोलता है |
जब एंडपॉइंट होस्टनाम हों तो ये हॉप अलग-अलग रिज़ॉल्वर उपयोग कर सकते हैं। HTTPS के लिए, फ़ॉरवर्ड प्रॉक्सी CONNECT का गंतव्य होस्ट और पोर्ट पैरेंट को दे सकता है, और पैरेंट अंतिम कनेक्शन बनाता है। मूल क्लाइंट को पहले वेबसाइट हल करने की आवश्यकता नहीं है। सादा HTTP फ़ॉरवर्डिंग भी गंतव्य की जानकारी आगे ले जाती है।
यह वादा नहीं है कि हर नाम के लिए ठीक एक ही मशीन क्वेरी करती है। ACL मूल्यांकन, कैशिंग, नीति और कार्यान्वयन विवरण अतिरिक्त लुकअप करा सकते हैं।
पैरेंट उपलब्ध न हो तो फ़ॉलबैक नीति जाँचें। यदि सीधा पहुँच अनुमत है, तो स्थानीय प्रॉक्सी अपने रिज़ॉल्वर और स्रोत-पता निर्णयों के साथ वेबसाइट की ओर मुँह किए हॉप बन सकता है। केवल पैरेंट कॉन्फ़िगर करना यह सिद्ध नहीं करता कि हर अनुरोध ने उसका उपयोग किया।
विफलता पर, hosts फ़ाइल संपादित करने से पहले वह नाम और प्रक्रिया पहचानें जो उसे हल करने का प्रयास कर रही है। क्लाइंट पक्ष का संपादन हर आगे के निर्णय को ठीक नहीं कर सकता। अंतिम सार्वजनिक स्रोत उस हॉप का है जो वेबसाइट कनेक्शन खोलता है; उस स्रोत को देखना यह मापने के समान नहीं है कि DNS कहाँ हुआ।