Basahin nang tama ang DNS ng Android: kada network, hindi resolv.conf

Kumuha ka ng shell sa device, binasa ang /etc/resolv.conf o hinukay ang lumang halaga ng net.dns1, at isang address ang nakuha mo. Ang app sa harap mo ay nagre-resolve sa ganap na ibang paraan. Sa kasalukuyang release ng Android, ang resolver ay kada network: may policy ang system para sa bawat Network at inilalapat ito sa socket na nagpadala ng kahilingan. Ang file at ang lumang property ay mga labi, at wala sa dalawa ang naglalarawan ng landas na talagang tinahak ng query mo.

Lumilitaw ang puwang na ito sa pag-deploy ng split-tunnel at Private DNS, kung saan ang dalawang app sa isang telepono ay legal na makakakita ng magkaibang sagot. Nagsisimula ang gabay na ito sa mali o kulang na pag-resolve at bumabalik sa configuration na may-ari nito.

Ang resolver ay pag-aari ng isang network, hindi ng device

Ang pag-resolve ng pangalan sa Android 9 at mas bago ay dumadaan sa system resolver na nakabatay sa Network kung saan nakatali ang socket. Bawat network ay may sariling LinkProperties, at ang mga property na iyon ay naglalaman ng listahan ng DNS server, search domains at estado ng Private DNS para sa network na iyon lamang. Wala sa modelong iyon ang tumutugma sa isang listahang pang-buong device na mababasa mo mula sa file.

Ginagawang malinaw ng VPN ang paghihiwalay. Kapag umangat ang tunnel, nagbibigay ang VPN app ng mga DNS server na nakarehistro sa sariling network ng VPN, kaya ang mga app na niruruta sa pamamagitan nito ay nagre-resolve sa mga server na iyon habang ang mga ibinukod na app ay patuloy na gumagamit ng nasa ilalim na network. Isang device, dalawang landas ng sagot, walang kontradiksyon.

Basahin ang snapshot mula sa loob ng apektadong app

Tanungin ang app mismo. Ang isang method na may Context at ang normal na pahintulot na android.permission.ACCESS_NETWORK_STATE ay makakabasa ng snapshot nang hindi hinahawakan ang mga property ng system:

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 ang default na network ng proseso mo, hindi ang nag-iisang network sa device, at maaaring null kapag walang magamit na default ang tumatawag. Ang naka-block na default na VPN ang karaniwang dahilan. Sinasabi ng isPrivateDnsActive kung ang mga query sa network na iyon ay dumadaan sa TLS papunta sa pinangalanang resolver, na nagbabago sa ipapakita ng simpleng UDP 53 probe. Ang ibabaw ng API ay dokumentado sa ilalim ng LinkProperties, at bawat halaga nito ay snapshot ng configuration, hindi patunay na may partikular na query na umabot sa partikular na server.

Kapag ang default na network ay hindi ang gumagawa ng trabaho

Ang snapshot ay sumasagot lamang para sa default. Maaaring i-bind ng app ang proseso nito o isang socket sa ibang network, at sinusundan ng pag-resolve ang pagpipiliang iyon habang ang diagnosis mo ay nag-uulat pa rin ng default. Ang browser na may sariling DNS-over-HTTPS resolver ay hindi man lang nagtatanong sa listahan ng system, kaya walang sinasabi ang mga sagot nito tungkol sa iba pang bahagi ng device. Ang work profile app ay tumatakbo sa ilalim ng hiwalay na user na may sariling policy. Suriin ang binding bago sisihin ang mga server.

Ang integrasyon ng VPN ang kabilang kalahati. Ang pagtanggap ng linyang dhcp-option DNS sa profile ng OpenVPN at ang pagrerehistro ng address na iyon sa Android VPN network ay dalawang hiwalay na hakbang, at ang kulang na ruta patungo sa server ay nabigo nang kasing tahimik ng maling address. Mula sa development machine, ipiniprint ng adb shell dumpsys connectivity ang parehong link properties kada network kapag pinapayagan ng build, na nagpapatunay sa listahan nang hindi nagsusulat ng code.

Ihambing ang configuration sa isang pag-resolve na pinapayagan mong gawin

Pumili ng pangalan na dapat ma-resolve sa private namespace at isang pampublikong pangalan, at itala ang dalawang resulta sa tabi ng snapshot: network, mga naka-configure na server, estado ng Private DNS at ang eksaktong teksto ng error. Ang direktang query sa pinangalanang server ay nagpapatunay na sumasagot sa iyo ang server na iyon; hindi nito pinapatunayan na pinili ito ng ordinaryong pag-resolve ng app. Ang sagot mula sa cache ay hindi bagong pagsubok, kaya i-clear ang cache o gumamit ng pangalan na wala pang nagtatanong ngayong araw.

Kung ang resolver ay naglilingkod lamang sa mga client mula sa isang partikular na access network, ang nakikita nito pagkatapos ng VPN egress ay maaaring magpasiya ng resulta, at ito ay tanong ng policy para sa nagpapatakbo nito, hindi patunay na hinaharangan ng mga operator ang UDP 53. Kung saan aktibo ang Private DNS, ang hindi kwalipikadong hostname ay maaaring tanggihan ayon sa disenyo habang ang parehong server ay normal na sumasagot sa mga pampublikong pangalan. Ang pagbasa ng mga property ay nagsasabi kung aling mode ang umiiral, kaya tumitigil ka sa paghula ng mga packet filter.

Ayusin ang layer na may-ari ng mismatch

Magtrabaho pataas sa halip na i-edit ang global na estado. Kung ang app ay nakatali sa maling network, ayusin ang binding. Kung ang profile ay nagbibigay ng maling DNS option, ayusin ang profile. Kung ang Private DNS ay mahigpit sa network na hindi kayang pagsilbihan ng resolver nito ang private zone mo, iyon ay desisyon ng pamamahala ng device, hindi dahilan para patayin ang feature sa lahat ng dako.

Ang pagtulak ng mga pampublikong resolver sa DHCP hook o system property ang pag-aayos na patuloy na nagdudulot ng insidente: tumitigil ang pag-resolve ng mga private na pangalan, nabubuhay ang pagbabago nang mas matagal kaysa sa VPN session, at ang susunod na tao sa device ay makakahanap ng lumang address na walang may-ari. Panatilihin ang pagbabago sa loob ng VPN, app o management layer na may-ari ng mismatch, pagkatapos basahin muli ang snapshot upang kumpirmahing talagang nagbago ang listahan ng server.

Sa huli, ang gusto mo ay isang request ng app na nakatali sa isang network, listahan ng resolver at estado ng Private DNS. Kapag naipakita mo ang kadena na iyon, ang pamilyar na address sa isang file ay hindi na patunay ng anuman.