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 ऐप वे 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 प्रोफ़ाइल में पाना और उस पते को Android 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 स्थिति से बँधा हो। जब आप यह शृंखला दिखा सकें, फ़ाइल में कोई जाना-पहचाना पता किसी चीज़ का प्रमाण नहीं रह जाता।

संबंधित लेख