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

تلاش کو اصل میں کیا درکار ہے

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

کلائنٹ اپنا resolver VPN پروفائل سے، سرنگ کے DHCP سے یا اپنی ترتیب سے سیکھتا ہے، اور کون سا ذریعہ جیتے گا یہ پلیٹ فارم پر منحصر ہے۔ Windows پر، ipconfig /all ہر اڈاپٹر کے لیے DNS سرور دکھاتا ہے، اس لیے آپ دیکھ سکتے ہیں کہ بھیجی گئی قدر واقعی پہنچی یا نہیں۔ وہ قدر جو کبھی آپریٹنگ سسٹم تک نہ پہنچی ایک خاموش اور عام ناکامی ہے۔ پروفائل کو چھونے سے پہلے ترتیب شدہ قدر پڑھیں۔

Linux اور macOS اسی سوال کا جواب مختلف کمانڈز سے دیتے ہیں، اور جواب بھی اسی پڑھائی کا حقدار ہے: resolvectl status اور scutil --dns دونوں ہر انٹرفیس کے لیے سرور فہرست کرتے ہیں۔ اس فہرست کا موازنہ اس پتے سے کریں جسے پروفائل بھیجنے کا دعویٰ کرتا ہے۔ یہاں کی عدم مطابقت نیچے کا سب کچھ بیان کرتی ہے، اس لیے نام جانچنے سے پہلے اسے طے کریں۔

ایک عوامی اور ایک نجی نام جانچیں

ایک عام عوامی ہوسٹ نام اور دستاویزی نجی ہوسٹ نام اسی مشین سے پوچھیں اور لکھیں کہ کس سرور نے کس کو جواب دیا۔ اگر دونوں ناکام ہوں تو resolver یا اس کا راستہ ٹوٹا ہوا ہے۔ اگر صرف نجی نام ناکام ہو تو resolver نے جواب دیا ہے اور سوال زون یا روٹنگ بن جاتا ہے۔ دونوں سوال ایک منٹ کے اندر چلائیں تاکہ راستے کی تبدیلی فرق کی وضاحت نہ کر سکے۔

اندرونی نام عوامی اسکرین شاٹس اور عوامی resolver سے باہر رکھیں۔ وقت کا ختم ہونا اور غیر موجود ڈومین کا جواب مختلف مشاہدات ہیں: پہلا کہتا ہے کچھ واپس نہیں آیا، دوسرا کہتا ہے کسی اتھارٹی نے جواب دیا کہ نام موجود نہیں۔ دونوں کو ایک خرابی سمجھنا آپ کو غلط تہہ پر لے جاتا ہے، اور سرٹیفکیٹ کی وارننگ پھر تیسری چیز ہے، DNS کی ناکامی نہیں۔

nslookup وہ سرور بھی دکھاتا ہے جس سے پوچھا گیا اور وہ جواب بھی جو ملا، اور یہی وہ جوڑی ہے جو آپ کو درکار ہے۔ اسے اسی شیل میں دو بار چلائیں اور ہر جواب کے ساتھ جواب دینے والا پتہ لکھیں۔

nslookup example.com
nslookup host.corp.example 10.20.30.53

تصدیق کریں کہ کلائنٹ واقعی اس سرور تک پہنچ سکتا ہے

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

ہر پلیٹ فارم اس کا جواب ایک سطر میں دیتا ہے، اور آؤٹ پٹ میں مذکور انٹرفیس پورا جواب ہے۔ اگر یہ جسمانی اڈاپٹر کی طرف اشارہ کرے جبکہ resolver سرنگ کے پیچھے ہو، تو پروفائل ایسا سابقہ نہیں بھیج رہا جو اسے ڈھانپے۔

ip route get 10.20.30.53                      # Linux
route -n get 10.20.30.53                     # macOS
Find-NetRoute -RemoteIPAddress 10.20.30.53   # Windows PowerShell

منقسم سرنگ پروفائل میں resolver بھیجے گئے راستوں سے باہر ہو سکتا ہے، جو سرور کی نہیں بلکہ پروفائل کی مسئلہ ہے۔ resolver کے پتے کا موازنہ بھیجے گئے سابقوں سے کریں اور تصدیق کریں کہ ان میں سے ایک اسے ڈھانپتا ہے۔ وہی عدم مطابقت بیان کرتی ہے کہ DNS ایک نیٹ ورک پر کام کیوں کرتا ہے اور اسی پروفائل کے ساتھ دوسرے پر کیوں ناکام ہوتا ہے۔

یاد رکھیں کہ براؤزر سسٹم resolver کو نظر انداز کر سکتے ہیں

محفوظ DNS والا براؤزر اپنے منتخب کردہ فراہم کنندہ کو HTTPS کے ذریعے سوالات بھیج سکتا ہے اور آپریٹنگ سسٹم کے resolver کو مکمل طور پر نظر انداز کر سکتا ہے۔ تب سسٹم درست دکھائی دیتا ہے جبکہ براؤزر ناکام ہوتا ہے، یا اس کے برعکس۔ یہ سرنگ کے لیے نہیں بلکہ براؤزر کے لیے پالیسی کا سوال ہے۔

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

کیش صاف کریں اور اصل کام دوبارہ جانچیں

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

ipconfig /flushdns                 # Windows
resolvectl flush-caches            # Linux
sudo killall -HUP mDNSResponder    # macOS

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

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

متعلقہ مضامین