Läs Android-DNS korrekt: per nätverk, inte i resolv.conf

Du får ett skal på enheten, läser /etc/resolv.conf eller gräver fram ett gammalt net.dns1-värde, och får en adress. Appen framför dig löser via något helt annat. I en aktuell Android-version är resolvern per nätverk: systemet håller en policy för varje Network och tillämpar den på socketen som gjorde förfrågan. Filen och den gamla egenskapen är rester, och ingen av dem beskriver den väg din fråga faktiskt tog.

Den klyftan syns vid utrullning av split-tunnel och Private DNS, där två appar på samma telefon legitimt kan se olika svar. Den här genomgången börjar i den felaktiga eller saknade uppslagningen och arbetar bakåt till konfigurationen som äger den.

Resolvern tillhör ett nätverk, inte enheten

Namnuppslagning i Android 9 och senare går via en systemresolver som utgår från det Network som en socket är bunden till. Varje nätverk bär sina egna LinkProperties, och dessa egenskaper innehåller DNS-serverlistan, sökdomänerna och Private DNS-läget för just det nätverket. Inget i den modellen motsvarar en enhetsövergripande lista som du kan läsa från en fil.

En VPN gör uppdelningen tydlig. När tunneln kommer upp levererar VPN-appen DNS-servrar som registreras på VPN:ens eget nätverk, så appar som dirigeras genom den löser mot dessa servrar medan uteslutna appar fortsätter använda det underliggande nätverket. En enhet, två svarsvägar, ingen motsägelse.

Läs ögonblicksbilden inifrån den drabbade appen

Fråga appen själv. En metod som har en Context och den vanliga behörigheten android.permission.ACCESS_NETWORK_STATE kan läsa ögonblicksbilden utan att röra 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 är standardnätverket för din process, inte det enda nätverket på enheten, och det kan vara null när anroparen inte har någon användbar standard. En blockerad VPN-standard är det vanliga skälet. isPrivateDnsActive berättar om frågor på det nätverket går över TLS till en namngiven resolver, vilket ändrar vad en vanlig UDP 53-probe visar. API-ytan är dokumenterad under LinkProperties, och varje värde i den är en ögonblicksbild av konfigurationen och inte bevis för att en viss fråga nådde en viss server.

När standardnätverket inte är det som gör jobbet

Ögonblicksbilden svarar bara för standardnätverket. En app kan binda sin process eller en enda socket till ett annat nätverk, och då följer uppslagningen det valet medan din diagnostik fortfarande rapporterar standardnätverket. En webbläsare som levererar sin egen DNS-over-HTTPS-resolver rådfrågar aldrig systemlistan, så dess svar säger inget om resten av enheten. En arbetsprofil-app körs under en separat användare med egen policy. Kontrollera bindningen innan du skyller på servrarna.

VPN-integrationen är den andra halvan. Att ta emot en dhcp-option DNS-rad i en OpenVPN-profil och att registrera adressen på Androids VPN-nätverk är två separata steg, och en saknad rutt till servern misslyckas lika tyst som en felaktig adress. Från en utvecklingsmaskin skriver adb shell dumpsys connectivity ut samma länkegenskaper per nätverk när bygget tillåter det, vilket bekräftar listan utan att skriva kod.

Jämför konfigurationen med ett uppslag du får göra

Välj ett namn som måste lösas i det privata namnområdet och ett publikt namn, och anteckna båda resultaten bredvid ögonblicksbilden: nätverk, konfigurerade servrar, Private DNS-läge och den exakta feltexten. En direkt fråga till en namngiven server bevisar att den servern svarar dig; den bevisar inte att den vanliga appuppslagningen valde den. Ett cachat svar är inte ett färskt test, så rensa cachen eller använd ett namn som ingen frågat efter i dag.

Om resolvern bara betjänar klienter från ett visst åtkomstnätverk kan det den ser efter VPN-utgången avgöra utfallet, och det är en policyfråga för den som driver den, inte bevis för att operatörer blockerar UDP 53. Där Private DNS är aktivt kan ett okvalificerat värdnamn avvisas enligt design medan samma server svarar publika namn normalt. Att läsa egenskaperna säger vilket läge som gäller, så du slutar gissa på paketfilter.

Reparera lagret som äger avvikelsen

Arbeta uppåt i stället för att redigera globalt tillstånd. Om appen är bunden till fel nätverk, reparera bindningen. Om profilen levererar fel DNS-alternativ, reparera profilen. Om Private DNS är strikt på ett nätverk vars resolver inte kan betjäna din privata zon, är det ett beslut för enhetshanteringen och inte ett skäl att stänga av funktionen överallt.

Att tvinga in publika resolvers i en DHCP-hook eller en systemegenskap är reparationen som ständigt orsakar incidenter: privata namn slutar lösas, ändringen överlever VPN-sessionen, och nästa person på enheten hittar en inaktuell adress utan ägare. Håll ändringen inom VPN:et, appen eller hanteringslagret som äger avvikelsen, och läs sedan ögonblicksbilden igen för att bekräfta att serverlistan verkligen ändrades.

Det du vill ha till slut är en appförfrågan knuten till ett nätverk, en resolverlista och ett Private DNS-läge. När du kan visa den kedjan är en välbekant adress i en fil inte längre bevis för någonting.