प्रॉक्सी कंटेनर DNS कंटेनर का स्वतः उपयोग क्यों नहीं करता

एक ही Docker होस्ट पर प्रॉक्सी और DNS सर्वर चलाना उनके DNS पथों को नहीं जोड़ता। तीन अलग संबंध मायने रखते हैं:

• नेटवर्क पहुँच। अलग Compose प्रोजेक्ट के सामान्यतः अलग डिफ़ॉल्ट नेटवर्क होते हैं। सेवाओं को उपयुक्त साझा नेटवर्क पर रखें, चाहे एक प्रोजेक्ट के भीतर या प्रोजेक्टों के बीच स्पष्ट रूप से साझा नेटवर्क के माध्यम से।
• सेवा खोज। कस्टम Docker नेटवर्क का अंतर्निहित DNS कंटेनर नामों को हल कर सकता है। इससे एप्लिकेशन किसी पड़ोसी को खोज सकता है; परंतु यह उस पड़ोसी को स्वतः अपना DNS रिज़ॉल्वर नहीं चुनता।
• रिज़ॉल्वर चयन। प्रॉक्सी कंटेनर के भीतर उपयोग होने वाले रिज़ॉल्वर की पहचान करें। Compose का dns फ़ील्ड DNS सर्वर पते लेता है। एप्लिकेशन में हल होने वाला dns.local जैसा नाम उसे उस फ़ील्ड के लिए वैध मान नहीं बनाता।

क्वेरी को प्रॉक्सी कंटेनर से उसके कॉन्फ़िगर किए गए रिज़ॉल्वर पते तक ट्रेस करें। उस पते पर रूट और DNS श्रोता होने की पुष्टि करें। होस्ट पोर्ट 53 प्रकाशित करना होस्ट की ओर एक पहुँच पथ बनाता है; परंतु यह कंटेनरों को उसका उपयोग करने को नहीं कहता। नेटवर्क साझा करने वाले कंटेनर इसके बजाय सीधे संवाद कर सकते हैं।

यदि कॉन्फ़िगरेशन DNS कंटेनर के पते का संदर्भ देता है, तो उसे संगत IPAM कॉन्फ़िगरेशन के अंतर्गत स्थिर रखें। कल के कंटेनर से कॉपी किया गया गतिशील रूप से आवंटित पता पुनः निर्माण पर विफल हो सकता है। रिज़ॉल्वर के अपस्ट्रीम पथ की भी जाँच करें: अनुत्तरित क्वेरीज़ को उसी के पास वापस भेजना अगम्य रिज़ॉल्वर से भिन्न विफलता उत्पन्न करता है।

अंत में, पहचानें कि गंतव्य को कौन हल करता है। CONNECT नाम हल करने वाला HTTP प्रॉक्सी इस कंटेनर पथ का उपयोग कर सकता है; स्थानीय रूप से हल करने वाला SOCKS क्लाइंट शायद नहीं। होस्ट लुकअप होस्ट के मार्ग को सिद्ध करता है, प्रॉक्सी प्रक्रिया के मार्ग को नहीं।