Четете Android DNS правилно: по мрежа, не в resolv.conf

Получавате шел на устройството, четете /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 отпечатва същите свойства на връзката по мрежа, когато билдът го позволява, което потвърждава списъка без писане на код.

Сравнете конфигурацията с едно резолвване, което ви е позволено

Изберете име, което трябва да се резолвне в частното пространство от имена, и едно публично име, и запишете двата резултата до снимката: мрежа, конфигурирани сървъри, състояние на Private DNS и точния текст на грешката. Директна заявка към именуван сървър доказва, че този сървър ви отговаря; не доказва, че обичайното резолвване на приложението го е избрало. Отговор от кеша не е свеж тест, затова изчистете кеша или използвайте име, за което днес никой не е питал.

Ако resolver-ът обслужва само клиенти от определена достъпна мрежа, това, което вижда след излизането от VPN, може да реши изхода, а това е въпрос на политика за този, който го управлява, не доказателство, че операторите блокират UDP 53. Където Private DNS е активен, неквалифицирано име на хост може да бъде отказано по дизайн, докато същият сървър нормално отговаря на публични имена. Четенето на свойствата ви казва кой режим е в сила, така че спирате да гадаете филтри на пакети.

Поправете слоя, на който принадлежи несъответствието

Работете нагоре, вместо да редактирате глобално състояние. Ако приложението е вързано към грешната мрежа, поправете връзката. Ако профилът доставя грешната DNS опция, поправете профила. Ако Private DNS е строг в мрежа, чийто resolver не може да обслужва частната ви зона, това е решение на управлението на устройството, а не причина да изключите функцията навсякъде.

Натрапването на публични resolver-и в DHCP hook или системно свойство е поправката, която непрекъснато причинява инциденти: частните имена спират да се резолвват, промяната надживява VPN сесията и следващият човек на устройството намира остарял адрес без собственик. Дръжте промяната в VPN-а, приложението или слоя за управление, на който принадлежи несъответствието, и след това прочетете снимката отново, за да потвърдите, че списъкът със сървъри наистина се е променил.

На края искате една заявка на приложението, вързана към една мрежа, списък с resolver-и и състояние на Private DNS. Щом можете да покажете тази верига, познат адрес във файл престава да бъде доказателство за каквото и да е.