Læs Android-DNS korrekt: per netværk, ikke i resolv.conf

Du får en shell på enheden, læser /etc/resolv.conf eller graver en gammel net.dns1-værdi frem, og får én adresse. Appen foran dig opløser via noget helt andet. På en aktuel Android-version er resolvere per netværk: systemet holder en politik for hvert Network og anvender den på den socket, der stillede forespørgslen. Filen og den gamle egenskab er rester, og ingen af dem beskriver den vej, din forespørgsel faktisk tog.

Det gab viser sig under udrulning af split-tunnel og Private DNS, hvor to apps på samme telefon med rette kan se forskellige svar. Denne gennemgang starter ved den forkerte eller manglende opslagning og arbejder baglæns til den konfiguration, der ejer den.

Resolveren hører til et netværk, ikke til enheden

Navneopløsning på Android 9 og nyere går gennem en systemresolver, der tager udgangspunkt i det Network, som en socket er bundet til. Hvert netværk bærer sine egne LinkProperties, og disse egenskaber indeholder DNS-serverlisten, søgedomænerne og Private DNS-tilstanden for netop det netværk. Intet i den model svarer til én enhedsdækkende liste, som du kan læse fra en fil.

En VPN gør opdelingen tydelig. Når tunnelen kommer op, leverer VPN-appen DNS-servere, der registreres på VPN'ets eget netværk, så apps, der rutes gennem den, opløser mod disse servere, mens udelukkede apps fortsat bruger det underliggende netværk. Én enhed, to svarveje, ingen modsætning.

Læs øjebliksbilledet inde fra den berørte app

Spørg appen selv. En metode med en Context og den normale tilladelse android.permission.ACCESS_NETWORK_STATE kan læse øjebliksbilledet uden at røre systemegenskaber:

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 din proces, ikke det eneste netværk på enheden, og den kan være null, når kalderen ikke har en brugbar standard. En blokeret VPN-standard er den sædvanlige grund. isPrivateDnsActive fortæller, om forespørgsler på det netværk går over TLS til en navngivet resolver, hvilket ændrer, hvad en almindelig UDP 53-probe viser dig. API-fladen er dokumenteret under LinkProperties, og hver værdi i den er et øjebliksbillede af konfigurationen og ikke bevis for, at en bestemt forespørgsel nåede en bestemt server.

Når standardnetværket ikke er det, der udfører arbejdet

Øjebliksbilledet svarer kun for standarden. En app kan binde sin proces eller en enkelt socket til et andet netværk, og så følger opslagningen det valg, mens din diagnostik stadig rapporterer standarden. En browser, der leverer sin egen DNS-over-HTTPS-resolver, spørger slet ikke systemlisten, så dens svar siger intet om resten af enheden. En arbejdsprofil-app kører under en separat bruger med egen politik. Kontrollér bindingen, før du bebrejder serverne.

VPN-integrationen er den anden halvdel. At modtage en dhcp-option DNS-linje i en OpenVPN-profil og at registrere adressen på Androids VPN-netværk er to separate trin, og en manglende rute til serveren fejler lige så stille som en forkert adresse. Fra en udviklermaskine udskriver adb shell dumpsys connectivity de samme linkegenskaber per netværk, når buildet tillader det, hvilket bekræfter listen uden at skrive kode.

Sammenlign konfigurationen med et opslag, du må foretage

Vælg et navn, der skal opløses i det private navnerum, og et offentligt navn, og notér begge resultater ved siden af øjebliksbilledet: netværk, konfigurerede servere, Private DNS-tilstand og den præcise fejltekst. En direkte forespørgsel til en navngivet server beviser, at den server svarer dig; den beviser ikke, at den almindelige app-opslagning valgte den. Et cachet svar er ikke en frisk test, så tøm cachen eller brug et navn, som ingen har spurgt efter i dag.

Hvis resolveren kun betjener klienter fra et bestemt adgangsnetværk, kan det, den ser efter VPN-udgangen, afgøre udfaldet, og det er et politikspørgsmål for den, der driver den, ikke bevis for, at operatører blokerer UDP 53. Hvor Private DNS er aktivt, kan et ikke-kvalificeret værtsnavn afvises efter design, mens den samme server svarer offentlige navne normalt. At læse egenskaberne fortæller, hvilken tilstand der gælder, så du holder op med at gætte på pakkefiltre.

Reparér det lag, der ejer afvigelsen

Arbejd opad i stedet for at redigere global tilstand. Er appen bundet til det forkerte netværk, reparér bindingen. Leverer profilen den forkerte DNS-indstilling, reparér profilen. Er Private DNS strengt på et netværk, hvis resolver ikke kan betjene din private zone, er det en beslutning for enhedsadministrationen og ikke en grund til at slå funktionen fra overalt.

At tvinge offentlige resolvere ind i en DHCP-hook eller en systemegenskab er den reparation, der konstant forårsager hændelser: private navne holder op med at opløses, ændringen overlever VPN-sessionen, og den næste person på enheden finder en forældet adresse uden ejer. Hold ændringen inden for den VPN, app eller administrationslag, der ejer afvigelsen, og læs derefter øjebliksbilledet igen for at bekræfte, at serverlisten faktisk blev ændret.

Det, du vil have til sidst, er én appforespørgsel knyttet til ét netværk, en resolverliste og en Private DNS-tilstand. Når du kan vise den kæde, er en velkendt adresse i en fil ikke længere bevis for noget.