1.1.1.1 کون چلاتا ہے؟ بھروسہ کرنے سے پہلے DNS پتے کی جانچ
VPN کے ساتھ استعمال ہونے والا DNS پتہ ضروری نہیں کہ اسی VPN کے زیرِ انتظام ہو۔ ریزالور کی شناخت کریں، پھر راستہ اور نجی ناموں کی پالیسی الگ الگ جانچیں۔
آپ نے 1.1.1.1 کو VPN کے DNS خانے میں چسپاں کیا، صفحہ لوڈ ہوا، اور ٹیوٹوریل اب تصدیق شدہ لگتا ہے۔ یہ مشاہدہ محسوس ہونے سے زیادہ تنگ ہے: ایپلیکیشن نے مختلف سلوک کیا، اور تبدیلی ابھی یہ نہیں بتاتی کہ استفسار کا جواب کس نے دیا یا پرانا انتظام کیوں ناکام ہوا۔ نقل کیا گیا ٹیوٹوریل کسی مانوس عوامی پتے کو «VPN کا DNS» کہتا ہے، اور یہ ملکیت کا دعویٰ ہے، رسائی کا نہیں۔ پتہ کیا نمائندگی کرتا ہے یہ جانچنے میں پانچ منٹ لگتے ہیں اور غلط وجہ سے کی گئی مستقل تبدیلی رک جاتی ہے۔
چلتی ہوئی سیٹنگ شناخت نہیں ہوتی
سیٹنگ خانے کا پتہ ایک اختتامی نقطہ ہے، اور اختتامی نقطے کا ایک آپریٹر ہوتا ہے۔ یہ دو حقائق الگ ہیں، اور دوسرا وہ ہے جسے لوگ چھوڑ دیتے ہیں۔ سب سے زیادہ نقل کی جانے والی جوڑی کے لیے جواب عوامی ہے: Cloudflare 1.1.1.1 اور 1.0.0.1 کو اپنے ریزالور کے پتے کے طور پر شائع کرتا ہے اور انہیں اپنے سرکاری پتہ حوالے میں درج کرتا ہے۔ اسی لیے آپریٹر کا نام پتے کے ساتھ ہوتا ہے، الگ ٹیوٹوریل میں نہیں۔
سرنگ فعال ہونے کے دوران وہ جوڑی درج کرنا VPN کمپنی کو اس کا آپریٹر نہیں بناتا، اور ٹریفک کو گمنام نہیں بناتا۔ استفسار آپ کی مشین سے اس کمپنی کی طرف جاتا ہے جو پتوں کی حد شائع کرتی ہے، اور وہ کمپنی معتبر ہو سکتی ہے اور پھر بھی وہ فریق نہ ہو جس کی ٹیوٹوریل نے نشاندہی کی۔ ہدایات کا لیبل اور حقیقت کا آپریٹر دو مختلف دعوے ہیں۔ کوئی بھی یہ نہیں بتاتا کہ درمیان کا نیٹ ورک راستہ کون چلاتا ہے۔
پتہ جوڑی یا خفیف شدہ اختتامی نقطہ کی تصدیق کے لیے ریزالور کے اپنے شائع شدہ حوالے کا استعمال کریں۔ کسی دوسرے فراہم کنندہ کی سفارش جائز ہو سکتی ہے، اور «سفارش کردہ»، «کے ذریعے پہنچا» اور «کے زیرِ انتظام» اب بھی تین مختلف رشتے بیان کرتے ہیں۔
ریکارڈ کو جن تین چیزوں کی ضرورت ہے ان کا موازنہ کریں
جائزے کے لیے تیار ریکارڈ تین سوالات الگ کرتا ہے: استفسار کس کو ملنا چاہیے، تبادلہ سادہ ہے یا خفیف، اور کون سا راستہ اسے لے جائے گا۔ فراہم کنندہ کا نام دوسرا یا تیسرا نہیں بھر سکتا، اور ملک کا لیبل ان میں سے کوئی بھی نہیں بھر سکتا۔ تبدیلی سے پہلے تینوں اندراج لکھیں اور بعد میں ان کا موازنہ کریں۔ یہ اندراج بدلے نہیں جا سکتے، اور انہیں ایک سمجھنا وہ راستہ ہے جس سے قیاس دستاویز بن جاتا ہے۔
موازنہ ہی چلتی ہوئی سیٹنگ کو دستاویزی فیصلے میں بدلتا ہے۔ اس کے بغیر اگلے شخص کو بغیر کسی وجہ کے جڑا پتہ وراثت میں ملتا ہے۔ پہلے نیچے دیے گئے جدول کا تیسرا کالم پڑھیں، کیونکہ وہیں زیادہ تر پُراگزار وضاحتیں واقعی رکتی ہیں۔
| Entry | What it records | What it cannot tell you |
|---|---|---|
| Recipient | Which resolver should answer | Who operates the path to it |
| Transport | Plain DNS or an encrypted variant | Whether names stay private |
| Path | Which interface carries the query | Which upstream answers last |
جدول جان بوجھ کر مختصر ہے۔ اس کا مطلب یہ ہے کہ ہر اندراج مختلف سوال کا جواب دیتا ہے، اور کوئی ایک خانہ تینوں نہیں بھرتا۔
مقامی فارورڈر اصل ذریعہ چھپاتا ہے
وہ آلہ جو اپنے راؤٹر کو DNS کے طور پر استعمال کرنے پر سیٹ ہے، فارورڈر کی طرف اشارہ کر رہا ہے۔ وہ پتہ استفسار کے اگلے وصول کنندہ کی شناخت کرتا ہے، اس ریزالور کی نہیں جو آخر میں جواب دیتا ہے۔ مقامی اسٹب ریزالور وہی اضافی مرحلہ شامل کرتا ہے, اور اسے اصل چیز سے خلط کرنا آسان ہے کیونکہ یہ ہر حالت کی آؤٹ پٹ میں ظاہر ہوتا ہے۔
اسٹب ان ذرائع کی طرف بھیجتا ہے جو وہی آؤٹ پٹ بھی درج کرتی ہے، عام طور پر مزید نیچے۔ آپریٹر کے بارے میں کوئی نتیجہ نکالنے سے پہلے پوری زنجیر پڑھیں، کیونکہ پہلی سطر پورا جواب نہیں ہے۔ ورنہ آپ استقبالیہ کو کمپنی کہہ رہے ہیں۔
resolvectl status | grep -A4 'Current DNS Server'
dig +short CH TXT whoami.cloudflare @1.1.1.1
dig example.com | grep -E '^;; SERVER'دوسرا کمانڈ ریزالور کا بازگشت نام استعمال کرتا ہے، جہاں آپریٹر ایک شائع کرتا ہے، تاکہ وہ ماخذ پتہ رپورٹ کرے جو وہ دیکھتا ہے۔ تیسرا اس سرور کا نام بتاتا ہے جس نے جواب دیا، جو اکثر وہ پتہ نہیں ہوتا جو آپ نے تشکیل کیا۔ آپریٹر لکھنے سے پہلے تینوں آؤٹ پٹ کا موازنہ کریں۔
خفیف DNS یہ بدلتا ہے کہ کیا نظر آتا ہے، یہ نہیں کہ کون دیکھتا ہے
DNS over HTTPS اور DNS over TLS کلائنٹ اور ریزالور کے درمیان تبادلے کی حفاظت کرتے ہیں۔ ریزالور اب بھی ہر وہ نام پڑھتا ہے جس کے بارے میں پوچھا جاتا ہے، کیونکہ جواب دینا ہی کام ہے۔ جو بدلتا ہے وہ یہ ہے کہ تبادلہ کون دیکھ سکتا ہے: مقامی نیٹ ورک ایک اختتامی نقطے سے رابطہ دیکھتا ہے، سادہ متن کے استفسارات کی ریل نہیں۔
جو نہیں بدلتا وہ اعتماد کا رشتہ ہے، جو اب بھی اسی ادارے کی طرف اشارہ کرتا ہے جو وہ اختتامی نقطہ چلاتا ہے۔ اپنی محفوظ DNS سیٹنگ والا براؤزر آپریٹنگ سسٹم کے ریزالور کو مکمل طور پر نظرانداز کر سکتا ہے۔ انہیں دو ترتیبات کے طور پر دیکھیں جو متفق نہ ہو سکیں، نہ کہ ایک سیٹنگ جو دو بار لاگو کی گئی ہو۔
نجی ناموں کو پھر اپنا فیصلہ چاہیے۔ کام کی سرنگ منتخب ڈومینز کو تنظیمی ریزالورز کی طرف بھیج سکتی ہے، اور اسے عوامی خدمت سے بدلنا اندرونی تلاش کو توڑ سکتا ہے یا اندرونی نام غلط فریق پر ظاہر کر سکتا ہے۔ پورے اڈاپٹر کی سیٹنگز بدلنے سے پہلے ڈومین پالیسی جانچیں۔
مشاہدہ تنگ رکھیں
موازنہ کرتے وقت پرانی ترتیب محفوظ رکھیں اور ایک وقت میں ایک سیٹنگ بدلیں۔ ایپلیکیشن، عمل، ریزالور پالیسی، اور یہ کہ دوبارہ جڑنے کے بعد عوامی اور اجازت شدہ نجی نام اب بھی حل ہوتے ہیں یا نہیں، درج کریں۔ دو تبدیلیوں والا موازنہ کسی ایک کو بھی ثابت نہیں کرتا۔ نتیجہ وہاں لکھیں جہاں اگلا شخص اسے پائے، سیٹنگ کے بالکل ساتھ۔
resolvectl query intranet.corp.example
resolvectl domain
dig +short @1.1.1.1 example.comاگر ایپلیکیشن کام کرنے لگے تو دعوہ اتنا ہی چھوٹا رکھیں جتنا ثبوت اجازت دیں۔ اس تبدیلی نے ایک جانچ میں مدد کی، اور یہ نہیں بتاتی کہ پچھلے ریزالور نے بدنیتی سے کام کیا، سرنگ ٹوٹی تھی، یا کسی دوسرے آلے کو وہی تبدیلی درکار ہے۔ پائیدار نتیجہ وہ ترتیب ہے جس کا آپریٹر اور مقصد آپ بیان کر سکیں۔