Читајте 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 ги испишува истите особини на врска по мрежа кога build-от тоа го дозволува, што ја потврдува листата без пишување код.

Спореди ја конфигурацијата со едно решавање што смееш да го направиш

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

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

Поправи го слојот на кој му припаѓа несовпаѓањето

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

Наметнувањето јавни resolver-и во DHCP кука или системска особина е поправката што постојано предизвикува инциденти: приватните имиња престануваат да се решаваат, промената ја надживува сесијата на VPN-от, и следната личност на уредот наоѓа застарена адреса без сопственик. Држи ја промената внатре во VPN-от, апликацијата или слојот на управување на кој му припаѓа несовпаѓањето, па потоа повторно прочитај го снимокот за да потврдиш дека листата сервери навистина се сменила.

Она што го сакаш на крајот е едно барање на апликацијата врзано за една мрежа, листа resolver-и и состојба на Private DNS. Кога можеш да го покажеш тој ланец, позната адреса во датотека престанува да биде доказ за ништо.