ایک اڈاپٹر پر دو DNS سرور نام کی جگہیں تقسیم نہیں کرتے

ایک اڈاپٹر پر دو حل کنندے درج کرنا ایسا لگتا ہے جیسے ایک ڈومین کو ایک سرور پر اور دوسرے ڈومین کو دوسرے پر بھیجا جائے، لیکن حل کنندگان کی فہرست میں کچھ بھی ایسا کام نہیں کرتا۔ Windows نام سے حل کرتا ہے، اور یہ فیصلہ کہ کس سرور سے پوچھنا ہے منظم پتوں کی فہرست سے نہیں بلکہ پالیسی اشیاء سے آتا ہے۔ بدلنے والا ذہنی نمونہ قطار ہے: ڈومین A کے لیے پہلا سرور اور ڈومین B کے لیے دوسرا سرور جیسی کوئی چیز نہیں۔ ہر نام کی جگہ کے لیے قواعد کا مجموعہ ہے جو سروروں کے نام واضح طور پر لیتا ہے، اور جب وہ قواعد موجود ہوں تو اڈاپٹر کی فہرست دلچسپ نہیں رہتی۔

افسانہ: دو پتے دو ڈومین تقسیم کرتے ہیں

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

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

Windows انتخاب کے لیے دراصل کیا استعمال کرتا ہے

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

Get-DnsClientNrptRule
Get-DnsClientNrptPolicy -Effective

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

ہر نام کی جگہ کے لیے ایک قاعدہ، شے محفوظ رکھیں

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

$svcRule = Add-DnsClientNrptRule -Namespace ".svc.internal.example" -NameServers "10.60.0.53" -DisplayName "VPN lab services" -PassThru
$resRule = Add-DnsClientNrptRule -Namespace ".research.internal.example" -NameServers "10.61.0.53" -DisplayName "VPN lab research" -PassThru
$svcRule | Select-Object Name, Namespace, NameServers
$resRule | Select-Object Name, Namespace, NameServers

ابتدائی نقطہ لاحقے کی مطابقت بتاتا ہے، اس لیے قاعدہ app.svc.internal.example اور اس کے نیچے ہر چیز کو ڈھانپتا ہے۔ یہاں کے دونوں پتے اس تجربہ گاہ کے اپنے روٹنگ منصوبے کے ہیں؛ قاعدہ زون نہیں بناتا، راستہ نہیں لگاتا اور آخر میں جڑنے والی ایپلیکیشن کو اختیار نہیں دیتا، اور Add-DnsClientNrptRule کا حوالہ بالکل بتاتا ہے کہ کون سا پیرامیٹر کیا کرتا ہے۔

غور کریں یہ کمانڈ کیا نہیں کرتے: یہ پوری مشین پر لاگو ہیں، VPN سیشن تک محدود نہیں، اور ونڈو بند ہونے کے بعد بھی رہتے ہیں۔ جو تجربہ گاہ یہ بھول جائے وہ سرنگ جانے کے بعد پالیسی پیچھے چھوڑ دیتی ہے۔

ثابت کریں کہ کلائنٹ نے سرور منتخب کیا

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

Resolve-DnsName app.svc.internal.example
Resolve-DnsName build.research.internal.example
Resolve-DnsName app.svc.internal.example -DnsOnly -NoHostsFile

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

جو بنایا ہے بالکل وہی ہٹائیں

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

Remove-DnsClientNrptRule -Name $svcRule.Name -Force
Remove-DnsClientNrptRule -Name $resRule.Name -Force
Get-DnsClientNrptPolicy -Effective

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