Android DNS'i doğru okuyun: ağ başına, resolv.conf'ta değil

Android uygulamanız, az önce okuduğunuz resolv.conf üzerinden değil, ağ başına bir çözümleyici üzerinden çözümler. Önce LinkProperties'i, soket bağlamalarını ve Private DNS'i inceleyin.

Cihazda bir kabuk elde edip /etc/resolv.conf dosyasını okursunuz ya da eski bir net.dns1 değerini kazıp çıkarırsınız ve tek bir adres elde edersiniz. Önünüzdeki uygulama tamamen başka bir şey üzerinden çözümler. Güncel bir Android sürümünde çözümleyici ağ başınadır: sistem her Network için bir politika tutar ve bunu isteği yapan sokete uygular. Dosya ve eski özellik artıklardır ve hiçbiri sorgunuzun gerçekte izlediği yolu tanımlamaz.

Bu boşluk, aynı telefondaki iki uygulamanın meşru olarak farklı yanıtlar görebildiği split-tunnel ve Private DNS dağıtımlarında ortaya çıkar. Bu kılavuz yanlış veya eksik çözümlemeden başlar ve ona sahip olan yapılandırmaya doğru geri gider.

Çözümleyici cihaza değil, bir ağa aittir

Android 9 ve sonrasında ad çözümleme, bir soketin bağlı olduğu Network ağına dayanan bir sistem çözümleyicisi üzerinden yürür. Her ağ kendi LinkProperties bilgisini taşır ve bu özellikler yalnızca o ağ için DNS sunucuları listesini, arama alan adlarını ve Private DNS durumunu içerir. Bu modelde, bir dosyadan okuyabileceğiniz cihaz genelinde tek bir listeye karşılık gelen hiçbir şey yoktur.

Bir VPN bölünmeyi apaçık hale getirir. Tünel açıldığında VPN uygulaması, VPN'in kendi ağında kayıtlı DNS sunucuları sağlar; böylece onun üzerinden yönlendirilen uygulamalar bu sunucularda çözümlerken hariç tutulan uygulamalar alttaki ağı kullanmaya devam eder. Tek cihaz, iki yanıt yolu, çelişki yok.

Anlık görüntüyü etkilenen uygulamanın içinden okuyun

Uygulamanın kendisine sorun. Context ve normal android.permission.ACCESS_NETWORK_STATE iznine sahip bir yöntem, sistem özelliklerine dokunmadan anlık görüntüyü okuyabilir:

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 sürecinizin varsayılan ağıdır, cihazdaki tek ağ değildir ve çağıranın kullanılabilir bir varsayılanı yoksa null olabilir. Engellenmiş bir varsayılan VPN bunun olağan nedenidir. isPrivateDnsActive, o ağdaki sorguların TLS üzerinden adlandırılmış bir çözümleyiciye gidip gitmediğini söyler; bu, basit bir UDP 53 yoklamasının size ne göstereceğini değiştirir. API yüzeyi LinkProperties altında belgelenmiştir ve içindeki her değer yapılandırmanın anlık görüntüsüdür, belirli bir sorgunun belirli bir sunucuya ulaştığının kanıtı değildir.

Varsayılan ağ işi yapan ağ olmadığında

Anlık görüntü yalnızca varsayılan ağ için yanıt verir. Bir uygulama sürecini veya tek bir soketi başka bir ağa bağlayabilir; o zaman çözümleme bu seçimi izlerken tanılamanız hâlâ varsayılanı bildirir. Kendi DNS-over-HTTPS çözümleyicisini getiren bir tarayıcı sistem listesine hiç başvurmaz, bu yüzden yanıtları cihazın geri kalanı hakkında hiçbir şey söylemez. Bir iş profili uygulaması, kendi politikası olan ayrı bir kullanıcı altında çalışır. Sunucuları suçlamadan önce bağlamayı kontrol edin.

VPN entegrasyonu işin diğer yarısıdır. Bir dhcp-option DNS satırı OpenVPN profilinde almak ile o adresi Android VPN ağında kaydetmek iki ayrı adımdır ve sunucuya giden eksik bir yol, yanlış bir adres kadar sessizce başarısız olur. Bir geliştirme makinesinden adb shell dumpsys connectivity, derleme buna izin verdiğinde aynı bağlantı özelliklerini ağ başına yazdırır; bu, kod yazmadan listeyi doğrular.

Yapılandırmayı yapmanıza izin verilen tek bir çözümlemeyle karşılaştırın

Özel ad alanında çözülmesi gereken bir ad ile bir genel ad seçin ve iki sonucu da anlık görüntünün yanına yazın: ağ, yapılandırılmış sunucular, Private DNS durumu ve hatanın tam metni. Adlandırılmış bir sunucuya doğrudan sorgu, o sunucunun size yanıt verdiğini kanıtlar; olağan uygulama çözümlemesinin onu seçtiğini kanıtlamaz. Önbellekteki bir yanıt taze bir test değildir, bu yüzden önbelleği boşaltın veya bugün kimsenin sormadığı bir ad kullanın.

Çözümleyici yalnızca belirli bir erişim ağındaki istemcilere hizmet ediyorsa, VPN çıkışından sonra gördüğü şey sonucu belirleyebilir ve bu, onu işleten için bir politika sorunudur; operatörlerin UDP 53'ü engellediğinin kanıtı değildir. Private DNS'in etkin olduğu yerlerde, niteliksiz bir ana bilgisayar adı tasarım gereği reddedilebilirken aynı sunucu genel adlara normal yanıt verir. Özellikleri okumak hangi kipin geçerli olduğunu söyler, böylece paket filtreleri hakkında tahmin yürütmeyi bırakırsınız.

Uyuşmazlığa sahip olan katmanı düzeltin

Genel durumu düzenlemek yerine yukarı doğru çalışın. Uygulama yanlış ağa bağlıysa bağlamayı düzeltin. Profil yanlış DNS seçeneğini getiriyorsa profili düzeltin. Private DNS, çözümleyicisi özel alanınıza hizmet edemeyen bir ağda katıysa bu bir cihaz yönetimi kararıdır, özelliği her yerde kapatmak için bir neden değildir.

Genel çözümleyicileri bir DHCP kancasına veya sistem özelliğine zorlamak, sürekli olaylara yol açan düzeltmedir: özel adlar çözülmeyi bırakır, değişiklik VPN oturumunu atlatır ve cihazdaki bir sonraki kişi sahipsiz, eskimiş bir adres bulur. Değişikliği uyuşmazlığa sahip VPN, uygulama veya yönetim katmanı içinde tutun, ardından sunucu listesinin gerçekten değiştiğini doğrulamak için anlık görüntüyü yeniden okuyun.

Sonunda istediğiniz şey, tek bir ağa, çözümleyici listesine ve Private DNS durumuna bağlı tek bir uygulama isteğidir. Bu zinciri gösterebildiğinizde, bir dosyadaki tanıdık adres artık hiçbir şeyin kanıtı değildir.

İlgili makaleler