Android DNS সঠিকভাবে পড়ুন: নেটওয়ার্ক অনুযায়ী, resolv.conf-এ নয়

আপনার Android অ্যাপ প্রতিটি নেটওয়ার্কের resolver দিয়ে সমাধান করে, আপনি এইমাত্র পড়া resolv.conf দিয়ে নয়। আগে LinkProperties, socket বাইন্ডিং এবং Private DNS দেখুন।

আপনি ডিভাইসে shell নেন, /etc/resolv.conf পড়েন বা পুরোনো net.dns1 মান খুঁড়ে বের করেন, এবং একটি ঠিকানা পান। আপনার সামনের অ্যাপ সম্পূর্ণ অন্য কিছু দিয়ে সমাধান করে। বর্তমান Android সংস্করণে resolver নেটওয়ার্ক অনুযায়ী: সিস্টেম প্রতিটি Network-এর জন্য নীতি রাখে এবং তা সেই socket-এ প্রয়োগ করে যা অনুরোধ পাঠিয়েছে। ফাইলটি ও পুরোনো বৈশিষ্ট্য অবশেষ, এবং কোনোটিই আপনার কোয়েরি আসলে যে পথ নিয়েছে তা বর্ণনা করে না।

এই ফাঁক split-tunnel ও Private DNS রোলআউটে দেখা যায়, যেখানে একই ফোনের দুই অ্যাপ বৈধভাবে ভিন্ন উত্তর দেখতে পারে। এই নির্দেশিকা ভুল বা অনুপস্থিত সমাধান থেকে শুরু হয় এবং যে কনফিগারেশনের এটি মালিক সেদিকে ফিরে যায়।

resolver নেটওয়ার্কের, ডিভাইসের নয়

Android 9 ও পরবর্তীতে নাম সমাধান একটি সিস্টেম resolver দিয়ে যায় যা সেই Network-এর উপর নির্ভর করে যেখানে socket বাঁধা। প্রতিটি নেটওয়ার্ক নিজের LinkProperties বহন করে, এবং এই বৈশিষ্ট্যগুলো কেবল সেই নেটওয়ার্কের জন্য DNS সার্ভারের তালিকা, অনুসন্ধান ডোমেইন ও Private DNS অবস্থা রাখে। সেই মডেলে ফাইল থেকে পড়া যায় এমন একক ডিভাইস-ব্যাপী তালিকার সাথে মেলে এমন কিছু নেই।

VPN এই বিভাজন স্পষ্ট করে। টানেল উঠলে VPN অ্যাপ VPN-এর নিজের নেটওয়ার্কে নিবন্ধিত DNS সার্ভার দেয়, তাই এর মধ্য দিয়ে রাউট হওয়া অ্যাপ সেই সার্ভারগুলোতে সমাধান করে আর বাদ দেওয়া অ্যাপ নিচের নেটওয়ার্ক ব্যবহার করে চলে। একটি ডিভাইস, দুটি উত্তরপথ, কোনো বিরোধ নেই।

স্ন্যাপশট আক্রান্ত অ্যাপের ভেতর থেকে পড়ুন

অ্যাপকেই জিজ্ঞেস করুন। যে মেথডের 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 প্রোফাইলে গ্রহণ করা এবং সেই ঠিকানা Android VPN নেটওয়ার্কে নিবন্ধ করা দুটি আলাদা ধাপ, আর সার্ভার পর্যন্ত হারানো পথ ভুল ঠিকানার মতোই নিঃশব্দে ব্যর্থ হয়। ডেভেলপমেন্ট মেশিন থেকে adb shell dumpsys connectivity একই লিঙ্ক বৈশিষ্ট্য প্রতি নেটওয়ার্কে ছাপে যখন build অনুমতি দেয়, যা কোড না লিখেই তালিকা নিশ্চিত করে।

কনফিগারেশন এমন এক সমাধানের সাথে তুলনা করুন যা করার অনুমতি আপনার আছে

এমন একটি নাম বাছুন যা ব্যক্তিগত নামস্থানে সমাধান হওয়া আবশ্যক এবং একটি সার্বজনীন নাম, এবং দুটি ফলাফলই স্ন্যাপশটের পাশে লিখুন: নেটওয়ার্ক, কনফিগার করা সার্ভার, Private DNS অবস্থা এবং ত্রুটির হুবহু পাঠ। নামযুক্ত সার্ভারে সরাসরি কোয়েরি প্রমাণ করে যে সার্ভারটি আপনাকে উত্তর দেয়; এটি প্রমাণ করে না যে সাধারণ অ্যাপ সমাধান তাকেই বেছেছে। ক্যাশে থাকা উত্তর নতুন পরীক্ষা নয়, তাই ক্যাশ খালি করুন বা আজ কেউ না-জিজ্ঞেস করা নাম ব্যবহার করুন।

resolver যদি কেবল নির্দিষ্ট অ্যাক্সেস নেটওয়ার্কের ক্লায়েন্টকে সেবা দেয়, তবে VPN নির্গমনের পরে সে যা দেখে তা ফলাফল নির্ধারণ করতে পারে, এবং এটি তার পরিচালকের জন্য নীতির প্রশ্ন, অপারেটররা UDP 53 ব্লক করে—এর প্রমাণ নয়। যেখানে Private DNS সক্রিয়, সেখানে অসম্পূর্ণ হোস্টনাম ডিজাইন অনুযায়ী প্রত্যাখ্যাত হতে পারে আর একই সার্ভার সার্বজনীন নামে স্বাভাবিক উত্তর দেয়। বৈশিষ্ট্য পড়লে বোঝা যায় কোন মোড কার্যকর, তাই আপনি প্যাকেট ফিল্টার অনুমান করা ছেড়ে দেন।

যে স্তরের এই অসঙ্গতি সেটিই ঠিক করুন

বৈশ্বিক অবস্থা সম্পাদনার বদলে উপরের দিকে কাজ করুন। অ্যাপ ভুল নেটওয়ার্কে বাঁধা থাকলে বাইন্ডিং ঠিক করুন। প্রোফাইল ভুল DNS অপশন দিলে প্রোফাইল ঠিক করুন। যে নেটওয়ার্কের resolver আপনার ব্যক্তিগত জোনে সেবা দিতে পারে না সেখানে Private DNS কঠোর হলে এটি ডিভাইস ব্যবস্থাপনার সিদ্ধান্ত, সর্বত্র সুবিধা বন্ধ করার কারণ নয়।

সার্বজনীন resolver-গুলোকে DHCP হুকে বা সিস্টেম বৈশিষ্ট্যে ঠেলে দেওয়া সেই মেরামত যা অবিরত ঘটনা ঘটায়: ব্যক্তিগত নাম সমাধান হওয়া বন্ধ হয়, পরিবর্তন VPN সেশন ছাড়িয়ে টেকে, এবং ডিভাইসে পরের ব্যক্তি মালিকহীন পুরোনো ঠিকানা পান। পরিবর্তনটি VPN, অ্যাপ বা যে ব্যবস্থাপনা স্তরের এই অসঙ্গতি তার ভেতরেই রাখুন, তারপর স্ন্যাপশট আবার পড়ে নিশ্চিত করুন সার্ভার তালিকা সত্যিই বদলেছে।

শেষে আপনি চান একটি নেটওয়ার্ক, resolver তালিকা ও Private DNS অবস্থার সাথে বাঁধা একটি অ্যাপ অনুরোধ। এই শৃঙ্খল দেখাতে পারলে ফাইলের চেনা ঠিকানা আর কোনো কিছুর প্রমাণ থাকে না।

সম্পর্কিত নিবন্ধ