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 तपशील लक्ष्यांमधील निवडीचे वर्णन करतो, आणि त्याला अधिकृतता यंत्रणा म्हणून वाचणे हा उपयुक्त रेकॉर्ड सुरक्षा गृहीतक बनण्याचा मार्ग आहे। हेतुपूर्वक प्रकाशित करा, तुमच्या दस्तऐवजात लेबलचे नाव नमूद करा, आणि यातील काही महत्त्वाचे आहे का हे ठरवणारा घटक म्हणून क्लायंटकडे पहा।