VPN کے ذریعے NXDOMAIN کا مطلب ٹنل کا بند ہونا نہیں

ایک ناکام تلاش کو ٹنل کے گرنے کا ثبوت سمجھنا پرکشش ہے، خاص طور پر جب نام دس منٹ پہلے کام کر رہا تھا۔ جواب کچھ اور کہتا ہے۔ NXDOMAIN ایک مکمل شدہ DNS لین دین ہے جس میں حل کنندہ نے بتایا کہ پوچھا گیا نام موجود نہیں; خراب ٹنل عام طور پر خاموشی، وقت کا ختم ہونا یا غلط سرور کے خلاف حل کی کوشش پیدا کرتی ہے۔ wireshark کے بغیر دلیل کی شکل ایک استفسار، ایک جواب دہندہ اور ایک جوابی کوڈ ہے، اور کسی بھی ترتیب کی تبدیلی سے پہلے یہ تینوں محفوظ کرنا مناسب ہے۔

جواب دراصل کیا ثابت کرتا ہے

DNS ان نتائج کو الگ کرتا ہے جنہیں کلائنٹ اکثر ایک ہی ناکامی میں ملا دیتے ہیں۔ غیر موجود نام NXDOMAIN کوڈ کے ساتھ منفی جواب دیتا ہے، جبکہ موجود نام جس کے پاس مطلوبہ قسم کا ریکارڈ نہیں، خالی جوابی حصے کے ساتھ کامیاب جواب دیتا ہے۔ دونوں کسی ایپلیکیشن کو بے کار لگتے ہیں، اور ان میں سے صرف ایک کا مطلب ہے کہ نام غلط ہے۔

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

افسانہ: نجی نام کا نہ ہونا ٹنل کی ناکامی ہے

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

split-horizon ترتیبات اسے معمول بناتی ہیں: وہی زون نام عوامی اور اندرونی طور پر مختلف مواد کے ساتھ موجود ہے، اور نجی ریکارڈ صرف اندرونی حل کنندہ جانتا ہے۔ اس لیے مستند دکھنے والا منفی جواب ملنا اس بات کا ثبوت ہے کہ کس حل کنندہ نے جواب دیا، انٹرفیس کی حالت کا ثبوت نہیں۔

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

صحیح نام کے ساتھ صحیح حل کنندہ سے پوچھیں

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

resolvectl query vpn.internal.example
resolvectl status | grep -A3 'DNS Servers'
dig +search app.intranet.example A
dig @10.8.0.1 app.intranet.example A

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

منفی کیشنگ مرمت کے بعد کی تاخیر کی وضاحت کرتی ہے

منفی جوابات ڈیزائن کے مطابق کیش ہوتے ہیں، اور RFC 2308 بیان کرتا ہے کہ منفی کیش کی عمر زون کے اختیار ریکارڈ سے کیسے اخذ ہوتی ہے۔ اس لیے ریکارڈ یا حل کنندہ کا قاعدہ درست کرنا کلائنٹ پر فوری تبدیلی کی ضمانت نہیں دیتا، اور کیش شدہ جواب واپس کرنے والی تلاش کو دہرانا کوئی نئی بات ثابت نہیں کرتا۔ صرف مختلف جواب دہندہ، مختلف نام یا خالی کیا گیا کیش تازہ ثبوت دیتا ہے۔

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

نام کو راستے سے الگ کریں

ایک بار نام متوقع نجی پتے پر حل ہو جائے، تو DNS بطور موضوع ختم ہے اور اگلا سوال ایپلیکیشن کا راستہ بنتا ہے۔ جو میزبان تلاش کا جواب دیتا ہے مگر کنکشن سے انکار کرتا ہے اس کا مسئلہ الگ ہے، اور درست جواب کے بعد بھی حل کنندگان کو ایڈجسٹ کرتے رہنا وہ طریقہ ہے جس سے کسی واقعے کو تین غیر متعلق تبدیلیاں مل جاتی ہیں۔ دونوں کے مطابق ہونے کا گمان کرنے سے پہلے حل شدہ پتے کا موازنہ اس پتے سے کریں جس پر سروس واقعی سنتی ہے۔

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