اینڈرائیڈ DNS درست پڑھیں: نیٹ ورک کے حساب سے، resolv.conf میں نہیں

آپ ڈیوائس پر shell لیتے ہیں، /etc/resolv.conf پڑھتے ہیں یا پرانی net.dns1 قدر کھودتے ہیں، اور ایک پتہ ملتا ہے۔ آپ کے سامنے کی ایپ بالکل کسی اور چیز سے حل کرتی ہے۔ موجودہ اینڈرائیڈ ریلیز میں resolver ہر نیٹ ورک کے حساب سے ہے: سسٹم ہر Network کے لیے پالیسی رکھتا ہے اور اُسے اُس socket پر لاگو کرتا ہے جس نے درخواست بھیجی۔ فائل اور پرانی خصوصیت باقیات ہیں اور ان میں سے کوئی بھی وہ راستہ بیان نہیں کرتا جو آپ کی استفسار نے واقعی طے کیا۔

یہ خلا split-tunnel اور Private DNS کے آغاز میں نظر آتا ہے، جہاں ایک ہی فون پر دو ایپیں جائز طور پر مختلف جواب دیکھ سکتی ہیں۔ یہ رہنما غلط یا غائب حل سے شروع ہوتا ہے اور اُس کنفیگریشن کی طرف واپس جاتا ہے جس کی یہ ملکیت ہے۔

resolver کا تعلق نیٹ ورک سے ہے، ڈیوائس سے نہیں

اینڈرائیڈ 9 اور بعد میں ناموں کا حل ایک سسٹم resolver سے گزرتا ہے جو اُس Network پر مبنی ہے جس سے socket بندھا ہے۔ ہر نیٹ ورک اپنی LinkProperties رکھتا ہے، اور یہ خصوصیات صرف اُسی نیٹ ورک کے DNS سرورز کی فہرست، تلاش کے ڈومین اور Private DNS کی حالت رکھتی ہیں۔ اِس ماڈل میں کوئی چیز ایسی واحد ڈیوائس بھر کی فہرست سے مطابقت نہیں رکھتی جو آپ فائل سے پڑھ سکیں۔

VPN اِس تقسیم کو واضح کرتا ہے۔ جب ٹنل اُٹھتا ہے، VPN ایپ ایسے DNS سرورز فراہم کرتی ہے جو خود VPN کے نیٹ ورک پر رجسٹر ہیں، لہٰذا اُس سے گزرنے والی ایپیں اُن سرورز سے حل کرتی ہیں جبکہ خارج شدہ ایپیں نیچے والا نیٹ ورک استعمال کرتی رہتی ہیں۔ ایک ڈیوائس، دو جوابی راستے، کوئی تضاد نہیں۔

اسنیپ شاٹ متاثرہ ایپ کے اندر سے پڑھیں

خود ایپ سے پوچھیں۔ ایسا میتھڈ جس کے پاس Context اور عام android.permission.ACCESS_NETWORK_STATE اجازت ہو، سسٹم خصوصیات کو چھوئے بغیر اسنیپ شاٹ پڑھ سکتا ہے:

val cm = getSystemService(ConnectivityManager::class.java) ?: return
val network = cm.activeNetwork
val links = network?.let { cm.getLinkProperties(it) }

val dnsServers = links?.dnsServers
val privateDnsActive = links?.isPrivateDnsActive
val privateDnsName = links?.privateDnsServerName

activeNetwork آپ کے عمل کا ڈیفالٹ نیٹ ورک ہے، ڈیوائس کا واحد نیٹ ورک نہیں، اور null ہو سکتا ہے جب کال کرنے والے کے پاس قابلِ استعمال ڈیفالٹ نہ ہو۔ مسدود ڈیفالٹ VPN عام وجہ ہے۔ isPrivateDnsActive بتاتا ہے کہ اُس نیٹ ورک کی استفساریں TLS کے ذریعے نامزد resolver تک جاتی ہیں یا نہیں، جو بدلتا ہے کہ سادہ UDP 53 جانچ آپ کو کیا دکھائے گی۔ API سطح LinkProperties کے تحت دستاویزی ہے، اور اُس میں ہر قدر کنفیگریشن کا اسنیپ شاٹ ہے، اِس بات کا ثبوت نہیں کہ کوئی مخصوص استفسار کسی مخصوص سرور تک پہنچا۔

جب ڈیفالٹ نیٹ ورک وہ نہ ہو جو کام کر رہا ہو

اسنیپ شاٹ صرف ڈیفالٹ کے لیے جواب دیتا ہے۔ ایپ اپنا عمل یا ایک socket کسی دوسرے نیٹ ورک سے باندھ سکتی ہے، پھر حل اُس انتخاب کی پیروی کرتا ہے جبکہ آپ کی تشخیص اب بھی ڈیفالٹ بتاتی ہے۔ اپنا DNS-over-HTTPS resolver لانے والا براؤزر سسٹم فہرست سے بالکل رجوع نہیں کرتا، اِس لیے اُس کے جوابات باقی ڈیوائس کے بارے میں کچھ نہیں کہتے۔ ورک پروفائل ایپ الگ صارف کے تحت اپنی پالیسی کے ساتھ چلتی ہے۔ سرورز کو قصوروار ٹھہرانے سے پہلے بائنڈنگ دیکھیں۔

VPN انضمام دوسرا نصف ہے۔ dhcp-option DNS سطر OpenVPN پروفائل میں وصول کرنا اور اُس پتے کو اینڈرائیڈ VPN نیٹ ورک پر رجسٹر کرنا دو الگ مراحل ہیں، اور سرور تک گم شدہ راستہ غلط پتے کی طرح ہی خاموشی سے ناکام ہوتا ہے۔ ڈویلپمنٹ مشین سے adb shell dumpsys connectivity وہی لنک خصوصیات فی نیٹ ورک چھاپتا ہے جب build اجازت دے، جو کوڈ لکھے بغیر فہرست کی تصدیق کرتا ہے۔

کنفیگریشن کا موازنہ ایک ایسے حل سے کریں جس کا آپ کو اختیار ہو

ایک ایسا نام چنیں جو نجی نام کی جگہ میں حل ہونا ضروری ہو اور ایک عوامی نام، اور دونوں نتائج اسنیپ شاٹ کے ساتھ لکھیں: نیٹ ورک، تشکیل شدہ سرورز، Private DNS کی حالت اور خطا کا عین متن۔ نامزد سرور سے براہِ راست استفسار ثابت کرتا ہے کہ وہ سرور آپ کو جواب دیتا ہے؛ یہ ثابت نہیں کرتا کہ عام ایپ حل نے اُسے چنا۔ کیشے میں محفوظ جواب تازہ جانچ نہیں، اِس لیے کیشے صاف کریں یا ایسا نام استعمال کریں جس کے بارے میں آج کسی نے نہ پوچھا ہو۔

اگر resolver صرف کسی خاص رسائی نیٹ ورک کے کلائنٹس کی خدمت کرتا ہے، تو VPN سے باہر نکلنے کے بعد وہ جو دیکھتا ہے نتیجہ طے کر سکتا ہے، اور یہ اُس شخص کے لیے پالیسی کا سوال ہے جو اُسے چلاتا ہے، نہ کہ اِس بات کا ثبوت کہ آپریٹرز UDP 53 بلاک کرتے ہیں۔ جہاں Private DNS فعال ہو، غیر مکمل ہوسٹ نام ڈیزائن کے تحت مسترد ہو سکتا ہے جبکہ وہی سرور عوامی ناموں کا معمول کے مطابق جواب دیتا ہے۔ خصوصیات پڑھنا بتاتا ہے کہ کون سی کیفیت نافذ ہے، تو آپ پیکٹ فلٹرز کا اندازہ لگانا چھوڑ دیتے ہیں۔

اُس تہہ کو درست کریں جس کی ملکیت میں یہ عدم مطابقت ہے

عالمی حالت میں ترمیم کے بجائے اوپر کی طرف کام کریں۔ اگر ایپ غلط نیٹ ورک سے بندھی ہے تو بائنڈنگ درست کریں۔ اگر پروفائل غلط DNS اختیار دیتا ہے تو پروفائل درست کریں۔ اگر Private DNS ایسے نیٹ ورک پر سخت ہے جس کا resolver آپ کے نجی زون کی خدمت نہیں کر سکتا، تو یہ ڈیوائس مینجمنٹ کا فیصلہ ہے، ہر جگہ خصوصیت بند کرنے کی وجہ نہیں۔

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

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