Citiți DNS-ul Android corect: pe rețea, nu în resolv.conf

Obțineți un shell pe dispozitiv, citiți /etc/resolv.conf sau scoateți o veche valoare net.dns1, și obțineți o singură adresă. Aplicația din fața dumneavoastră rezolvă prin cu totul altceva. Pe o versiune actuală de Android resolverul este pe rețea: sistemul ține o politică pentru fiecare Network și o aplică socketului care a făcut cererea. Fișierul și vechea proprietate sunt rămășițe, și niciuna dintre ele nu descrie calea pe care a urmat-o de fapt interogarea dvs.

Această diferență apare în timpul implementărilor de split-tunnel și Private DNS, unde două aplicații de pe același telefon pot vedea în mod legitim răspunsuri diferite. Acest ghid pornește de la rezolvarea greșită sau lipsă și merge înapoi la configurația căreia îi aparține.

Resolverul aparține unei rețele, nu dispozitivului

Rezolvarea numelor pe Android 9 și versiunile ulterioare trece printr-un resolver de sistem care se bazează pe Network-ul de care este legat un socket. Fiecare rețea are propriile LinkProperties, iar acele proprietăți conțin lista de servere DNS, domeniile de căutare și starea Private DNS doar pentru acea rețea. Nimic din acel model nu corespunde unei liste unice la nivel de dispozitiv pe care ați putea-o citi dintr-un fișier.

Un VPN face separarea evidentă. Când tunelul urcă, aplicația VPN furnizează servere DNS înregistrate pe rețeaua proprie a VPN-ului, astfel încât aplicațiile rutate prin el rezolvă către acele servere, în timp ce aplicațiile excluse continuă să folosească rețeaua de bază. Un dispozitiv, două căi de răspuns, nicio contradicție.

Citiți instantaneul din interiorul aplicației afectate

Întrebați aplicația însăși. O metodă care are un Context și permisiunea normală android.permission.ACCESS_NETWORK_STATE poate citi instantaneul fără a atinge proprietățile sistemului:

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 este implicitul procesului dumneavoastră, nu singura rețea de pe dispozitiv, și poate fi null când apelantul nu are un implicit utilizabil. Un VPN implicit blocat este motivul obișnuit. isPrivateDnsActive vă spune dacă interogările de pe acea rețea trec prin TLS către un resolver numit, ceea ce schimbă ce vă va arăta o sondă UDP 53 simplă. Suprafața API este documentată la LinkProperties, iar fiecare valoare din ea este un instantaneu al configurației, nu dovada că o anumită interogare a ajuns la un anumit server.

Când rețeaua implicită nu este cea care face treaba

Instantaneul răspunde doar pentru implicit. O aplicație își poate lega procesul sau un singur socket de altă rețea, iar apoi rezolvarea urmează acea alegere în timp ce diagnosticul dumneavoastră raportează în continuare implicitul. Un browser care își livrează propriul resolver DNS-over-HTTPS nu consultă deloc lista sistemului, așa că răspunsurile sale nu spun nimic despre restul dispozitivului. O aplicație de profil de lucru rulează sub un utilizator separat cu propria politică. Verificați legătura înainte de a da vina pe servere.

Integrarea VPN este cealaltă jumătate. Primirea unei linii dhcp-option DNS într-un profil OpenVPN și înregistrarea acelei adrese pe rețeaua VPN Android sunt doi pași separați, iar o rută lipsă către server eșuează la fel de silențios ca o adresă greșită. De pe o mașină de dezvoltare, adb shell dumpsys connectivity afișează aceleași proprietăți de legătură pe rețea când buildul permite, ceea ce confirmă lista fără a scrie cod.

Comparați configurația cu o rezolvare pe care aveți voie să o faceți

Alegeți un nume care trebuie rezolvat în spațiul privat și un nume public, apoi notați ambele rezultate lângă instantaneu: rețea, servere configurate, starea Private DNS și textul exact al erorii. O interogare directă către un server numit dovedește că acel server vă răspunde; nu dovedește că rezolvarea obișnuită a aplicației l-a ales. Un răspuns din cache nu este un test proaspăt, așa că goliți cache-ul sau folosiți un nume pe care nimeni nu l-a interogat astăzi.

Dacă resolverul servește doar clienți dintr-o anumită rețea de acces, ce vede după ieșirea VPN poate decide rezultatul, iar aceasta este o chestiune de politică pentru cel care îl administrează, nu dovada că operatorii blochează UDP 53. Unde Private DNS este activ, un nume de gazdă necailificat poate fi refuzat prin proiectare în timp ce același server răspunde normal numelor publice. Citirea proprietăților vă spune care mod este în vigoare, astfel încât să nu mai ghiciți filtre de pachete.

Reparați stratul căruia îi aparține nepotrivirea

Lucrați în sus în loc să editați starea globală. Dacă aplicația este legată de rețeaua greșită, reparați legătura. Dacă profilul livrează opțiunea DNS greșită, reparați profilul. Dacă Private DNS este strict pe o rețea al cărei resolver nu poate servi zona dumneavoastră privată, aceasta este o decizie de administrare a dispozitivului, nu un motiv de a dezactiva funcția peste tot.

Forțarea unor resolvere publice într-un hook DHCP sau într-o proprietate a sistemului este reparația care nu încetează să cauzeze incidente: numele private nu mai rezolvă, modificarea supraviețuiește sesiunii VPN, iar următoarea persoană de pe dispozitiv găsește o adresă învechită fără proprietar. Păstrați modificarea în VPN, în aplicație sau în stratul de administrare căruia îi aparține nepotrivirea, apoi recitiți instantaneul pentru a confirma că lista de servere s-a schimbat într-adevăr.

Ce doriți la final este o singură cerere a aplicației legată de o rețea, o listă de resolvere și o stare Private DNS. Odată ce puteți arăta acel lanț, o adresă familiară dintr-un fișier nu mai este dovada nimic.