عوامی DNS کا کام کرنا یہ نہیں دکھاتا کہ Active Directory مل سکتا ہے

VPN جڑتا ہے، براؤزر ایک عوامی سائٹ کھولتا ہے، اور لیپ ٹاپ پھر بھی ڈومین میں سائن اِن نہیں کر سکتا۔ عام نتیجہ یہ ہوتا ہے کہ DNS ٹھیک ہے کیونکہ نام حل ہو رہے ہیں۔ یہ ٹھیک نہیں ہے، اور وجہ یہ ہے کہ براؤزر کی جانچ ڈومین سے منسلک کلائنٹ کو درکار زنجیر میں سے صرف ایک تلاش آزماتی ہے۔ ڈومین کی کھوج پہلے سروس ریکارڈ مانگتی ہے، پھر اُن کنٹرولروں کے پتے جن کے نام وہ ریکارڈ رکھتے ہیں، اور پھر اُن پورٹس تک راستہ جن پر وہ کنٹرولر سنتے ہیں۔ عوامی جواب ان میں سے کوئی مرحلہ پورا نہیں کرتا۔

افسانہ: نام حل ہو جاتے ہیں، اس لیے DNS مکمل ہے

عوامی سائٹ کا حل ہونا صرف یہ بتاتا ہے کہ کسی ریزولوَر نے عوامی زون کے نام کے لیے ایک A یا AAAA استفسار کا جواب دیا۔ Active Directory وہی پروٹوکول ایک دوسرے سوال کے لیے استعمال کرتا ہے: ڈومین کی سروسز کہاں ہیں، اور یہ کلائنٹ کون سا کنٹرولر استعمال کرے۔ سوال ڈومین کے نام والے زون کے تحت SRV ریکارڈز کے طور پر بیان ہوتا ہے، اور تکراری عوامی ریزولوَر کے پاس اُنہیں رکھنے کی کوئی وجہ نہیں۔

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

ڈومین کلائنٹ واقعی کیا مانگتا ہے، ترتیب سے

corp.example جیسے ڈومین کے لیے عمومی لوکیٹر استفسار _ldap._tcp.dc._msdcs.corp.example ہے۔ SRV جوابات ممکنہ کنٹرولروں اور اُن کے پورٹس کے نام دیتے ہیں، پھر کلائنٹ کو کنکشن کھولنے سے پہلے اُن ہوسٹ ناموں کے لیے پتہ ریکارڈ درکار ہوتے ہیں۔ سائٹ سے واقف کھوج سائٹ ذیلی ڈومین کے تحت استفسارات شامل کرتی ہے، اور جوابات طے کرتے ہیں کہ کون سے کنٹرولر ترجیحی ہیں، یہ نہیں کہ کون لازمی ہے۔

nltest /dsgetdc:corp.example
Resolve-DnsName -Type SRV _ldap._tcp.dc._msdcs.corp.example

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

عوامی ریزولوَر جواب کیوں دیتا ہے اور سائن اِن پھر بھی کیوں ٹوٹتا ہے

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

دونوں اندرونی ریزولوَر، اگر آپ دو چلاتے ہیں، AD کے نام کی جگہ رکھیں اور کلائنٹ کے موجودہ نیٹ ورک سے قابلِ رسائی ہوں۔ تقسیم شدہ ٹنل کے ڈیزائن یہی چیز توڑتے ہیں: VPN ٹنل کا ذیلی نیٹ ورک لے جا سکتا ہے جبکہ اندرونی ریزولوَر ایسے سابقے پر بیٹھا ہو جسے ٹنل راستہ نہیں دیتا، اس لیے استفسار ایسے ریزولوَر تک جاتا ہے جو اُس کا جواب نہیں دے سکتا۔

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

ٹنل کا DNS اور اُس کے راستے ہم آہنگ رکھیں

جو VPN پروفائل ریزولوَر بھیجتی ہے مگر اُسے سمیٹنے والا سابقہ نہیں بھیجتی، وہ ایسا ریزولوَر بناتی ہے جس تک کلائنٹ نہیں پہنچ سکتا؛ جو سابقہ بھیجتی ہے مگر ریزولوَر نہیں، وہ کلائنٹ کو مقامی سے پوچھنے پر چھوڑ دیتی ہے۔ اِس جوڑی کو ایک ترتیب کی شے سمجھیں اور ہر پروفائل تبدیلی کے بعد دونوں جانچیں، کیونکہ دوبارہ ترتیب شدہ پش یا نئی تقسیم شدہ ٹنل پالیسی اُنہیں الگ کر سکتی ہے۔

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

کھوج کی کال اور ایک زندہ کارروائی سے قبول کریں

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

Microsoft کی DNS کلائنٹ کے لیے سفارشات اندرونی نام کی جگہ حل کرنے اور عوامی استفسارات اوپر بھیجنے کے درمیان وہی لکیر کھینچتی ہیں، اور VPN متعارف کرانے پر یہی ترتیب محفوظ رکھنی چاہیے۔

اگر ناکامی صرف سست ہو، ناکام نہ ہو، تو تاخیر کو تشخیص سے الگ رکھیں۔ کھوج کے دوران وقت ختم ہونا ناقابلِ رسائی کنٹرولر، بند پورٹ یا دیر سے جواب دینے والے ریزولوَر سے آ سکتا ہے، اور اِن میں سے کوئی بھی صرف انتظار سے ثابت نہیں ہوتا۔ ریزولوَر کی ترتیب بدلنے سے پہلے اصل استفسار، اُس کا جواب اور کنکشن کی کوشش درج کریں۔