VPN کا DNS غلط؟ ایک مستند سرور پرانا ہو سکتا ہے

VPN سے جڑیں اور ایک ہوسٹ نام کل کے پتے پر، یا کسی چیز پر بھی حل نہیں ہوتا۔ منقطع کریں اور یہ پھر کام کرتا ہے۔ فطری ردعمل ٹنل کے مسلط کردہ حل کنندہ کو قصوروار ٹھہرانا ہے، مگر زیادہ عام وجہ ایک شائع شدہ نام سرور ہے جس نے زون کی تازہ کاریاں وصول کرنا بند کر دیں۔ نئی راہ بس اس مستند سے مختلف مستند تک پہنچی جہاں سے آپ کا محفوظ جواب آیا تھا۔

علامت حل کنندہ کے ساتھ بدلتی ہے

ایک تکراری حل کنندہ وہ واپس کرتا ہے جو کسی مستند نے اسے بتایا، پھر وہ جواب TTL تک رکھتا ہے۔ اگر ٹنل کوئی دوسرا حل کنندہ مسلط کرے، یا راستہ ایسا بدلے کہ پرانا مزید قابل رسائی نہ رہے، تو کلائنٹ کسی دوسرے مستند سے پوچھتا ہے اور دوسرا جواب پاتا ہے۔ اس لمحے ڈومین نہیں بدلا؛ اس کے بارے میں آپ کا نظریہ بدلا۔

اسی لیے ایک ہی نام ایک دفتر میں کام کر سکتا ہے اور ہوٹل سے ناکام ہو سکتا ہے، اور اسی لیے مقامی کیش صاف کرنا صرف کبھی کبھی مدد دیتا ہے۔ کیش صاف کرنے سے سوال پھر اسی مستند کی طرف جاتا ہے۔

فرق کرنے والا امتحان ہر شائع شدہ سرور پر براہ راست استفسار ہے۔

ہر مستند سے براہ راست پوچھیں

یاد رکھی فہرست سے نہیں، تفویض سے شروع کریں۔ والدین سے NS مجموعہ پوچھیں، پھر اس مجموعے کے ہر نام سے وہ ریکارڈ پوچھیں جس کی آپ کو ضرورت ہے۔ ایک ہی نام کے بارے میں مختلف مستندوں پر دو استفسار فوراً بتاتے ہیں کہ زون ہم آہنگ ہے یا نہیں۔

dig +short NS example.com
dig @ns1.dns.example app.example.com A
dig @ns2.dns.example app.example.com A

زون کے سرے کے NS ریکارڈ کے لیے بھی یہی کریں، کیونکہ منتقلی کے بعد والدین کی تفویض اور زون کا اپنا NS مجموعہ مختلف ہو سکتے ہیں۔ SOA پر ترتیبی نمبر اگلی موازنہ کی چیز ہیں، اور بہت پیچھے رہ جانے والا ثانوی سرور جواب کا نہیں، منتقلی کا مسئلہ ہے۔

وہ استفسار صرف اپنی میز سے نہیں، ناکام ہونے والے نیٹ ورک سے چلائیں۔

مطلوبہ نظاروں کو ٹوٹے نظاروں سے الگ کریں

کچھ ڈومین علاقے یا حل کنندہ گروپ کے مطابق جان بوجھ کر مختلف جواب دیتے ہیں، اور منقسم افق کی ترتیبات کاروباری نیٹ ورکس میں معمول ہیں۔

سوال یہ ہے کہ فرق دستاویزی اور مستقل ہے یا نہیں۔ غیر مطلوب نظارہ مختلف دکھائی دیتا ہے: ایک مستند کے پاس ایسا ریکارڈ ہے جو باقیوں کو کبھی نہیں ملا، یا اس کے پاس وہ نہیں جو سب مشترک رکھتے ہیں۔ RFC 2182 کی انتخاب اور تعیناتی رہنمائی مستند دستیابی کو مشترکہ ذمہ داری سمجھتی ہے، اور یہیں درست فریم ورک ہے۔ فالتو پن صرف اس وقت موجود ہے جب ہر شائع شدہ سرور مطلوبہ ڈیٹا کا جواب دے سکے، صرف پورٹ 53 پر کنکشن قبول کرنا نہیں۔

SERVFAIL جواب دینے والا سرور اعتماد سے غلط جواب دینے والے سے زیادہ آسانی سے تشخیص کیا جا سکتا ہے۔

منتقلی وہ ظاہر کرتی ہے جو کیش نے چھپایا تھا

فراہم کنندہ بدلتے وقت دو مستند مقامات بدلتے ہیں: والدین کی تفویض اور زون کے اپنے NS ریکارڈ۔ دونوں کو تازہ کرنا ہوتا ہے، اور دونوں اپنے TTL تک محفوظ ہوتے ہیں۔ اگر پرانا سرور چلتا رہے اور پچھلا زون پیش کرتا رہے، تو جن کے حل کنندہ اس سے پوچھتے ہیں وہ کلائنٹ تبدیلی مکمل دکھائی دینے کے بہت بعد تک پرانا جواب پاتے رہیں گے۔

طویل عمر والا کیش اسی حالت کو چھپاتا ہے۔ جو ورک سٹیشن پورا ہفتہ چلا وہ نئے مستند کا تازہ جواب رکھنے والے حل کنندہ سے بات کر رہا تھا، جبکہ پرانا باقی سب کو پرانا ڈیٹا بانٹتا رہا۔

لیپ ٹاپ پر حل کنندہ بدلنے سے صرف وہی لیپ ٹاپ ٹھیک ہوتا ہے، اور کچھ نہیں۔

زون ٹھیک کریں، حل کنندہ نہیں

پہچانیں کہ کون سے سرور زون کے لیے مستند ہونے چاہئیں، زیرِ انتظام زون یا تفویض کو درست کریں تاکہ ان میں سے ہر ایک مطلوبہ ڈیٹا پیش کرے، اور اپنی منصوبہ بند فالتو پن برقرار رکھیں۔ ایک VPN اخراج کو عجیب جواب ملنے پر نام سرور حذف کرنا دستیابی کم کرتا ہے اور عدم مطابقت کو اپنی جگہ چھوڑ دیتا ہے۔

پھر دونوں نیٹ ورکس سے براہ راست استفسار دوبارہ چلائیں اور جس ریکارڈ کو آپ نے بدلا اس کا TTL ختم ہونے تک انتظار کریں۔

یقینی بنائیں کہ جواب ہر مستند سے مستقل ہے، اور مطلوبہ نظارہ زون دستاویزات میں لکھیں تاکہ اگلا فرق آسانی سے درجہ بند ہو سکے۔