VPN کے بغیر خفیہ کردہ DNS استفسار چھپاتا ہے، آپ کا پتہ نہیں

آپ کے گھریلو نیٹ ورک کو دکھانے والی DNS رساؤ کی جانچ اس بات کا ثبوت نہیں کہ خفیہ کردہ DNS ناکام ہوا، اور اس بات کا بھی ثبوت نہیں کہ کچھ کام کیا۔ جانچ ایک سوال کا جواب دیتی ہے: یہ استفسار اس نیٹ ورک سے کس حل کنندہ تک پہنچا۔ یہ مسئلہ ہے یا نہیں، یہ اس بات پر منحصر ہے کہ آپ کس سے اور کس سے بچا رہے تھے۔

کوئی بھی جانچ چلانے سے پہلے ہدف لکھیں۔

مرحلہ 1: اُس حفاظت کا نام لیں جو آپ واقعی چاہتے ہیں

تین ہدف مل جل جاتے ہیں۔ آپ چاہ سکتے ہیں کہ راستے پر موجود کوئی نگران استفسارات پڑھنا بند کر دے۔ آپ چاہ سکتے ہیں کہ کوئی مخصوص حل کنندہ اُنہیں وصول کرنا بند کر دے۔ آپ چاہ سکتے ہیں کہ آپ کی ملاقات والی ویب سائٹیں آپ کا گھریلو پتہ دیکھنا بند کر دیں. خفیہ کردہ DNS پہلے کی خدمت کرتا ہے، بدلتا ہے کہ دوسرا کون پورا کرتا ہے، اور تیسرے کے لیے کچھ نہیں کرتا۔

VPN تیسرے کی خدمت کرتا ہے اور فراہم کنندہ کے لحاظ سے پہلے کی بھی۔ دونوں میں سے کوئی بھی آلہ دوسرے کا سپر سیٹ نہیں۔

مرحلہ 2: ایک حل کنندہ چنیں اور اُس کی شناخت کی تصدیق کریں

DNS over TLS استفسار کو حل کنندہ کے ساتھ TLS نشست میں لپیٹتا ہے، اور DNS over HTTPS اُسے HTTP درخواست میں لپیٹتا ہے؛ RFC 7858 اور RFC 8484 دونوں کی وضاحت کرتے ہیں، اور کسی کو بھی سرنگ کی ضرورت نہیں۔ عملی طور پر اہم یہ ہے کہ سرٹیفکیٹ اُس نام کے خلاف تصدیق ہو جو آپ نے ترتیب دیا، کیونکہ غلط فریق کے ساتھ خفیہ نشست درست فریق کے ساتھ سادہ متن سے بدتر ہے۔ اس کا مطلب ہے کہ جہاں پلیٹ فارم پیش کرے وہاں سخت موڈ، نہ کہ موقع پرست موڈ جو تصدیق ناکام ہونے پر پیچھے ہٹ جائے۔ ترتیب پر بھروسہ کرنے سے پہلے نشست براہ راست جانچیں: openssl s_client -connect 9.9.9.9:853 -servername dns.quad9.net -brief.

ہاتھ ملانا چاہیے کہ آپ کے ترتیب کردہ حل کنندہ کا نام لے اور ایسی زنجیر واپس دے جس کی آپ تصدیق کر سکیں۔

مرحلہ 3: ناکامی کے وقت رویہ طے کریں

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

systemd-resolved پر موقع پرست موڈ نہیں، DNSOverTLS=yes منتخب کریں؛ دوسری قدر، opportunistic; اور Android پر اس کا مطلب ہے خودکار کے بجائے Private DNS ہوسٹ نام موڈ۔

اصل میں کیا نافذ ہے یہ اِس سے جانچیں: resolvectl status | grep -i -A1 "dns over tls"، کیونکہ کبھی دوبارہ لوڈ نہ ہونے والی drop-in فائل کچھ نہیں بدلتی۔

مرحلہ 4: جانچیں کہ ایپلیکیشنز سسٹم حل کنندہ کی پیروی کرتی ہیں

اپنی محفوظ-DNS ترتیب رکھنے والا براؤزر سسٹم کنفیگریشن کو مکمل طور پر نظر انداز کرتا ہے، اور ایمبیڈڈ حل کنندہ والا کنٹینر رن ٹائم یا سخت کوڈ شدہ فہرست پڑھنے والا زبان رن ٹائم بھی ایسا ہی کرتا ہے۔ یا اُنہیں سسٹم کی پیروی کرنے دیں یا واضح طور پر ترتیب دیں اور یہ لکھیں۔ پھر ہر ایک کے فال بیک رویے کو دیکھیں، کیونکہ سب بند انداز میں ناکام نہیں ہوتے۔ فہرست عملاً مختصر ہے: براؤزر، کنٹینر رن ٹائم، اور کوئی بھی VPN کلائنٹ جو آپ بھی چلاتے ہیں۔

ادارے کے نجی نام منظور شدہ اندرونی حل کنندہ پر ہی رہتے ہیں۔ جانچ کو صاف دکھانے کے لیے اُنہیں عوامی سروس پر بھیجنا جان بوجھ کر الگ مسئلہ پیدا کرتا ہے۔

مرحلہ 5: ضرورت کے مقابلے میں رساؤ کی جانچ پڑھیں

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

اگر ہدف استفسارات کو مقامی نیٹ ورک سے دور رکھنا تھا، تو آپ کا عام حل کنندہ دکھانے والی جانچ حقیقی دریافت ہے۔ اگر ہدف براؤزنگ کے دوران گمنامی تھی، تو کوئی DNS ترتیب اُسے کبھی نہ دے سکتی۔

قبولیت کی سطر ہدف کی زبان میں لکھیں: یہ تلاشیں اِن شرائط کے تحت اِس تصدیق شدہ حل کنندہ کو استعمال کرتی ہیں۔ اس سے وسیع کوئی بھی چیز ایسا دعویٰ ہے جسے آپ جانچ نہیں سکتے۔