Les Android-DNS riktig: per nettverk, ikke i resolv.conf

Du får et skall på enheten, leser /etc/resolv.conf eller graver fram en gammel net.dns1-verdi, og får én adresse. Appen foran deg løser opp via noe helt annet. På en gjeldende Android-versjon er resolveren per nettverk: systemet holder en policy for hvert Network og bruker den på socketen som sendte forespørselen. Filen og den gamle egenskapen er rester, og ingen av dem beskriver veien forespørselen din faktisk tok.

Det gapet vises under utrulling av split-tunnel og Private DNS, der to apper på samme telefon med rette kan se ulike svar. Denne gjennomgangen starter ved den feilaktige eller manglende oppslaget og jobber bakover til konfigurasjonen som eier det.

Resolveren tilhører et nettverk, ikke enheten

Navneoppslag på Android 9 og nyere går gjennom en systemresolver som tar utgangspunkt i Network-en en socket er bundet til. Hvert nettverk har sine egne LinkProperties, og disse egenskapene inneholder DNS-serverlisten, søkedomenene og Private DNS-tilstanden for bare det nettverket. Ingenting i den modellen tilsvarer én enhetsdekkende liste du kan lese fra en fil.

En VPN gjør delingen tydelig. Når tunnelen kommer opp, leverer VPN-appen DNS-servere som registreres på VPN-ens eget nettverk, slik at apper som rutes gjennom den løser opp mot disse serverne mens utelukkede apper fortsetter å bruke det underliggende nettverket. Én enhet, to svarveier, ingen motsigelse.

Les øyeblikksbildet fra den berørte appen

Spør appen selv. En metode som har en Context og den vanlige tillatelsen android.permission.ACCESS_NETWORK_STATE, kan lese øyeblikksbildet uten å røre systemegenskaper:

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, ikke det eneste nettverket på enheten, og den kan være null når kallekoden ikke har en brukbar standard. En blokkert VPN-standard er den vanlige årsaken. isPrivateDnsActive forteller om forespørsler på det nettverket går over TLS til en navngitt resolver, noe som endrer hva en vanlig UDP 53-probe viser deg. API-flaten er dokumentert under LinkProperties, og hver verdi i den er et øyeblikksbilde av konfigurasjonen og ikke bevis for at en bestemt forespørsel nådde en bestemt server.

Når standardnettverket ikke er det som gjør jobben

Øyeblikksbildet svarer bare for standarden. En app kan binde prosessen eller én enkelt socket til et annet nettverk, og da følger oppslaget det valget mens diagnosen din fortsatt rapporterer standarden. En nettleser som leverer sin egen DNS-over-HTTPS-resolver, spør aldri systemlisten, så svarene sier ingenting om resten av enheten. En arbeidsprofil-app kjører under en separat bruker med egen policy. Kontroller bindingen før du gir serverne skylden.

VPN-integrasjonen er den andre halvdelen. Å motta en dhcp-option DNS-linje i en OpenVPN-profil og å registrere adressen på Androids VPN-nettverk er to separate trinn, og en manglende rute til serveren feiler like stille som en feil adresse. Fra en utviklermaskin skriver adb shell dumpsys connectivity ut de samme lenkeegenskapene per nettverk når bygget tillater det, noe som bekrefter listen uten å skrive kode.

Sammenlign konfigurasjonen med ett oppslag du har lov til å gjøre

Velg et navn som må løses opp i det private navnerommet og et offentlig navn, og noter begge resultatene ved siden av øyeblikksbildet: nettverk, konfigurerte servere, Private DNS-tilstand og den nøyaktige feilteksten. En direkte forespørsel til en navngitt server beviser at den serveren svarer deg; den beviser ikke at det vanlige appoppslaget valgte den. Et bufret svar er ikke en fersk test, så tøm bufferen eller bruk et navn ingen har spurt om i dag.

Hvis resolveren bare betjener klienter fra et bestemt tilgangsnettverk, kan det den ser etter VPN-utgangen avgjøre utfallet, og det er et policy-spørsmål for den som driver den, ikke bevis for at operatører blokkerer UDP 53. Der Private DNS er aktivt, kan et ukvalifisert vertsnavn avvises ved design mens samme server svarer offentlige navn normalt. Å lese egenskapene forteller hvilken modus som gjelder, så du slutter å gjette på pakkefiltre.

Reparer laget som eier avviket

Arbeid oppover i stedet for å redigere global tilstand. Er appen bundet til feil nettverk, reparer bindingen. Leverer profilen feil DNS-alternativ, reparer profilen. Er Private DNS strengt på et nettverk der resolveren ikke kan betjene den private sonen din, er det en beslutning for enhetsadministrasjonen og ikke en grunn til å slå av funksjonen overalt.

Å tvinge offentlige resolvere inn i en DHCP-krok eller en systemegenskap er reparasjonen som stadig forårsaker hendelser: private navn slutter å løses opp, endringen overlever VPN-økten, og neste person på enheten finner en utdatert adresse uten eier. Hold endringen innenfor VPN-en, appen eller administrasjonslaget som eier avviket, og les deretter øyeblikksbildet på nytt for å bekrefte at serverlisten faktisk ble endret.

Det du vil ha til slutt, er én appforespørsel knyttet til ett nettverk, en resolverliste og en Private DNS-tilstand. Når du kan vise den kjeden, er en kjent adresse i en fil ikke lenger bevis for noe.