آپ کا VPN تین DNS سرور بھیجتا ہے: کون جواب دیتا ہے؟
اضافی اندراجات بیک اپ، ہر ڈومین کے لیے راستہ یا فزیکل لنک کی باقیات ہو سکتی ہیں۔ فہرست کو لیک کہنے سے پہلے ہر ایک کو ایک دائرے سے جوڑیں۔
جوڑنے کے بعد سیٹنگز صفحہ کھولیں اور تین DNS پتے فہرست میں نظر آئیں گے؛ آڈٹ کا سوال یہ ہے کہ آپ کی آخری استفسار کس نے سنبھالی۔ صرف تعداد کسی بات کا جواب نہیں دیتی، کیونکہ کلائنٹ پش، ایک فزیکل انٹرفیس اور ہر ڈومین کی پالیسی سب ایک ہی منظر میں لکھتے ہیں۔ ان اندراجات کے مختلف دائرے ہیں، اور جواب کون دے گا یہ مقام نہیں، دائرہ طے کرتا ہے۔ ذرائع کو الگ کر کے شروع کریں، پھر وہ ذریعہ جانچیں جس کے پاس وہ نام ہے جو آپ کے لیے اہم ہے۔
فہرست آپ کی پروفائل سے لمبی کیوں ہے
VPN کلائنٹ ٹنل لنک کے لیے حل کنندہ کے پتے بھیجتا ہے، اور آپریٹنگ سسٹم انہیں فزیکل انٹرفیس کے پاس پہلے سے موجود چیز کے ساتھ رکھتا ہے۔ راؤٹر، کارپوریٹ DHCP لیز، دوسرا VPN اور ہر ڈومین کی پالیسی ہر ایک اپنی اندراج شامل کرتا ہے۔ اس لیے صفحہ پر تین پتے ایک کام کے لیے تین امیدوار نہیں، تین دائرے ہو سکتے ہیں۔ تعداد کو لیک کا ثبوت پڑھنا اس آڈٹ کی پہلی غلطی ہے۔
ایک انٹرفیس کے اندر کلائنٹ واقعی اپنے سرور ترتیب سے آزماتا ہے، اس لیے ترتیب شدہ فہرست بے معنی نہیں۔ جو قطار نہیں ہے وہ یکجا منظر ہے، جہاں پروفائل، فزیکل لنک اور ہر ڈومین کے قواعد کی اندراجات ایک ہی درجہ بندی کے بغیر ساتھ ساتھ بیٹھتی ہیں۔ یہی فرق طے کرتا ہے کہ آپ کیا جانچیں گے: ترتیب ایک دائرے کے اندر رویہ بیان کرتی ہے، اور دائرہ باقی سب کچھ۔
انکرپٹڈ DNS تصویر کو ایپلیکیشن کے اندر سے توڑتا ہے۔ اپنا DNS-over-HTTPS حل کنندہ رکھنے والا براؤزر یا چیٹ کلائنٹ استفسارات کو آپریٹنگ سسٹم کی فہرست کو مکمل طور پر نظر انداز کر کے بھیجتا ہے، اس لیے سیٹنگز صفحہ کے پتے ایسی ٹریفک بیان کرتے ہیں جو ایپ نے کبھی پیدا نہیں کی۔ نام غلط آنے پر پروفائل کو الزام دینے سے پہلے ایپ کی اپنی حل کنندہ سیٹنگ دیکھیں۔
تین جانچوں میں سے ہر ایک کیا بتاتی ہے
ہر ذریعہ اپنا نشان مختلف جگہ چھوڑتا ہے، اور کوئی ایک حکم سب نہیں دکھاتا۔ سیٹنگز صفحہ کے پاس رکھنے کے قابل نقشہ یہ ہے:
| Entry source | Where it is visible | What it proves |
|---|---|---|
| Tunnel profile | Link-scoped DNS on the tunnel device | Which servers the VPN asked you to use, not which one answered |
| Per-domain policy | Suffix list or routing domains | Which names are steered to a particular resolver |
| Physical link | DNS on the LAN interface | Whether a second scope still exists outside the tunnel |
| Application resolver | App settings, absent from the OS list | Whether the system list was consulted at all |
systemd-resolved استعمال کرنے والے نظام میں resolvectl status مستند ہے، کیونکہ یہ روٹنگ ڈومینز کے ساتھ ہر لنک کا DNS رپورٹ کرتی ہے۔ macOS scutil --dns کے ذریعے جواب دیتا ہے، جو دائرہ رکھنے والے حل کنندگان کو آزمائش کی ترتیب سے فہرست کرتا ہے۔ Windows دو آدھے حصے کرتا ہے: ہر انٹرفیس کے سرورز کے لیے Get-DnsClientServerAddress اور سابقہ قواعد کے لیے Get-DnsClientNrptPolicy۔ وہ حکم چلائیں جو واقعی استعمال ہو رہے حل کنندہ سے تعلق رکھتا ہے، کیونکہ کنٹینر رن ٹائم اور ڈیسک ٹاپ حل کنندہ والی مشین میں ایک سے زیادہ نصب ہو سکتے ہیں۔
ایک بیک اپ حل کنندہ جو آپ کے زون کا جواب نہیں دے سکتا
دوسری اندراج عام طور پر دستیابی کے لیے ہوتی ہے، اور دستیابی تبھی کام کرتی ہے جب بیک اپ نام جانتا ہو۔ کسی عوامی حل کنندہ سے اندرونی ہوسٹ نام پوچھیں، وہ NXDOMAIN واپس کرتا ہے، یا آپ سے کوئی تعلق نہ رکھنے والے تلاش ڈومین سے وائلڈ کارڈ جواب دیتا ہے۔ پھر کوئی بھی نہ جانچا گیا فال اوور ٹھیک اسی لمحے رکاوٹ پیدا کرتا ہے جب اس کی ضرورت ہو۔
Split DNS اسی کو روکنے کے لیے ہے: کمپنی کے سابقے زون رکھنے والے حل کنندہ کے پاس جاتے ہیں، اور عوامی نام طے شدہ راستے پر رہتے ہیں۔ ڈیزائن مضبوط ہے، اور یہ سابقہ فہرست کے مکمل ہونے پر منحصر ہے۔ Microsoft ہر سابقہ کے لیے حل کنندہ پالیسی کی دستاویز کرتا ہے جو Windows پر یہ چلاتی ہے، اور وہی خیال systemd-resolved میں روٹنگ ڈومینز اور macOS پر دائرہ رکھنے والے حل کنندگان کے طور پر نظر آتا ہے۔
بیک اپ جن زون کا جواب دے سکتا ہے ان کا پالیسی میں موجود سابقوں سے موازنہ کریں۔ یہ موازنہ صارف کے یہ بتانے سے پہلے ہی خلا تلاش کر لیتا ہے کہ ٹنل تبدیلی کے بعد ایک اندرونی سائٹ حل ہونا بند ہو گئی۔
پالیسی کے ذریعے پوچھیں، اس کے گرد نہیں
آپریٹنگ سسٹم کے حل کنندہ کے ذریعے پوچھیں، کیونکہ سرور سے براہ راست استفسار پالیسی کو نظر انداز کرتا ہے اور صرف وہی بتاتا ہے جو وہ سرور کہتا۔ دو جوابات کے درمیان خلا ہی پوری بات ہے:
resolvectl query intranet.example.com
dig +short intranet.example.com @198.51.100.53اگر نظام کا استفسار نجی پتہ واپس کرے جبکہ براہ راست استفسار NXDOMAIN واپس کرے، تو پالیسی کام کر رہی ہے اور کمزور مقام بیک اپ ہے۔ اگر دونوں ایک ہی عوامی جواب واپس کریں، تو نام آپ کے ارادے کے دائرے سے باہر حل ہو رہا ہے، اور سابقہ فہرست دیکھنے کی جگہ ہے۔ دونوں آؤٹ پٹ رکھیں، کیونکہ سیٹنگز صفحہ کے اسکرین شاٹ سے زیادہ دو سطروں سے حل کنندہ کی بحث جلد طے ہوتی ہے۔
پھر ناکامی کا راستہ مشق کریں، کیونکہ جس بیک اپ کو کسی نے نہ جانچا وہ محض ایک اندازہ ہے۔ ایک استفسار کے لیے پسندیدہ حل کنندہ کو بلیک ہول بنائیں اور دیکھیں کون سا پتہ واپس آتا ہے:
ip route add blackhole 198.51.100.53/32
resolvectl query intranet.example.com
ip route del blackhole 198.51.100.53/32استفسار ختم ہوتے ہی وہ راستہ حذف کریں، ورنہ اگلا شخص ایک معمہ ورثے میں پاتا ہے۔ اگر اس دورانیے میں اندرونی نام اب بھی حل ہوں، تو ارادے کے دائرے سے باہر کسی چیز نے انہیں جواب دیا۔ اگر وہ اس کے بجائے وقت ختم ہو جائیں، تو بیک اپ موجود نہیں یا درست طور پر محدود ہے، اور حل کنندہ کا اپنا لاگ بتاتا ہے کہ دونوں میں کون سا تھا۔
فیصلہ کریں: رکھیں، محدود کریں یا ہٹائیں
دوسرا حل کنندہ تب رکھیں جب وہ آپ کے مطلوبہ نام کی جگہ کا جواب دے اور پروفائل کے تحت قابل رسائی رہے۔ اسے تب محدود کریں جب اسے صرف ایک سابقہ نظر آنا چاہیے اور کچھ نہیں، اور اسے ہٹا دیں جب اس کا نہ دائرہ ہو نہ دستاویزی مقصد۔ بے کام کی اندراج بے فائدہ مستقبل کی لیک ہے، اور وینڈر کا طے شدہ ہونا مقصد نہیں۔
نتیجہ چار کالم میں لکھیں: سابقہ، حل کنندہ، انٹرفیس اور مالک۔ وہ سطر کسی بھی اسکرین شاٹ سے جلدی اگلے آڈٹ سوال کا جواب دیتی ہے، اور فہرست کو خاموشی سے دوبارہ ترتیب دینے والی کلائنٹ اپ ڈیٹ سے بھی بچی رہتی ہے۔