VPN पर Azure का निजी DNS: रिज़ॉल्वर एंडपॉइंट या फ़ॉरवर्डर
दोनों डिज़ाइन सुरंग के ज़रिए निजी ज़ोन का जवाब देते हैं। प्रबंधित इनबाउंड एंडपॉइंट की तुलना फ़ॉरवर्डर VM से करें, फिर वह पथ जाँचें जो हर हाल में मौजूद होना चाहिए।
ऑन-प्रिमाइज़ का एक सर्वर निजी पते से Azure VM तक पहुँचता है और फिर भी उसका निजी होस्टनाम हल नहीं कर पाता, जिससे लोग टूटी सुरंग खोजने लगते हैं। सुरंग ठीक है। जो कम है वह DNS सीमा है: ऑन-प्रिमाइज़ की ओर कोई नहीं जानता कि किसी विशेष Azure निजी ज़ोन का उत्तर VNet के भीतर के रिज़ॉल्वर को देना चाहिए। दो डिज़ाइन यह अंतर भरते हैं, और वे इस बात में अलग हैं कि आप अंत में क्या संचालित करते हैं, इस बात में नहीं कि क्वेरी काम करती हैं या नहीं।
सुरंग प्रश्न ले जाती है, ज़ोन का ज्ञान नहीं
साइट-टू-साइट कनेक्शन पैकेटों को दो नेटवर्क के बीच मार्ग देता है। यह ऑन-प्रिमाइज़ DNS सर्वर को नहीं बताता कि कौन-सा नामस्थान Azure का है या कौन-सा पता उत्तर देगा, इसलिए क्वेरी या तो इंटरनेट जाती है और खाली लौटती है, या स्थानीय रिज़ॉल्वर से कभी नहीं निकलती।
समाधान के दो आधे हैं जिन्हें अलग करना आसान है। एक आधा VNet के भीतर का रिज़ॉल्वर है जो सुरंग से आने वाली क्वेरी स्वीकार करता है। दूसरा आधा ऑन-प्रिमाइज़ की ओर का सशर्त फ़ॉरवर्डर है जो ठीक एक नामस्थान उस रिज़ॉल्वर को भेजता है। कोई भी आधा अकेले काम नहीं करता।
इस पूरे विवरण के लिए मान लें कि ज़ोन cloud.corp.example है, और हर पते को उदाहरण मानें।
विकल्प A: प्रबंधित इनबाउंड एंडपॉइंट
Azure DNS Private Resolver एक इनबाउंड एंडपॉइंट देता है जो VNet के बाहर से DNS क्वेरी स्वीकार करता है। आप इसे एक समर्पित प्रत्यायोजित सबनेट में तैनात करते हैं, निजी ज़ोन को उस VNet से जोड़ते हैं, और सेवा द्वारा दिया गया इनबाउंड पता नोट करते हैं।
इसके बाद ऑन-प्रिमाइज़ DNS सर्वर पर उस सटीक नामस्थान के लिए उस पते की ओर एक सशर्त फ़ॉरवर्डर बनाते हैं:
Namespace: cloud.corp.example
Forward to: 10.20.2.4Microsoft की हाइब्रिड DNS प्रक्रिया ज़ोन लिंक और फ़ॉरवर्डर चरण दोनों का दस्तावेज़ीकरण करती है। प्रबंधित मार्ग में पैच करने के लिए कोई DNS सॉफ़्टवेयर नहीं बचता, और एंडपॉइंट पता संसाधन के पूरे जीवनकाल में स्थिर रहता है।
कीमत यह है कि अब आपके पास एक रिज़ॉल्वर संसाधन, उसका सबनेट प्रत्यायोजन और उसकी लागत है, जो क्वेरी की मात्रा बहुत कम होने पर भी वास्तविक है।
विकल्प B: VNet के भीतर फ़ॉरवर्डर VM
पुराना डिज़ाइन VNet में एक सामान्य VM पर DNS सॉफ़्टवेयर चलाता है: Windows DNS, BIND या dnsmasq, और निजी ज़ोन या तो स्थानीय रूप से होस्ट होता है या 168.63.129.16 पर Azure रिज़ॉल्वर को भेजा जाता है। ऑन-प्रिमाइज़ सशर्त फ़ॉरवर्डर उस VM के निजी पते की ओर इशारा करता है।
यह विकल्प उन टीमों के लिए परिचित है जो पहले से DNS सर्वर चलाती हैं, और यह लॉगिंग या स्प्लिट-होराइज़न उत्तरों जैसी अतिरिक्त तर्क ले जा सकता है। यह DNS सर्वर के हर संचालन कर्तव्य को भी विरासत में लेता है: पैचिंग, उपलब्धता के लिए दूसरा इंस्टेंस, निगरानी, और VM बदले जाने तथा उसका पता बदलने पर पुनर्निर्माण का मार्ग।
सामान्य VNet होस्ट DNS प्रॉक्सी नहीं होता जब तक सेवा स्थापित न हो और उन क्लाइंट का उत्तर देने की अनुमति न मिले, और VM क्लोन करते समय लोग यही चरण छोड़ देते हैं।
कौन आपके संचालन में फ़िट है
तुलना इस बारे में नहीं है कि कौन-सा डिज़ाइन तेज़ है। यह इस बारे में है कि क्या आप DNS सॉफ़्टवेयर संचालित करना चाहते हैं, और क्या क्वेरी की मात्रा ऐसे प्रबंधित संसाधन को उचित ठहराती है जो एंडपॉइंट और क्वेरी के अनुसार बिल करता है।
| Question | Managed inbound endpoint | Forwarder VM |
|---|---|---|
| Software to patch | None | The DNS service on every instance |
| Address stability | Fixed for the resource lifetime | Tied to the VM or its reserved address |
| Availability work | Handled by the service | Second instance, health checks, failover |
| Extra logic | Limited to resolver features | Whatever the DNS software supports |
कोई भी पंक्ति निर्णय ले, ऑन-प्रिमाइज़ फ़ॉरवर्डर नियम एक जैसा दिखता है। यही वह हिस्सा है जो दोनों डिज़ाइनों में होना चाहिए, और यही वह हिस्सा है जो सबसे अधिक गायब होता है जब कोई बताता है कि रिज़ॉल्यूशन Azure के भीतर से काम करता है लेकिन कार्यालय से नहीं।
पथ को क्रम से जाँचें
पुष्टि करें कि ज़ोन उस VNet से जुड़ा है जिसमें रिज़ॉल्वर है, और ऑन-प्रिमाइज़ फ़ॉरवर्डर नामस्थान का नाम लेता है, मूल डोमेन का नहीं। corp.example के लिए फ़ॉरवर्डर cloud.corp.example से मेल नहीं खाएगा जब तक रिज़ॉल्वर स्वयं प्रत्यायोजित न करे, और यह बेमेल एक साफ़ नकारात्मक उत्तर देता है जो गायब रिकॉर्ड जैसा दिखता है।
फिर जाँचें कि क्वेरी एंडपॉइंट तक पहुँचती है: ऑन-प्रिमाइज़ स्रोत को रिज़ॉल्वर पते तक मार्ग और वापसी मार्ग चाहिए, और जहाँ नीति अनुमति दे वहाँ UDP और TCP दोनों पोर्ट 53 खुले होने चाहिए। NSG गायब ज़ोन रिकॉर्ड नहीं दे सकता, और सही ज़ोन उस क्वेरी का उत्तर नहीं दे सकता जो कभी पहुँचती ही नहीं।
निदान करते समय माँगा गया FQDN चुने हुए रिज़ॉल्वर के पास रखें, और टाइमआउट को नकारात्मक उत्तर से अलग करें। टाइमआउट पथ या नीति की समस्या है। नकारात्मक उत्तर का अर्थ है कि क्वेरी पहुँची और नामस्थान मेल नहीं खाया। काम का क्रम: ज़ोन लिंक करें, सशर्त फ़ॉरवर्डर जोड़ें, दोनों दिशाओं में पोर्ट 53 खोलें, ऑन-प्रिमाइज़ से एक नाम जाँचें, और उसके बाद ही अनुप्रयोग के अपने प्राधिकरण को देखें।