Les Android-DNS rett: per nettverk, ikkje i resolv.conf

Du får eit skal på eininga, les /etc/resolv.conf eller grev fram ein gammal net.dns1-verdi, og får éin adresse. Appen framfor deg løyser opp via noko heilt anna. På ein gjeldande Android-versjon er resolvaren per nettverk: systemet held ein policy for kvart Network og brukar han på socketen som sende førespurnaden. Fila og den gamle eigenskapen er restar, og ingen av dei skildrar vegen førespurnaden din faktisk tok.

Det gapet syner seg under utrulling av split-tunnel og Private DNS, der to apper på same telefon med rette kan sjå ulike svar. Denne gjennomgangen startar ved den feilaktige eller manglande oppslaget og arbeider bakover til konfigurasjonen som eig det.

Resolvaren høyrer til eit nettverk, ikkje eininga

Namneoppslag på Android 9 og nyare går gjennom ein systemresolver som tek utgangspunkt i Network-en ein socket er bunden til. Kvart nettverk har sine eigne LinkProperties, og desse eigenskapane inneheld DNS-serverlista, søkjedomena og Private DNS-tilstanden for berre det nettverket. Ingenting i den modellen svarar til éi einingdekkjande liste du kan lese frå ei fil.

Ein VPN gjer delinga tydeleg. Når tunnelen kjem opp, leverer VPN-appen DNS-servarar som vert registrerte på VPN-en sitt eige nettverk, slik at apper som vert ruta gjennom han løyser opp mot desse servarane medan utelukka apper held fram med å bruke det underliggjande nettverket. Éi eining, to svarvegar, inga motseling.

Les augneblinksbiletet frå den råka appen

Spør appen sjølv. Ein metode som har ein Context og den vanlege løyva android.permission.ACCESS_NETWORK_STATE, kan lese augneblinksbiletet utan å røre systemeigenskapar:

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 er standarden for prosessen din, ikkje det einaste nettverket på eininga, og han kan vere null når kallaren ikkje har ein brukande standard. Ein blokkert VPN-standard er den vanlege årsaka. isPrivateDnsActive fortel om førespurnader på det nettverket går over TLS til ein namngjeven resolver, noko som endrar kva ein vanleg UDP 53-probe viser deg. API-flata er dokumentert under LinkProperties, og kvar verdi i henne er eit augneblinksbilete av konfigurasjonen og ikkje prov for at ein bestemt førespurnad nådde ein bestemt server.

Når standardnettverket ikkje er det som gjer jobben

Augneblinksbiletet svarar berre for standarden. Ein app kan binde prosessen eller éin einaste socket til eit anna nettverk, og då følgjer oppslaget det valet medan diagnosen din framleis rapporterer standarden. Ein nettlesar som leverer sin eigen DNS-over-HTTPS-resolver, spør aldri systemlista, så svara seier ingenting om resten av eininga. Ein arbeidsprofil-app køyrer under ein separat brukar med eigen policy. Kontroller bindinga før du gir servarane skulda.

VPN-integrasjonen er den andre halvdelen. Å ta imot ei dhcp-option DNS-linje i ein OpenVPN-profil og å registrere adressa på Androids VPN-nettverk er to separate steg, og ei manglande rute til serveren feilar like stille som ei feil adresse. Frå ein utviklarmaskin skriv adb shell dumpsys connectivity ut dei same lenkjeegenskapane per nettverk når bygget tillèt det, noko som stadfester lista utan å skrive kode.

Samanlikn konfigurasjonen med eitt oppslag du har lov til å gjere

Vel eit namn som må løysast opp i det private namnerommet og eit offentleg namn, og noter begge resultata ved sida av augneblinksbiletet: nettverk, konfigurerte servarar, Private DNS-tilstand og den nøyaktige feilteksten. Ein direkte førespurnad til ein namngjeven server provar at den serveren svarar deg; det provar ikkje at det vanlege appoppslaget valde han. Eit bufra svar er ikkje ein fersk test, så tøm bufferen eller bruk eit namn ingen har spurt om i dag.

Viss resolvaren berre betener klientar frå eit bestemt tilgangsnettverk, kan det han ser etter VPN-utgangen avgjere utfallet, og det er eit policy-spørsmål for den som driv han, ikkje prov for at operatørar blokkerer UDP 53. Der Private DNS er aktivt, kan eit ukvalifisert vertsnamn verte avvist ved design medan same server svarar offentlege namn normalt. Å lese eigenskapane fortel kva modus som gjeld, så du sluttar å gjette på pakkefilter.

Reparer laget som eig avviket

Arbeid oppover i staden for å redigere global tilstand. Er appen bunden til feil nettverk, reparer bindinga. Leverer profilen feil DNS-alternativ, reparer profilen. Er Private DNS strengt på eit nettverk der resolvaren ikkje kan betene den private sona di, er det eit vedtak for einingadministrasjonen og ikkje ein grunn til å slå av funksjonen overalt.

Å tvinge offentlege resolvarar inn i ein DHCP-krok eller ein systemeigenskap er reparasjonen som stadig valdar hendingar: private namn sluttar å løysast opp, endringa overlever VPN-økta, og neste person på eininga finn ei utdatert adresse utan eigar. Hald endringa innanfor VPN-en, appen eller administrasjonslaget som eig avviket, og les deretter augneblinksbiletet på nytt for å stadfeste at serverlista faktisk vart endra.

Det du vil ha til slutt, er éin appførespurnad knytt til eitt nettverk, ei resolverliste og ein Private DNS-tilstand. Når du kan vise den kjeda, er ei kjend adresse i ei fil ikkje lenger prov for noko.