DNS حل کنندہ لاگ اور VPN کنکشن لاگ: ہر ایک میں کیا محفوظ ہوتا ہے
حل کنندہ ان ناموں کو درج کرتا ہے جن کا جواب دینے کو کہا گیا؛ VPN اپنے نفاذ سے سرنگ کے واقعات درج کرتا ہے۔ ایک تحفظ پالیسی دوسری کو ڈھکتی نہیں۔
DNS حل کنندہ کا لاگ اور VPN کنکشن کا لاگ دونوں نیٹ ورک ریکارڈ ہیں، دونوں مفید ہیں اور ایک دوسرے کی جگہ نہیں لے سکتے۔ حل کنندہ ان ناموں کو وصول کرتا ہے جن کا جواب دینے کو کہا گیا۔ VPN کا آخری نقطہ سرنگ کے کنکشن سنبھالتا ہے اور وہ درج کرتا ہے جو اس کے نفاذ نے ان کے بارے میں درج کرنے کا انتخاب کیا۔ وہ ایک ہی عمارت میں ہو سکتے ہیں، ایک ہی ٹیم چلا سکتی ہے اور ایک ہی رازداری نوٹس کے دائرے میں آ سکتے ہیں، پھر بھی مختلف شناخت کنندگان اور مختلف تحفظ کے ساتھ مختلف واقعات بیان کرتے ہیں۔ ایک کو دوسرا سمجھ کر پڑھنا ہی تفتیش کے راستے سے بھٹکنے کا سبب ہے۔
دو لاگ، دو واقعات
حل کنندہ کا ایک اندراج نام رکھنے کے بارے میں سوال کا جواب دیتا ہے: اس کلائنٹ نے اس وقت یہ نام مانگا، اور جواب یہ تھا۔ VPN کا ایک اندراج رابطے کے بارے میں سوال کا جواب دیتا ہے: اس ساتھی نے سرنگ قائم کی یا کھو دی، اسے یہ پتہ دیا گیا، اور جانے سے پہلے تقریباً اتنا ڈیٹا منتقل کیا۔ دونوں میں سے کوئی بھی HTTPS سیشن کے اندر صارف نے کیا کیا اس کا ریکارڈ نہیں، اور کوئی بھی دوسرے کی جگہ نہیں لیتا۔
اس فرق کا وعدوں کے لیے عملی نتیجہ ہے۔ یہ بیان کہ VPN فراہم کنندہ سرنگ کی سرگرمی درج نہیں کرتا، اس حل کنندہ کے بارے میں کچھ نہیں کہتا جو وہ دیتا ہے، اور حل کنندہ کی تحفظ پالیسی سرنگ سے کون جڑا اس بارے میں کچھ نہیں کہتی۔ ہر دعویٰ اپنے آپریٹر اور اپنے نظام کا ہے۔
کوئی بھی لاگ پڑھنے سے پہلے استفسار کا پیچھا کریں
استفسار حل کنندہ تک صرف تب پہنچتا ہے جب راستہ واقعی اس سے پوچھتا ہے۔ کوئی اطلاقیہ آپریٹنگ سسٹم کا حل کنندہ استعمال کر سکتا ہے، اپنا خفیہ کردہ DNS کلائنٹ چلا سکتا ہے، یا کیش شدہ جواب پڑھ کر کچھ بھی نہ بھیجے۔ اس لیے کچھ نہ دکھانے والا حل کنندہ لاگ اس بات کا ثبوت نہیں کہ کوئی نام کبھی استعمال نہیں ہوا؛ یہ اس بات کا ثبوت ہے کہ اس حل کنندہ سے نہیں پوچھا گیا۔
resolvectl status
dig @127.0.0.53 build.corp.example +qr
journalctl -u systemd-resolved -n 20 --no-pagerوہ آخری حکم مقامی حل کنندہ کی اپنی جرنل پڑھتا ہے، جو اوپر والے سرور کے لاگ جیسا نہیں ہے۔ اگر آپ کے استفسارات DNS over HTTPS کے ذریعے کسی فراہم کنندہ کی طرف جاتے ہیں، تو مقامی اسٹب کچھ نہ دکھا سکتا ہے جبکہ فراہم کنندہ کے پاس مکمل ریکارڈ ہوتا ہے، اور فراہم کنندہ مختلف پالیسی والا دوسرا آپریٹر ہے۔
ہر ریکارڈ کیا دکھا سکتا ہے اور کیا نہیں
| Record | Typically shows | Does not show |
|---|---|---|
| Resolver log | Queried name, client address, time, response | Which page was fetched, or what the tunnel did |
| VPN connection log | Peer identity, assigned address, connect and disconnect times, volume | Which name the application asked for |
| Application or proxy log | Requests, status codes, sometimes full URLs | Resolved addresses for every dependency |
انہیں جوڑنا ہی اصل کام ہے، اور جوڑنا ہمیشہ ممکن نہیں۔ کلائنٹ پتے درج کرنے والے حل کنندہ کا موازنہ اس VPN سے کیا جا سکتا ہے جو کسی معلوم تالاب سے پتے مختص کرتا ہے، اور وہ موازنہ پوچھے گئے نام اور سرنگ کے درمیان ایک معقول ربط پیدا کرتا ہے، جو دو ریکارڈوں کے درمیان ربط ہی رہتا ہے، کسی شخص کا ریکارڈ نہیں۔
خفیہ کردہ DNS نقل و حمل بدلتا ہے، آخری نقطے پر نظر آنا نہیں۔ حل کنندہ اب بھی وہ سوال وصول کرتا ہے جس کا وہ جواب دیتا ہے، جیسا کہ RFC 8484 واضح کرتا ہے، اور اس حل کنندہ پر تحفظ پروٹوکول کی خصوصیت نہیں بلکہ پالیسی کا فیصلہ ہے۔
جہاں منقسم DNS اور کیش کہانی کو الجھاتے ہیں
ایک سے زیادہ حل کنندے معمول کی بات ہے۔ منقسم DNS کا ڈیزائن اندرونی نام اندرونی سرور کی طرف اور باقی سب عوامی سرور کی طرف بھیجتا ہے، اس لیے ایک تفتیش میں ایسے دو لاگ شامل ہو سکتے ہیں جنہیں کبھی ملانے کے لیے نہیں سوچا گیا اور ایسی دو تحفظ ترتیبات جنہیں کبھی موازنہ کرنے کے لیے نہیں سوچا گیا۔ دونوں میں استفسارات دیکھنا اس بات کا ثبوت ہے کہ ڈیزائن کام کرتا ہے، رساؤ کا ثبوت نہیں۔
کیش مخالف سمت میں کاٹتا ہے۔ کسی مقبول نام کا جواب گھنٹوں تک کیش سے دیا جا سکتا ہے، اس لیے حل کنندہ کا ریکارڈ پہلا استفسار دکھاتا ہے اور پھر کچھ نہیں، جبکہ صارف کا اطلاقیہ اسی نام کو خوشی سے حل کرتا رہتا ہے۔ کسی خاص وقت کے بعد اندراجات کا نہ ہونا اس بات کا مطلب نہیں کہ اس وقت کے بعد کسی نے نام استعمال نہیں کیا۔
پس منظر ٹریفک تیسری تحریف ہے۔ بوٹ پر ٹیلی میٹری نام حل کرنے والا فون، تلاش کی تجویز کا ڈومین حل کرنے والا براؤزر، اور ہر گھنٹے رابطہ کرنے والا اپ ڈیٹر—سب حل کنندہ لاگ میں اس نام کے ساتھ نظر آتے ہیں جو واقعی آپ کے لیے اہم ہے۔ اس لاگ میں مقدار توجہ نہیں، اور استفسارات گننا وزٹ گننا نہیں۔ حل کنندہ لاگ سوالات کا ریکارڈ ہے، اور سوالات بنانا سستا ہے۔
تحفظ کے سوالات الگ پوچھیں
ہر نظام کے لیے تین سوال پوچھیں: کون جمع کرتا ہے، کیا جمع ہوتا ہے، اور کتنی دیر وہ رکھا جاتا ہے. پھر پوچھیں کہ اسے کون پڑھ سکتا ہے اور کس عمل کے تحت۔ DNS over HTTPS پر RFC 8484 کی بحث اچھی یاد دہانی ہے کہ خفیہ نقل و حمل آخری نقطے کو نہیں ہٹاتا، اور آپریٹر کی اپنی دستاویزات ہی اس بارے میں واحد قابل اعتماد بیان ہے کہ وہ آخری نقطہ کیا رکھتا ہے۔
جب رازداری کے بارے میں “VPN” پر دعویٰ کیا جاتا ہے، تو اسے قبول کرنے سے پہلے اجزا میں تقسیم کریں: سرنگ کا آپریٹر، سرنگ کا فراہم کردہ حل کنندہ، کوئی بھی اوپر والا حل کنندہ جہاں یہ استفسارات پہنچتے ہیں، اور آلے پر موجود اطلاقیے۔ ہر ایک کا اپنا جواب ہے، اور جو دعویٰ ایک کے لیے درست ہے وہ معمول کے مطابق اس طرح دہرایا جاتا ہے جیسے وہ چاروں کو ڈھکتا ہو۔
مسئلہ حل کرنے کے لیے وہی تقسیم استعمال کریں۔ پوچھیں کہ کس اطلاقیے نے استفسار کیا اور کس حل کنندہ نے جواب دیا، پھر اس لاگ کو دیکھیں جو واقعی اس واقعے کا مالک ہے. دوسرے لاگ سے اندازہ لگانا ایک منٹ بچاتا ہے اور ایک دوپہر خرچ کرتا ہے۔