Android-DNS goed lêze: per netwurk, net yn resolv.conf

Do krijst in shell op it apparaat, lêst /etc/resolv.conf of groevet in âlde net.dns1-wearde op, en do krijst ien adres. De app foar dy lost op fia hiel wat oars. Op in aktuele Android-ferzje is de resolver per netwurk: it systeem hâldt in belied foar elk Network en past dat ta op de socket dy't it fersyk dien hat. It bestân en de âlde eigenskip binne oerbliuwsels, en gjinien fan beide beskriuwt it paad dat dyn fraach wier nommen hat.

Dat gat lit him sjen by de útrol fan split-tunnel en Private DNS, wêr't twa apps op deselde tillefoan mei rjocht ferskillende antwurden sjogge. Dizze rûn begjint by de ferkearde of ûntbrekkende opfraach en wurket werom nei de konfiguraasje dy't der eigner fan is.

De resolver heart by in netwurk, net by it apparaat

Namme-oplossing op Android 9 en letter giet fia in systeemresolver dy't him basearret op it Network wêr't in socket oan ferbûn is. Elk netwurk draacht syn eigen LinkProperties, en dy eigenskippen befetsje de DNS-tsjinnerlist, de sykdomeinen en de Private DNS-tastân foar dat netwurk allinnich. Neat yn dat model komt oerien mei ien apparaatbrede list dy'tst út in bestân lêze kinst.

In VPN makket de splitsing dúdlik. As de tunnel omheech komt, leveret de VPN-app DNS-tsjinners dy't op it eigen netwurk fan 'e VPN registrearre binne, sadat apps dy't der trochhinne rûte wurde tsjin dy tsjinners oplosse wylst útsletten apps it ûnderlizzende netwurk bliuwe brûken. Ien apparaat, twa antwurdpaden, gjin tsjinstridichheid.

Lês de momintopname fanút de belutsen app

Freegje it de app sels. In metoade mei in Context en de normale tastimming android.permission.ACCESS_NETWORK_STATE kin de momintopname lêze sûnder systeemeigenskippen oan te reitsen:

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 is de standert foar dyn proses, net it iennige netwurk op it apparaat, en kin null wêze as de oanropper gjin brûkbere standert hat. In blokkearre VPN-standert is de gewoane reden. isPrivateDnsActive fertelt dy oft fragen op dat netwurk oer TLS nei in neamde resolver geane, wat feroaret wat in gewoane UDP 53-probe dy sjen lit. It API-oerflak is dokumintearre ûnder LinkProperties, en elke wearde deryn is in momintopname fan konfiguraasje en gjin bewiis dat in beskate fraach in beskate tsjinner berikt hat.

As it standertnetwurk net it netwurk is dat it wurk docht

De momintopname antwurdet allinnich foar de standert. In app kin syn proses of ien socket oan in oar netwurk ferbine, en dan folget de opfraach dy kar wylst dyn diagnostyk noch altyd de standert meldt. In browser mei syn eigen DNS-over-HTTPS-resolver rieplachtet de systeemlist hielendal net, dus syn antwurden sizze neat oer de rest fan it apparaat. In wurkprofyl-app rint ûnder in aparte brûker mei eigen belied. Kontrolearje de binding foardatst de tsjinners de skuld joust.

VPN-ynbouding is de oare helte. In dhcp-option DNS-rigel yn in OpenVPN-profyl ûntfange en dat adres op it Android-VPN-netwurk registrearje binne twa aparte stappen, en in ûntbrekkende rûte nei de tsjinner mislearret like stil as in ferkeard adres. Fan in ûntwikkelmasine ôf prints adb shell dumpsys connectivity deselde keppeleigenskippen per netwurk as de build it talit, wat de list befêstiget sûnder koade te skriuwen.

Fergelykje konfiguraasje mei ien opfraach dy'tst dwaan meiest

Kies in namme dy't yn 'e partikuliere nammeromte oplosse moat en ien iepenbiere namme, en skriuw beide resultaten njonken de momintopname: netwurk, konfigurearre tsjinners, Private DNS-tastân en de krekte flatertekst. In direkte fraach oan in neamde tsjinner bewiist dat dy tsjinner dy antwurdet; it bewiist net dat gewoane tapassingoplossing him keazen hat. In cache-antwurd is gjin farske test, dus leegje de cache of brûk in namme dy't hjoed noch nimmen opfrege hat.

As de resolver allinnich kliïnten fan in beskaat tagongsnetwurk betsjinnet, kin wat hy nei VPN-útgong sjocht de útkomst besljochtsje, en dat is in beliedsfraach foar wa't him beheart, gjin bewiis dat oanbieders UDP 53 blokkearje. Wêr't Private DNS aktyf is, kin in net-kwalifisearre hostnamme by ûntwerp wegere wurde wylst deselde tsjinner iepenbiere nammen normaal antwurdet. De eigenskippen lêze fertelt dy hokker modus jildt, sadatst ophâldst mei rieden oer pakketfilters.

Reparearje de laach dy't eigner is fan 'e mismatch

Wurk omheech ynstee fan globale tastân te bewurkjen. Is de app oan it ferkearde netwurk ferbûn, reparearje de binding. Leveret it profyl de ferkearde DNS-opsje, reparearje it profyl. Is Private DNS strang op in netwurk wêrfan't de resolver dyn partikuliere sône net betsjinje kin, dan is dat in beslissing fan apparaatbehear en gjin reden om de funksje oeral út te skeakeljen.

Iepenbiere resolvers yn in DHCP-heak of systeemeigenskip twinge is de reparaasje dy't mar ynsidinten bliuwt feroarsaakjen: partikuliere nammen hâlde op mei oplossen, de feroaring oerlibbet de VPN-sesje, en de folgjende persoan op it apparaat fynt in ferâldere adres sûnder eigner. Hâld de feroaring yn 'e VPN, de app of de behearlaach dy't eigner is fan 'e mismatch, en lês dêrnei de momintopname op 'e nij om te befêstigjen dat de tsjinnerlist wier feroare is.

Watst úteinlik wolst, is ien app-fersyk keppele oan ien netwurk, resolverlist en Private DNS-tastân. Sadree'tst dy keatling sjen litte kinst, is in bekende adres yn in bestân gjin bewiis mear foar wat dan ek.