क्यों SRV रिकॉर्ड केवल उसी क्लाइंट की मदद करता है जो स्वयं इसे खोजता है

अपने ज़ोन में SRV रिकॉर्ड जोड़ने से कोई भी VPN क्लाइंट उसे खोजना नहीं सीखता। क्लाइंट को लेबल पता होना चाहिए, क्वेरी भेजने का निर्णय लेना चाहिए और जो लौटता है उसके अनुसार कार्य करना चाहिए, और DNS इनमें से पहले दो नहीं दे सकता। इसलिए अधिकांश असफल SRV योजनाएँ DNS के भेस में क्लाइंट की समस्याएँ हैं। पहले क्लाइंट का खोज-व्यवहार पढ़ें, फिर केवल वही लेबल प्रकाशित करें जो वह वास्तव में खोजता है।

जिस रिकॉर्ड को कोई नहीं खोजता, वह किसी की मदद नहीं कर सकता

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

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

लिखने से पहले फ़ील्ड पढ़ें

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

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

क्लाइंट वास्तव में जो लेबल भेजता है, उसे खोजें

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

dig +short SRV _vpn._tcp.gw.example
dig +short A edge2.gw.example
tcpdump -ni any udp port 53

उत्तर की तुलना अपने प्रकाशित रिकॉर्ड से अक्षर-दर-अक्षर करें, क्योंकि अंडरस्कोर और अंत का बिंदु नाम का हिस्सा हैं। वास्तव में भेजी गई क्वेरी का खाली उत्तर ज़ोन की ओर इशारा करता है, जबकि क्वेरी का बिलकुल न होना क्लाइंट की ओर इशारा करता है, और ये निष्कर्ष आपको अलग-अलग टीमों के पास भेजते हैं। वास्तविक उत्तर नीचे की पंक्ति जैसा दिखता है, जहाँ प्राथमिकता 20 किसी भी कम प्राथमिकता वाले रिकॉर्ड से हार जाती है और क्लाइंट नामित लक्ष्य पर पोर्ट 8443 डायल करता है।

_vpn._tcp.gw.example. 600 IN SRV 20 10 8443 edge2.gw.example.

लक्ष्य का भी अस्तित्व होना चाहिए

हल होने वाला लक्ष्य उत्तर देने वाली सेवा के समान नहीं है। लक्ष्य के पता रिकॉर्ड जाँचें, फिर जाँचें कि प्रकाशित पोर्ट और प्रोटोकॉल पर कुछ सुन रहा है। केवल UDP श्रोता की ओर इशारा करने वाला TCP रिकॉर्ड ऐसी असंगति है जिसे कोई ज़ोन संपादन ठीक नहीं करता। जब तक लक्ष्य अस्थिर है TTL छोटा रखें, और नाम का चलना बंद होने पर उसे बढ़ा दें।

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

खोज प्रमाणीकरण नहीं है

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

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