Android-DNS richteg liesen: pro Netzwierk, net an der resolv.conf

Du kréis eng Shell op dem Apparat, lies /etc/resolv.conf oder gräfs en ale net.dns1-Wäert eraus, an du kréis eng Adress. D’App virun dir löst iwwer eppes ganz Aneres op. Op enger aktueller Android-Versioun ass de Resolver pro Netzwierk: de System huet eng Richtlinn fir all Network a wendt se op de Socket un, deen d’Ufro gemaach huet. D’Fichier an déi al Eegeschaft sinn Iwwerreschter, an keng vun deenen zwee beschreift de Wee, deen deng Ufro tatsächlech geholl huet.

Dës Lück weist sech beim Rollout vu Split-Tunnel a Private DNS, wou zwee Appen op demselben Telefon legitimerweis verschidden Äntwerten gesinn kënnen. Dëse Wierkgank fänkt bei der falscher oder fehlender Opléisung un an schafft sech zréck bis zu der Konfiguratioun, déi se besëtzt.

De Resolver gehéiert zu engem Netzwierk, net zum Apparat

Nummopléisung op Android 9 a méi geet iwwer en Systemresolver, deen sech op d’Network stützt, un dat eng Socket gebonnen ass. All Netzwierk dréit seng eege LinkProperties, an déi Eegeschaften enthalen d’DNS-Serverlëscht, d’Sichdomänen an de Private-DNS-Zoustand just fir dat Netzwierk. Näischt an deem Modell entsprécht enger apparatwäiter Lëscht, déi s du aus enger Fichier liese kanns.

Eng VPN mécht d’Opdeelung evident. Wann den Tunnel eropkënnt, liwwert d’VPN-App DNS-Serveren, déi um eegene Netzwierk vun der VPN registréiert sinn, soudatt Appen, déi duerch se geroutet ginn, géint déi Serveren opléisen, während ausgeschlossen Appen d’Netzwierk drënner weider benotzen. Een Apparat, zwee Äntwertweeër, keen Widdersproch.

D’Momentopnam aus der betraffener App eraus liesen

Fro d’App selwer. Eng Method mat engem Context an der normaler Berechtegung android.permission.ACCESS_NETWORK_STATE kann d’Momentopnam liesen, ouni Systemeegeschaften unzepaken:

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 ass den Default fir deng Prozess, net dat eenzegt Netzwierk um Apparat, an et kann null sinn, wann den Uruffer keen brauchbaren Default huet. Eng blockéiert VPN als Default ass de üblechen Grond. isPrivateDnsActive seet dir, ob Ufroen op deem Netzwierk iwwer TLS zu engem benannte Resolver ginn, wat ännert, wat eng einfach UDP 53-Probe dir weist. D’API-Uewerfläch ass ënner LinkProperties dokumentéiert, an all Wäert dran ass eng Momentopnam vun der Konfiguratioun an net de Beweis, datt eng bestëmmten Ufro en bestëmmten Server erreecht huet.

Wann den Defaultnetzwierk net deen ass, deen d’Aarbecht mécht

D’Momentopnam äntwert just fir den Default. Eng App kann hire Prozess oder eng eenzeg Socket un en anert Netzwierk binden, an dann follegt d’Opléisung deem Choix, während deng Diagnos nach ëmmer den Default mellt. En Browser mat sengem eegene DNS-over-HTTPS-Resolver freet d’Systemlëscht guer net, soudatt seng Äntwerten näischt iwwer de Rescht vum Apparat soen. Eng Aarbechtsprofil-App leeft ënner engem separate Benotzer mat eegener Richtlinn. Kontrolléier d’Bindung, ier s du de Serveren d’Schold gëss.

D’VPN-Integratioun ass déi aner Hallschent. Eng dhcp-option DNS-Linn an engem OpenVPN-Profil ze kréien an déi Adress um Android-VPN-Netzwierk ze registréieren sinn zwee getrennte Schrëtt, an eng fehlend Route zum Server feelt grad esou stëll wéi eng falsch Adress. Vun enger Entwécklungsmaschinn aus dréckt adb shell dumpsys connectivity déi selwecht Linkeegeschaften pro Netzwierk of, wann de Build et zouloosst, wat d’Lëscht bestätegt, ouni Code ze schreiwen.

Vergläich d’Konfiguratioun mat enger Opléisung, déi s du däerfst maachen

Wiel en Numm, dee bannent dem private Nummraum opléise muss, an een ëffentlechen Numm, a notéier béid Resultater niewent der Momentopnam: Netzwierk, konfiguréiert Serveren, Private-DNS-Zoustand an den exakten Feelertext. Eng direkt Ufro un e benannte Server beweist, datt dee Server dir äntwert; se beweist net, datt déi gewéinlech Applikatiounsopléisung hien erausgesicht huet. Eng gecächte Äntwert ass keen frëschen Test, also eidel de Cache oder benotz en Numm, deen haut nach kee gefrot huet.

Wann de Resolver just Clienten aus engem bestëmmten Zougangsnetzwierk servéiert, kann dat, wat hie nom VPN-Egress gesäit, d’Resultat entscheeden, an dat ass eng Richtlinnsfro fir dejenen, deen en bedreift, keen Beweis, datt Ubidder UDP 53 blockéieren. Wou Private DNS aktiv ass, kann en net-qualifizéierten Hostnumm aus Design verworf ginn, während deeselwechte Server ëffentlech Nimm normal beäntwert. D’Eegeschaften ze liesen seet dir, wéi ee Modus gëllt, soudatt s du ophalen, iwwer Paketfilter ze raden.

Reparéier d’Schicht, déi de Mismatch besëtzt

Schaff no uewen, amplaz globalen Zoustand ze beaarbechten. Wann d’App un dat falscht Netzwierk gebonnen ass, reparéier d’Bindung. Wann de Profil déi falsch DNS-Optioun liwwert, reparéier de Profil. Wann Private DNS strikt ass op engem Netzwierk, deem säi Resolver deng privat Zon net ka servéieren, dann ass dat eng Entscheedung vum Apparatemanagement an keen Grond, d’Funktioun iwwerall auszeschalten.

Ëffentlech Resolver an en DHCP-Hook oder eng Systemeegeschaft ze forcéieren ass d’Reparatur, déi ëmmer nees Tëschefäll verursaacht: privat Nimm léisen net méi op, d’Ännerung iwwerlieft d’VPN-Sessioun, an déi nächst Persoun um Apparat fënnt eng verouderte Adress ouni Besëtzer. Halt d’Ännerung bannent der VPN, der App oder der Management-Schicht, déi de Mismatch besëtzt, a lies duerno d’Momentopnam nach eng Kéier, fir ze bestätegen, datt d’Serverlëscht wierklech geännert huet.

Wat s du am Enn wëlls, ass eng App-Ufro, verbonne mat engem Netzwierk, enger Resolverlëscht an engem Private-DNS-Zoustand. Soubal s du déi Kette weise kanns, ass eng bekannten Adress an enger Fichier kee Beweis méi fir eppes.