Split-DNS کی گرفت: بتائیں کہ ہر مشاہدہ کہاں لیا گیا

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

ایک تلاش، کئی مشاہدے کے نکات

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

ہر ایک الگ سوال کا جواب دیتا ہے، اور کوئی اکیلا یہ ثابت نہیں کرتا کہ استفسار کہاں گیا۔

اڈاپٹر پر گرفت پیکٹ دکھاتی ہے، نیت نہیں۔ یہ نہیں بتاتی کہ کلائنٹ نے کون سا resolver چنا، اور خالی گرفت کیش شدہ جواب یا کوئی دوسرا resolver API ہو سکتی ہے، پھینکا ہوا پیکٹ نہیں۔ ہر مشاہدے کو ایک مرحلے کا ثبوت سمجھیں۔ پھر مراحل کو ایک راستے میں جوڑیں۔

کلائنٹ کا فلٹر ایپ اور تار کے درمیان بیٹھتا ہے

Split-DNS والا VPN کلائنٹ پیکٹ کے مشین سے نکلنے سے پہلے ڈومین مماثلت لاگو کرتا ہے۔ ٹنل شدہ لاحقے کے نام اندرونی resolver کو جاتے ہیں؛ باقی سب مقامی resolver کو جاتا ہے۔ فلٹر پالیسی ہے، اور پالیسی پلیٹ فارم اور کلائنٹ ورژن کے لحاظ سے مختلف ہو سکتی ہے۔

Cisco کی Secure Client Split-DNS رہنمائی ڈومین مماثلت اور Windows فلٹر کا احاطہ کرتی ہے، اور اسے الگ کرتی ہے کہ ایپ مقامی resolver API استعمال کرتے وقت کیا دیکھتی ہے اور nslookup جیسا آلہ کیا دیکھتا ہے۔ یہی فرق اصل بات ہے۔

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

nslookup ایپ سے مختلف راستہ لیتا ہے

nslookup اپنا DNS استفسار بناتا ہے اور آپریٹنگ سسٹم کی resolver پالیسی کو نظرانداز کر سکتا ہے۔ یہ اسے مخصوص سرور سے مخصوص سوال پوچھنے کے لیے مفید آلہ بناتا ہے، اور یہ جانچنے کے لیے گمراہ کن آلہ کہ ایپلیکیشن کیا تجربہ کرے گی۔

Windows میں نام حل کرنے کی پالیسی جدول طے کرتی ہے کہ کون سا لاحقہ کون سا سرور استعمال کرتا ہے۔ اسے پڑھنا وہ پالیسی دکھاتا ہے جس پر ایپلیکیشن چلے گی، اور اکثر یہی گمشدہ حصہ ہوتا ہے۔

پالیسی پڑھیں اور پھر وہی سوال عام resolver کے ذریعے پوچھیں:

Get-DnsClientNrptPolicy
Resolve-DnsName intranet.hq.example

خفیہ کردہ resolver استفسار چھپاتے ہیں، کنکشن نہیں

اپنا DNS-over-HTTPS resolver رکھنے والا براؤزر بالکل الگ معاملہ ہے۔ استفسار TLS کے اندر سے نکلتا ہے، اس لیے پیکٹ گرفت resolver پتے سے کنکشن دکھاتی ہے مگر پوچھا گیا نام نہیں دکھاتی۔

پہلے براؤزر کی زیرِ انتظام پالیسی معلوم کریں، پھر اس کا آپریٹنگ سسٹم کی تلاش سے موازنہ کریں۔ اپنا resolver چننے کی اجازت رکھنے والا براؤزر Split-DNS پالیسی شاید کبھی نہ دیکھے۔

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

لیبل والے ٹیسٹ سے موازنہ کریں

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

جہاں اجازت ہو، resolver کی وصولی کا موازنہ کلائنٹ یا گیٹ وے کے ایک تنگ مشاہدے سے کریں:

nslookup intranet.hq.example 10.55.0.53
Get-DnsClientNrptPolicy | Format-List

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