کیوں 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 تفصیلات اہداف کے درمیان انتخاب بیان کرتی ہیں، اور اِنہیں اجازت کے طریقہ کار کے طور پر پڑھنا ہی وہ راستہ ہے جس سے مفید ریکارڈ سلامتی کا مفروضہ بن جاتا ہے۔ جان بوجھ کر شائع کریں، اپنی دستاویزات میں لیبل کا نام لیں، اور کلائنٹ کو وہ جزو سمجھیں جو فیصلہ کرتا ہے کہ اِن میں سے کچھ اہم ہے یا نہیں۔